The IAG Server 2007 is known for the flexibility to allow access from anywhere to the internal resource in a secure manner. However, if you are really thinking about security there is a key pillar called “Authentication”. The good part about the IAG is that it allows all this flexibility and customization to access internal resource while it is compatible with many authentication providers, such as:
· Active Directory
· Novell Directory
· Notes Directory
· and others…
This article is going to explain how to configure Secure LDAP as an authentication method to use on IAG Server 2007.
2. Preparing the LDAP Server
If your LDAP Server is a Windows Server 2003 Domain Controller, than you just need a couple of more steps in order to conclude the configuration. Pretty much what you need is to install the Certificate Services and follow the article below to create a Domain Controller Certificate:
Processing Domain Controller Certificates
But, if you need to request a certificate from a third party, make sure to use the article below that has the standard for this type of certificate:
How to enable LDAP over SSL with a third-party certification authority
First thing after install the certificate in the DC, is to make sure that you can connect to Secure LDAP (TCP port 636) from the IAG. To test that real quickly you can use the utility LDP.exe from MS Windows Server Support Tools. Open it and type the server name and port, like the figure below:
Figure 1 – LDP.exe utility.
When you establish the connection the result will vary with the one below, but the items in red should be the ones that you should pay attention:
ld = ldap_sslinit("dallas.contoso.com", 636, 1);
Error <0x0> = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, LDAP_VERSION3);
Error <0x0> = ldap_connect(hLdap, NULL);
Error <0x0> = ldap_get_option(hLdap,LDAP_OPT_SSL,(void*)&lv);
Host supports SSL, SSL cipher strength = 128 bits
Established connection to dallas.contoso.com.
Retrieving base DSA information...
Result <0>: (null)
Getting 1 entries:
After confirm that the access can be done, let’s configure the IAG Server.
3. Creating a New Authentication Repository
To create a new authentication repository follow the steps below in the IAG 2007 Configuration interface:
1) Open the IAG 2007 configuration console, expand the HTTPS Connection and click in Portal Trunk.
2) In the Security & Networking session, click in the Configure button besides the Advanced Trunk Configuration option.
3) Click in the Authentication tab and the window below will appear:
Figure 2 – Advanced Trunk Configuration window.
4) Click in the Add button under the Select Authentication Servers.
5) In the Authentication and User/Group Servers, click Add button.
6) In the Type field, choose Active Directory. For the purpose of this example I’m going to use the example below:
Figure 3 – Add Server window.
7) Click in the OK button and then OK again.
8) Activate the configuration.
The authentication repository is already created, now you just need to use this repository in the application publishing that you have.
Note: on this scenario the IAG 2007 is member of the CONTOSO domain.
This troubleshooting session will cover the scenario below:
The administrator gets the error message below when tries to configure the secure LDAP repository on IAG Server 2007:
Figure 4 – Error message when try to configure the Secure LDAP.
4.1. Gathering Data
Since this error message is really generic, at least the following items should be checked up front:
· Name resolution: check if the DNS can correctly resolve the LDAP Server’s name.
· Connectivity: review the network connectivity between the IAG Server and the LDAP Server. If there is any firewall in between the IAG and the LDAP Server, make sure that the TCP port 636 is allowed.
If those items are correct them a good start is get a netmon trace from the IAG Server while creating the LDAP Repository. Let’s see the netmon trace of this scenario:
LDAP Server: 10.1.1.6
IAG Server: 10.1.1.5
1. First thing that we see is the handshake for port 636 on the destination server:
10.1.1.5 10.1.1.6 TCP TCP: Flags=.S......, SrcPort=1116, DstPort=ldap protocol over TLS/SSL (was sldap)(636), Len=0, Seq=876287887, Ack=0, Win=65535
10.1.1.6 10.1.1.5 TCP TCP: Flags=.S..A..., SrcPort=ldap protocol over TLS/SSL (was sldap)(636), DstPort=1116, Len=0, Seq=3489137283, Ack=876287888, Win=16384
10.1.1.5 10.1.1.6 TCP TCP: Flags=....A..., SrcPort=1116, DstPort=ldap protocol over TLS/SSL (was sldap)(636), Len=0, Seq=876287888, Ack=3489137284, Win=65535
2. That’s good sign. We can see that we are able to reach the destination server on the TCP port 636 and it is answering. Continuing the analyses you see that both parties start to talk in encrypted mode:
10.1.1.5 10.1.1.6 SSL SSL
Tcp: Flags=...PA..., SrcPort=1116, DstPort=ldap protocol over TLS/SSL (was sldap)(636), Len=45, Seq=876287888 - 876287933, Ack=3489137284, Win=65535 (scale factor not found)
10.1.1.6 10.1.1.5 SSL SSL
Tcp: Flags=....A..., SrcPort=ldap protocol over TLS/SSL (was sldap)(636), DstPort=1116, Len=1460, Seq=3489137284 - 3489138744, Ack=876287933, Win=65490 (scale factor not found)
3. This is also good; this means that we were able to establish the SSL connection. But then you start to see unencrypted LDAP traffic moving between the parties.
IAG Server sends the bind request:
10.1.1.5 10.1.1.6 LDAP LDAP: Bind Request, MessageID: 5, Version: 3
Ldap: Bind Request, MessageID: 5, Version: 3
LDAP Server successfully accepts the bind request:
10.1.1.6 10.1.1.5 LDAP LDAP: Bind Response, MessageID: 5, Status: Success
Ldap: Bind Response, MessageID: 5, Status: Success
IAG Server sends a search to check the CA for the certificate:
10.1.1.5 10.1.1.6 LDAP LDAP: Search Request, MessageID: 6, BaseObject: CN=Dallas,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com, SearchScope: base Object, SearchAlias: neverDerefAliases
Ldap: Search Request, MessageID: 6, BaseObject: CN=Dallas,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com, SearchScope: base Object, SearchAlias: neverDerefAliases
LDAP Server fails to answer this request:
10.1.1.6 10.1.1.5 LDAP LDAP: search Result Done, MessageID: 6, Status: Operations Error
Ldap: search Result Done, MessageID: 6, Status: Operations Error
4. After that the IAG Server unbinds and finishes the connection:
10.1.1.5 10.1.1.6 LDAP LDAP: Unbind Request, MessageID: 7
10.1.1.5 10.1.1.6 TCP TCP: Flags=F...A..., SrcPort=1117, DstPort=LDAP(389), Len=0, Seq=3029917969, Ack=3581929819, Win=65340 (scale factor not found)
5. At this point, the following message is logged in the application log of the IAG Server:
Event Type: Error
Event Source: Schannel
Event Category: None
Event ID: 36882
Time: 10:46:47 AM
The certificate received from the remote server was issued by an untrusted certificate authority. Because of this, none of the data contained in the certificate can be validated. The SSL connection request has failed. The attached data contains the server certificate.
Note: this message is controlled by the registry key below:
Value Name: EventLogging
Data Type: REG_DWORD
To see the warning and error messages you should use the value 0x0003. For more information review the KB260729.
Now things start to make more sense. We are failing during that time because we don’t trust the CA that issues the certificate that the LDAP Server is using. To fix the issue we have to import the trusted CA certificate (.CER file) to the Trusted Root Certificate container on the IAG Server.
Here the steps to import the CER file to the IAG Server:
1) Open MMC.
2) Click Add/Remove Snap in.
3) Click Add and then choose Certificates.
4) Click in Add and chose the Computer Account, click in Finish.
5) Click in Close and OK.
6) Expand the Trusted Root Certificate/Certificates.
7) Right click in Certificates and choose All Tasks / Import.
8) Click Next and then browser the .CER file
9) Choose the file, click in Next and choose Browse.
10) On the Select Certificate Store window, click in Show Physical Stores and choose the following one:
Trusted Root Certification Authorities / Local Computer
11) Click OK / Next and then Finish.
After doing that, we were able to correctly establish the Secure LDAP connection and now the netmon trace looks like this:
10.1.1.5 dallas.contoso.com SSL SSL
dallas.contoso.com 10.1.1.5 SSL SSL
10.1.1.5 dallas.contoso.com KerberosV5 KerberosV5: AS Request Cname: administrator Realm: contoso.com Sname: krbtgt/contoso.com
dallas.contoso.com 10.1.1.5 KerberosV5 KerberosV5: AS Response Ticket[Realm: CONTOSO.COM, Sname: krbtgt/CONTOSO.COM]
10.1.1.5 dallas.contoso.com KerberosV5 KerberosV5: TGS Request Realm: CONTOSO.COM Sname: ldap/dallas.contoso.com
dallas.contoso.com 10.1.1.5 KerberosV5 KerberosV5: TGS Response Cname: Administrator
dallas.contoso.com 10.1.1.5 TCP TCP: Flags=....A..., SrcPort=ldap protocol over TLS/SSL (was sldap)(636), DstPort=1107, Len=0, Seq=1502064533, Ack=2667167371, Win=65535 (scale factor not found)
This article explained how to create a Secure LDAP repository for authentication purpose on IAG 2007. The troubleshooting session described a common approach to check where the issue is occurring. Since the error message in this case is very generic, you could potentially see the same error message, and the root cause for the problem is different.
1. Introduction Last article about authentication repository I explained how to create a LDAPS repository
Section 2, just after Figure 1, you say: "but the items in red should be the ones that you should pay attention" What is it about those errors that we need to do to resolve?
You need to verify if the:
- Target FQDN is correct, it will only work if it matches with the cert.
- Port number (636)
- Cipher in use is supported between client and server
- Connection was correctly estabilished