Issue
Why does webNetwork need to be able to talk to a DC that is not on our local network?
Solution
Please see the following article for a complete description on how AD LDAP works:
I've copied the two important pieces from the article:
- Finding a Server
Discusses how when an LDAP enabled DC starts up, it registers itself as being an available LDAP server
- LDAP Referrals
Discusses how referrals work, which is where we run into an issue with webNetwork. When an LDAP enabled DC refers the webNetwork server to another LDAP enabled DC, it will use any one of the DCs that are registered as providing LDAP.
- Finding a Server
The first step that a directory client must take in conducting an Active Directory search is to find an LDAP directory server (in other words, a domain controller) to search against. To find a domain controller, directory clients rely on DNS. When a domain controller starts up, it registers service (SRV) records in DNS that indicate that the domain controller provides LDAP directory services. To locate a domain controller, a directory client performs a DNS query for SRV records of hosts that provide LDAP directory services. For more information about how DNS is used to locate domain controllers, see “DNS Support for Active Directory Technical Reference.”
- LDAP Referrals
When a requested object exists in the directory but is not present on the contacted domain controller, resolution of the object name depends on information that is stored on that domain controller about how the directory is partitioned. In a partitioned directory, by definition, the entire directory is not always available on any one domain controller.
In its Configuration container, every domain controller has information about the other domains in the forest. The objects in cn=Partitions,cn=Configuration,dc=ForestRootDomain are cross-reference objects that contain information that Active Directory uses to construct the directory tree hierarchy. When an operation in Active Directory requires action on objects that might exist in the forest but that are not located in the particular domain that is stored on a domain controller, that domain controller must send the client a message that describes where to continue this action — that is, the client is “referred” to a domain controller that is presumed to hold the requested object.
An LDAP referral is a domain controller’s way of indicating to a client application that the domain controller does not have a copy of a requested object (or, more precisely, that the domain controller does not hold the section of the directory tree where that object would be if, in fact, it exists) and of providing the client with a name of a server that is more likely to hold the object. The client uses the name of the server that is provided in the LDAP referral as the basis for a DNS search for a domain controller. Ideally, referrals always reference a domain controller that does indeed hold the object. However, it is possible for the referred-to domain controller to generate yet another referral, although it usually does not take long to discover that the object does not exist and to inform the client that the object does not exist. Active Directory returns referrals in accordance with RFC 2251.
Clients do not have to know the name or location of a child domain to contact a domain controller in that domain. They can query the root domain and reach the appropriate domain controller by being referred there. Two situations generate this type of domain controller response:
An external referral, in which the base distinguished name of the requested object is not in this directory, but the domain controller holds information about another LDAP directory where the requested object might be found.
A subordinate referral, in which the base distinguished name of the requested object is in this directory, but the directory partition that contains the requested object is not stored locally.
Every domain controller contains information about how the directory is partitioned, and this information can be used in conjunction with DNS to find the Active Directory domain that contains a particular object.
The root issue for webNetwork, is how AD handles the LDAP referrals between the DCs.
- The DC webNetwork is configured to talk to can, and will, tell the webNetwork server to connect to another DC to look for what it wants.
- The DC will pick another DC that is registered as an LDAP enabled DC and tell webNetwork to connect to it.
- Since all LDAP enabled DCs are registered, the DC can, and will, tell the webNetwork server to connect to one that could be malfunctioning, down, or purposely isolated from the webNetwork server.
Thus the only options are:
- Allow the webNetwork loaders to connect to the DC.
- Disable LDAP referrals on the DC webNetwork connects to. This requires the DC to have copies of all objects on it.
- Remove LDAP from the DC.
- Completely remove the DC.
Keywords: Active Directory, AD, DC, Domain Controller, Failover