We set up ldap.domain.com (ports 389 and 636) on our hardware load balancer, forwarding the LDAP requests on to our Active Directory domain controllers. It works just fine for most of our applications. We did find that it failed with some applications, however, because our domain controllers were performing an “LDAP referral,” referring the LDAP client initially connecting to “ldap.domain.com” to instead use “domain.com.” Normally, LDAP requests to “domain.com” would work correctly in an Active Directory environment thanks to how Active Directory populates DDNS (courtesy of those “same as parent folder” A Records, and Domain Controllers respond in a Round Robin fashion to requests sent to the domain name). However, in our environment, “domain.com” points to our web servers via our load balancer so that users can simply type “domain.com” into their web browsers. The LDAP requests were simply being referred to something that couldn’t answer them.
We received some advice to use the standard ports 3268 and 3269 for clear-text and encrypted LDAP traffic, respectively, instead of 389 and 636 because AD would not do an LDAP referral when accessed via these ports. This worked. What might also work is configuring the hardware load-balancer (in our case) to divert port 389 and 636 traffic to the domain controllers while still sending port 80 traffic to our web servers.
Allowing additional ports 445, 139, 137, etc. through to the DCs also allowed us to set up our domain-based DFS namespace successfully. Attempts at doing this had previously failed with the error “The namespace cannot be queried. The RPC server is unavailable.” Allowing these same ports through to the DCs also allows Mac OS X Lion (10.7) clients to connect to these domain-based DFS Namespaces/shares. Their attempts to connect to the DFS domain-based namespace failed with “There was a problem connecting to the server “domain.com”. The server may not exist or it is unavailable at this time.”
Giving your AD domain name to your web servers in DNS can cause other problems beyond the above. We’ve so far been able to overcome any issues created by this design, but it would be better not to have this setup in the first place.