A busy week for MS tools updates, this time it’s ADMT (Active Directory Migration Tool) to be updated for Server 2008 R2.

Important to mention: as previously, it cannot be installed on read-only domain controller (RODC) or on domain controllers running a “Core” version.

Download links as well as extra information:

• MS Download - Active Directory Migration Tool version 3.2
• MS Download - Password Export Server version 3.1 (updated in 2009 for Server 2008, still current for 2008 R2)
• MS Download - Active Directory Migration Tool (ADMT) v3.0 Migration Guide (same remark as above)

Marc

I did not expect to receive so much feedback by mail regarding this (not so fascinating) topic. Not to mention referring sites and so on… This brought the motivation to loop the loop by testing on Windows Server 2008 (SP2) as well as on 2008 R2 in-depth in order to cover the whole stuff.

So in summary, when will PAC signature verification will finally occur?

The table hereunder summarizes possible scenario’s:

Server OS/ Target Application or Service	Server 2003 pre SP2	Server 2003 SP2 and above with extra registry configuration	Server 2008, Server 2008 R2
File & Print Sharing	NO Validation	NO Validation	NO Validation
Exchange Server	Validation	NO Validation	NO Validation
SQL Server	Validation	NO Validation	NO Validation
IIS with application pool identity set to Local System or Network Service	Validation	NO Validation	NO Validation
IIS with application pool identity set to a domain account	Validation	Validation	Validation

So in short, the only difference between Server 2003 and 2008/2008 R2 is that with from 2008, you do not need to modify registry anymore since the default value is inverted.

Once again, the important point here is: if you configure Kerberos on a IIS farm (SharePoint or “simple” ASP.Net), PAC Validation will ALWAYS occur, regardless what you will do to prevent it UNLESS the application is granted and makes use of the right “Act as part of the operating system”.

If the target application is granted seTCB making use of it:

Granting the seTCB privilege is not sufficient because it will be disabled by default until the application effectively requests it. But why would it need it? For various reasons this privilege might be needed by the server application. 2 common usages are described in the sections below.

Protocol transition

Protocol transition is the ability for a server application to delegate user credentials to a back-end service using Kerberos while they were not initially provided under that form by the client.

In clear, this means that a user may be authenticated by a service using non-Kerberos protocols such as Basic, NTLM, Digest and this service, making use of that feature, will transform the credentials in order to propagate them to another server. Example: a user authenticates against SharePoint using NTLM, want to use reporting service while it runs on a 2nd server, the SharePoint server will perform the necessary transition to push (aka “delegate”) the user’s credentials to the SRS server using Kerberos.

IIS MVP Ken Schaefer gives an excellent overview on his blog: IIS and Kerberos Part 5 - Protocol Transition, Constrained Delegation, S4U2S and S4U2P.

Services For User

SU4 extensions are tightly linked to Protocol Transitions. In very very short, they allow, under certain conditions, an application to perform a logon on behalf of a user without knowing his/her password.

This feature is, for example, used in IAM/SSO products such as IBM TAM/WebSEAL or CA SiteMinder

For both technologies, since the user does not initially authenticate using Kerberos, there is no PAC to validate.

OK but finally, why is disabling PAC validation so important?

Well I won’t say it is “so important”. I might help improving performances under some circumstances.

Since, in short, the PAC is verified by the server application before granting a Ticket-Granting-Service (TGS) to the client, it does not occur at every request as long as the TGS remains valid (note: there are some exceptions to this rule). BUT in some case, this initial verification can take some times because 1) the client’s AD is far (in term of network, hops, latency, bandwidth…) from the server’s AD or 2) the client’s AS is too busy. This could therefore give the wrong impression that client to server authentication seem slow while you expect a big boost by switching to Kerberos.

Additional Resources

• MSDN Patterns & Practices - Protocol Transition with Constrained Delegation Technical Supplement
• MSDN Magazine April 2003 - Exploring S4U Kerberos Extensions in Windows Server 2003
• MSDN - [MS-APDS]: Authentication Protocol Domain Support Specification

Marc

A lot of bloggers have published how to configure Kerberos authentication “how-to” on the Internet, many of them focusing on IIS, Asp.Net and subsequently SharePoint. Some report performance boost over NTLM, others described how to disable “PAC Validation” and increase that performance gain even more.

Recently, I was asked to evaluated that configuration, ensure it works as expected and measure the effective gain from an end-user perspective. This post is a quick summary of the findings not subject to NDA.

What is a PAC and what is PAC Validation (actually PAC Signature Verification)

PAC stands for “Privilege Account Certificate”. It is a data structure contained in some Kerberos requests. It actually contains authorization-oriented information’s such as the group membership of an authenticated user, his/her SID (and SID history) as well as other information’s such as user flags or the time when a forced logoff should potentially happen (most are stuffs you usually configure on the “Account” and “Group Membership” tabs of the AD Users and Computers console.

Since the original Kerberos protocol did not cover the “authorization” part while windows had to maintains the compatibility when switching from NTLM to Kerberos, MS had no other choice than implementing a proprietary extension named PAC. Since the PAC travels over the network when users authenticate to servers (and service actually), it may be altered by malicious user able to decrypt it and modify it on the fly. The purpose of PAC Signature Verification is to make sure the PAC is unaltered when it is used by the server/Service for granting access

The verification/validation process takes place between a server and a domain controller of the domain the server belongs to. The server sends over RPC (therefore NOT using the standard Kerberos protocol) a request to the domain controller of the domain it belongs to specify it wants to verify the PAC signature and of-course, includes that signature (not the PAC itself). if the PAC whose signature is to be validated does not belong to the same domain as the server’s domain, the domain controller contacted for that purpose will follow the trust relationship in order to finally located a domain controller for the user’s domain and send the verification request to it. PAC verification is therefore a security feature implemented to prevent malicious alteration of user’s privileges.

Some people indicate that the verification process brings such an overhead to authentication that Kerberos finally becomes less performing, making end-user’s perceive poor performances and therefore behaves like NTLM or Basic (in term of performance, not security of course).

How to disable it (when you can)

There are 2 main scenario’s in which validation will not occur as long as specific conditions are met:

• The server must run as least Windows Server 2003 Service Pack 2, the registry must include the setting “ValidateKdcPacSignature” set to “1” (default on Server 2008) and the server application is a Windows system service (its primary security token actually include the “SERVICE” SID)

• The server application’s identity is granted seTcb privilege (aka Act as part of the operating system) and makes an effective use of it. 

Witnessing the PAC Signature Verification Process

From a technical (read “measurable”) perspective, there are multiple ways to witness the PAC verification process:

1. Use a network traffic analyzing tool such as MS Netmon or Wireshark and look for RPC communications between the server and the DC of its own domain right after the user’s attempted to authenticate against that server. Captured using Netmon 3.3, it would look like this:

From the server to the DC: NetLogonr:NetrLogonSamLogonEx Request, NLRNetrLogonSamLogonEx, Encrypted Data

Reply from the DC: NetLogonr:NetrLogonSamLogonEx Response

2. Enable netlogon logging and look for entries such as hereunder:

07/31 15:56:23 [LOGON] SamLogon: Generic logon of MYDOMAIN.LOCAL\(null) from (null) Package:Kerberos Returns 0x0

3. Enable Kerberos tracing/lsass logging and look for entries such as

396.500> Kerb-Warn: KerbVerifyPacSignature contacting domain MYDOMAIN.LOCAL for user MYUSER

Some noticeable behaviors…

IIS application pools do not run as “service”, they usually logon as “BATCH” BUT their process token will include the “SERVICE” SID if the identity used to run them is “LocalSystem” or “NetworkService”. Since you cannot used these identities when multiple IIS servers are used in a cluster or a “farm”, Kerberos requiring a domain account, there is very little chance (read no chance) for the PAC validation to be disabled.

Accidentally, this gave me the opportunity to witness that when you schedule a batch job under the context of the “NetworkService”, it will actually get the '”SERVICE” SID too!

Although online documentation reports that verification does not occur if the server’s process token holds the seTcb right, this did not seem to be sufficient. The application must explicitly make use of it.Simply granting the right will not lead to preventing PAC validation. This makes sense if you look at the reasons' why seTcb is often granted: it allows to make use of the S4U Kerberos extension which enable, for example, the ability to perform user logon without having to provide any password (!). These extensions are often used in single sign-on solutions or packages and allow easy transitioning of identities. Since in that case, the a new token is “regenerated”, there is no use in verifying a PAC signature

Generally speaking, granting the SeTCB right is something to be cautiously evaluated before implementation because it would allow its holder to perform OS-level operations such as, for example, logging on as a given domain user without knowing his/her password.

(Challengeable) Conclusions

• Disabling effectively PAC Signature Validation is a no-brainer when the server application is running as a Windows system service (MS Exchange Store, File & Print  Sharing, MS SQL Server…). IIS Application Pools are NO Windows system services, they require special care and some scenario will not allow preventing PAC Signature Verification
• Granting the seTcb privilege (aka Act as part of the operating system) is not sufficient per-se to prevent PAC Validation. The server application must effectively make use of the privilege by, for example, making use of MS proprietary Kerberos extensions like Service 4 User (S4U)
• Disabling PAC validation on a SharePoint farm (IIS application pool running with a domain identity instead of Network Service) in order to prevent roundtrip to domain controllers when a user is authenticating against a WFE will not work, unlike stated by many bloggers!
• Finally, Unless the authentication rate is extremely high and/or the server must authenticate users from “remote” domain with high-latency communications, disabling PAC Verification does not significantly improves performances.

More Information (to be decoded and tested properly!)

• Microsoft Open Specification Support Team Blog: Understanding Microsoft Kerberos PAC Validation,
• [MS-PAC]: Privilege Attribute Certificate Data Structure and Kerberos PAC Validation
• MS Support KB: You experience a delay in the user-authentication process when you run a high-volume server program on a domain member in Windows 2000 or Windows Server 2003
• Spencer Harbar’s blog: SDN Session Recap: SharePoint Architecture, Myths & Kerberos
• Spat's WebLog (Steve Patrick): Kerberos PAC Validation… what is it?
• Time Springston AD Blog: Why! Won't! PAC! Validation! Turn! Off!

I would like to thank the Windows security specialist Emmanuel Dreux (www.Ilinfo.fr) for his help and input while deciphering Windows’s internal security behavior as well as my colleague Olivier B for his nearly encyclopedic knowledge of Kerberos on Windows.

I am aware my conclusions may seem to conflict with 1) Some official MS documentation 2) the technical recommendations of highly influential bloggers. Test it careful and feel free to report your findings here!

Marc

First, I’d like to thank all the people who took time to send me their feedbacks, comments or questions regarding my first post about the People Picker in WSS/MOSS.

Now let’s go for the second part, covering the following topics:

• Additional filtering capabilities
• Detailed configuration for each AD scenario
• how people picker is related to authentication and profile import (MOSS only)
• Guidance to optimize people-picker

Once again, it is important to remind you that these posts are covering people picker used exclusively with Windows-based authentication provider.

Additional filtering capabilities or Control

peoplepicker-searchadcustomquery

This setting allows to specify extra criteria to the existing built-in search query. Be very careful when you use this option because the results can be sometimes unexpected or there are no results at all. Moreover, if you target multiple forests or domains, the same criteria will be applied to all targets! It is highly recommended to test and validate your query using LDP.exe, Active Directory Users & Computer “Query” function or any other LDAP-client in order to make sure it behaves as expected.

A real-life usage can be the following: your organization is also working with MS Exchange and you wish to excluded from the people-picker people also hidden from address list. In this case, you can add this extra condition:

• (!msExchHideFromAddressLists=TRUE)

peoplepicker-onlysearchwithinsitecollection

As far as I could experience it, this one’s behavior is rather funny: it will query the target AD as configured by the administrator and then refine the results by comparing them to the users already present in the site collection. So using this option will not really increase query performance since it performs queries against the configured AD anyway and then performs additional operations afterwards.

Typically, it would be used in site collections where membership is highly controlled or in hosting environments.

peoplepicker-activedirectorysearchtimeout

This setting control the timeout option for a query operation against a given target AD. So it is not an overall timeout but a per-target timeout value. So to calculate the maximum time it would take to perform a people picker query, you have to multiple the value set by the number of forests/domains specified.

Increasing the timeout obviously makes sense in a scenario’s where target domain controllers are located behind low-bandwidth/high-latency network connections OR if they are particularly busy (for example, also intensively used by MS Exchange and MS Exchange Clients such as Outlook)

Setsiteuseraccountdirectorypath

This setting is to be primarily used by hosting companies wishing to 1) place all users from a given customer in a given AD container (organizational unit for example) 2) make a site collection or a web application available to that customer and 3) Restricting what users from that customer can see in the people picker to the users present in that container.

The parameter passed in the distinguished name of the organizational unit (example: OU=contoso,ou=customers,dc=litware,dc=local). The parameter is used as the start location for a search (the “base path” in correct terms). if this setting is no set, the base path is always the root of a forest or domain. With the parameter set, it will start at the level of the container specified.

Since the distinguished name contains the name of the domain where the container exists, is does not make a lot of sense to combine this setting with the query of multiple forests/domains since only one will contain the container specified.

Peoplepicker-serviceaccountdirectorypaths

Not really appropriately named, this parameter will do the same as the previous setting but will only apply to Farm administrators. Still mostly applicable to hosting companies, it will usually prevent administrators to be restricted when then want to use the people picker.

Detailed configuration for each AD scenario

OK, my basic assumptions are always the following:

• The SharePoint server performing people picker queries is always member of the domain “avatar.local”
• The application pool identity running used by the sharepoint web application is wheterh “Local System”, “Network Service” or a domain account of “avatar.local”

“Simple” 2-way trust

• Trust type: external or forest
• Trust direction: 2-way

Possible configurations to search "watertribes.local" exclusively

• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local”
• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:watertribes.local”

Possible configurations to search both "avatar.local" and "watertribes.local"

• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;forest:watertribes.local”
• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:avatar.local;domain:watertribes.local"
• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:avatar.local;forest:watertribes.local"
• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;domain:watertribes.local"

“Simple” 1-way trust

• Trust type: external or forest
• Trust direction: 1-way

 

The configurations are identical as for the first scenario except that to search “watertribes.local”, the people picker must provide credentials explicitly

To search "watertribes.local" exclusively

• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local,WATERTRIBES\KATARA,PASSWORD”
• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:watertribes.local,WATERTRIBES\KATARA,PASSWORD”

To search both "avatar.local" and "watertribes.local"

• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;forest:watertribes.local,WATERTRIBES\KATARA,PASSWORD”
• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:avatar.local;domain:watertribes.local,WATERTRIBES\KATARA,PASSWORD"
• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:avatar.local;forest:watertribes.local,WATERTRIBES\KATARA,PASSWORD"
• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;domain:watertribes.local,WATERTRIBES\KATARA,PASSWORD"

Multiple 2-way trusts

• Trust type: external or forest
• Trust direction: 2-way

 

The possible configurations are almost identical to the first scenario except that “firenation.local” must be appended to the list of forest/domains. Examples:

• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local,WATERTRIBES\KATARA,PASSWORD;forest:firenation.local,FIRENATION\ZUKO,PASSWORD”
• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;forest:watertribes.local,WATERTRIBES\KATARA,PASSWORD;forest:firenation.local,FIRENATION\ZUKO,PASSWORD”

Note: some people might say that it is not wise to trust the fire nation but since Zuko is the new fire lord, it should not be a problem anymore.

Multiple 1-way trusts

• Trust type: external or forest
• Trust direction: 1-way

The configuration is the same as above except that explicit credentials must be provided for each trusted forest or domain to be queried:

• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local,forest:firenation.local”
• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;forest:watertribes.local;forest:firenation.local”

Once again, depending on the type of query you wish to use (LDAP or GC), specify domain or forest as prefix)

Forest 2-way trusts

Trust type: forest. By transitivity North will be trusted too

Trust direction: 1-way

In this special case, let’s say that you want the people picker to query both “watertribes.local” and its child domain “North.watertribes.local”. The easiest and most efficient way to proceed is to use the “forest” prefix, this will force the people picker to use the global catalog service to query the whole “watertribe.local” forest, thus including its child domain but this using a single connection and a single query.

• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local”

Finally, if the trust was one-way, simply provide the credentials:

• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local,WATERTRIBES\KATARA,PASSWORD”

Note: if you used the “domain” prefix instead, the query would be limoited to the domain “watertribes.local”

how people picker is related to authentication/authorization and profile import (MOSS only)

I’ve often met people who were convinced that the people picker is impacted by the configuration applied to the Profile Import component present in MOSS SSP’s. This is not the case.

While the people picker is used to define permissions or other element by using AD security principals (users and groups) and storing them in content databases, the profile import is “only” responsible for updating informational properties of those users or groups when they already exist in content databases. The profile import will not “touch” any security-related information or change the way people picker behaves when querying AD.

On the other hand, the people picker is directly linked to the authentication or should I say authorization (to be accurate) mechanism in WSS/MOSS because one a user is authenticated by Windows/IIS, SharePoint will then verify if the authenticated user is authorized to access the page requested. The information being used for that purpose being the user’s token (SID, group membership…).

Another important thing is the relationship between the trust type and the authentication protocol used by Windows. In order to use Kerberos, a forest trust must be in place. On the other hand, an “external” trust (domain-based) will always imply NTLM authentication.

Guidance to optimize people-picker

From a purely SharePoint perspective, there is little you can do to optimize people picker:

• Reduce as much as possible the number of domain or forest to query. If you target multiple domains from the same forest, considered targeting the whole forest instead in a single query
• Do not use extra criteria (customadsearchfilter) or extra processing (onlysearchwithinsitecollection) if possible
• Try not to mix queries against very responsive AD’s and less responsive AD’s (not easy I know) because then the less responsive will impact the whole query process

In combination with the AD administrator, you can improve the performances and availability by:

• Placing a DC of the target domain “close to” the SharePoint server, and put in place the a&appropriate AD topology configuration. Ideally the SharePoint server and the target DC should “see” each other as member of the same Active Directory site even though they do not belong to the same forest (this means naming the sites identically in the resource and the user forests). Generally speaking, low-latency matters more than high-bandwidth in the perception of responsiveness
• Making sure the targeted DC’s are available and responsive (not too busy with other LDAP-oriented operations or near capacity in general)
• It’s a detail, but since DNS resolution is used to reach DC’s, make sure it is also efficient and why not, ideally cached (not too short but not too long, in case of failover to another DC). Of course, the SharePoint server MUST be able to resolves all AD-related domains appropriately. Use suffixes search order wisely and only if necessary

Note: the recommendations above will also be beneficial to authentication mechanisms used by Windows/IIS

Additional information’s

• MS Protocols Documentation - Active Directory: People Picker Browse Display UI
• MS Support KB Article - How to optimize pass-through authentication of user accounts after you create an external trust between two Microsoft Windows Server 2003 Service Pack 1 (SP1)-based forests

Due to the massive feedback of non-infrastructure people (developers…) or people with limited AD skills, I have planned a third post over detailed troubleshooting.

I will also cover the challenges of using Windows Integrated authentication in complex IIS/SharePoint set-up, like for example, cross-forest federated search while preserving security-trimmed search results…

Stay tuned!

Marc

Recently, I’ve been troubleshooting multiple WSS/MOSS implementations experiencing problems with the people picker.

I must confess that only documentation is poor and other blog posts are sometimes unclear to me. I decided to make a digest but comprehensive attempt to document the people picker behavior and configuration in and AD/Integrated Windows Authentication (IWA) configurations. Note: what applies to IWA also applies to Basic, Digest and client certificate mapping authentication: what matters is AD to be the repository for authentication information.

It is therefore critical to correctly understand how AD, domains, forests and trusts are working in order to get your people-picker working correctly (displays what you effectively want to see), rapidly (does not take ages to return a result) and reliably (its behavior is predictable and persistent over time). I am often surprise by the fact that very few SharePoint specialists really know about the windows and AD  internals, this often lead to improper people picker configuration.

How it works, with the default configuration

The people-picker is a SharePoint interface responsible for querying repositories for identities or groups in order to grant them permission in the SharePoint application. It is implemented as part of the WFE role, this means that when you’re using it, the WFE you’re connected to will attempt to contact AD in order to returns items matching your query’s criteria. Here is, step by step, how it exactly works from an AD/Windows point-of-view:

1. A users submit a query to the people-picker
2. The WFE performs a DNS query in order to locate a domain controller hosting the Global Catalog Service. There are actually two possible DNS queries:
3. The first query will include the server’s Active Directory site name, in order to locate a domain controller that reside on the same site or “covers” it (does not reside in the same site but is configured as a candidate to receive request from originating from that site).If that first query succeeds, there’ll be no second.
4. It it fails and the DNS reports that there is no such name, a second query will take place without any reference to the server’s site.
5. with an IP address of a DC in hand, SharePoint will initiate a connection from a local random port to the remote port 3368 (Global Catalog LDAP over TCP) against the select domain controller. This first connection, which is is anonymous, will report to the SharePoint server extra information over the DC it contacted. It will include various LDAP information, the its exact capabilities as well as the authentication mechanism it supports. This entry point is known as the “Root” or “RootDSE”
6. Once SharePoint know how to “talk” to AD, it will perform a query whose part of the parameters are based on the users' input. This query is actually programmatically powered by the System.DirectoryService Namespace. since that query is made against the Global Catalog Service, it can only use a subset of the AD attribute (known as the partial attribute set). the exact list of attributes depends on the Windows version of the DC and on the presence of schema extension (MS Exchange, OCS or custom…). If the AD requires authentication, which is by default the case, SharePoint will authenticate using the context of the IIS application pool the SharePoint web application runs under. It can be Local system or Network Service (then DOMAIN\SERVERNAME$ is used) or a specified user
7. SharePoint displays the results to the user

The query, as stored in the code:

• (&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(name={0}*)(displayName={0}*)(cn={0}*)(mail={0}*)(sn={0}*)(SamAccountName={1}*)(proxyAddresses=SMTP:{0})(proxyAddresses=sip:{0}){2}))", "(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(name={0})(displayName={0})(cn={0})(mail={0})(samAccountName={0})(proxyAddresses=SMTP:{0})(proxyAddresses=sip:{0})))", "(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(mail={0})(proxyAddresses=SMTP:{0})))"), new SearchParameter("(&(objectCategory=group)(|(name={0}*)(displayname={0}*)(cn={0}*)(SamAccountName={1}*)(mail={0}*)(proxyAddresses=SMTP:{0}){2}))", "(&(objectCategory=group)(|(name={0})(displayname={0})(SamAccountName={0})(mail={0})(proxyAddresses=SMTP:{0})))", "(&(objectCategory=group)(|(mail={0})(cn={0})(proxyAddresses=SMTP:{0})))"), new SearchParameter("(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648)(|(name={0}*)(displayname={0}*)(cn={0}*)(SamAccountName={1}*){2}))", "(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648)(|(name={0})(displayName={0})(cn={0})(samAccountName={0})))

The query criteria in clear:

• A user or a group
• If it is user, at least of of the following attribute must begin with the input the user provided: name, displayName, cn, mail, sn, SamAccountName, proxyAddresses (with SMTP or sip)
• It it is a user it must not be disabled
• If it is a group, at least of of the following attribute must begin with the input the user provided: name, displayname, cn, SamAccountName
• if it is a group, it must be a security group (domain local, global or universal), not a distribution group

The following attributes are requested to be returned for each record found:

• objectSID
• mail
• displayName
• title
• department
• proxyAddresses
• cn
• samAccountName
• groupType
• userAccountControl
• distinguishedName

And finally, the following server controls are specified:

• LDAP_PAGED_RESULT_OID_STRING: Page the results and get 20 results per page
• LDAP_SERVER_DOMAIN_SCOPE_OID: Instructs the DC not to generate LDAP continuation references in response to a search operation.

Key points:

• By default, SharePoint only knows about the AD forest its server(s) belong(s) to
• SharePoint uses DC locator DNS records to locate a DC hosting the Global Catalog Service
• It issues a queries using the LDAP-like dialect against that Global Catalog Service using System.DirectoryService Namespace
• There is no “security trimming” per se. The queries returns the results based on what the IIS application pool identity is allowed to see, not the end-user’s identity

Still unclear to me:

• In the case (non default and not recommended), in the case the IIS Application pool runs under the context of a user from another domain, which domain controller of which domain will be used?

Querying Additional Forest or Domains

In this section, I will cover the most frequent configuration: the SharePoint server belongs to a forest and/or domain that has 2-way trusts established with other forests or domain. The accounts of the users accessible SharePoint therefore belong to those trusted domains and since the trust is in both direction, the identity of the IIS application pool is also capable of authenticating against those trusted domains.

In order to instruct SharePoint to query those trusted domain or forests, the command “STSADM.exe -o setproperty -pn peoplepicker –searchadforests” must be used. But it seems like many people are getting confused, for good reasons, with the exact syntax of the parameter to be passed.

first you keep to gather the following information:

• Do you want to query a forest (in this case, you’ll need a forest-trust) or a domain (in this case, an external trust is sufficient)
• What is the DNS name of the forest you wish to query (also the DNS name of its root domain) or what is the DNS name of the

Then, based on the information above, you can assemble the parameter correctly. The configuration of each forest or domain to be queried must be separated with a semi-colon and inside the configuration, the first word must be forest: or domain: and it must be followed by a valid DNS name. Example:

• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:dune.local;domain:carthag.local;domain:tuono.local”

Key points:

• The DC Locator process used with the standard configuration is still applicable BUT is extended beyond the local forest boundaries. This means that the SharePoint servers must be able to resolve names of remote forests/domains domain controllers (SRV records and A records)
• Also, Active Directory Sites should be identically named between forests, otherwise, SharePoint may not target the “closest” domain controller
• If you use “Selective authentication” or “SID Filtering” in order to restrict authentication through trusts, you must make sure that the IIS application pool identity is allowed to authenticate against the remote forest/domain it queries
• Needless to say that if there are firewall between SharePoint and the remote forest/domains, they must be configured adequately
• As I said above,if the “forest” argument is specified, a forest-trust must be in place
• If you still wish to query the forest/domain SharePoint belongs to, you’ll have to add it as part of the parameter too
• If you configure a forest to be queried, it is not necessary to declare all or some child domains separately, they will be queried anyway
• If “forest” is specified, the Global Catalog Service will be used to perform the query, if “Domain” is specified, the LDAP service will be used instead. Global Catalog (GC in short) can query all objects inside a given forest BUT knows only, as stated above, about a limited set of attributes while LDAP knows about ALL attributes but its boundaries is the domain it is targets
• Do not forget to perform IISRESET on each SharePoint server where the configuration must be applied

Still unclear to me:

• I have a great level of certainty that the query against each forest/domain are not performed in parallel, at least not the DNS part

The One-way trust Configuration

This configuration is identical to the above except that since the IIS application pool identity is unable to authenticate against the remote forest/domain due to the limitation set by one-way trust, alternate credentials must be specified. Those credentials must be from the forest/domain to be queried or from a trusted domain, as long as it is allowed to authenticate and is not denied to logon remotely.

The tough part of the job in this case is to apply the configuration.

first, a key must be generated in order to encrypt/decrypt the alternate credentials that will be used, in order to do so, you have to run the command hereunder on every SharePoint server where the people picker will be used (shortcut: do it on all servers!):

• STSADM.exe -o setapppassword -password MYPASSWORD. where MYPASSWORD is the key –> it makes sense that the more complex, the better but is is not ruled by the Windows password policy

Secondly, you have to provide the list of forest/domains to be queried as well as the credentials to do so. Each block is separated by semi-colons and each element in a block is separated by comma. Example:

• STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:dune.local,DUNE\PAULA,PasswordOfPaulA;domain:carthag.local,CARTHAG\Gurney,PasswordOfGurney;domain:tuono.local,TUONO\SHANIA,PasswordOfShania”

Key points:

• Make sure you have valid credentials for each forest/domain
• Make sure each forest/domain element is correctly structured
• Do not forget to perform IISRESET on each SharePoint server where the configuration must be applied

Troubleshooting Tips

Useful tools

• NTLTEST command-line: (part of the windows Server 2008 Support tools or built-in Windows Server 2008)
• Wireshark network capture utility
• LDP.exe simple LDAP client (part of the windows Server 2008 Support tools or built-in Windows Server 2008)
• Active Directory User and computer (ADUC) Console
• ADInsight from MS Sysinsternals (not super reliable alas)

Global Approach

The most straightforward way to trace the behavior of the people picker is to take a network capture while performing the search from the Web GUI, taking care of flushing the DNS resolver cache (ipconfig /flushdns). Take this capture of the WFE your target with your tests and filter the results as follows:

Apply a display filter to show only DNS requests, you should see requests like the following:

If you attempt to query a domain: _ldap._tcp.Site-Name._sites.domain.local: type SRV, class IN (first attempts, in order to locate a DC in the same site) or _ldap._tcp.domain.local: type SRV, class IN (any DC in that domain, regardless of the site)

If you specified to query a forest, you should see _gc instead of _ldap

If you don’t see those DNS request or if you see them but they fail, make sure the SharePoint servers are able to resolve names from remote domains ad are configured with the correct DNS Servers and optionally with a list of suffixes

Once name resolution is working fine, go back to the capture and make sure you see LDAP (port 389) or GC (same as LDAP but on port 3268).

for each domain or forest, you should see a “bindRequest” with a successful response followed by a “seachRequest” followed by a successful response as well. drill-down into the search request for the details about the query submitted: the filter and conditions applied in particular

Retrieving the server’s AD site

Execute the command “NLTEST /dsgetsite”. It should return the AD site the SharePoint server belongs to. If it does not, there is a serious AD configuration problem ;)

Retrieving a DC for a given domain

Execute the command “NLTEST /dsgetdc:mydomain.local

If the list of flags it return includes the following, you’re ok:

• CLOSE_SITE= the DC is in the same AD site as the SharePoint server or is “covering” that site
• LDAP: the DC is LDAP server (all DCs are but must advertise it)
• GC: the DC is also global catalog (NOT all DCs are but if they are, they must advertise it too)

Note: Other information returned by the command might also be useful for troubleshooting: Name and IP address of the DC…

Simple LDAP connection test

1. On the SharePoint server, start ldp.exe

2. Go to the menu “Connection” and click “Connect”. Enter the IP or the host name of the remote DC. You should test with a FQ host name in order to test DNS too. Select port 389 for LDAP or 3268 for GC. If it works, it will return a list of server-related information

3. repeat this test for each DC SharePoint would potentially target

Testing the credentials to connect to a remote domain using LDAP (one-way trust scenario in particular)

If the test above works, proceed to this one:

1. Return to the menu “connection” then click “Bind” then enter the credential of the remote domain to be browsed (including the domain name in the 3^rd textbox

2. If it fails, you’ll see a message such as

res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3

               {NtAuthIdentity: User=’myuser’; Pwd= <unavailable>; domain = ‘mydomain’.}

Error <49>: ldap_bind_s() failed: Invalid Credentials.

3. If it succeeds, it will report

res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3

               {NtAuthIdentity: User=’myuser’; Pwd= <unavailable>; domain = ‘mydomain’.}

Authenticated as dn:’myuser’.

Top People-Picker Reliability/Performance Killers

• The more forest/domains there are two query, the slower it will be to get results
• Problematic Name Resolution Process: In order to resolve DC locator records, Windows will exhaust all possible name resolution methods, from DNS to broadcast… And this for each declared forest/domain
• Unresponsive DC brings major slow down
• Suboptimal/Inconsistence AD Site configuration: Site-awareness is a key factor, this makes sure SharePoint always query the nearest DC
• Network devices/Security devices breaking the TCP traffic: from broken NIC to firewall, anything generating TCP retransmit or “forcibly closing” connections
• Load on Active Directory/Domain controller or security settings on the domain controller (preventing DoS attacks for example)
• If custom filter is used: Improperly written filter: make sure the complexity of criteria remains reasonable, only indexed attributed are queried and of course if the GC is used, only attributed that are part of the partial attribute set

Additional information’s

• MS TechNet LDAP Query Basics
• MS TechNet Select users from multiple forest domains
• MS TechNet Peoplepicker-searchadforests: Stsadm property (Office SharePoint Server)
• MS TechNet Active Directory Trust Types
• MS KB How to query Active Directory by using a bitwise filter
• Joel Oleson Multi Forest/Cross Forest People Picker peoplepicker-searchadcustomquery
• Bill Baer Configuring SharePoint Products and Technologies for Cross-Forest Deployments

What’s next?

In the next posts, I will cover:

• Additional filtering capabilities of LDAP searches
• Detailed configuration for each scenario
• how people picker is related to authentication and profile import (MOSS only)
• Guidance to optimize people-picker in different scenario’s

And cut!