Windows 2000 domain authentication "up hill" on a PIX

[patrick.peters]

As part of setting up our Outlook Web Access (for Exchange 5.5) server in our DMZ, we're opening ports as described in Microsoft TechNet articles Q179442 and Q259240. We've created a static to bring one of our domain controllers into the DMZ's address space and set up access lists to allow only the ports described in the Q articles to access the domain controller. Everything seems to be configured correctly.

Here's the rub: We've set up a member server in the DMZ and are trying to join it to the domain. The member server contacts the domain controller (at its DMZ address) and starts the process. However, DNS records relating to the domain structure (like the location of the LDAP and Kerberos servers) are coming back untranslated. When the member server tries to take the next steps in joining the domain, it uses the *real* IP addresses of the domain controllers (not the static translated addresses in the DMZ). It seems like the PIX should have done a fixup on these addresses (translating the answer of the DNS query), but it didn't. The attempt to join the domain fails miserably.

Because Windows 2000 uses DNS in many new ways, I'm guessing that the member server wasn't querying for A records. For example, I think the location of the LDAP server is in an SRV DNS record. Is the PIX smart enough to do fixups on these other kinds of DNS records? Is there some other way to solve this problem?

The documentation for Outlook Web Access clearly states that the server must be a member of the domain where the mailboxes exist. I don't like that, but I can't change it.

All suggestions are welcome.

Thanks!

Pat

[dwhitis]

Check out the "alias" command.

Also, remember that you can always setup a static translation to the real ip....static (inside, dmz) 10.10.10.1 10.10.10.1. That way the IP's are always the same.

[eenest]

The best approach I can recommend:

1. On the OWA box use internal DNS - the one that has all AD records.

2. On PIX configure static to the internal network - i.e. OWA should be able to contact internal LAN using the "real" addressing (no NAT).

3. Restrict access from OWA server to internal LAN with proper access-lists bound to the DMZ interface. You shlould enable only traffic that is absolutely needed while blocking all the rest.

4. Be VERY careful in what traffic you allow FROM OWA (i.e. originated from the server). Probably you'll need to block everything with the source address of OWA and with the destination that is anywhere on the Internet except for the reply traffic. This can prevent the situation when your server can be used to attack someone else (in the event it's compromized).

5. You can use access-list filtering on the Ethernet interface in Windows 2000 as well - that really works and not just for RAS. In reality most NT admins never use that. My personal experience tells me that right-of-the-box Windows 2000 (even without the patches that you SHOULD install) has ENOUGH tools to make it well-secure. Use them!

Hope that helps.

-- Eugene