Rob's Tech Fun and Games

As a follow up query to the previous notes on working with the PeoplePicker and ADAM, I’ve been asked about the behaviour of the PeoplePicker – specifically, that it appears to only return external users if their username is specifically searched for, not if part of their name is entered.  Is there a way to get exactly the same results for users from AD and ADAM?  Unfortunately, there are pretty severe limits to this, and unfortunately, I don’t believe you can actually get the same results, though I’d love to be proven wrong.

By default, when dealing with custom authentication sources, including ADAM, the PeoplePicker only returns exact matches.  If I search for the username, it will find it.  If its a user already on the site collection, it can use the local user details.  However, to find non exact matches in a custom repository, you need to edit the WebConfig file, by adding the following section:

<PeoplePickerWildcards>
  <clear />
  <add key=”ADAMMembership” value=”*” />
</PeoplePickerWildcards>

Unfortunately, this solution isn’t perfect.  It effectively adds the wildcard symbol * to every search in the people picker.  Lets illustrate this step by step, using a Pat Smith as an example name.

If I search for “Pat”, before updating the web.config file, they’ll only appear with the full name in the results if they’ve already been added to the site somewhere, or if they’re actually in the Active Directory repository.

If I search for “Pat” after updating the web.config file, all the Pats from the ADAM repository and from AD will appear.   Problem solved?  No.

If I search for Smith, as a surname, I’ll get all the Smiths from AD, but not from ADAM.   Thats because the search going to ADAM is actually like “Smith*”.  It’ll find everything starting with Smith, not all names containing Smith, and I haven’t come across any variations that will actually resolve this search issue.  However, you’ll probably find that this is a significant step forward in any event.

As always with SharePoint, make sure you edit all of the relevant web.config files.  You may find SharePoint is happier if you run

iisreset -noforce

after making the change, although in theory you shouldn’t need to - as a rule of thumb, major changes to web applications within SharePoint can have odd consequences otherwise.

One of the comments on my PeoplePicker post asked some questions about the way PeoplePicker works with ECTS – the External Collaboration Toolkit for SharePoint.  To be honest, I haven’t worked with the ECTS myself, but I understand the theory.

The ECTS uses Microsoft’s ADAM – Active Directory Application Mode – to act a a user repository, which gives you a SharePoint structure that should resemble the following:

External Collaboration Toolkit for SharePoint Architecture

Getting the PeoplePicker to work correctly with this is difficult, but not impossible.  The question asked was what could cause the PeoplePicker to fail to return AD users when logged in as an external user?   Of course, as is often the case with comments on blogs, there really isn’t anywhere near enough information about the setup to answer accurately.

My first guess would be that the PeoplePicker has actually been deliberately configured that way.  It is a potentially huge security risk to allow external users to see all the usernames of your company, which is why many people using ADAM authentication run the following command:

stsadm -o setproperty -url https://<url> -pn peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode -pv yes

This command deliberately stops PeoplePicker returning internal AD users when logged in via forms based authentication outside of windows, including using ADAM.  You can tell if this is turned on by running:

stsadm -o getproperty -url https://<url> -pn peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode

If this is the problem, you can turn the security feature off by running:

stsadm -o setproperty -url https://<url> -pn peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode -pv no

And your PeoplePicker should leap back into life for all users.

However, there are still some quirks with using the PeoplePicker with ADAM, even if AD users are allowed to respond.  Take a look at Matt Morse’s excellent blog on how the PeoplePicker returns different results from ADAM than you might expect if you are used to working with normal windows authentication.

EDIT:-

As always, after applying stsadm commands to your SharePoint installation, don’t forget to either reset IIS or the relevant application pool.