Todo Sharepoint: Tips de Troubleshooting para People Picker de Sharepoint

Voy a mostrar algunos tips útiles para verificar el funcionamiento correcto del People Picker de Sharepoint.

Entorno (montado sobre Azure):

AD: Windows Server 2012
1 Granja (1 WFE, 1 App Server, 1 SQL Server)
Sharepoint 2013 SP 1, CU de febrero 2015

El people picker de Sharepoint es el responsible de consultar el AD en búsqueda de usuarios (accounts) y grupos, se usa para dar permisos a los sitios de Sharepoint.

En este link podrás ver todas las configuraciones posibles del People Picker.

En este link y en este podrás ver la secuencia que se realizar cuando haces un “check name” en el people picker. En 50 pasos ves cómo funciona el people picker.

Algunos pasos resumidos:

Cuando haces una consulta en el people picker, el WFE consulta via una DNS Query al Global Catalog Service (se llama “LDAP Global Catalog Search Request”)
En esta query, se pregunta por usuarios y grupos que tengan un string de búsqueda (wildcard search).
Cuando se busca en el AD, se busca por los siguientes atributos

# User objects: 'name', 'displayName', 'cn', 'sn', 'SamAccountName', 'mail', 'proxyAddresses'
# Group objects: 'name', 'displayName', 'cn', or 'SamAccountName' attributes.

Ahora mostremos algunos tips útiles para hacer throu

1-Evaluar la conectividad desde el WFE hacia el Global catalog.

Supongamos que estamos en el dominio “contoso.com”.

Supongamos que estamos buscando todas las cuentas que tengan “sp” en el display name o en el atributo “SamAccountName”. Sharepoint cómo les comenté buscará en varios atributos del container de usuarios y grupos de AD (user Objects y groups Objects)

Supongamos que también buscamos por un grupo específico (Ej: que tengan en el display name “Domain”). En amarillo las líneas más importantes.

El siguiente query (descargar) nos permite evaluar la conexión contra nuestro el AD, buscando un usuario y un grupo (usando wildcards). La funcionalidad es parecida a cómo busca Sharepoint.

function SearchUsers($cn) {
   $strFilter = "(&(objectClass=User)(cn=$cn))"
   $objDomain =New-Object System.DirectoryServices.DirectoryEntry("LDAP://CONTOSO")
   $ds = New-Object System.DirectoryServices.DirectorySearcher
   $ds.SearchRoot = $objDomain
   $ds.PageSize = 1000
   $ds.PropertiesToLoad.Add("displayName")
   $ds.PropertiesToLoad.Add("name")
   $ds.PropertiesToLoad.Add("cn")
   $ds.PropertiesToLoad.Add("sn")
   $ds.PropertiesToLoad.Add("SamAccountName")
   $ds.PropertiesToLoad.Add("mail")
   $ds.PropertiesToLoad.Add("proxyAddresses")
   $ds.Filter = $strFilter
   $ds.SearchScope = "Subtree"
   Write-Host " >> Buscando usuarios: " $cn
   $colResults = $ds.Findall()
   foreach ($usrTmp in $colResults)
    {
      Write-Host $usrTmp.Properties["name"]
    }
}

function SearchGroup($cn) {
   $strFilter = "(&(objectClass=group)(cn=$cn))"
   $objDomain =New-Object System.DirectoryServices.DirectoryEntry("LDAP://CONTOSO")
   $ds = New-Object System.DirectoryServices.DirectorySearcher
   $ds.SearchRoot = $objDomain
   $ds.PageSize = 1000
   $ds.PropertiesToLoad.Add("displayName")
   $ds.PropertiesToLoad.Add("name")
   $ds.PropertiesToLoad.Add("cn")
   $ds.PropertiesToLoad.Add("sn")
   $ds.PropertiesToLoad.Add("SamAccountName")
   $ds.Filter = $strFilter
   $ds.SearchScope = "Subtree"
   Write-Host " >> Buscando grupos: " $cn
   $colResults = $ds.Findall()
   foreach ($usrTmp in $colResults)
    {
      Write-Host $usrTmp.Properties["name"]
    }
}

$startDTM = (Get-Date)
SearchUsers("*sp*")
$endDTM = (Get-Date)
"La consulta tardo: $(($endDTM-$startDTM).totalseconds) segundos"

$startDTM = (Get-Date)
SearchGroup("*domain*")
$endDTM = (Get-Date)
"La consulta tardo: $(($endDTM-$startDTM).totalseconds) segundos"

Cuando lo ejecuto me retorna lo siguiente.

Es cómo si hubiera hecho esto.

Este script nos permite evaluar la performance de búsqueda de perfiles y grupos contra nuestro Global Catalog. Cómo pueden ver los tiempos son muy buenos.

2-Evaluar la conectividad mediante Message Analyzer

Ejecuto lo siguiente en la línea de comandos (run as a administrator)

netsh trace start persistent=yes capture=yes tracefile=C:\nettrace-sharepoint.etl

Después realizo algunas querys desde el People Picker, ej: sp_

Después detengo el trace.

netsh trace stop

Abro el Message Analyzer cómo administrador (run as a administrator)

Selecciono New Session / Files

Agrego el archivo del trace

En la sección de filtros agrego lo siguiente: contains "displayName"

En los mensajes veo que las query al AD, en el sumary dice:

Search Operation Search For RootDSE

Cuando entro a un mensaje, por ejemplo 1003

Hago click en el atributo LDAP.

En filter dice lo siguiente

(((objectCategory == person) && ((SubstringFilter{Type=anr,SubStrings=[Sp_]}) || (SubstringFilter{Type=SamAccountName,SubStrings=[Sp_]}))) || ((objectCategory == group) && (MatchingRuleAssertion{MatchingRule=1.2.840.113556.1.4.803 (LDAP_MATCHING_RULE_BIT_AND),Type=groupType,MatchValue=2147483648,DnAttributes=False}) && ((SubstringFilter{Type=anr,SubStrings=[Sp_]}) || (SubstringFilter{Type=SamAccountName,SubStrings=[Sp_]}))))

Pero si entro en más detalle, en la parte de Filter, veo que tiene dos contenidos (objectCategory==person y objectCategory==group). Es decir en la misma query, consulta por usuarios y grupos que coincidan con “sp_”