I currently do this (DMZ domain trusting internal domain) with a PIX, and
the port allowances are far more restrictive than you would think.
Technical corrections inline:
> -----Original Message-----
> From: Mikael Olsson [mailto:[EMAIL PROTECTED]]
>
> netcomm wrote:
> >
> > Hi
> >
> > I was just wondering what are the implications of having a oneway trust
> > relationship between DMZ domain and another domain inside the internal
> > network behind a firewall. ( domain--> NT domains)
>
> Uhm, you mean that you want to have the DMZ domain trust the internal
> domain? (Your message wasn't clear on which way it was, I'll assume
> you mean this way).
>
> In theory, you shouldn't have a problem. However, in practice
> (someone correct me if I'm wrong here), you'll need to open
> up NetBIOS/SMB/DCE/Whatever-its-named-anyway RPC between your
> DMZ servers and your internal network PDC. This means you get
> to allow:
>
> DMZ:any to int:PDC, TCP and UDP 135-139
> DMZ:any to int:PDC, TCP 1024-65535
No, for starters, there is no RPC connection needed, and you only need to
open traffic between the two primary domain controllers. No other DMZ host
will need to authenticate to a DC in the internal network. Pass-through
authentication would only involve cross-domain communication between a DC in
the DMZ and the PDC in the internal. NT hosts do not cross domain lines to
authenticate themselves. So now you are talking about a host-to-host port
allowance. This is what you will need:
DMZ PDC to Internal PDC: TCP 139 NetBios Session
DMZ PDC to Internal PDC: UDP 137 Name Service
DMZ PDC to Internal PDC: UDP 138 Datagram Service
To keep things quiet and as obscure as this arrangement allows, do not allow
any DMZ host to communicate with any internal WINS server. Set up an LMHOSTS
file in the DMZ PDC that resolves the name (and nature (#DOM:DOMAIN_NAME))
of the internal PDC, and make sure that the trust is only one way, with the
internal domain being the trusted one.
> To me, this looks like swiss cheese, and I wouldn't do it if
> I were you.
It's not Swiss cheese, and if the rest of your services are locked down
tight, and your DMZ host passwords are especially difficult (21 char mixed?)
and routinely changed, I would consider that due diligence. One must both
protect _and_ serve.
> On the other hand, I could be completely mistaken
> here; this is only my understanding of how the trust model
> works. I'd _really_ appreciate it if someone more knowledgeable
> about the NT Domain protocol would step in and enlighten us
> all.
No problem.
Dave Shackelford
Network Engineer
IRSC/DBT Online/ChoicePoint
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
