Rob's Tech Fun and Games » LDAP

More People Picker issues

Rob — Mon, 26 Oct 2009 12:30:23 +0000

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

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

Filtering the SharePoint People Picker Results

Rob — Fri, 24 Jul 2009 10:47:47 +0000

Someone asked in the comments on another post how to filter the responses to the People Picker to only show active users. Its an unusual question, in that “Active Users” is so difficult to define. The People Picker’s default behaviour includes a check to make sure that the account is enabled in Active Directory, so disabled accounts are hidden. Perhaps it means just users, not groups, or just those users granted access to the Site Collection.

I actually favor the option in the people picker to only return users which have been granted permissions on the Site collection. This instantly means users in one site collection don’t know about the existence of others by default, and is easy to implement. Just run:

stsadm -o setproperty –url http:// –pn peoplepicker-onlysearchwithinsitecollection –pv yes

You can add specific users to the site collection by searching for the fully qualified logon name, but the people picker will only return users on the site.

If you need slightly more unusual options though, you’ll need to alter the query itself. It’ll also potentially affect the ability to add any users to the site, so be very, very careful - I’d really recommend not trying this unless you are pretty confident with LDAP queries.

There are several ways of doing this – first, you can set the People Picker to use a custom LDAP query, and select exactly what you need from the AD. The alternative is that you can allow the People Picker to use standard querys, and then filter the result set. You can also restrict queries to a particular OU, which would obviously limit the response.

The first is best if you need to limit the query to a specific OU or search for a custom field flagging people as a SharePoint Site user, but be wanred – performanced on a non indexed field will be appalling. I’d avoid it if possible. The second is better if you need to hide certain user accounts (like service accounts) from the returned queries. The last option is quite neat, but its rare that you structure AD for your SharePoint web applications. Synergy online covers all these options in detail here.

Incidentally, I believe the LDAP query to filter for only active users is:

(&(objectCategory=person)(objectClass=user)(!userAccountControl:1.2.840.113556.1.4.803:=2))

So to only return active users, not groups, you could use the following filter:

stsadm -o setproperty -url http://server/sites/vp-site -pn peoplepicker-searchadcustomfilter -pv “(&(objectCategory=person)(objectClass=user)(!userAccountControl:1.2.840.113556.1.4.803:=2))”

One final note – the AD filter and limiting the queries to an OU are only available from SharePoint SP1 onwards – make sure you’re patched!

Configuring ISA Server 2006 to allow password changes through Forms Based Authentication

Rob — Wed, 13 May 2009 10:28:51 +0000

ISA Server 2006 is a strange, temperamental beast, and often needs to be cajoled into fairly standard functionality. In order to deploy security so that users can authenticate from both the DMZ Active Directory, and the internal network (with a one way trust between the two) you need to deploy LDAP authentication. In order to act as a secure front end and logging point, forms based authentication is recommended, particularly if branded authentication pages are important for you. If you want to use it as a front end to extranet systems, a custom login page is pretty much a necessity, and if you need external users to change their passwords (rather than using code within your extranet or OWA), you’ll need to configure LDAP over SSL (LDAPS).

Before you begin, you’ll need to configure a domain user for ISA server to use to bind to the LDAP server, with rights to make changes if you need password change functionality.

You’ll need to ensure that your active directory domain can support LDAPS. In order to do this, you need to intall certificate services, and ensure that the domain controllers and your ISA server all have server certificates installed, with the certificates matching their fully qualified domain names correctly.

You can find a pretty complete guide here:

http://technet.microsoft.com/en-gb/library/bb794854.aspx

I struggled with a few points – its not clear that for password changes to work, for example, you need to use a user account with the right to make AD changes when defining the LDAP server set, and you don’t in order to simply log users onto the domain. You apparently do in order to change passwords.

You can’t use windows authentication for any domains other than the one that the server is in, even if one way trusts are correctly configured – you really need to use LDAP server sets. Thats not a problem if all of your internal users will access your secure extranet from the internal domain – you could bypass your ISA server and go straight to the web server. However, people will want to give demonstrations, and work on the extranets from outside the office – its up to your policy to determine if this will affect the configuration. Existing SSL VPN solutions might be a better option for your own employees.