Configure Tridion 2011 LDAP integration

Authentication in Tridion 2011 SP1 can be done several ways; you can use local Windows accounts, install Tridion with an Active Directory user on a server within a domain, or you can use LDAP. The former two are easy to implement, but LDAP can give you some headaches. This post will explain the steps needed to configure LDAP authentication in the Tridion configuration files and MMC snap-in and also describe ways to tackle problems.

Required LDAP settings

The first thing to do is verify if all required connection details for the LDAP server are available. You will need:

• The LDAP server address and port number;
• Know if SSL is required and install the server’s certificate if needed;
• The Distinguished Name (DN) and password for the LDAP search account;
• Configure firewall rules that allow access from the Tridion CME Server to the LDAP server.

To verify if all settings are correct you can use an LDAP client to connect to the LDAP server, such as ldp.exe available on Windows Server installations or an external tool such as Softerra’s LDAP Browser. Do this on the Tridion CME machine so you immediately identify if the connection to the LDAP server isn’t blocked by firewalls. When connected search for the Organizational Unit (OU) that contains all users you want to authenticate. Pick one user and find the Username Attribute and User Description Attribute. Also note the User Base DN and Group Base DN, as you will need this to configure LDAP in the MMC snap-in.

Configuring Tridion for LDAP authentication

The Tridion installation manual gives a good overview of all the steps needed to configure LDAP authencation in Tridion. The steps are basically the following:

1. Configure IIS for Anonymous Authentication, so authentication is handled by Tridion;
2. Change the web.config files located in the web subfolder, WebUI\WebRoot subfolder, and webservices subfolder of the Content Manager root location;
3. Configure Directory Service in the Tridion MMC snap-in;
4. Configure an Impersonation User
5. Restart Tridion services, COM+ Application and IIS. Tip: for a quick way to restart Tridion services see my previous post on installing a Tridion 2011 PowerShell profile.

Steps 1 and 2 are well described in the Tridion 2011 manual (login required). The following screenshot is an example of the Directory Service window.

Some tips and tricks about the Directory Service settings:

• The Directory Service Name is used to identify the Directory Service and can’t be changed afterwards.
• In my experience with Tridion 2011 the Group base DN must be filled even when Group Sync isn’t enabled, else authentication will fail.
• The domain separator is mostly a colon, but on Windows environments it also can be a back-slash. When you’re not sure what to use and you’re migrating an existing Tridion installation you can take a look in the trustees table in the Tridion CM database. The domain separator and Directory Service Name are used in the user names column for LDAP users (e.g. Directory Service Name:username or Directory Service Name\username).

Troubleshooting Tridion LDAP

Most LDAP implementations are pretty straight forward and don’t cause a lot of trouble. But when they do, the following list can help you in troubleshooting the problem:

1. Verify if the LDAP connection from the CME server is possible by using an LDAP browser client and connect to the LDAP server, using the same credentials as configured in the MMC snap-in.
2. Verify if you completed all steps from the manual and restarted the Tridion services, COM+ Application and IIS after changing settings. Tip: for a quick way to restart Tridion services see my previous post on installing a Tridion 2011 PowerShell profile.
3. Use an unencrypted LDAP connection (port 389 without the SSL checkbox checked). By doing this network package contents can be analyzed.
4. Install a network package capture tool. My personal favorite is WireShark. Use this to analyze network traffic and see where things might go wrong. Be sure to specify the “ldap” filter, else your screen will be flooded with package captures.
5. Use Fiddler2 to analyze browser data when visiting the CME. This can give you insight in specific http error messages sent to the browser.
6. When the LDAP server is behind a load balancer, verify if the load balancer isn’t the issue by using an LDAP server name or IP address of one of the LDAP servers in the MMC snap-in.
7. Once I was working on a Tridion 2011 implementation with LDAP integration and the CME interface was terribly slow. User authentication did work, but reloading the CME interface took over 90 seconds. After several extensive sessions with SDL Support we discovered that the problem was in the server name resolving. We checked this by using IP addresses instead of server names in the MMC snap-in. So when dealing with slow CME performance always try to use server IP addresses instead of server names to see if this revolves the problem.
8. Install a second Tridion CME server and configure it for local authentication, using the same database as the CME server configured for LDAP authentication. This way the problem can be pinpointed to a specific authentication method.

When your LDAP implementation still doesn't work create a support ticket with SDL or post a question on the Tridion StackExchange page.