I have a Windows 2000 Server that is sitting on external DMZ that is accessible by our clients only. I need to join this Server to our Windows 2000 Domain. I put static translations, alias command and all appropriate rules. However, whenever I am trying to join the domain it tryes to make a connection to internal ip address not the nated address. It seems like it is bypassing NAT commpletely. The DNS is pointing to the NATED ip address of Win2k server and I am able to telnet to the port 53. I
Where is it picking up the real IP from? Have you set up the static and access-list? Why do you use alias? What does show log/syslog indicate what is going on?
I believe that you may have to open up tcp port 445 as well for windows 2000. In Windows NT 4.0, Windows Internet Name Service (WINS), and Domain Name System (DNS), name resolution was accomplished by using TCP port 134. Extensions to CIFS and NetBT now allow connections directly over TCP/IP with the use of TCP port 445. Both means of resolution are still available in Windows 2000 (will use which ever is faster). It is possible to disable either or both of these services in the registry.
Hope it helps.
When I try to connect to Win2k Domain Controler from DMZ I see in the logs that the Win2k Machine is hitting not a natted Win2k address eventhough I have a static nat and I know that it work because I can telnet to port 445,53 and 383. However, for some reason Win2k Box wants to talk to the real ip(internal ip) and not the nated ip of the Domail controller
Why not make it a static with no nat (ie let it connect to it's real IP) and nat everything else on your inside?
global (vendor) 20 10.216.15.90 netmask 255.255.255.0
nat (vendor) 20 0.0.0.0 0.0.0.0 0 0
static (inside,vendor) 10.216.20.7 10.216.20.7 netmask 255.255.255.255 0 0
I'm not sure if you running Active Directory or not but if thats case and you're doing address translation (other than nat 0) it will brake kerberos authentication. That happens because IP header will change after translation and does not match anymore with address included in Kerberos ticket.
And if you need replicate AD over firewall ,replication port should fixed otherwise you need to change you access-lists to swiss cheese.
Mickey soft AD documentation says Kerberos is not compatible with NAT and that is one reason you should not use NAT with replicated W2K enviroment otherwise .............lots of troubles.
make sure you open up
445 (TCP) - Server message block (SMB) for Netlogon, LDAP conversion and distributed file system (Dfs) discovery.
3268 (TCP) - LDAP to global catalog servers.
389 (TCP, UDP) - Lightweight Directory Access Protocol (LDAP).
135 (TCP) - EndPointMapper.
123 (TCP) - Windows Time Synchronization Protocol (NTP).
88 (Transmission Control Protocol [TCP], UDP) - Kerberos authentication
53 (Transmission Control Protocol [TCP], User Datagram Protocol [UDP]) - Domain Name System (DNS).
I know what the problem is but I do not know how to fix it. When Win2k Server is trying to join Win2k domain it looks at dns and in DNS the domain controlers are defined with real ip addresses not the nated ip address. When I do nslookup and
_ldap._tcp.FQDN where FQDN represents the domain controller's FQDN I get a listing of my domain controlers real ip address and that is why Pix is droping packets. I do not know if there is work around this issue since I need to use nat to go from a lower security lever to a higher security level. And accourding to microsoft AD with Nat does not work
If you use static to original source address it should work.
this will work fine static (inside,DMZ1) 192.168.0.2 192.168.0.2 but if you use
static (inside,DMZ1) 192.168.1.3 192.168.0.2 , it will broke Kerberos ticket even you can get DNS working. We did some testing in our project and came into same problem as you have now. You certainly will have some connections problems with AD replicated DNS if translated addresses are used.
Microsoft have released a good article on placing a Server into a firewalled DMZ. This may assist you in what ports to open and how Microsoft recommends that you set up the server in the DMZ. Link to article: