Archive

Posts Tagged ‘SID History’

SharePoint & SIDHistory

24 juin 2013 1 commentaire

Hey folks,

Récemment un client m’appel suite à une migration d’AD d’une forêt A vers une forêt B, jusque-là tout va bien, sauf pour SharePoint où des problématiques d’habilitations sont apparues.

Ces problématiques sont liées au SID History et la manière dont Windows effectue et met en cache ces requêtes Name to SID et SID to Name (qui sont en fait des lookup de l’AD).

Ce cache fait penser à SharePoint qu’un utilisateur qui souhaite se connecter provient du mauvais domaine, et SharePoint essaye de créer une nouvelle identité pour cet utilisateur.

La plupart du temps il s’agit d’un problème de people picker (configurable avec les commandes STSADM ou bien PowerShell) vous trouverez la description de ce problème ici :

http://blogs.technet.com/b/rgullick/archive/2010/05/15/sharepoint-people-picker.aspx

La solution de contournement envisagez pour résoudre cette problématique est la suivante:

Fasten your seatbelt !

Le LsaCache stocke les noms d’utilisateur déjà recherché ainsi que leur domaine et leur SID. En interrogeant un DC qui a des utilisateurs qui ont à la fois le nouveau SID et le SID migré en même temps, le DC relie toujours le SID migré vers le nouveau nom d’utilisateur, et non l’ancien nom d’utilisateur. Si nous pouvons artificiellement mapper le LsaCache avec correspondances des anciens noms d’utilisateur avec leur ancien SID, nous pouvons agir comme si aucune ressource n’a encore migré.

Voici le scénario où les utilisateurs ont été migrés avec le SID-History à partir de CHILD.domainA.com à domainB.com


  1. CHILD\Michael s’authentifie sur une machine du domaine CHILD et ouvre un site SharePoint dans le DOMAINB (intranet.domainB.com)
  2. SharePoint appel IIS, qui demande à Windows un DC local pour résoudre un SID: S-1-5-21-[SID_de_CHILD]-1010
  3. Le DC local trouve le SID assigné à l’utilisateur migré dans le catalog global
  4. Le DC local retourne le nom du compte de l’utilisateur migré, DOMAIN\Michael
  5. Le serveur SharePoint ajoute le résultat à son LsaCache comme un mapping de ce SID avec le compte de DOMAIN

Ainsi, nous pouvons voir sur la photo ci-dessus que le LsaCache (la table dans le coin inférieur droit) à appliquer pour le nouveau nom d’utilisateur l’ancien ancien SID mais nous cherchons à avoir l’ancien nom d’utilisateur avec l’ancien SID

Donc, nous allons effectuer un WarmUp du LsaCache de façon à avoir :

  1. SharePoint exécute en permanence un script permettant de requêter le nom CHILD\Michael
  2. Le DC local requête le Global Catalog et ne trouve aucun enregistrement pour ce nom d’utilisateur
  3. Le DC local doit faire sa propre requête LSA pour interroger le DC du domaine CHILD pour ce nom d’utilisateur
  4. Le DC distant du domaine CHILD trouve le nom d’utilisateur et réponds avec le SID: S-1-5-21-[SID_de_CHILD]-1010
  5. Le DC de CHILD retourne la réponse au DC du DOMAINB (le DC du DOMAINB cache le résultat dans son propre LsaCache)
  6. Le DC local retourne le résultat au serveur SharePoint
  7. Le serveur SharePoint ajoute cette nouvelle entrée à son LsaCache

Donc maintenant nous avons:

Notre cache qui interroge de la manière souhaité et nous avons l’ancien nom d’utilisateur = ancien SID. De cette façon, quand une requête est faite pour OLD SID, le résultat viendra du cache avec l’ancien nom d’utilisateur.



 

  1. CHILD\Michael s’authentifie sur une machine de CHILD et ouvre un site SharePoint présent dans le DOMAINB (intranet.domainB.com)
  2. SharePoint ne demande pas au DC local le SID, il utilise le LsaCache
  3. Le LsaCache de SharePoint réponds en retour avec le username qui est relié au SID: S-1-5-21-[SID_de_CHILD]-1010 est CHILD\Michael

L’étape importante (le X rouge) où il n’y a pas d’étape J . C’est-à-dire que le serveur SharePoint n’a jamais parlé au DC pour obtenir l’ancien SID et renvoyer un résultat, ce qui signifie que nous nous sommes appuyés sur le cache de SharePoint seul.

Cette requête repose sur le LsaCache du serveur SharePoint qui possède toujours l’entrée pour le SID du domaine CHILD correspondant au nom d’utilisateur CHILD, et jamais le nom d’utilisateur correspondant du DOMAINB .

La seule façon d’y parvenir est:

  1. Une requête constante du serveur SharePoint pour le nom CHILD\username pour chaque utilisateur dans DOMAINB qui a été migré de CHILD et qui a son SIDHistory migré avec.

    Vous pouvez utiliser un outil qui invoque LookupAccountName () pour localiser le SID pour le nom d’utilisateur: CHILD\username.

    LookupAccountName est expliquée ici: http://msdn.microsoft.com/en-us/library/aa379159(v=VS.85) .

    Je pense que PsGetSid de Sysinternals serait en mesure d’aider ici aussi.

  2. En PowerShell pour connaitre le domain\username ou le sid en fonction de l’un ou de l’autre, vous pouvez utiliser le code suivant :
    Write-Host -ForegroundColor Green « 1. Domain User to SID »

    Write-Host -ForegroundColor Green « 2. SID to Domain User »

    Write-Host -ForegroundColor Green « Other to exit »

    $choice = Read-Host « Select 1 – 2 – Other »

    Switch ($choice)

    {

    1{

    write-host -foreground Green « # DOMAIN USER TO SID »

    write-host -foreground Green « # This will give you a Domain User’s SID »

    $domain = read-host « Domain »

    $user = read-host « User »

    $objUser = New-Object System.Security.Principal.NTAccount($domain, $user)

    $strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])

    Write-host -foreground Magenta $strSID.Value

    break;

    }

    2{

    write-host -foreground Green « # SID TO DOMAIN USER »

    write-host -foreground Green « # This will allow you to enter a SID and find the Domain User »

    $SID = read-host « SID »

    $objSID = New-Object System.Security.Principal.SecurityIdentifier ($SID)

    $objUser = $objSID.Translate( [System.Security.Principal.NTAccount])

    $reponse = $objUser.Value

    Write-host -foreground Magenta $reponse

    break;

    }

    }

  3. Le LsaCache de SharePoint doit être assez grand pour être certain que les entrées qui sont requêtées ne soient jamais remplacées par les entrées du DOMAINB .

    Réglez la clé de registre HKLM\System\CurrentControlSet\contôle\Lsa\LsaLookupCacheMaxSize = (DWORD) = 0x2000 (8192 décimal)

    Si cette valeur n’existe pas, le système utilise une taille de cache par défaut de 128 entrées, ce qui est écrasée trop rapidement sur ​​les serveurs SharePoint. 8192 entrées sur une paire de serveurs équilibrés en charge devraient être en mesure de tenir toutes les SID pour tous les utilisateurs accédant au site SharePoint depuis les 2 forêts (si votre forêt a plus d’utilisateurs, vous aurez besoin d’augmenter cette valeur.

  4. Il s’agit d’une solution de contournement.

    La véritable solution serait d’avoir des utilisateurs migrés à partir CHILD.domaine.com à DOMAINB .com avec leur SIDHistory.

    Après la migration, leurs comptes CHILD doivent être désactivés ou supprimés et SIDHistory devraient être retirés des comptes DOMAINB . Il s’agit d’une action très complexe à faire, car il ne permet pas d’effectuer de test de manière simple, et le retour arrière est également extrêmement complexe.

Pour afficher les actions telles qu’elles sont effectuées par les Lookups du LSA, ajouter ces 2 DWORDs au Registre sous HKLM\System\CurrentControlSet\Control\Lsa\ :

  • LspDbgTraceOptions = 0x1 (1 signifie « enregistrer un fichier », le fichier est C:\Windows\Debug\Lsp.log)
  • LspDbgInfoLevel = 0x88888888
    (les 8 de en hexadécimal signifie « Loguer en mode verbaux autant que possible »)

Les clés de registres sont expliquées ici :

http://technet.microsoft.com/en-us/library/ff428139(v=ws.10).aspx

Donc, dans l’ensemble cela reste assez compliqué, la solution de contournement est d’augmenter la valeur pour LsaLookupCacheMaxSize et de faire fonctionner en permanence un script sur ​​le serveur SharePoint pour interroger le SID des noms d’utilisateur dans CHILD (avec un filtre pour cibler uniquement les utilisateurs qui ont été migrés vers DOMAINB).

Ceci est couvert par le CU d’Aout 2012.

Le groupe produit a ajouté une ligne de commande :

stsadm.exe -o setproperty -propertyname « HideInactiveProfiles » -propertyvalue « true »

Cela bypass les comptes désactiver et effectue une requête sur le domaine actif. L’état non supporté par Microsoft est de posséder des SID Dupliqués mais SharePoint a maintenant un peu plus de flexibilité pour travailler dans ces cas de figure.

Il existe des outils tiers permettant de ne pas avoir ce type de problème, comme AvePoint par exemple J

Quelques infos à propos de la commande STSADM –o migrateuser :

http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=75

http://technet.microsoft.com/en-us/library/cc262141.aspx

A partir du SP3 de SharePoint 2007, la notion des SID History est apparemment gérée, donc le passage du simple Service Pack de SharePoint pourrait résoudre votre problématique. Puis maintenir ces plateformes à jour est un des best practice qu’il est important de respecter (à condition évidemment de tester techniquement et recetter fonctionnellement votre solutionJ), d’autre part, le SP2 de SharePoint 2007 ne sera bientôt plus supporté par Microsoft.

A special thanks to Craig Foster (http://blogs.technet.com/b/craigf) ping back AD & SID

Enjoy & Have fun !

Publicités