Troubleshooting SharePoint 2010 Claims Based Authentication with Active Directory Lightweight Directory Services (AD LDS)

We recently had a requirement to set up AD LDS for SharePoint authentication. Using AD LDS means you don’t need to create domain accounts in your “real” Active Directory environment, and you can completely limit access to your SharePoint installation. At least, that’s the plan 🙂

Some background info on setting up Forms-Based Authentication with LDAP and AD LDS can be found here:
Configuring Forms Authentication in SharePoint 2010 Using ADLDS
Configuring Forms-Based Authentication for Claims Based Web Applications
Setting Up SharePoint 2010 forms-based authentication for claims based web applications

I created an AD LDS installation using a ‘CN=SharePointDirectory,DC=my,DC=local’ Distinguished Name. I followed the steps on configuring forms based authentication, but when I tried to use the People Picker in SharePoint Central Admin, it found no users and returned the message (in red no less) “No results were found to match your search item. Please enter a new term or less specific term.”

I started with ULS Log Viewer, and found an issue with the filtering of LDAP requests:

LdapRoleProvider.RoleExists() exception: {0}.System.ArgumentException: The (&((ObjectClass=group))(|(cn=)(samAccountName=))) search filter is invalid.
at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext()
at System.DirectoryServices.DirectorySearcher.FindOne()
at Microsoft.Office.Server.Security.LDAP.FindOneObject(DirectoryEntry searchRoot, String filter, SearchScope scope, String[] propertiesToLoad, ResultPropertyCollection& entryProperties)
at Microsoft.Office.Server.Security.LdapRoleProvider.RoleExists(String roleName)

The message implies that the filter “(&((ObjectClass=group))(|(cn=)(samAccountName=)))” was invalid. So I needed to set up my web.config file to ensure that the filter is valid for doing LDAP queries against in the people picker.

To help debug the problem, I dialled up the SharePoint logging by setting the following trace log settings in Central Administration:

SharePoint Foundation – Claims Authentication
SharePoint Server – Shared Services

This displayed the following error in the ULS Log:
LdapRoleProvider.RoleExists() exception: {0}.System.ArgumentException: The (&(((ObjectClass=group)))(|(cn=)(userPrincipalName=))) search filter is invalid.
at System.DirectoryServices.SearchResultCollection.ResultsEnumerator.MoveNext()
at System.DirectoryServices.DirectorySearcher.FindOne()
at Microsoft.Office.Server.Security.LDAP.FindOneObject(DirectoryEntry searchRoot, String filter, SearchScope scope, String[] propertiesToLoad, ResultPropertyCollection& entryProperties)
at Microsoft.Office.Server.Security.LdapRoleProvider.RoleExists(String roleName)

So there is an issue with the LDAP search filter being applied. I then installed Microsoft NetMon 3.4 (Microsoft Network Monitoring Tool) and after creating a new trace set the following trace settings.

You can set the “Current capture filter” by clicking “Capture Settings”:
// Show only LDAP frames, which by default operates on port 389
TCP.Port == 389 or UDP.Port == 389
and
IPV4.DestinationAddress == a.b.c.d // INSERT YOUR IP ADDRESS HERE
or
IPV4.SourceAddress == a.b.c.d // INSERT YOUR IP ADDRESS HERE
and
TCP.Port == 389 or UDP.Port == 389

and you can set the “Display filter” in the capture tab itself:
// Only show frames with LDAP
LDAP

The data seemed to be correct i.e. the LDAP query was being submitted and a reply was returned. The issue seemed to come down to two points:
1. I hadn’t created an object of class “container” in my AD LDS root. I created one and called it “Users”
2. I hadn’t set up my sharepoint central admin user account to the “CN=Readers” object. You can set this via ADSIEdit by clicking on the contain “CN=Roles”, then selecting “member” in the properties and click “Edit”. YOu can then add the users you need to the roles, which would normally be your Farm service account and your web app pool service account

As soon as I made this change, search results from the LDAP server were returned straight away! Other gotchas I found:

– Ensure that the users you create have their password set, as well as the “msDS-UserAccountDisabled” set to FALSE
– Check that your CN is correct to your Users container by right-clicking on the Users container and checking the distinguishedName is the same as your userContainer property in web.config

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: