Tout d’abord, j’aimerais remercier toutes le personnes qui ont pris le temps de m’envoyer leur feedback, commentaires ou questions en rapport avec mon premier post relatif au people picker dans WSS/MOSS.
Maintenant, concentrons-nous sur la 2e partie qui va couvrir les sujets suivants :
- Possibilités additionnelles de filtrage des recherches LDAP
- Configurations détaillées pour chaque scénario Active Directory
- Comment le people picker est lié à l’authentification et à l’importation du profil (exclusivement MOSS)
- Conseils pour optimiser le people picker dans différents scénarios
Une fois de plus, il est important de rappeler que ces posts couvrent le people picker reposant exclusivement l’authentification Windows.
Possibilités additionnelles de filtrage des recherches LDAP
peoplepicker-searchadcustomquery
Ce paramètre permet de spécifier des critères additionnels à la recherche « built-in ». Si vous utilisez cette option, faites-le avec prudence parce que les résultats peuvent être parfois inattendus ou il peut n’y avoir aucun résultat du tout. De plus, si vous visez de multiples forêts ou domaines, le même critère sera appliqué à toutes les cibles ! Il est fortement recommandé de tester et valider votre requête en utilisant LDP.exe, la fonction de query d’ADUC (Console « Active Directory Utilisateurs et Ordinateurs ») ou tout autre client LDAP afin de s’assurer que la recherche se comporte comme espéré.
Dans la pratique, vous pourriez rencontrer le cas suivant: votre organisation utilise également MS Exchange et vous désirez empêcher le people picker d’afficher les personnes cachées de la list d’adresses. Dans ce cas, vous pouvez ajouter la condition additionnelle suivante :
- (!msExchHideFromAddressLists=TRUE)
peoplepicker-onlysearchwithinsitecollection
Pour autant que j’aie pu l’expérimenter, le comportement dans ce cas est assez amusant : cela interrogera AD tel que configuré par l’administrateur et affinera le résultat en le comparant avec la liste des utilisateurs déjà présents dans la collection de sites. Avoir recours à cette requête n’améliorera donc pas vraiment les performances puisque la requête se fera tout de même vis-à-vis d’AD et réalisera les opérations additionnelles par après.
Typiquement, cela serait utilisé dans des collections de sites où l’appartenance de groupes est hautement contrôlée où dans des environnement de hosting.
peoplepicker-activedirectorysearchtimeout
Ce paramètre contrôle l’option d’expiration (timeout) d’une opération de requête envers un AD donné. Cette valeur d’expiration n’est donc pas globale, mais bien spécifiée par cible. Ainsi pour calculer le temps maximum qu’il faudrait au people picker de faire une requête, vous devez multiplier la valeur par le nombre de forêts/domaines spécifiés.
Augmenter le timeout prend évidemment tout son sens dans des scénarios où les contrôleurs de domaine cibles sont connectés via des réseaux avec de faibles bandes passantes/hautes latences OU s’ils sont particulièrement chargés (par exemple, utilisés intensivement par MS Exchange et les clients MS Exchange tels que Outlook).
Setsiteuseraccountdirectorypath
Ce paramètre est primordialement utilisé par les compagnies de hosting qui désirent 1) placer tous les utilisateurs d’un client donné dans un containeur AD déterminé (unité organisationnelle par exemple) 2) mettre une collection de site ou une application Web à disposition de ce client 3) Restreindre la vue du people picker aux seuls utilisateurs présents dans ce containeur.
Le paramètre passé est le distinguished Name de l’unité organisationnelle (par exemple : OU=contoso,ou=customers,dc=litware,dc=local). Ce paramètre est utilisé comme point de départ de la recherche (le « base path »). Si ce paramètre n’est pas défini, le « base path » est toujours la racine de la forêt ou du domaine. Une fois ce paramètre défini, il démarrera au niveau du containeur spécifié.
Puisque le distinguishedName contient le nom du domaine où le containeur existe, cela n’a pas beaucoup de sens de combiner ce paramètre avec la recherche dans de multiple forêts/domaines puisque ce containeur se trouve à un seul endroit spécifique.
Peoplepicker-serviceaccountdirectorypaths
Par vraiment nommé de manière adéquate, ce paramètre a la même fonction que les précédents, mais s’applique exclusivement aux administrateurs de fermes. Toujours applicable essentiellement aux compagnies de hosting, cela empêchera généralement aux administrateurs d’être restreints lorsqu’ils veulent utiliser le people picker.
Configurations détaillées pour chaque scénario Active Directory
- Nous utiliserons toujours le postulat de base suivant:
Le serveur SharePoint qui réalise les requêtes du people picker est toujours membre du domaine « avatar.local »
- L’identité du pool d’application utilisée par l’application web SharePoint est soit « Local System », « Network Service », ou un compte du domaine « avatar.local »
« Simple » relation d’approbation bidirectionnelle (2-way trust)
- Type de relation d’approbation : externe ou forêt
- Direction de la relation d’approbation : bidirectionnelle
Configurations possibles pour interroger « watertribes.local » seulement
- STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local”
- STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “domain:watertribes.local”
Configurations possibles pour interroger à la fois « watertribes.local » et « avatar.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 » relation d’approbation unidirectionnelle (1-way trust)
- Type de relation d’approbation : externe ou forêt
- Direction de la relation d’approbation : unidirectionnelle
Ces configurations sont identiques au premier scénario, sauf que pour effectuer une requête dans « watertribes.local », le people picker doit fournir des crédentiels de manière explicite.
Pour interroger « watertribes.local » exclusivement
- 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”
Pour interroger à la fois « watertribes.local » et « avatar.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"
Multiples Relations d’approbation bidirectionnelles (2-way trusts)
- Type de relation d’approbation : externe ou forêt
- Direction de la relation d’approbation : bidirectionnelle
Les configurations possibles sont presqu’identiques au premier scénario à ceci près que “firenation.local” doit être ajouté à la liste des forêts/domaines. Exemples:
- 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: certaines personnes diront qu’il n’est pas sage d’approuver Firenation mais puisque Zuko est le nouveau fire lord, cela ne devrait plus être un problème.
Multiples Relations d’approbation unidirectionnelles (1-way trusts)
- Type de relation d’approbation : externe ou forêt
- Direction de la relation d’approbation : unidirectionnelle
Cette configuration est la même que la précédente sauf que des crédentiels explicites doivent être fournis pour chaque forêt ou domaine approuvé à interroger :
- 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”
Une fois de plus, suivant le type de requête que vous désirez réaliser (LDAP ou GC), spécifiez domain ou forest comme préfixe.
Relation d’approbation bidirectionnelle entre forêts (2-way trust)
- Type de relation d’approbation : forêt. Par transitivité, North sera approuvé également
- Direction de la relation d’approbation : bidirectionnelle
Dans ce cas particulier, disons que vous désirez interroger à la fois « watertribes.local » et son domaine enfant « North.watertribes.local”. La méthode la plus facile et efficace de procéder est d’utiliser le préfixe forest : cela forcera le people picker à utiliser le service de catalogue global pour interroger la forêt “watertribe.local” en incluant évidemment le domaine enfant, mais dans ce cas une seule connexion et une seule requête sont suffisantes.
- STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local”
Enfin, si la relation d’approbation avait été unidirectionnelle, il suffit simplement fournir d’autres crédentiels :
- STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:watertribes.local,WATERTRIBES\KATARA,PASSWORD”
Note : si vous utilisez le préfixe domain, la requête sera limitée au domaine « watertribes.local »
Comment le people picker est lié à l’authentification et à l’importation du profil (exclusivement MOSS)
J’ai souvent rencontré des personnes qui étaient convaincues que le people picker était impacté par le composant d’importation du profil (Profile Import) présent dans MOSS SSP. Ce n’est pas le cas.
Alors que le people picker est utilisé pour définir des permissions ou d’autres éléments en utilisant les security principals AD (utilisateurs et groupes) et les enregistrer dans des content databases , l’importation du profil est « seulement » responsable de mettre à jour les propriétés de ces utilisateurs ou groupes quand ils existent déjà dans les content databases.
L’importation du profil ne « touchera » pas aux informations relatives à la sécurité, ni ne changera la manière dont le people picker se comporte en interrogeant AD.
D’un autre côté, le people picker est directement lié à l’authentification ou devrais-je dire au mécanisme d’autorisation (pour être exact) dans WSS/MOSS parce qu’une fois l’utilisateur authentifié par Windows/IIS, SharePoint vérifiera alors si l’utilisateur est autorisé à accéder à la page demandée. L’information utilisée dans ce but étant le token de l’utilisateur (SID, appartenance aux groupes, …).
Une autre chose importante est le lien qui existe entre le type de relation d’approbation et le protocole d’authentification utilisé par Windows. Afin d’utiliser Kerberos, une relation d’approbation entre forêts doit être mise en place. D’un autre côté, une relation d’approbation « externe » (basée sur les domaines) impliquera toujours l’authentification NTLM.
Conseils pour optimiser le people picker dans différents scénarios
Du point de vue de SharePoint exclusivement, il n’y a que peu de chose à faire pour optimiser le people picker
- Réduire autant que possible le nombre de forêts et domaines à interroger. Si vous envisagez d’interroger plusieurs domaines de la meme forêt, considérez plutôt de viser la forêt dans son entièreté via une requête unique
- N’utilisez pas de critère additionnel (customadsearchfilter) ou de processus additionel (onlysearchwithinsitecollection) si possible
- Essayez de ne pas mélanger de requêtes contre des AD très réactifs et d’autres moins qui le sont moins (pas evident, je sais) parce que les AD les moins réactifs impacteront le processus de requête dans son entièreté
Avec l’aide de l’administrateur AD, vous pouvez améliorer les performances et la disponibilité en:
- Plaçant un contrôleur de domaine cible « à proximité » du serveur SharePoint et appliquant la configuration de la topologie AD appropriée. Idéalement, le serveur SharePoint et le contrôleur de domaine cible doivent « se voir » en tant que membre du même site Active Directory , même s’ils n’appartiennent pas à la même forêt AD (ce qui signifie de nommer les sites de manière identique dans les forêts resource et utilisateurs). De manière générale, une faible latence importe plus qu’une large bande passante dans la perception de la réactivité.
- S’assurant que les contrôleurs de domaine visés sont disponibles et réactifs (pas trop chargés par d’autres opérations orientées LDAP ou proche de la pleine capacité en général).
- C’est un detail, mais puisque la resolution DNS est utilisée pour atteindre les DCs, s’assurer de sa bonne configuration/efficacité, pourquoi pas en utilisant la cache (temps idéalement pas trop court mais pas trop long non plus, en cas de failover vers un autre DC). Bien sûr le serveur SharePoint DOIT être capable de résoudre tous les domaines AD de manière appropriée. Utilisez l’ordre de recherche des suffixes à bon escient et seulement si nécessaire.
Note: les recommandations ci-dessus seront aussi bénéfiques aux mécanismes d’authentification utilisés par Windows/IIS
Informations Additionnelles
Au vu du feedback important que j’ai reçu de la part de personnes ne faisant pas partie du monde infrastructure (développeurs, …) ou ayant des competences limitées avec AD, je planifie un 3e post détaillé relatif au dépannage.
Je couvrirai également les challenges de l’utilisation de l’authentification intégrée de Windows dans une configuration IIS/Sharepoint complexe, comme par exemple lors d’une recherche fédérée inter-forêt tout en s’assurant que les résultats de la recherche resteront sécurisés par limitation (security trimming) …
Marc
(traduit de l’Anglais par Anthony)
J’ai récemment eu l’occasion de dépanner des implémentations WSS/MOSS présentant des problèmes relatifs au people picker (sélecteur de personnes).
Je dois reconnaître que les documentations existantes sont assez pauvres et que d’autres messages postés sur des blogs sont peu clairs à mes yeux. J’ai donc décidé de synthétiser un document sur le comportement et la configuration du people picker, lorsqu’il se repose sur Active Directory/l’authentification intégrée de Windows (Integrated Windows Authentication – IWA). Notes : ce qui s’applique ici à IWA s’applique également aux authentifications basique, digest et à l’authentification s’appuyant sur un certificat client : ce qui importe c’est qu’Active Directory (AD) soit l’entité de référence pour l’authentification.
Il est donc primordial de comprendre comment AD, les domaines, les forêts et les relations d’approbations se comportent afin de faire fonctionner le people picker correctement (retourne le résultat effectivement attendu), rapidement (ne prend pas des plombes pour retourner le résultat) et de manière fiable (son comportement est prévisible et ne varie pas dans le temps). Je suis souvent surpris par le fait que très peu de spécialistes Sharepoint connaissent réellement les mécanismes internes de Windows et d’AD, conduisant très souvent à une configuration incorrect du people picker.
Comment ça marche, avec la configuration par défaut
Le people picker est une interface SharePoint en charge d’interroger différentes entités sur les identités ou les groupes afin de leurs accorder des permissions dans l’application SharePoint. Il est implémenté dans le cadre du rôle Web Font End (WFE), ce qui signifie que si vous l’utilisez, le WFE auquel vous vous connectez tentera de contacter AD afin de retourner les éléments correspondants aux critères de votre requête. Voici, pas à pas, comment cela fonctionne du point de vue d’AD/Windows :
- Un utilisateur soumet une requête au people picker
- Le WFE exécute une requête DNS afin de localiser un contrôleur de domaine (DC) configuré en tant que serveur de catalogue global (Global Catalog – GC). Il y a en fait 2 requêtes DNS possibles :
- La première requête contient le nom du site Active Directory dans lequel se trouve le serveur afin de localiser un contrôleur de domaine qui réside dans le même site ou qui le « couvre » (il ne se trouve pas dans le même site mais est configuré en tant que candidat pour recevoir des requêtes venant de ce site). Si cette requête réussit, il n’y en a pas de seconde.
- Si elle échoue et que le service DNS rapporte qu’un tel site n’existe pas, une deuxième requête sera envoyée sans aucune référence au site du serveur.
- Avec l’adresse IP d’un contrôleur de domaine en main, SharePoint initiera une connexion d’un port local aléatoire vers le port distant 3268 (Global Catalog LDAP en TCP) du contrôleur de domaine sélectionné. La première connexion, qui est anonyme, rapportera à SharePoint des informations complémentaires à propos du contrôleur de domaine qu’il a contacté. Cela inclut diverses informations LDAP, ses fonctionnalités exactes, ainsi que les mécanismes d’authentification qu’il supporte. Ce point d’entrée est connu en tant que « racine » (« root ») ou « rootDSE ».
- Une fois que SharePoint sait comment « parler » à Active Directory, il exécutera une requête dont une partie des paramètres est basée sur les entrées de l’utilisateur. Cette requête est en fait régie de manière programmée dans l’espace de noms System.DirectoryService. Puisque la requête se fait auprès du service de catalogue global, elle ne peut se servir que d’une partie des attributs d’AD (connue sous le nom de « partial attribute set », ensemble d'attributs partiel). La liste des attributs exacts dépend de la version de Windows des contrôleurs de domaine et de la présence d’extensions du schéma (MS Exchange, OCS ou personnalisées …). Si AD nécessite une authentification, ce qui est le cas par défaut, SharePoint s’authentifiera dans le contexte du pool d’applications sous lequel tourne l’application Web SharePoint. Cela peut être Local System ou Network Service (alors DOMAIN\NOMDUSERVEUR$ sera utilisé) ou un utilisateur spécifié.
- SharePoint affiche le résultat à l’utilisateur
La requête, telle qu’enregistrée dans le 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})))
Les critères de la requête en clair :
- Un utilisateur ou un groupe
- Si c’est un utilisateur, au moins un des attributs suivants doit commencer par ce que l’utilisateur a entré comme information : name, displayName, cn, mail, sn, SamAccountName, proxyAddresses (avec SMTP ou sip)
- Si c’est un utilisateur, il ne doit pas être désactivé
- Si c’est un groupe, au moins un des attributs suivants doit commencer par ce que l’utilisateur a entré comme information : name, displayName, cn, sAMAccountName
- Si c’est un groupe, cela doit être un groupe de sécurité (domaine local, global, universel), pas un groupe de distribution
Les attributs suivants seront retournés pour chaque enregistrement trouvé :
- objectSID
- mail
- displayName
- title
- department
- proxyAddresses
- cn
- samAccountName
- groupType
- userAccountControl
- distinguishedName
Et finalement, les contrôles serveurs suivants seront spécifiés :
- LDAP_PAGED_RESULT_OID_STRING: découpe le résultat en pages et affiche 20 résultats par page
- LDAP_SERVER_DOMAIN_SCOPE_OID: ordonne au DC de ne pas générer de référence de continuation LDAP en réponse à une opération de recherche
Points clés :
- Par défaut, SharePoint n’a connaissance que de la forêt AD à laquelle le serveur appartient
- SharePoint utilise les enregistrements DNS « DC locator » pour localiser un DC faisant tourner le service de catalogue global
- Il émet des requêtes en utilisant un dialecte pseudo-LDAP contre le service de catalogue global en utilisant l’espace de noms System.DirectoryService
- Il n’y a pas de « security trimming » en soi. Les requêtes retournent les résultats en se basant sur ce que le pool d’application IIS est autorisé à voir, pas l’identité de l’utilisateur
Toujours obscur à mes yeux :
- Dans le cas ( pas par défaut, et non recommandé) où le pool d’application IIS tourne dans le contexte d’un utilisateur d’un autre domaine, quel domaine contrôleur de quel domaine sera utilisé ?
Interroger des forêts ou domaines additionnels
Dans cette section, je couvrirai la configuration la plus fréquente : le serveur SharePoint appartient à une forêt et/ou domaine qui a une relation d’approbation bidirectionnelle (2-way trust) établie avec une autre forêt ou domaine. Les comptes des utilisateurs accédant à SharePoint appartiennent donc à ces domaines approuvés puisque l’approbation est bidirectionnelle , l’identité du pool d’application IIS est aussi capable de s’authentifier face à ces domaines approuvés.
Afin d’ordonner à SharePoint d’interroger ces domaines ou forêts approuvés, la commande « STSADM.exe –o setproperty –pn peoplepicker -searchadforest » doit être utilisée. Mais il semblerait que de nombreuses personnes sont désorientées, pour de bonnes raisons, quant à la syntaxe exacte des paramètres à passer.
Vous devez premièrement collecter les informations suivantes :
- Voulez-vous interroger une forêt (dans ce cas vous aurez besoin d’une relation d’approbatiopn entre deux forêts) ou un domaine (dans ce cas une relation externe d’approbation est suffisante)
- Quel est le nom DNS de la forêt que vous voulez interroger (ainsi que le nom DNS de son domaine racine)
Suivant les informations collectées ci-dessus, vous pourrez alors assembler les paramètres correctement. Les configurations de chaque forêt ou domaine à interroger doivent être séparées par un point-virgule et à l’intérieur de la configuration, le premier mot doit être « forest: » ou « domain: » et il doit être suivipar un nom DNS valide. Exemple :
- STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:dune.local;domain:carthag.local;domain:tuono.local”
Points clés:
- Le processus “DC Locator » utilisé avec la configuration standard est toujours applicable MAIS s’étend au-delà des limites de la forêt locale. Cela signifie que les serveurs SharePoint doivent être capables de résoudre les noms des contrôleurs de domaine des forêts/domaines distants (enregistrement SRV et A)
- Aussi, les sites Active Directory doivent être nommés de manière identique dans chaque forêt, sinon SharePoint peut ne pas sélectionner le contrôleur de domaine “le plus proche”.
- Si vous utilisez l’ “authentification sélective” ou le “filtrage des SID” afin de restreindre l’authentification à travers les relations d’approbation, vous devez vous assurer que l’identité du pool d’application IIS est autorisée à s’authentifier face au domaine/à la forêt distant qu’il interroge.
- Il va de soi que s’il y a des firewalls entre SharePoint et le domaine/la forêt distant(e), ils doivent être configurés de manière adéquate.
- Comme il a été dit précédemment, si l’argument “forest” est spécifié, une relation d’approbation entre deux forêts doit être mise en place.
- Si vous désirez toujours interroger la forêt/le domaine auquel SharePoint appartient, vous devrez le spécifier également comme paramètre
- Si c’est une forêt que vous interrogez, il est inutile de déclarer tous ou une partie des domaines enfants de manière séparée, ils seront de toute façon interrogés.
- Si “forest” est spécifié, le service de catalogue global sera utilisé pour réaliser la requête.
Si “domain” est spécifié, le service LDAP sera alors utilisé.
Le catalogue global (“Global Catalog”, GC en abrégé) peut interroger tous les objets à l’intérieur d’une forêt mais ne connaît qu’une partie limitée de leurs attributs alors que LDAP connaît tous les attributs mais est limité au domaine ciblé.
- Ne pas oublier d’exécuter IISRESET sur chaque serveur SharePoint où la configuration doit être appliquée
Toujours obscur à mes yeux :
- Je suis persuadé que les requêtes contre chaque forêt/domaine ne sont pas executées en parallèle, du moins pas la partie DNS
La configuration avec une relation d’approbation unidirectionnelle (one-way trust)
Cette configuration est identique à la précédente, excepté le fait que des crédentiels alternatifs doivent être spécifiés, dû au fait que l’identité du pool d’application IIS n’est pas capable de authentifier face à la forêt/domaine distant à cause la limitation définie par la relation d’approbation unidirectionnelle. Ces crédentiels doivent provenir du domaine/de la forêt interrogée ou d’un domaine approuvé, tant qu’ils sont autorisés à s’authentifier et que la connexion à distance ne leur est pas refusée.
La tâche la plus difficile consiste à appliquer la configuration
Premièrement, une clé doit être générée afin d’encrypter/de décrypter les crédentiels alternatifs à utiliser. Pour ce faire, vous devez exécuter la commande suivante sur chaque serveur SharePoint où le people picker sera utilisé (raccourci: faites-le sur chaque serveur!):
- STSADM.exe -o setapppassword -password MYPASSWORD
où MYPASSWORD est la clé -> il va de soi qu’il est préférable d’utiliser une clé la plus complexe possible. Cependant, elle n’est pas soumise à la stratégie de mots de passe de Windows.
Deuxièmement, vous devez fournir la liste de forêts/domaines à interroger ainsi que les crédentiels pour le faire. Chaque bloc est séparé par un point-virgule et chaque élément dans les blocs est séparé par une virgule.
Exemple:
- STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:dune.local,DUNE\PAULA,MotDePasseDePaulA;domain:carthag.local,CARTHAG\Gurney, MotDePasseDeGurney;domain:tuono.local,TUONO\SHANIA, MotDePasseDeShania”
Points clés:
- Assurez-vous d’avoir des crédentiels valides pour chaque forêt/domaine
- Assurez-vous que chaque élément de la forêt/domaine est correctement structuré
- Ne pas oublier d’exécuter IISRESET sur chaque serveur SharePoint où la configuration doit être appliquée
Astuces de dépannage
Outils utiles
- L’outil de commande NTLTEST (fait partie des outils de support de Windows Serveur 2003, ou inclus dans Windows Serveur 2008)
- L’outil de capture réseau Wireshark
- LDP.exe, simple client LDAP (fait partie des outils de support de Windows Serveur 2003, ou inclus dans Windows Serveur 2008)
- Console Active Directory Utilisateurs et Ordinateurs (AD Users and computers - ADUC)
- ADInsight de MS Sysinsternals (malheureusement pas toujours totalement fiable)
Approche globale
Le moyen le plus direct de retracer le comportement du people picker est de prendre une capture réseau lors d’une recherche réalisée à partir de l’interface graphique Web, en prenant soin de vider la cache DNS (ipconfig /flushdns). Prenez cette capture depuis le Web front-end que vous visez et filtrez les résultats comme suit:
Appliquez un filtre d’affichage afin de ne visualier que les requêtes DNS; vous devriez voir des requêtes semblables à ceci:
Si vous tentez d’interroger un domaine: _ldap._tcp.Site-Name._sites.domain.local: type SRV, class IN (premières tentatives, afin de localiser un DC du même site) ou _ldap._tcp.domain.local: type SRV, class IN (n’importe quel DC du domaine, indifféremment du site)
Si vous tentez d’interroger une forêt, vous devriez voir _gc au lieu de _ldap
Si vous ne voyez pas ces requêtes DNS ou si vous les voyez mais qu’elles échouent, assurez-vous que les serveurs SharePoint sont capable de résoudre les noms des domaines distants et qu’ils sont configurés avec les serveurs DNS corrects, éventuellement accompagnés de suffixes DNS additionnels.
Une fois que la résolution de noms fonctionne correctement, retournez à votre capture et assurez-vous de trouver LDAP (port 389) ou GC (identique à LDAP mais utilisant le port 3268).
Pour chaque forêt ou domaine, vous devez apercevoir un “bindrequest” et sa réponse réussie, suivi d’un “searchrequest” et de sa réponse réussie également. Plongez-vous dans la requête afin d’en retrouver les détails, et plus particulièrement le filtre et les conditions appliquées.
Détermination du site AD du serveur
Exécutez la commande suivante: “NLTEST /dsgetsite”. Cela devrait retourner le site AD auquel le serveur SharePoint appartient. Si ce n’est pas le cas, vous avez de sérieux problèmes de configuration AD ;-)
Détermination d’un DC pour un domaine donné
Exécutez la commande suivante: “NLTEST /dsgetdc:mydomain.local”
Analysez le résultat et vérifiez la liste des flags retournée. Si elle comporte les éléments suivants, vous avez tout bon:
- CLOSE_SITE= le DC est dans le même site AD que le serveur SharePoint ou “couvre” ce site
- LDAP: le DC est un serveur LDAP (tous les DCs le sont, mais doivent l’annoncer)
- GC: le DC est également serveur de catalogue global (Tous les DCs ne sont PAS GC, mais ceux qui le sont doivent également l’annoncer)
Note: les autres informations renvoyées par cette commande peuvent également être utiles pour le dépannage, telles que le nom du DC, son adresse IP, …
Simple test de connexion LDAP
- Sur le serveur SharePoint, démarrer ldp.exe
- Allez dans le menu “Connection” et cliquer sur “Connect”. Entrez l’adresse IP ou le nom du DC distant. Vous devriez tester avec un FQDN (“nom de domaine totalement qualifié”) afin de tester la résolution DNS également.
Sélectionnez le port 389 pour LDAP ou 3268 pour GC
Si cela fonctionne, cela devrait renvoyer une liste d’information relative au server.
- Répétez ce test pour chaque DC face auquel SharePoint pourrait éventuellement réaliser une requête
Tester les crédentiels pour se connecter au domaine distant en utilisant LDAP (en particulier dans le cas du scénario utilisant la relation d’approbation unidirectionnelle)
Si les tests précédents fonctionnent, procédez à celui-ci:
- Retournez dans le menu “Connection” et cliquez ensuite sur “Bind”. Entrez alors les crédentiels du domaine distant (incluant le nom de domaine dans la 3e textbox)
- Si cela échoue, vous obtiendrez un message tel que le suivant:
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.
- Si cela fonctionne, cela rapportera
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User=’myuser’; Pwd= <unavailable>; domain = ‘mydomain’.}
Authenticated as dn:’myuser’.
Eléments perturbants le plus la fiabilité et/ou les performances du people picker
- Plus il y a de domaines/forêts à interroger, plus la requête prendra du temps à délivrer les résultats
- Processus de résolution de noms problématique: afin de résoudre les enregistrements “DC locator”, Windows épuisera toutes les méthodes de résolution de nom possibles, du DNS au broadcast.. Et ceci pour chaque forêt/domaine déclaré
- Un DC qui ne fournit pas de réponse accroît considérablement la lenteur du processus
- Configuration de sites AD non optimisée/inconsistante: la détermination du site est un facteur clé; cela permet de s’assurer que SharePoint interroge toujours le DC le plus proche
- Equipement réseau ou de sécurité empêchant le trafic TCP: depuis la carte réseau défaillante jusqu’au firewall, tout ce qui génére des retransmissions TCP ou force les connexions à se terminer
- La charge d’Active Directory/du DC ou les paramètres de sécurité du DC (permettant d’empêcher les attaques de type DoS)
- Si un filtre personnalisé est utilisé: filtre mal construit
Assurez-vous que la complexité des critères reste raisonnable, que seuls les attributs indexés sont recherchés et que bien sûr, seuls les attributs faisant parties du “partial attribute set” sont utilisés dans le cas d’une requête GC
Informations Additionnelles (en anglais)
Et après?
Dans des articles suivants, je couvrirai:
- Possibilités additionnelles de filtrage des recherches LDAP
- Configurations détaillées pour chaque scénario
- Comment le people picker est reliés à l’authentification et à l’importation du profil (exclusivement MOSS)
- Conseils pour optimiser le people picker dans différents scénarios
Marc
(traduit de l’anglais par Anthony)
Je ne m’attendais pas à recevoir un tel retour par mail à ce sujet (si peu passionnant), et je ne parle pas que des sites de référencement. Cela me motiva donc à boucler la boucle en exécutant de nouveaux tests intensifs avec Windows 2008 (SP2) ainsi que Windows 2008 R2 afin de couvrir tous les cas de figure.
En résumé, quand la vérification de la signature PAC va-t ’elle se réaliser ?
Le tableau ci-dessous nous montre les différents scénarios possibles :
|
OS Serveur / Application
ou Service Cible
|
2003 Serveur pre-SP2
|
2003 Serveur SP2 et supérieur,
avec configuration additionnelle de la base de registre
|
2008 Serveur,
2008 Serveur R2
|
|
File & Print Sharing
|
PAS de Validation
|
PAS de Validation
|
PAS de Validation
|
|
Exchange Server
|
Validation
|
PAS de Validation
|
PAS de Validation
|
|
SQL Server
|
Validation
|
PAS de Validation
|
PAS de Validation
|
|
IIS dont le pool d’application tourne dans le contexte Local System ou Network Service
|
Validation
|
PAS de Validation
|
PAS de Validation
|
|
IIS dont le pool d’application tourne dans le contexte d’un utilisateur du domaine
|
Validation
|
Validation
|
Validation
|
En bref, la seule différence entre Windows Serveur 2003 et 2008/2008R2 est que la base de registre n’a plus à être modifiée puisque la valeur par défaut est inversée depuis 2008.
Une fois de plus, le point important ici est: si vous configurez Kerberos sur une ferme IIS (Sharepoint ou “simple” ASP.Net), la validation PAC sera TOUJOURS effectuée, quoique vous fassiez pour l’en empêcher A MOINS que l’application ne se voit accorder le droit « Autorisation d'agir dans le cadre du système d'exploitation », et en fasse usage.
Si l’application cible s’est vue accorder le privilège seTcb et en fait usage :
Accorder le privilège seTcb n’est pas suffisant parce qu’il sera désactivé par défaut jusqu’à ce que l’application le requière. Mais pourquoi en aurait-elle besoin ? Pour différentes raisons ce privilège peut être nécessaire par l’application du serveur. Deux usages courants sont expliqués dans les sections ci-dessous.
Transition de protocole
La transition de protocole est l’habilité pour une application serveur de déléguer les crédentiels d’un utilisateur vers un service back-end utilisant Kerberos, bien que non soumis de cette manière par le client.
En clair, cela signifie qu’un utilisateur peut être authentifié par un service utilisant des protocoles autres que Kerberos, tels que Basic, NTLM ou digest et que ce service, en utilisant cette particularité, transformera les crédentiels afin de les présenter à un autre serveur.
Exemple : un utilisateur qui s’authentifie à SharePoint en utilisant NTLM, désire utiliser le service de reporting qui tourne sur un second serveur. Le serveur SharePoint fera la transition nécessaire afin de transférer (appelé « déléguer ») les crédentiels de l’utilisateur au serveur SRS en utilisant Kerberos.
Ken Schaefer, MVP IIS, nous en donne un excellent aperçu sur son blog (en anglais) : IIS and Kerberos Part 5 - Protocol Transition, Constrained Delegation, S4U2S and S4U2P.
Services pour l’utilisateur (S4U – Services for user)
Les extensions S4U sont étroitement liées à la transition de protocole. Pour faire très court, elles permettent, sous certaines conditions, à une application d’effectuer un logon pour le compte de l’utilisateur sans connaître son mot de passe.
Cette caractéristique est, par exemple, utilisée dans le produits IAM (Identity Access Management) ou SSO (Single Sign-On) tels que IBM TAM/WebSEAL ou CA SiteMinder.
Pour chacune des technologies, puisque l’utilisateur ne s’authentifie pas à l’origine en utilisant Kerberos, il n’y a pas de PAC à valider.
OK. Mais finalement, pourquoi désactiver la validation PAC est si importante ?
En fait, je ne dirais pas que c’est « si important ». Cela peut permettre d’améliorer les performances sous certaines circonstances. Puisque, pour faire bref, le PAC est vérifié par l’application serveur avant d’accorder un Ticket-Granting-Service (TGS) au client, cela n’est pas effectué à chaque requête tant que le TGS reste valide (note : il existe certaines exceptions à cette règle). MAIS dans certains cas, la vérification initiale peut prendre un certain temps car 1) l’AD du client est distant (en termes de réseau, nombre de sauts, latence, bande passante, …) de l’AD du serveur ou 2) l’AS du client est trop chargé. Cela donne donc la fausse impression que l’authentification du client au serveur est ralentie alors qu’on s’attend à une nette amélioration en passant à Kerberos.
Ressources additionnelles (en anglais)
· 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
(traduit de l’anglais par Anthony)
Il existe déjà pas mal d’articles ou de de blogs traitant du sujet il est vrai. Mais ayant beaucoup travaillé pour de nombreux clients sur le sujet, j’avais envie de livrer une approche complète (toutes les étapes, y compris avant et après installation) de manière peu détaillée (lien vers de bonne sources d’informations, détaillées elles) afin de tenir dans un blog sans souffrir d’une longueur rébarbative.
Dans l’ordre voici les étapes d’une installation complète (sans toutefois tenir compte des dépendances de type comptes techniques, Active Directory, Reverse-proxy etc…)
Les Frameworks .Net
Le niveau de version des Framework dépend du code qui tournera sur vos applications.
Attention : il faudra tenir compte des redémarrages éventuels (et très probables)
Les Frameworks supportes les paramètres d’installation /q (quiet) /norestart (empêcher le redémarrage automatique si celui-ci est requis)
N’oubliez pas d’installer les MAJ si nécessaire. Les paramètres sont identiques pour la plupart
IIS
Installer IIS est relativement simple, la méthode dépendant de la version choisie :
Configurer IIS peut se révéler complexe en fonction des éléments que l’on veut paramétrer et de la version utilisée
SQL Server
L’installation de SQL dépend de la version et du choix au niveau SharePoint
Pour paramétrer SQL Server, il faut la plupart du temps recourir à des scripts en Transact-SQL exécutable à partir, par exemple, de SQLCMD (http://msdn.microsoft.com/en-us/library/ms162773.aspx) voir utiliser les SQL Management Objects (http://msdn.microsoft.com/en-us/library/ms162169.aspx et http://msdn.microsoft.com/en-us/library/dd206997.aspx) à travers PowerShell
Les Binaires SharePoint
L’installation des binaire consiste à installer les composants nécessaires à SharePoint grâce à une série de packages MSI. C’est à ce moment que le type de serveur peut-être spécifié : WFE (frontal) Application ou Standalone (incluant donc SQL Server). C’est également le moment ou la clé d’activation est fournie ainsi que la version exacte de MOSS (Standard ou Enterprise). Attention, la clé fournie prend le pas sur le paramètre.
Le tout se fait grâce à la commande setup.exe et son fichier d’entrée au format XML : WSS (http://technet.microsoft.com/fr-fr/library/cc288033.aspx), MOSS (http://technet.microsoft.com/fr-fr/library/cc262897.aspx)
Il ne faut pas oublier d’en faire de même pour la language packs (http://technet.microsoft.com/en-us/library/cc288518.aspx)
C’est également l’occasion d’incorporer les mises à jour, grâce au répertoire « Updates » (http://technet.microsoft.com/en-us/library/cc261890.aspx)
Créer ou joindre une ferme
La commande PSCONFIG effectuera les mêmes opérations que l’assistant d’installation avec un avantage : pouvoir spécifier le nom de la base de données de contenu du Central Admin et dès lors éviter l’affreux GUID : http://technet.microsoft.com/fr-fr/library/cc263093.aspx
C’est également PSCONFIG qui mettra en place l’application Central Admin.
Paramétrage de base
Paramétrage avancé
Beaucoup d’éléments de configuration (liés aux SSP en particulier) ne sont hélas pas directement accessibles via STSADM en standard. Il vous faudra soit recourir à :
Des extensions de STSADM
Du développement .Net (applications console par ex.)
Des scripts PowerShell s’apparentant à du développement (usage quasi identique des API)
Toutefois, certains paramètres avancés sont accessibles avec STSADM :
Paramétrage IIS Post-Déploiement de SharePoint
Une fois SharePoint déployé et paramétrer, la configuration IIS peut être finalisée :
- Les Applications Pools
- Les Paramètres spécifiques par Web Application
Dans les deux cas, les méthodes détaillées plus haut (section IIS) s’avèreront être suffisantes dans la plupart des cas
Gestion de sites et Ajout de contenu
Pour ajouter du contenu, il est préférable de toujours recourir à l’utilisation des API, soit avec une application soit avec PowerShell :
Active Directory
Si vous utilisez Kerberos, la commande SETSPN (http://technet.microsoft.com/en-us/library/cc773257(WS.10).aspx) facilitera le paramétrage des Service Principal Names
Si le déploiement automatisé est un facteur clé de l’industrialisation de votre environnement SharePoint, il convient de le renforcer par un Framework de déploiement afin d’en faciliter la gestion.
Le Microsoft Deployment Toolkit 2010 (http://technet.microsoft.com/en-us/solutionaccelerators/dd407791.aspx) peut s’avérer d’une aide précieuse. Il existe également des alternatives commerciales
Informations additionnelles
C’est tout pour aujourd’hui, à chaque jour suffisant sa Payne, Max!
Marc
Une petite surprise de fin d’année 2009 repointe le bout de son nez début 2010: Sur IIS6, si un site est paramétré pour utiliser l’authentification Windows Intégrée (IWA), le processus W3WP.exe servant ce site est susceptible de planter avec le code de retour 0xffffffff si Windows Server 2003 est en service pack 2 et que la mise à jour KB973917 est installée.
Ce problème est en fait causé par un certain nombre de fichiers d’IIS qui ne sont pas au niveau requis malgré la présence du service pack 2.
Petite procédure pour remettre IIS en ordre de marche et si nécessaire réinstaller cette MAJ
- Effectuer un inventaire des MAJ actuellement installées, afin de pouvoir les réinstaller si nécessaire par après. Personnellement j’utilise PsInfo pour ce faire (option –h). Mais il existe évidemment d’autres méthodes
- Ré-appliquer le Service Pack 2
- Si nécessaire, réinstaller les MAJ en fonction de l’inventaire effectué à l’étape 1
- Vérifier les niveaux de version des fichiers d’IIS. Voir “Complément d’information”
- Si nécessaire, réinstaller la MAJ KB973917
Complément d’information
Evidemment, il se peut que IIS plante pour d’autres raisons. Le code de retour devrait dans ce cas vous mettre sur la piste du coupable.
Marc
A plusieurs reprises, il m'a été donné d'aider des administrateurs ou développeurs SharePoint aux prises avec ce comportement pour le moins déconcertant: alors que les utilisateurs peuvent se connecter et s'authentifier au serveur SharePoint sans le moindre problème, les administrateurs ayant ouvert une session localement sur le serveur se voient refusés l'accès à SharePoint tout en recevant l'erreur HTTP 401.1 (Unauthorized: Access is denied).
Ce comportement est, comme souvent avec Microsoft "By Design" depuis le service pack 1 de Windows Server 2003: il a pour but d'augmenter le niveau de sécurité sur un serveur lorsque les conditions suivantes sont d'application:
- La version de l'OS est au moins Windows Server 2003 SP1
- Un utilisateur ou administrateur est loggé localement sur la console du serveur ou via RDP
- Il (ou elle, ne soyons pas macho, le système ne l’étant pas), tente d’accéder à une ressource ou un service utilisant l’authentification NTLM en passant un nom d’hôte pointant vers l’adresse de loopback (127.0.0.1) alors que ce nom d’hôte n’est pas “localhost”
Le résultat étant un “Access Denied” ou en langage HTTP, un 401.1. il est à noter que ce problème pourrait tout aussi bien se produire en accédant à un répertoire partagé, par ex.
Bien mais pourquoi est-ce alors si flagrant dans le cas de SharePoint? Il existe deux grands cas de figure dans lesquels il est fréquent de recourir à la modification du fichier HOSTS afin de faire pointer une ou plusieurs application web vers l’adresse 127.0.0.1:
- L'indexeur paramétré pour se viser lui-même, et non un autre serveur frontal. Cela se faisant soit manuellement par l’édition du fichier HOSTS, soit en laissant SharePoint s’en charger
- Les machines de développement, afin d’éviter de devoir enregistrer des noms dans le serveur DNS
Il n’est pas rare que des scripts de “warm-up” de SharePoint provoque également le problème.
Plusieurs solutions existent:
Marc