Setting Up and Troubleshooting LDAPS Authentication in Forefront TMG 2010
Lightweight Directory Access Protocol over SSL (LDAPS) is used in Forefront Threat Management Gateway (TMG) when the decision has been made not to join TMG to the Active Directory domain. LDAP is a protocol used to read and write to Active Directory and, by default, is not secure. LDAPS is secure but requires some extra steps to get it working correctly.
Server Authentication Certificates
The first requirement to get LDAPS set up and working correctly between TMG and your domain is to issue Server Authentication certificates to the DCs. If you have PKI in your environment then it is entirely possible the Domain Controllers already have these. They must be issued to the fully qualified domain name (FQDN) of the DCs. They must be installed in the Local Computer’s Personal certificate store (See Figure 1) and should exist on any DC that you want TMG to use for authentication.
Fig. 1
TMG Must Trust Issuer of the Server Authentication Certificate
The second requirement is that TMG must trust the issuing Certification Authority (CA) of the certificates that were issued in step 1 above. You can export this certificate from the certificate store on your Domain Controller and then import it into TMG’s certificate store. You must install it into the Local Computer’s Personal certificate store on TMG and it should be under the proper branch, which is Trusted Root Certification Authorities (See Figure 2).
Fig. 2
Define the LDAP Servers on TMG
The third thing you will need to configure is an LDAP Server set on your TMG Server. By doing this you are defining which DC or DCs that TMG will used for authentication.
To define the LDAP Servers:
1.) Go into your TMG MMC
2.) Click on the Firewall Policy branch, click on the Tasks tab in the far right pane, and then choose “Configure Authentication Server Settings” (See Figure 3)
Fig. 3
3.) Click on the LDAP Servers tab and choose “Add”
4.) Give your LDAP server set a name
5.) Add any domain controllers you will be using. Keep in mind that the name MUST be the fully qualified name (FQDN) of the DC and you must ensure it is resolvable from TMG.
6.) Type the Active Directory domain name in the appropriate box
7.) Check the “Connect LDAP servers over secure connection” box
8.) Provide valid credentials in the domain in the form domain\username. These credentials will be used to verify the account status of your external users that are accessing your published web sites in TMG.
9.) Create a Login Expression and associate it with the LDAP Server set you just created
The completed LDAP Server set will look similar to Figure 4.
Fig. 4
Configuring 3rd Party Firewalls that Separate TMG from the Domain
The final requirement in getting this to work is that you have to ensure communications between TMG and the Domain Controllers. Companies that decide TMG should not be part of the Active Directory Domain often decide to put TMG in their DMZ and use another firewall to isolate it. You must ensure that the proper rules are in place for proper communication. LDAPS requires TCP Port 636 be open in order to function properly.
Troubleshooting
A quick an easy way to verify that you have all of the requirements in place is to use the LDP.exe tool. It is normally installed by default on your TMG server. To use it, go to a command prompt, and then type ldp. You should see the tool pop up as shown in Figure 5.
Fig. 5
Test the LDAPS connection
1.) Choose “Connection” and then “Connect”
2.) In Server put in the fully qualified domain name of the DC you want to test the LDAPS connection to
3.) Under “Port” put 636
4.) Check the “SSL” Box
See Figure 6
Fig. 6
A successful connection will look like Figure 7.
Fig. 7
An unsuccessful connection will resemble Figure 8.
Fig. 8
If you get an unsuccessful connection attempt, go back through the steps and verify that everything has been done correctly.
Conclusion
In this article I explained how to set up and troubleshoot LDAPS authentication on Forefront TMG. I also showed you how to use the LDP.exe tool to verify that the requirements are correctly in place from the TMG perspective. As always please let me know if this article helped you. Cheers!
Comments
Anonymous
January 01, 2003
Great article Keith, it really helped me, thanks. But you don't say anywhere how to choose the certificate that gets published in TMG. When I request a LDAPS connection I get the private issued certificate instead of the one issued by my CA. And I can't choose a different certificate anywhere...Anonymous
January 01, 2003
Unfortunately I am having similar problems as described above. We get the " LDAP server not responding" alert quite regularly, but in our case all functionality appears to be fine and the LDP test described in this blog is fine too. Any suggestions on finding the root cause for this would be much appreciated! Alternatively, if this is some kind of "false" alert, is it safe to override it in SCOM? Many thanks, GAnonymous
April 25, 2012
Hi Very good post. I've implemented it on my TMG NLB. Normally it works fine. But in the last time when i have checked the log i saw the following Alert Information: "The LDAP server x.domain.local did not respond. If the server is physically reachable and a secure (SSL) connection is required, this event may be caused by failure of the SSL handshake.This event may also occur when the credentials used to connect to the LDAP server to verify the status and change the password of an account are rejected by the server " After a few minutes i have the following Alert Information: "Description: The connection to the LDAP server x.domain.local was restored." I can't understand why it happens. I checked the FW between the TMG's and the DC. I checked the DC, everything semms to work. Also the Certificatas are ok. Wiht the LDP.exe Toll i can successful create a connection. Analysing the network trace with wireshark shows me, that there are no ssl handshake or tcp problems. Have you ever seen this? Do you have any ideas? I'm searching for a solutinos since weeks but I can't find anything. Thank youAnonymous
March 15, 2013
As jr_suisse I'm experiencing exactly the same issue. I have found nothing wrong in the network and TMG is configured correctly. It's the same on two different domains. I have been looking at timeout settings etc., but haven't had luck to figure out what was wrong. And as the warnings comes in the Application Event Log, the user (if logged in) experience a timeout until the Event Log 'Description: The connection to the LDAP server x.domain.local was restored' is logged. If a user is about to logon, they can also experience long login times and the same Event Log is logged, and Again when 'Description: The connection to the LDAP server x.domain.local was restored' is logged the session may even be signed in and the user can browse the SharePoint site, or the timeout was so long that the user need to login Again.- Anonymous
April 01, 2016
@Karsten Hedemann do you found a solution for your problem?
- Anonymous
Anonymous
August 07, 2013
hi, I have two Domain servers lets say Domain1 and Domain2 to connect to TMG, I have Exported and imported the certificates. now there is no issue on certificates. I could authenticate Domian1 users but could not authenticate Domain2 users. I hve tested connectivity as you explained with LDP tool on TMG. I wonder that I got "Cannot open connection" for both Domains on both ports 389 and 636 though I could authenticate DOMAIN1 users. please help what might be reason behind this. FYI, I could see users login attempt on TMG and login success logs on DOMAIN2 DC security logs.Anonymous
January 23, 2015
Hi,
i have two domains in domain trust relationship. Authentication to domain1 works like a charm, authentication to domain 2 causes errors in the TMG-Log: Status: 8240 there is no such object on the server.
but i can connect successfully with ldp.exe to both domains using SSL 636.
I am actually wondering if it is possible to authenticate on two different domains within TMG
Many thanks for any hints
Markus