Unable to Initialize TDSE object when using LDAP

Question

I'm attempting to configure Content Manager to authenticate against an OpenLDAP backend. I believe I've followed the docs on configuring LDAP.

When I try to connect I get prompted to authenticate. This appears to succeed, but then I get an error:

Unable to Initialize TDSE object. Access is denied for the user DOMAIN1\USER1.

Error Code: 0x80040302 (-2147220734)

Call stack: Tridion.ContentManager.Security.AuthorizationManager.LoadAccessToken(String,IEnumerable`1,IEnumerable`1) Tridion.ContentManager.Security.AuthorizationManager.LoadAccessToken(IEnumerable`1) Tridion.ContentManager.Security.AuthorizationManager.LoadAccessToken(String,String) Tridion.ContentManager.Session..ctor(String,String,UserContext) Tridion.ContentManager.BLFacade.SystemFacade.InitializeUserContext(UserContext,String,String) UtilitiesTDS.GetUserContext TDSE.Initialize

Tailling the OpenLDAP logs show Content Manager is able to connect and search the directory. The user DOMAIN1\USER1 is in the TRUSTEES table.

I suspect the problem is with my configuration of the LDAP impersonation user. According to the docs:

LDAP uses an LDAP impersonation user to impersonate a user in an LDAP directory.

and

For LDAP authentication, create an impersonation user of type Directory Service and point to the Directory Service used by the Content Manager. The impersonation user name should match the credentials used by the Content Manager SDL Tridion 2011 Application Pool. If this is Network Service, then the impersonation user is NT AUTHORITY\NETWORK SERVICE

My app pool is running as NETWORK SERVICE, does this mean I need to add an impersonation user of type 'directory' for the user NT AUTHORITY\NETWORK SERVICE?

I haven't found much detail on this, can anyone tell me how the LDAP impersonation user is used?

Answer 1

A Tridion impersonation user is a Windows account that is trusted to impersonate any trustee. In addition, if your impersonation user is of type Directory Service, then the configuration settings of the selected directory service will be available for looking up group memberships.

So, yes, it's quite likely that "NT AUTHORITY\NETWORK SERVICE" should be configured as an impersonation user. The default configuration already has this set up. Of course, that means that you must trust any code that runs under that account to be able to "become" any Tridion user in the Trustees table.

Answer 2

The Tridion Configuration Snap-in has 2 settings related to this: 1) Directory Services 2) Impersonation Users

According to your provided snippet from the docs, if you use a Directory Service, the impersonation user that you configure must be an authentic user in your Directory Service, and should be the same user used in the Tridion Directory Service configuration, and same user used for running the app pool.

What user do you have configured for OpenLDAP?:

It should be the same user configured under Impersonation Users:

And it should be the same user configured to run the App Pool.

If this doesn't work, then submit a ticket to Support. They'll definitely sort you out.

Answer 3

After a couple of days head scratching, I managed to make it work. As it turned out the problem was a typo in the TRUSTEES table.

For the benefit of anyone else struggling to configure LDAP, here's a few notes on how it was set up:

The SDL Tridion 2011 Application pool is running as NetworkService, so under impersonation users I have NT AUTHORITY\NETWORK SERVICE with type: directory.

In the Directory Services configuration, the search account is set to an account which can connect to OpenLDAP and search the directory. In this test environment, this is cn=admin,dc=domain1,dc=com.

DOMAIN1\USER1 is a user in the OpenLDAP directory, it's also in the database TRUSTEES table.

In addition there are some changes to be made to enable the Content Manager site to authenticate against the LDAP server. These are documented in the manual, so I won't repeat them here.

As for what the LDAP impersonation user is used for - I believe what happens is that if I try and log in as DOMAIN1\USER1 to Content Manager, then the LDAP impersonation user (NT AUTHORITY\NETWORK SERVICE in my case), impersonates the directory user (DOMAIN1\USER1) and attempts to initialize TDSE object using those credentials. This is where it was failing. Because of the typo in the TRUSTEES table, that user was not allowed access.