RE: [ActiveDir] DMZ to Internal LAN one-way trust via firewall

[Roger Seielstad]

Least wrong way to do it is indeed continue with an upgrade to have a second forest in the DMZ, without any trusts.   I'd also suggest a different operations model, one in which the developers have no elevated permissions to the production environment. Take it from much personal experience that no good can come from that situation. They need to develop and test against a staging environment, and then let the operations staff promote the changes into the production systems.   I completely understand that its unrealistic to expect that culture change to happen over night, however. So, I'd insist on them having different accounts (i.e. no trust), to help drive home the point that this is a special set of systems.   Roger -------------------------------------------------------------- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc.   From: Creamer, Mark [mailto:[EMAIL PROTECTED] Sent: Friday, May 07, 2004 4:33 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] DMZ to Internal LAN one-way trust via firewall Hi Al, good rant J   I think I can elaborate a bit…We can’t use the separate forest idea that you mention as a best practice, because it’s not a 2000 or above domain (the one in the DMZ). In fact, my first question was why don’t we upgrade it first (as its own forest, of course).   The goal is that we have developers who manage the content and apps on these web servers, and we’re trying to eliminate the accounts in the domain in the DMZ. So we’re trying to see if there is a good way to allow the developers to use their internal AD accounts to authenticate to the DMZ domain via a one-way trust.   Anything more specific on what risks we’d face? (e.g. would it be possible with a one-way trust for a person who breaks in to an account in a DMZ domain to then cross over into the other domain on the other side of the firewall?)   Is there a “least wrong” way to do this?   <mc> -----Original Message----- From: Mulnick, Al [mailto:[EMAIL PROTECTED] Sent: Friday, May 07, 2004 3:55 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] DMZ to Internal LAN one-way trust via firewall   <shudder>   So, if I read this correctly, somebody wants to put lipstick on a pig?  My first question is why?  My second question is also why?  Why would you ever want to have authentication handled inside your firewall for web servers?  Why would you want to put in a single point of failure only relying on the PDCe?  Why would you want to fly in the face of best practices (use separate forests internal and external?)   IPSec is something that would be nice to have if they had a 2000 forest out there, but then again, see above.    Overall, I'd say that this is a bad idea for many reasons including the single point of failure (what if your PDCe goes down?), the lowered security possibilities of NT4 etc.  Hacking NT 4 is not going to provide much of a challenge to most script kiddies these days, IMHO.  Opening ports from a DMZ to your internal network doesn't buy anything but convenience in this situation and since it flies in the face of good practices, I hate to see it running.   Fix your BAS DMZ domain permissions and upgrade it to 2003 AD for control purposes.    The PPTP that he's asking about is available in Win2K and above, but for Win2K it doesn't work at start up.  That would only be shared secret vs. kerberos negotiation.    </rant>   From: Creamer, Mark [mailto:[EMAIL PROTECTED] Sent: Friday, May 07, 2004 2:43 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] DMZ to Internal LAN one-way trust via firewall L & G, I'm sending this on behalf of one of our project engineers. Thanks for any assistance or advice.   1.  We have a 12-server (mostly 2000 web servers) NT 4.0 domain in our Checkpoint firewall-protected DMZ subnet.  All support is currently a mess of local and domain users, no security policy, etc. Making it a Workgroup isn't a popular choice given the number of servers and differences between. 2.  Therefore, we are looking to setup a one-way trust to our internal 2000 AD to support user authentication only.  I've read that the ports necessary for an NT 4.0 -> 2000 trust are the same as an NT -> NT (no LDAP, LDAPS, GC ports necessary), as long as you are pointing to NT4 PDC -> 2000 PDCEmulater.  Question - is this correct?? The list of ports I have is: From-To                                    Client Port(s)                             Server Port Service DMZPDC-IntPDC                         1024-65535/TCP                        135/TCP     RPC  DMZPDC-IntPDC                         137/UDP                                   137/UDP     NetBIOS Name *AllDMZServers-IntPDC               138/UDP                                   138/UDP     Netlogon/Browsing DMZPDC-IntPDC                         1024-65535/TCP                        139/TCP     NetBIOS  **DMZPDC-IntWINS Rep              1024-65535/TCP                        42/TCP      WINS *per article 179442 **optional - read below 3.  I've read both sides of the option regarding name resolution. In our environment, I'm leaning NOT to run WINS Replication across the firewall (use lmhosts instead), since the outside boxes only have to know the name of the internal domain and the PDC emulator, but I'd appreciate anyone's insight on whether or not the risk/benefit is worth the admin overhead of managing 10 different lmhosts files and the potential for single POF?  I've never been a fan of hosts or lmhosts, but it may make the most sense from a security perspective. 4.  I've also read about leveraging PPTP for the trust as well - but have had no luck finding documentation other than the port number. Anyone have any insight? Your assistance in verifying my information is MUCH appreciated.     Mark Creamer Systems Engineer Cintas Corporation Honesty and Integrity in Everything We Do