Rob's Tech Fun and Games

Tom commented on a post with the following problem, and I thought it merited a post.

“We have a MOSS 2007 FARM AND 3 DOMAINS all have a two way trust.  We have over 78 sites all of which stopped with no known reason from being able to find users that are in one of the domains we can find the users in the view profiles yet we can no longer find users using peoplepicker for any users from the one domain.

We have tried this command you have provided and they come back with commandline error
stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:full domain name,-userlogin domain\username password –url http://webapp url”

It sounds like an interesting problem, but its difficult to answer without more information.  Incidentally, the profiles comment, about being able to view user profiles, is rather a red herring.  This is handled by an import process specified elsewhere in the SSP, and has nothing to do with the People Picker displaying users.

Lets discuss the stsadm command first.   Without knowing the specific error message, I can’t say why the command is failing, but there are two probable outcomes.   stsadm is not generally included in the default path for a windows installation, so if the error message is:

‘stsadm’ is not recognized as an internal or external command, operable program or batch file.

The problem is simply that you need to find the appropriate location first.  The location is generally:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>

so simple change directory to that path, and run the STSADM again.  It sounds obvious, but I must admit, I had a bit of a nightmare trying to find the stsadm path when I first started looking at SharePoint!

The other possibility is that the command has been run, but that the parameters haven’t been entered correctly.  If so, you get the terribly helpful response of :

Command line error.

Followed by a complete syntax reference for the command, and it sounds much more likely that this is the cause of the problem, from the notes in the question.  Unfortunately, this is quite a lot harder to discuss, as unsuprisingly people aren’t going to give the specific command line with all of their configuration details and passwords to be put onto a website, and the generic, censored versions are probably going to be correct, at least as far as it goes.

The best help I can give here is to put together a full hypothetical example, rather than just repeating the command syntax yet again.

Essentially, you first need to set an internal SharePoint encryption key, then tell the server what domains to add to the list, and what valid username and password to use to connect to the domain in order to pull back the list.  Don’t use administrator, btw!!!

To set the initial encryption key, use:

stsadm.exe -o setapppassword -password <yourencryptionkey>

To set the actual domain link, use:

stsadm.exe -o setproperty -url http://domain1.example.com:80 -pn “peoplepicker-searchadforests” -pv “domain:domain1.example.com,domain1\LoginName, P@ssword; domain:domain2.example.com,domain2\LoginName, P@ssword; domain:domain3.example.com,domain3\LoginName, P@ssword“

Of course, with two way trusts a single user name and password could be used if you granted the appropriate rights. 

What normally goes wrong putting this together?  Normally it is either the encryption key hasn’t been set first, or that construction of the domain list has a syntax issue (or that the surrounding quotes have been missed off).

As a rule, though, if you get a command line error when running stsadm, you have got the format wrong.  If the format is right, it won’t necessarily solve the problem (if your username or password is wrong, for example, it still can’t access the other domain information), but you’ll see the changes applied.  A good way of checking is to run:

stsadm.exe -o getproperty -url http://domain1.example.com:80 -pn “peoplepicker-searchadforests”

And it will show the details you’ve set (with passwords asterisked out).

What makes the problem Tom is experiencing interesting is that apparently the People Picker has been working, and now isn’t.  This, to me, implies that something has changed with the installation, or the Active Directory configuration.

Key things to check would be:

Has the system user context still got access rights to the domain that appears to be no longer accessible?  A two way trust means that user rights can be assigned … by default they arent.

Have the active directory servers changed?  If so, you may need to force DNS updates, otherwise resolution against the AD may be looking for defunct servers.

Has the stsadm command been run succesfully in the past, and the usernames and passwords have since changed (or expired)?  This will obviouslly drop off the people pickers ability to query the domain.

Has a security patch been applied against the domain, or has permissions to the Active Directory been changed?  By default, older systems allowed anyone to do a basic LDAP query against the Active Directory, but this was locked down.  If this loophole was previously being used instead of setting correct access rights for the security context of the wep application, it’ll obviously start causing this issue.

I hope this helps – Tom, if you’ve solved the problem, please let me know the solution

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.

After installing SharePoint, and importing all the User Profiles, you’ll find if you are using the People Picker, you’ll only see users from the trusted domain that have successfully logged on the SharePoint 2007 server, rather than all of them.  This is rather bizarre, as you’ve imported all the profiles, and can see them!

You actually need to configure the PeoplePicker to do a lookup to the Domain Controllers, as its here the People looks, NOT the SharePoint user profile store.  It seems unusual, but true!  It’s quite a complex task.

Before you do anything else, work out a list of all of the domains the PeoplePicker needs to look at, INCLUDING the domain SharePoint is installed on.  If SharePoint is on Domain1 and you want to see all the Domain1 users and all the users from the trusted domain Domain2, you’re going to need to list them both, something most of the guides online don’t make clear.  You’ll also need the fully qualified domain names – doing use the older NetBIOS name.  If your domain is exampledomain.local, don’t just use “exampledomain” – we’ll need the full thing.

Next, make sure you have a valid Active Directory user account on each of the domains you want to look at.  You don’t need to worry about the domain the SharePoint server is on – the accounts SharePoint should be running under will already have access.

Now, we first need to set up an encryption key, so SharePoint can securely store the usernames and passwords for the other domains.  Use the following command on every server in the farm – if you don’t, the other SharePoint servers won’t be able to decrypt the stored user names and passwords:

stsadm –o setapppassword –password MyPassword

Replace MyPassword with your chosen encryption key, of course! 

Next, we need to tell each Web Front End server, which domains to use.  I always list the current domain SharePoint is a member of first, for ease of reference.  Normally, I’d expect at least two entries – the current domain and the trusted domain (or domains) – if there isn’t a trusted domain, why are you doing this???.  We’ll need to separate the entries in the domain list with semi-colons.

stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:domain1.com;domain:domain2.com,domain2\user,password –url https://sharepoint.domain1.com

Here, the url should be replaced by that of your web application – don’t forget to use https if you’ve set the application up to use SSL.  Domain names should obviously be replaced with your own, and you should use the usernames and passwords from each domain that you either created or ensured were available earlier.  A more realistic looking example might be:

stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:technet.microsoft.com;domain:kb.microsoft.com,kb\AD_Lookup,LookUp2009 –url https://sharepoint.technet.microsoft.com

Please note this is an entirely hypothetical example, so don’t think of trying the links or usernames! 

Fianlly, though this generally isn’t mentioned in most of the other guides, you need to reset IIS before SharePoint will pick up the changes.  As always, I prefer the noforce option, just in case.

issreset -noforce

You should now see all of the available people from the domains you’ve selected in the people picker!