Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem


Leave a comment

Office 365: MS Directory Synchronization Tool Comparison

Introduction

Over time, the number of free tools provided by Microsoft for synchronizing (and sometimes syncing back) on-premises AD and Azure AD has increased up to 3 (not to mention Azure Active Directory Connector for FIM 2010 R2):

  • Directory Sync aka DirSync
  • Azure AD Sync aka AADSync
  • Azure AD Connect aka AADConnect

While the first is apparently set for retirement and the two others would ultimately merge, it is still valuable to have a good idea of their capabilities and constraints before making the right choice for each implementation.

I will later publish the upgrade paths from DirSync to AADConnect.

Tool Comparison

The table hereunder is attempt to compare them as comprehensively as possible. Please note that 95% of credit for this comparison table go to French Directory Service MVP Maxime Rastello. Here is his original French article: DirSync vs Azure AD Sync vs Azure AD Connect : lequel choisir ?

Note: I will try to keep this table as up to date as possible at the following location: Office 365: MS Directory Synchronization Tool Comparison.

Tools Directory Sync
(DirSync)
Azure AD Sync
(AADSync)
Azure AD Connect
(AADConnect)
Capabilities
General
Latest Version Download 1.0.7020.0000
(07/31/2014)
1.0.0494.0501
(05/02/2015)
1.0.628.2
Public Preview 2
(03/20/2015)
Version History TechNet Wiki Article MSDN Article Not Currently Officially Available
Multi-Domain Sync Yes Yes Yes
Multi-Forest Sync No Yes Yes
Filtering by OU Yes Yes Yes
Filtering by Attributes Yes Yes Yes
Customizable Attribute Set Yes But Not Supported Yes Yes
Customizable Sync Rules Yes Yes Yes
Sync On-Premises to Cloud
Users Yes Yes Yes
Contacts Yes Yes Yes
Security Group Yes Yes Yes
Distribution Group Yes Yes Yes
Password Yes Yes Yes
Extended Attributes No No Yes
(Requires Azure AD Premium)
Devices No No Yes
(Requires Azure AD Premium)
Sync Cloud to On-Premises
Users No No Yes
(Requires Azure AD Premium)
Contacts No No Future Release
Security Group No No Future Release
Distribution Group No No Future Release
Password (Write-back) No Yes
(Requires Azure AD Premium)
Yes
(Requires Azure AD Premium)
Office 365 Group No No Yes
(Requires Azure AD Premium)
Devices No No Yes
(Requires Azure AD Premium)
Interoperability
Office 365 UPN Selection Yes But Not Supported Yes Yes
Hybrid Exchange Migration Support Yes But Single-Forest Only Yes But Single-Forest Only Yes
3rd Party LDAP Server Support No No Future Release
Assistance to ADFS Set-up No No Yes
Manageability
PowerShell Cmdlets Yes Yes Yes
Staging Mode No No Yes
Requirements
Hosting Server Operating System Windows Server 2008 64-bit with SP1 or later
Windows Server 2008 R2 with SP1 or later
Windows Server 2012
Windows Server 2012 R2
Windows Server 2008 64-bit with SP1 or later
Windows Server 2008 R2 with SP1 or later
Windows Server 2012
Windows Server 2012 R2
Windows Server 2008 R2 with SP1 or later
Windows Server 2012
Windows Server 2012 R2
Hosting Server .Net Framework v3.5 Service Pack 1
v4.5.1
v4.5.1 v4.5.1
Hosting Server Domain Membership Member Server
Domain Controller
(Same Forest)
Workgroup
Member Server
Domain Controller
Member Server
Domain Controller
(Same Forest)
AD Functional Level Windows Server 2003 or Higher Windows Server 2003 or Higher Windows Server 2003 or Higher
Domain Controller Operating System Windows Server 2003 with SP1
Windows Server 2008 64-bit with SP1 or later
Windows Server 2008 R2 with SP1 or later
Windows Server 2012
Windows Server 2012 R2
Windows Server 2003 with SP1
Windows Server 2008 64-bit with SP1 or later
Windows Server 2008 R2 with SP1 or later
Windows Server 2012
Windows Server 2012 R2
Windows Server 2008 R2 with SP1 or later
Windows Server 2012
Windows Server 2012 R2
Note: SSO with AD FS option requires Windows Server 2012 or higher

Additional Information’s

Advertisements


Windows: The Underestimated Ambiguous Name Resolution (ANR) Search in Active Directory

Windows Logo

Introduction

Very recently I’ve been troubleshooting an issue related to LDAP queries against Active Directory using .Net’s System.DirectoryServices namespace. I was surprised to see that the main query was using an LDAP filter (the equivalent of a WHERE SQL statement) with a concatenation of different conditions in order to find a user by its usual attributes such as display name, first name, last name, email address…

Active Directory Domain Services as well as Lightweight Domain Service both come with a handy feature in order to search through well-known user attribute in a simplified manner: Ambiguous Name Resolution (ANR). Exchange and Outlook specialist know this very well since it’s that feature that is used when Outlook looks for a recipient against the Global Address List (GAL).

Let’s start with an example (assuming you’re familiar with LDAP filter syntax). In your code, you wish to search for a user whose name (first, last or whatever) is “Bishop”, if you use the plain LDAP syntax, it would give something like:

(&(objectClass=user)(|(name=bishop)(displayName=bishop)(mail=bishop)(sn=bishop)(samAccountName=bishop)(proxyAddresses=bishop))

Using ANR, it will be:

(&(objectClass=user)(|(anr=bishop))

You get the point: not necessary to think about all name-related attributes when building your filter, ANR does it for you and moreover, it ensures consistency with Outlook’s behavior, which is great if you’re looking for a uniform user experience.

Attributes includes in ANR Search

The list of attributes queries by ANR differs a little depending upon the version of Windows Server AD is running on.

Windows 2000 Server

Windows Server 2003

Active Directory Application Mode (ADAM)

Windows Server 2003 R2

Windows Server 2008

Windows Server 2008 R2

Windows Server 2012

Query it yourself!

Not sure about the Windows version AD runs on? Simply issue and LDAP query using the filter hereunder against the schema partition to retrieve the list of attribute used in ANR:

(&(objectCategory=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=4))

Matching

While standard match will return either exact or a list of possible matches, specific match restrict to exact match

Customizing you AD’s Schema to add attributes to ANR

Add non-standard attribute to ANR search will require AD Schema modification. The link hereunder provides the, rather simple, procedure:

More Information

Happy AD Querying!

Marc


Windows: The Confusion over DisableLoopBackCheck, DisableStrictNameChecking and Kerberos

Windows Logo

Introduction

I’ve been answering technical questions in Forums and at customers for a while now and in the recent years there were many related to issue related to DisableLoopBackCheck and DisableStrictNameChecking security features from Windows. I also regularly noticed a lot of confusion and misinformation about these. This post is a modest attempt to explain them more in-depth.

DisableLoopBackCheck

LoopBackCheck is, like its name says, a security feature applicable to connection established to the loopback address (127.0.0.1). It applies to NTLM authentication only. It allows protecting a Windows computer against threat exploiting connections to the loop back adapter specifically. This extra protection level applies to all incoming connections and protocols

What is often misleading with LoopBackCheck is the error message making believe invalid credentials have been provided while it is actually not the case. Example with IIS: HTTP 401.1 – Unauthorized: Logon Failed.

Why isn’t it applicable to Kerberos authentication? Simply because Kerberos authentication is so strongly linked to names (host and service names) that is does actually need this security feature.

When will you experience this issue? Usually, in a test/dev environment when you redirect services such as IIS web sites or SharePoint to the loopback address. It might also affect production SharePoint when the crawler process is configured to crawl from the locally-deployed WFE role thanks to a modification of the HOSTS file. You may also experience this problem when the server’s are part of an NLB cluster or when an IIS-based application accesses a SQL Server instance located on the same server using the loopback address together with Windows Authentication.

This feature was originally implemented with Windows Server 2003 Service Pack 1 and is therefore present in all recent versions of Windows

Solutions/Workarounds

Note: MS KB Article states you have to disable Strict Name Checking as well; this is not true or at least not true if you don’t plan to use file & print sharing over the loopback adapter (see below)

Note2: My field experience tells not to use the loopback adapter anymore for SharePoint crawler because it may also generate other issue related on security software (anti-virus, local firewall…) adding their load of security checks to the communication channel to the loopback adapter.

DisableStrictNameChecking

Strict Name checking is a security feature specific to the Windows implementation of the SMB protocol (File & Print sharing). It will prevent connections from being stabled to a network share or to a shared printer if the host name used is not the server’s real one. The error message might also be considered as misleading: System error 52 has occurred. A duplicate name exists on the network.

The feature has been originally brought by Windows 2000 and is implemented is all subsequent versions of Windows.

Solutions/Workarounds

Kerberos and how it is related to Names

Like I stated upper in this post, Kerberos authentication protocol integrates name checking in its foundation since the secret exchanged between the client and the service are partially based on the name the service is accessed by. If the name of the service is missing or incorrectly configured in the Kerberos database (Active Directory in the Windows world), the authentication will fail with the internal error KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN and is likely to fall back in NTLM authentication, which will ultimately lead to a successful authentication with a less secure protocol

Therefore, if one or multiple alternate names are used to access a service, the appropriate configuration must be associated with the user account (or computer account) running the service, using, for example SETPSPN or NETDOM like in the example above. Note: While some software offer the possibility to auto-magically register Service Principal Names in AD, very few do that actually)

Marc


Active Directory: Schema Versions and How to Retrieve it

Windows Logo

Hello,

Since Windows Server 2012 RTM is publicly available, you might be busy upgrading your forest (or at least, planning to do so). I actually did the same in my lab environments and wanted, at the same time, to revisit the AD Schema’s possible version numbers and ways to retrieve it.

You will find all details in the article I just posted: Active Directory Schema Versions.

Marc


Leave a comment

Validating Domain, Local or AD LDS Credentials using PowerShell

Powershell

Hi there. When automating installation and configuration using PowerShell, you may have to push configuration containing credentials. It can therefore be useful to make sure they are correct before actually setting them.

PowerShell 2.0 and .Net 3.5 to the rescue: The assembly System.DirectoryServices.AccountManagement hopefully exposes this functionality. Here is how to do:

Load the assembly:

Add-Type -AssemblyName System.DirectoryServices.AccountManagement

Create a context type. It can be a domain, a machine (local or remote) or an AD LDS (aka ADAM) instance:

$MyContextType = [System.DirectoryServices.AccountManagement.ContextType]::Domain

Create a principal context. A context is actually the name of the context type you will validate credentials against. In this case, an AD domain:

$MyPrincipalContext = New-Object System.DirectoryServices.AccountManagement.PrincipalContext($MyContextType, “massivedynamic.local”)

An finally, execute the ValidateCredentials method providing username and password. Note: in the case of domain credentials as as long you have the appropriate trust in place, you can validate credentials from a user belonging to domain A against domain B, you name it, B must trust A. In return you get a Boolean:

$ValidCredentials = $MyPrincipalContext.ValidateCredentials(”MASSIVEDYNAMICWBELL”, “Azerty1”)

Sure it also works with UPN’s:

$ValidCredentials = $MyPrincipalContext.ValidateCredentials(”william.bell@massivedynamic.local”, “Azerty1”)

A warning though: validating credentials is actually performed thanks to a network logon. If a user account is valid while it’s password is wrong, the bad password count at AD or local SAM DB will be incremented. You guess, if an account lockout policy is applicable, too many attempts will lock out the account…

My colleague Bert VL (kind of PoSh scripting goldsmith, check his blog) has tracked this using the good old Account Lockout Tools from the Windows Server 2003 Resource Kit http://technet.microsoft.com/en-us/library/cc738772(WS.10).aspx.

Bad Password Count

More info:

Marc


Leave a comment

SharePoint 2010: Searching with a User from a Trusted Domain Returns No Results

This “issue” is documented  under MS KB 2344518: Unable to Perform a query on a One-Way trust Domains Scenario when an User from the trusted domain performs the query and the SSA Application Pool account is from the Trustee Domain. So why bother blogging about it then? Well just for my very own pleasure of scratching the surface of things of course!

ok so here are the conditions to be met for the problem to occur:

  • The SharePoint 2010 Server is member of an AD domain considered as a resource domain: it contains only servers and service account, no real user account
  • That resource domain has one-way trust with one or more trusted domain whose real users are member of
  • De-facto, classic Windows authentication is used
  • The content is indexed “as usual” with the crawler storing item permissions based on the user’s SID (as well the SID of the AD groups it belongs to if necessary) in order to use them for security-trimming of search results when user performs queries
  • The group “Pre-Windows 2000 Compatible Access” from the trusted domains does not contain “Everyone” but “Authenticated Users” (default “secure” configuration)

And this is what really happens behind the scenes (intentionally simplified to ease understanding):

  1. The users issue a query against the WFE role
  2. WFE authenticates the users as DOMAINUSER and builds its access token (group membership, SID history and so on…)
  3. The WFE passes only the authentication information to the “Query Processor” (QP) component (which may reside on another server depending upon the farm topology)
  4. In order to perform security trimming on search results, the QP has to know about the user’s authorization, to do so, it contacts the user’s domain by first calling the function “AuthzInitializeContextFromSid()”.
  5. To respond to this call the DC of the user’s domain expects the client to authenticate (a consequence of the Pre-Windows 2000 Compatible Access). This fail since only a one-way trust in in place
  6. The DC responds with “Access Denied”, the information cannot be supplied to anonymous caller
  7. The QP is unable to construct a valid token and therefore, will not return any result for the search

When this happens, the message hereunder will show up in the SharePoint diagnostic logs of the server hosting the QP role (source: Query Processor):

AuthzInitializeContextFromSid failed with ERROR_ACCESS_DENIED. This error indicates that the account under which this process is executing may not have read access to the tokenGroupsGlobalAndUniversal attribute on the querying user’s Active Directory object. Query results which require non-Claims Windows authorization will not be returned to this querying user

But wait, it did not happen on my MOSS2007 infrastructure! That’s right, it simply worked differently because the QP component was part of the WFE role and since the WFE role was aware of the user’s token, it could perform security-trimming without having to contact the user’s domain for this purpose.

Any Solution or Workaround?

Yep there are but I will let you qualify them and rank them by quality and feasibility 🙂

  1. Change your IIS Application Pool Identity for SharePoint with one from the trusted domain… This way the authentication of the call to the user’s domain is always ensured . Of course, it will not solve the problem if you have multiple trusted domains
  2. Establish 2-way trusts between the resource domains and the user domains. While this will solve the issue in all cases, some “security specialist” do not like 2-way trusts, it may not be allowed in your organization…
  3. Adding “Everyone” the the “Pre-Windows 2000 Compatible Access” group of the user’s domain. This is against security best practices since it will also expose large part of your AD to anonymous users…But it will also solve the problem
  4. Finally you can also change the way the indexer stores security descriptor by default by switching from Windows to Claim. This is the solution (rather poorly) documented in the KB2344518. Although exact consequences of this changes are unclear to me, it actually solves the problem. BTW, some say you cannot revert the change so as usual, make sure you test it in lab carefully! BTW, here are the commands in the correct order:

$SearchServiceApp = Get-SPEnterpriseSearchServiceApplication
$SearchServiceApp.SetProperty(“ForceClaimACLs”, 1)
$SearchContentSource = Get-SPEnterpriseSearchCrawlContentSource -SearchApplication $SearchServiceApp -Identity "Local SharePoint Sites"
$SearchContentSource.StartFullCrawl()

Implications on Scalability

If the default configuration is left as it is, I have noticed that for each search request, the method AuthzInitializeContextFromSid() is used. The user’s context seems therefore not to be stored in a cache. You guess it, this means one roundtrip to the user’s AD for each search. IO let you imagine the traffic and possible latency that occur if you AD’s are not designed appropriately. So I ask myself this question: since everything in SharePoint is internally based on claims and claim-based ACLs, why not using claim-based ACL OOB in Search application?

More information

Marc


Leave a comment

Windows: Disabling PAC Validation II – We Won't Get Fooled Again

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

Marc


Windows: Disabling PAC Validation Brings More than meets the eyes

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!)

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


Leave a comment

SharePoint: People-Picker and Active Directory Part 2

SharePoint 2007 SharePoint 2010 SharePoint 2013

[UPDATED on 12/04/2012]

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 SharePoint.

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

  • Additional filtering capabilities and control
  • Detailed configuration for each AD scenario
  • how people picker is related to authentication and profile import SharePoint Server 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/Classic Mode.

Additional Filtering Capabilities and 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. From my own experience, I can tell that using this paremter with multiple forests/domains equals to shooting yourself in the foot.

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,WATERTRIBESKATARA,PASSWORD”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:watertribes.local,WATERTRIBESKATARA,PASSWORD”

To search both “avatar.local” and “watertribes.local”

  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;forest:watertribes.local,WATERTRIBESKATARA,PASSWORD”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:avatar.local;domain:watertribes.local,WATERTRIBESKATARA,PASSWORD”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:avatar.local;forest:watertribes.local,WATERTRIBESKATARA,PASSWORD”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;domain:watertribes.local,WATERTRIBESKATARA,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,WATERTRIBESKATARA,PASSWORD;forest:firenation.local,FIRENATIONZUKO,PASSWORD”
  • STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:avatar.local;forest:watertribes.local,WATERTRIBESKATARA,PASSWORD;forest:firenation.local,FIRENATIONZUKO,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,WATERTRIBESKATARA,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 (SharePoint Server 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 SharePoint Server SSP’s/User Profile Service Application. 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

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

Happy people-picking!

Marc


SharePoint: People-Picker and Active Directory Part 1

SharePoint 2007 SharePoint 2010 SharePoint 2013

[UPDATED on 12/04/2012]

Introduction

In organizations operating SharePoint with multiple Active Directory forests/domains, configuring the people picker can be a challenge, particularely if trust relationships between the domain hosting SharePoint and the domain(s) hosting the users are “one-way”.

I must confess that only documentation is poor and blog posts were sometimes unclear to me. Therefore 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/Classic Mode. Note: what applies to IWA also applies to Basic, Digest and client certificate mapping authentication as long as AD is used as repository for authentication information. It is 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).

Default Behavior

The people-picker is a SharePoint interface responsible for querying repositories for users 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 works:

  1. A user submits a query to the people-picker
  2. The SharePoint contacts a domain controller of the domains it belongs to in order to retrieve the list of trusted forests/domains with which a 2-way trust is established. Note: to do so, the system function DsEnumerateDomainTrusts is called.
  3. For each Forest/Domain retrieved as previous steps, The SharePoint (WFE) will perform the steps 4 to 6 hereunder
  4. The SharePoint performs a DNS query in order to locate a domain controller hosting the Global Catalog Service (in case of a Forest) or LDAP service (in case of a Domain). There are actually two possible DNS queries: 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 secondone. 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.Note that, like with any DNS record resolution attempt in Windows, the result is cached according to the TTL of the record or put in the negative cache if the query failed
  5. With the IP address of a DC hosting GC or LDAP service in hand, SharePoint (WFE) will initiate a connection over port 3368 (Global Catalog LDAP over TCP for a forest) or 389 (LDAP over TCP for a Domain) against the selected domain controller. This first request, which is is anonymous, is necessary for the LDAP client and server to agree on a set of elements necessary for the protocol to work such as authentication, capabilities.This first contact is often known as the Root or RootDSE
  6. Once SharePoint know how to talk to an AD, it will perform a query whose part of the parameters are based on the user’s input. This query is powered by the System.DirectoryService Namespace. 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 (DOMAINSERVERNAME$ is used) or a domain user used as service account
  7. SharePoint aggregates the results with user information which could already exist in the site the user originally accessed and initiated the people-picker from
  8. 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 for each record found:

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

Key points:

  • By default, SharePoint only knows about the AD domain its server(s) belong(s) to and the other forest or domains trusted by that domain
  • SharePoint uses DC locator DNS records to locate a DC, attempting to honor Active Directory’s site awareness principle
  • SharePoint queries AD using the Global Catalog or LDAP Service
  • The same LDAP filter is used for every domain

Prerequisites for the people picker to work:

  • The SharePoint Server(s) must be able to resolve DNS names from the remote forests/domains
  • The network connectivity must be allowed from the SharePoint Server(s) and the Domain Controller of the remote forest/domain
  • A two-way trust relationship must be in-place. For one-way, see the section below

Custom Configuration for Querying Specific Forest/Domains

In some situation, you may want to restrict the forests/domain queried by the people. In this case, the list of forests/domains must be configured on a per web application-basis using the command STSADM.exe -o setproperty -pn peoplepicker –searchadforests. For each forest/domain, you need to gather the information below:

  • Do you query a forest or a domain
  • The DNS name of the forest or domain to be queried

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:

  • Using a custom configuration completely replaces the default behavior
  • SharePoint will not retrieve the list of forest/domain with which a 2-way trust is in place anymoire like it does at step 2 of Default Behavior
  • If you specify a forest, a forest trust must be in place, if you specify a domain, an external trust will be sufficient
  • 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 as well
  • If “forest” is specified, the Global Catalog Service will be used to perform the query while with domain, it will use the LDAP service
  • While the STSADM command is to be execute on one SharePoint server, an ISRESET must be performed on each SharePoint server for the configuration must be applied

Custom Configuration with One-Way trust Scenario

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 imposed by one-way trust, alternate credentials must be supplied. Those credentials must be from the forest/domain to be queried or from a trusted domain, as long as it is allowed to authenticate.

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:

  • STSADM.exe -o setapppassword -password MYPASSWORD. where MYPASSWORD is the key –> While it makes sense that the more complex, the better, it seems that too complex will prevent the people picker from working. Note: the complexity 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,DUNEPAULA,PasswordOfPaulA;domain:carthag.local,CARTHAGGurney,PasswordOfGurney;domain:tuono.local,TUONOSHANIA,PasswordOfShania”

Key points:

  • Do not forget to execute STSADM.exe -o setapppassword on each SharePoint server
  • Make sure you have valid credentials for each forest/domain
  • Make sure each forest/domain element is correctly structured
  • Sure you can combined forest/domain with and without explicit credentials. If ceredentials are not supplied, the context of the IIS application pool account running the web application will be used

Worth Mentionning

The people picker configuration is not only used by the web interface of sites but also by some STSADM commands, Powerhsell Cmdlets and API’s. Therefore, user or group-related interactions may faild if the configuration is incorrect or if the people picker is not operating correctly.

Moreover, if you wish to assign permission to users in the central admin (site collection owner, policy for web application…), it will also require people picker configuration, unless the default behavior is sufficient.

Some Troubleshooting Guidance

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)

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 3rd 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’.

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

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

Happy people-picking!

Marc