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_”
Los atributos que cargo en la query son
Si filtro solamente el mensaje 1003 vero que el tiempo que tardo en hacer la consulta fue de 0.0024204 ms
Y necesitó 4 paquetes para obtener los resultados
El AD (10.0.0.4) le retorno 3 paquetes, si ven en el summary, ven que dice LDAP Message, Search Result Entry, MessageID: 43
Si ves el field data, podes ver que aparece (SP_farm y SP_setup) lo mismo que buscaste por Sharepoint
Algunos links útiles:
http://thesharepointfarm.com/2014/01/people-picker-troubleshooting-tips/