IAG 2007 Authentication Repository

Article
06/04/2008

1. Introduction

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

· LDAP

· RADIUS

· WinHTTP

· 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

https://technet2.microsoft.com/windowsserver/en/library/d08181ca-4fac-4ca7-8171-b66e9e65606e1033.mspx?mfr=true

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

https://support.microsoft.com/default.aspx?scid=kb;en-us;321051

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)

Matched DNs:

Getting 1 entries:

>> Dn:

…..

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.

4. Troubleshooting

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

Date: 6/4/2008

Time: 10:46:47 AM

User: N/A

Computer: IBIZA

Description:

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:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL

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: