RE: NTLM authentication from DMZ

[Frank Knobbe <fknobbe () knobbeits com>]

On Fri, 2002-09-20 at 01:56, Ben Nagy wrote:
> Well, according to the MS docs [1], you need to open the works to get
> the domain and trust thing to work. Note that the MSKB article also says
> that the OWA box needs to be in the same domain as the Exchange server
> [2](I can't believe that's true - can anyone confirm it doesn't work
> with trusts?). 

I'm not 100% sure, but I think at one installation the OWA server was in
its own domain with a one-way trust to the internal domain. Most setups
I've seen were using the same domain though :(

> Are you saying that you can block nb-session and have everything still
> work? 

Nope. You need to have NetBIOS (or Kerberos) enabled to the domain
controller, but not the whole network[1]. 

> If that's so we're much better off, but I'm not sure I see much
> benefit in this isolated DC in another segment; if not then there's just
> a trivial two step attack via nb-session as soon as a good enough
> password turns up. The only way to stop that would be to have a firewall
> that knew enough about MS NBT to stop file sharing but allow whatever
> else is supposed to run over tcp/139. 

Basically true, and it doesn't help any with password harvesting. But it
is a second step which you may be able to detect much easier. For
example, on that DC you could deny login rights from the network. The
authentication from the OWA box is still passed through, but no one
would be able to login to the box through the network. I know, makes
maintenance a pita, but since you are not running anything on it besides
domain services...

> In theory I know that you
> shouldn't need nb-session at all, but I have distant memories of the
> solution barfing without it - it has, however, been a good few years
> since I was involved in one of these. 

Hehe... yeah, NetBIOS sucks, doesn't it? :)  This is actually where
Kerberos may come in handy (then again, there are flaws in Kerberos that
prevent certain design from implementation, such as the inability to NAT
MS-Kerberos...)

> I guess that's all out of date now anyway, since Exchange 2000 uses
> different ports altogether. I'm no Win2K guru, but SMB over TCP (port
> 445) is on the list of required ports for the 2K solution [3], and
> that's used for accessing SMB shares "without the extra layer of NBT"
> [4]. Presumably you'd need to be able to block that to get this thing to
> work securely with an Exchange 2000 box.

I'm sure Ex2000 will bring it's own set of problems. I don't have much
experience with it since I abandoned Microsoft all together... :)


Cheers,
Frank


[1] This is a footnote just for the heck of it. Seems that everyone is
using those now. :)

Attachment: signature.asc
Description: This is a digitally signed message part