In my post regarding the use of ADAM as a user repository for SharePoint, I gave some basic instructions on the configuration necessary to get SharePoint's PeoplePicker to be able to enumerate users from ADAM. This post contains a little more detail about the specifics of the behavior that Microsoft's LDAP provider provides.

(Note: It's probably safe to extrapolate these comments to other custom authentication providers as well, as the PeoplePicker is set up to interact with the MembershipProvider class, but I haven't tested with anything other than the ADAM provider.)

SEARCHING FOR USERS

Searching for users in the PeoplePicker works differently for custom authentication providers than with Active Directory -- and even differently depending on whether you enter criteria in the "Choose Users" textbox or pop up the "Select People and Groups" window.

First, unless you explicitly specify a wildcard for ADAM to use, the PeoplePicker will look only for an exact match on the user ID. To specify a wildcard, add an entry into the web.config for the web application as shown:

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

Specification of the wildcard will allow the PeoplePicker to perform a "starts with" search -- the wildcard is obviously appended to the search criteria. I haven't figured out a way to get this to be a "contains" search.

For example, I searched on Matt below; note that the PeoplePicker returns one account from Active Directory and two from ADAM. (You can tell this from the Account Name column; any non-AD accounts will be prefixed with the name of the provider.)

However, if I search on my last name, Morse, the results look like this:

Note that in this case, only the Active Directory account is returned. The behavior that's exhibited for the AD accounts seems pretty user-friendly to me; I haven't yet figured out how to get the ADAM accounts to work the same way.

USER DISPLAY 

The PeoplePicker displays account information stored in Active Directory differently than account information coming from the ADAM repository. For example, users with Active Directory accounts login to SharePoint using their qualified username (MYDOMAIN\myusername), while the ADAM accounts need no such qualifier (their context is specified by the zone in which they are authenticating). In the PeoplePicker, however, AD accounts show a "friendly" account name in the Display Name column, while the accounts coming from ADAM show the user ID. (Note the search results in the first screenshot above.)

This difference between a display of the user ID and a friendly name is also seen when the ADAM user logs into the MOSS site: the user context dropdown welcomes the user by username instead of the friendly alias you get with AD accounts.

As far as I can tell this is all controlled by the configuration of the membership definition element in the web.config file.

<add name="ADAMMembership" type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" server="localhost"
port="389"
useSSL="false"
userDNAttribute="distinguishedName"
userNameAttribute="cn"
userContainer="OU=ADAMTest,O=ADAM,C=US"
userObjectClass="user"
userFilter="(ObjectClass=user)"
scope="Subtree"
otherRequiredUserAttributes="sn,givenname,cn" />

Specifically, the userNameAttribute attribute defines which property in the ADAM directory entry for the user will be displayed in the Display Name column of the PeoplePicker. It's also the value that gets displayed in the "Welcome <user>" dropdown in the user interface.

There's only one problem: if you change the value of the userNameAttribute attribute, the forms authentication piece of SharePoint then wants the user to login with this value.

For example, I assigned my ADAM user account to have Matt.Morse as a login (cn property on the directory entry) and I set the ADAM displayName to be Morse, Matt. I then changed the userNameAttribute in my web.config entry to be displayName instead of cn. This caused the PeoplePicker to work closer to how I wanted, and it made the display for the end user more friendly ("Welcome Morse, Matt" instead of "Welcome Matt.Morse").

However, the forms authentication only worked when I logged in with Morse, Matt specified as the username -- not the Matt.Morse user ID that I had assigned the account.

CONCLUSION

I don't know if I've reached much of a conclusion -- other than that I think the implementation of the PeoplePicker for non-AD authentication providers needs a little fine-tuning. There may yet be a good solution, but there's not one that I've found, and the MS documentation and blogs offer little help so far.

My approach for now is going to be to assign ADAM user IDs that are manageable as both user IDs and display names. The "firstname.lastname" pattern isn't beautiful, but it's not horrible either. If users will more likely be searching by last name, I could easily change it to "lastname.firstname" to have the PeoplePicker search be more effective.