Introduction

From time to time someone may want to access your Active Directory Directory Service with LDAP. Usually from a system or location that you view as unsecure or untrustworthy. Examples are printers that do directory lookups to send scanned documents by e-mail and external systems where a provider needs information about your users to provide them service. The querying party is often an open source implementation of an LDAP client. Here is some advice about how to configure such a setup.

Connecting

All Active Directory Domain Controllers provide LDAP over TCP and UDP ports 389, and Secure LDAP (LDAP-S) over TCP port 636, by default. If there is a firewall between your Domain Controller and the connecting system you will have to allow and/or forward the required ports. For any connection you should always use LDAP-S, especially for connections that traverse untrusted networks, e.g. the Internet. For recent versions of Windows Server the host firewall is enabled by default and the inbound rules for LDAP and LDAP-S are automatically enabled when the server is promoted to a domain controller. Depending on your network firewalls you may have to enable Allow edge traversal. You do this from the properties of the rule in the Windows Firewall with Advanced Security console:

Selecting a DC

Choosing which DC the LDAP client connects to is either configured by you or located automatically. A Windows machine that is a member of a domain knows how to find LDAP servers in its domain, which it does by querying DNS. A lot of Active Directory discovery is done by DNS in Windows. A Windows client will typically query DNS for A (host) records for its own domain to find which servers are writable LDAP servers. All RW DCs register an A record for the domain name to indicate they are LDAP servers. Alternatively a Windows client can also query for SRV (service) records for _ldap._tcp.dc._msdcs.<DNS domain name>. The DC Locator component, implemented by the NETLOGON service on a Windows machine performs these queries. When a Windows client wants to log on to a domain it uses SRV records. But the fact that a Windows machine that is joined to a domain can find LDAP servers by using DNS does not mean that an application running on it can do the same, or take advantage of the information found by the DC Locator component. Very often an application that uses LDAP implements its own LDAP configuration and service discovery. Typically LDAP servers are either found by querying DNS for either A, CNAME, TXT or SRV records as specified by you, or LDAP servers a statically configured. If the connecting system is on your internal network then the best option would be for it to use DNS to discover LDAP servers based on the DNS name of the domain. That way the system will continue to function even if you introduce new or retire old domain controllers. If that is not possible try using an A record as an alias; like ldap.<DNS domain name>. The you can statically configure your LDAP client to connect to that name. If any change occurs in your directory service, all you have to do is update the alias. You can even have more than one record for the same alias and DNS will serve them up randomly. If the connecting system is outside your network and does not have access to your internal DNS zones, you are left with statically configuring it using either an IP address or an FQDN which is resolvable outside of your network.

Some more info:

• How Domain Controllers Are Located in Windows
• How Domain Controllers are Located Across Trusts

Certificates

The domain controller needs a certificate to be able to supply LDAP-S. You can in theory use a certificate signed by any authority, including a self signed one, as long as the connecting party either trust the signer or ignores certificate errors. The following KB article goes into details about the specific LDAP certificate requirements for domain controllers:

• How to enable LDAP over SSL with a third-party certification authority

It is not possible to configure a specific certificate for LDAP if there are several to choose from. The aforementioned KB article explains the certificate selection process that the DC uses.

It is also a good idea to provide the connecting party with a base DN from which to start a search, although you cannot stop them from changing it.

Account

After the connection is established the connecting party needs to authenticate to access the directory. The most common form of authentication in this scenario is a username and password combination. Since Active Directory is its own authentication provider you will need to create an account in AD and provide the connecting party with the domain, username and password information. This account will be an implicit member of the Authenticated Users group when it is logged on and thus have the same access rights in the directory as the Authenticated Users principal has. Unless you have changed your directory considerably Authenticated Users will have read access to most of your Active Directory. Changing this is not a trivial task and would require you to change the very basic authorization settings of your directory, and since these settings are enforced on a schedule by the DS you will have to create your own way of making them stay changed.

Any user account you opt to use will also be a member of the Domain Users group. This grants it certain rights in your domain that you might not want such an account to have. For example a member of Domain Users can log on to computers in your domain by power of the fact that Domain Users is a member of the Users group on every member computer in the domain. I recommend creating a new global security group, called NO_PRIVILEGE for example, and add the account to that group, and at the same time removing the account from Domain Users. By doing this you will revoke any permissions Domain Users has from the account. You cannot just remove it from Domain Users, since every user account in Active Directory must have a primary group associated with it. The NO_PRIVILEGE group will  become that new primary group once Domain Users membership is revoked.

Testing

To test if your setup work I recommend an LDAP browser or explorer. Windows includes one called LDP.EXE and it is quite good, but since it cannot ignore certificate errors, it might not work in all scenarios. Here are a couple of alternatives:

• LDAP Admin
  Open Source
• LEX – The LDAP Explorer
  Commercial license

I find that LDAP Admin servers all my needs. It even alerts you to certificate errors and lets you view the certificate and continue if you so choose.

To test if the required ports are open and forwarded you can also use the PortQry utility from Microsoft. Here is an example command to check for LDAP-S:

.PortQry.exe –n <my DC FQDN> -p TCP -e 636

Tip

To ignore certificate errors in LDAP on open source systems I recommend doing a search for TLS_REQCERT and LDAPTLS_REQCERT.