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)
Certains posts dans les newsgroups ainsi qu’un de mes clients m’ont remémoré ce message d’erreur rencontré lorsqu’un utilisateur visite un site web ou tente d’utiliser une application web hostée sur IIS.
Les requêtes/réponses HTTP contiennent deux parties: l’en-tête (header) et le corps (body). L’en-tête contient la plupart du temps des informations techniques échangées entre le client et le serveur; le corps contient des informations orientées utilisateur telles que le contenu d’une page web ou d’un fichier à télécharger par exemple. Le message d’erreur ci-dessus est en fait généré par le serveur parce que la requête envoyée par le client contient un en-tête qui est simplement trop large par rapport à ce que le serveur s’attend à recevoir. Mais qu’est-ce qui peut faire qu’un en-tête devienne si large? Tout dépend de la manière dont le navigateur (browser) est configuré (et parfois même le système d’exploitation sous-jacent dans certains cas), mais la plupart du temps les responsables sont les cookies (header: Cookie) et les informations d’authentification (Header: Autorization).
Lorsqu’on rencontre cette erreur sur un site Internet, il n’y a pas grand ’chose à faire si ce n’est nettoyer ses cookies et espérer que cela fonctionnera après.
Lorsque cette erreur survient dans un environnement intranet où les serveurs web tournent sous IIS et évezntuellement Sharepoint, SQL server reporting services ou Exchange avec OWA, elle est certainement causée par une combinaison des différents facteurs suivants:
- le serveur (ou site) web est configuré pour utiliser l’authentification Windows intégrée et Kerberos en particulier
- le client est capable de s’authentifier en utilisant Kerberos (le poste client et l’utilisateur sont membres d’une forêt Active Directory (AD))
- la taille du jeton de sécurité (security token) est large. Cela peut être causé par le fait que l’utilisateur soit membre de beaucoup de groupes AD (des centaines), que l’objet utilisateur dans AD contienne des informations dans son SID history relatives à des migrations/consolidations de domaines, que les groupes dont l’utilisateur est membre sont aussi affecés par le SID history tout comme l’utilisateur
- Le client envoie des informations d’authentification ET d’autorisation basées sur Kerberos. Contrairement aux méthodes NTLM et Basique qui n’envoient que des informations d’authentification et donc plus petites en taille, Kerberos inclut des informations telles que les groupes dont l’utilisateur est membre (group membership) ainsi que le SID history dans l’entête de la requête.
-> Suivant leur appartenance aux groupes et les informations contenues dans le SID History, certains utilisateurs peuvent être affectés alors que d'autres pas...
Heureusement, il existe plusieurs manières de contourner ce problème, bien que chacune d’entre-elles a ses inconvénients:
Utiliser l’adresse IP dans l’adresse URL au lieu des noms d’hôtes
Puisque Kerberos ne fonctionne qu’avec des noms d’hôtes, l’utilisation d’adresses IP forcera automatiquement la négociation NTLM. Bien sûr, cela ne dégrade pas que la sécurité, mais cela implique également de coder les adresses IP en dur, ce qui est rarement pratique et surtout signifie qu’un et un seul site web est hosté sur votre IIS. De plus, si votre application utilise la “délégation” de credentiels, qui est une caractéristique de Kerberos, cela ne fonctionnera plus (Je pense particulièrement à SQL SRS dans ce cas ou même Exchange OWA lorsqu’utilisé dans un scénario Front End-Back End)
Configurer IIS pour n’utiliser qu’NTLM
Dans le cadre de la configuration de l’authentification intégrée à Windows, vous pouvez simplement configurer IIS afin de n’utiliser que NTLM. Pour ce faire, il suffit de suivre l’article de la base de connaissances de Microsoft (MS KB) suivant: http://support.microsoft.com/kb/215383/fr
Bien que l’impact de cette configuration soit moins importante que celui de la première, il subsiste des problèmes de sécurité et de compatibilité avec Kerberos s’il est requis par votre application.
Configurer IIS pour accepter des en-têtes plus larges
Cela peut se faire en configurant IIS via la base de registres. Il est important de noter que cette configuration s’appliquera à tous les sites web tournant sur le même système qui tourne IIS parce ce paramètre est utilisé au niveau du composant kernel (http.sys). De ce fait, il impactera tous les applications sur ce server.
L’article MS KB suivant explique tous ces settings: http://support.microsoft.com/kb/820129/fr; celui à changer est MaxFieldLength. Cette opération doit se faire avec précautions car cela augmentera la taille de la mémoire utilisée par le système pour prendre en charge les requêtes. Sur un système 32 bits “assez chargé” (entendez: qui reçoit de nombreuses requêtes, non pas quelques requêtes larges), cela peut épuiser les resources allouées au kernel. Si boot.ini est configuré avec le paramètre /3G (éventuellement combiné au paramètre /USERVA), la situation peut empirer puisque moins de mémoire sera disponible pour le kernel. Sur un système 64bits, cette configuration sera sans danger, même si l’application tourne en mode 32 bits puisque c’est maintenu en mode kernel. Bien entendu, faites attention à ce que l’application fait avec ces en-têtes...
Prévoir une cure amaigrissante de vos utilisateurs AD
En réduisant (comprendre optimisant) l’appartenance aux groupes et en retirant les informations contenues dans le SID History des objets AD des utilisateurs et des groupes. Bien que cette solution soit profitable dans tous les scénarios et non pas uniquement ceux concernant l’authentification web (logon plus rapide, utilisation de mémoire réduite sur les serveurs, serveurs de boîte de mail Exchange, ...), cette solution ne doit jamais être implémentée sans une évaluation prudente de l’impact. L’article MS KB suivant explique comment automatiser cette tâche: http://support.microsoft.com/kb/295758/fr
Et maintenant quelques éléments d’information:
- Puisque cette erreur est générée par le driver HTTP.SYS, elle sera enregistrée dans HTTPERR.LOG et non pas dans un autre fichier de W3C. Afin de tracer qui est affecté, il suffit simplement de regarder l'adresse IP mentionnée dans le fichier log. Bien sûr, puisque l'information d'authentification ne peut pas être prise en charge, l’identité de l’utilisateur reste inconnue.
- Afin d’estimer la taille du jeton pour tous type d’utilisations, et non dans ce cas précis, Microsoft met à disposition l’outil suivant : http://www.microsoft.com/downloads/details.aspx?FamilyID=4A303FA5-CF20-43FB-9483-0F0B0DAE265C&displaylang=en
- La manière dont IIS traite les en-têtes et donc l’information relative à l’autorisation est une chose; la manière dont Windows, en général, traite les jetons de large taille en est une autre. Assurez-vous d’être consistant dans la manière dont l’authentification est traitée de bout en bout. Pour plus d’information, référez-vous à l’article MS suivant: http://www.microsoft.com/downloads/details.aspx?familyid=22DD9251-0781-42E6-9346-89D577A3E74A&displaylang=en (en anglais)
- un bon outil de surveillance du réseau (j’aime l’appeler http://www.wireshark.org/) ainsi qu’un bon outil de troubleshooting tel que MS WFetch (http://www.microsoft.com/downloads/details.aspx?FamilyID=b134a806-d50e-4664-8348-da5c17129210&DisplayLang=en) seront de grand aide pour le troubleshooting. Comme d’habitude, MS Logparser sera votre meilleur ami lorsqu’il s’agira d’analyser des log IIS. Jetez un coup d’oeil à ce forum pour vous aider à parser et comprendre HTTPERR.LOG: http://forums.iis.net/1141.aspx ou continuez de lire ce blog pour d’autres scripts LogParser
- Par facilité, j’utilise le terme “Kerberos” pour parler du protocole d’authentification entre un client et le serveur web. Le protocole réellement impliqué est SPNEGO ou “Négociation”, qui comporte plusieurs protocoles d’authentifications. Référez-vous à wikipedia pour plus de détails: http://en.wikipedia.org/wiki/SPNEGO
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
La consolidation est à la mode, Exchange n'y échappe pas. Moins de serveurs donc plus de BALs sur le même serveur. Idem pour les contrôleurs de domaine AD.
Récemment, un client en pleine phase de consolidation m'a fait part d'un problème d'authentification impactant uniquement les utilisateur d’Outlook et ce de manière récurrente: “aléatoirement”, les utilisateurs reçoivent une boîte de dialogue émanant d’Outlook leur demandant de se ré-authentifier. Les administrateurs Messagerie ayant tôt fait de décréter qu’il s’agissait d’un problème AD, l’équipe en charge dudit AD a commencé à chercher les problèmes d’ouvertures de session, de comptes verrouillés etc… Mais rien de visible au niveau des contrôleurs de domaine: pas de “logon failed”, de mot de passe expiré, en tout cas pas pour les utilisateurs subissant ce désagrément. Plus étrange encore, ce sont les utilisateurs d’un même site qui se plaignent, mais les utilisateurs impactés sont différents chaque jour (!).
Décision fut prise de prendre une trace réseau à partir du contrôleur de domaine dédicacé à ce site et également utilisé pour les opérations MAPI/NSPI. Verdict: le DC retourne à certains clients le message “MAPI_E_LOGON_FAILED” alors que l’utilisateur est bel et bien authentifié avec certitude. Après investigation, le coupable est une nouvelle option de sécurité au niveau AD qui limite le nombre de connections MAPI/NSPI concurrentes à 50 (par défaut) sur les DC tournant sous Server 2008 et retourne donc l’erreur MAPI_E_LOGON_FAILED à Outlook. Celui-ci l’interprétant correctement cad en demandant de saisir nom d’utilisateur et mot de passe à nouveau.
Fort heureusement, il est possible d’augmenter cette limite de conncetions voire de revenir au comportment d’application sur les versions antéreures de Windows (2000-2003). L’article du support MS ci-dessous fournit les explications, la solution ainsi que le niveau de logging à configurer pour qu’un événement soit écrit de le log de Windows dès que la limite est atteinte.
On aurait évidemment préféré que le protocole côté serveur retourne un message plus en rapport avec la cause exacte, dans le style “Too many concurrent connections” par ex…
Marc
Microsoft a récemment publié un outil à destination des organisations de taille petite à moyenne (Max 20 serveurs, 500 postes clients) afin de faciliter l’évaluation du niveau de qualité de l’infrastructure Microsoft qu’elles opèrent.
Cet outil, basé sur le moteur “Best Practice Analyzer (BPA)”, se concentre sur l’analyse des éléments-clés suivants:
- Etat des contrôleurs de domaine
- Réplication Active Directory et SYSVOL
- Synchronization du temps (NTP…)
- Résolution de noms (DNS)
- Le configuration réseau des serveurs en général (AD et Exchange)
- Des éléments de configuration Exchange fortement liés à AD (objets, connecteurs AD…)
Son installation et son éxécution nécéssitent bien évidemment des privilèges administratatifs sur toutes les machines à analyser. L’éxécution quant à elle est facile et centralisée, à partir de la machine connectée au domaine sur laquelle il est installé, les connections à distance se faisant grâce à WMI. Les OS à partir de Windows Server 2003 SP2 sont supporté. L’installation requiert le framework .NET 2.0.
En pratique, son éxécution prend la forme d’un assistant vous guidant pas à pas. Etant donné sa simplicité d’utilisation, je ne m’attarderai que sur les points les plus importants selon moi, soit les suivants.
L’outil ayant la faculté de se mettre à jour lors de chaque éxécution, il est impératif de décocher la case “Install available updates (recommended)” si la machine sur laquelle vous l’éxécutez n’est pas en mesure de se connecter à Internet. Il n’est pas inutile de mettre à jour le client Windows Update de la machine sur laquelle vous l’éxécuterez si vous comptez utiliser la fonctionalité de MAJ.
Au cours de la configuration, le terme “primary firewall” signifie en fait “passerelle par défault”, ce qui rejoint bien le type de réseau en place dans la plupart des infrastructures de type PME/PMO
Il est évident que pour permettre l’utilisation de WMI, les machines distantes doivent être configurées correctement au niveau de leur firewall (si applicable bien sur)
l’outil éxécutera tous les tests pour lequel il est prévu, je n’ai pas trouvé de moyen standard de spécifier de tests spécifiques (cela semble possible en bidouillant le fichier XML de configuration, ce que l’on ne recommandera pas évidemment). L’éxécution peut prendre du temps, en fonction de la complexité de l’infrastrcture, du nombre de serveurs, de l’état de ceux-ci voire des problèmes potentiellement rencontrés.
L’outil rapportera un status “Completed" si le test s’est bien passé OU si celui-ci n’est pas applicable (!). Cela peut créer un peu de confusion. Exemple: dans mon environnement de test, pas d’organisation Exchange présente, les tests Exchange passent pourtant tous au vert…
Si vous souhaitez conserver un rapport d’éxécution détaillé, il ne faut pas oublier de cliquer sur le bouton “Open larger view” ou récupérer le ficher XML correspondant sous C:\Microsoft IT Environment Health Scanner\Wizard\Data. Le bouton ”Open larger view” ouvrant en fait un Internet Explorer montrant le rapport au format XML présenté correctement (voir l’exemple ci-dessus concernant les tests Exchange)…
Visiblement, l’outil ne teste pas les trusts et encore moins les configurations à forêts multiples. Logique, vu son public-cible.
Il est également un peu “sensible” au niveau de la configuration DNS: zone intégrée à AD, délégation, glue records… Mais ce n’est pas plus mal pour garantir une infrastructure saine!
Conclusions
Suffisament complet et facile à utiliser, c’est un très bon outil pour les administrateurs de petites structures. Il peut être idéalement complété par l’Exchange Best Practices Analyzer si nécessaire.
Marc