Subinacl – Migration des permissions Windows sans domaine source

 Subinacl – Migration des permissions Windows sans domaine source

Read This Article in English / Lire cet article en Anglais

Introduction et généralités

Subinacl est la preuve qu’un outil peut être ancien sans être obsolète. Cet outil en ligne de commande est inclus dans le kit d’administration de Windows Server 2003, mais sa fonction reste importante dans les systèmes actuels. Subinacl permet aux administrateurs d’obtenir les informations de sécurité des fichiers, clés de registre et services. Subinacl permet de transférer ces informations entre utilisateurs, groupes et domaines. Ainsi, lors de la migration d’un domaine A vers un domaine B, l’administrateur peut transférer les autorisations de Domaine A\Utilisateur à domaine B\utilisateur. Ainsi, l’utilisateur pourra garder l’accès aux mêmes ressources à l’issue de son transfert vers le domaine B.

Migration Active Directory : Enjeux et défis

Dans le contexte d’une entreprise, migrer un Active Directory est une opération lourde. Lorsque des objets externes sont intégrés dans l’Active Directory de l’entreprise, il s’agit même d’une tache critique. En effet, le schéma classique d’une migration consiste à établir une relation d’approbation entre le domaine source et le domaine cible, puis d’effectuer la migration grâce à un outil de type ADMT. Il est toutefois impensable pour une entreprise de créer ce type de relation d’approbation avec une entité extérieure. De plus, si ce type de migration est réalisé lors de l’acquisition d’une activité, il est probable que le domaine source soit un concurrent. Il est toutefois possible de trouver des solutions techniques à ce type de problème. Une forêt intermédiaire peut recevoir les objets migrants, avant qu’une seconde migration ne les intègre au domaine cible.

Rôle du SID

Chaque utilisateur, groupe ou autre objet de sécurité possède un identifiant de sécurité (SID). Ce SID est attribué « à vie »  à l’objet, dont toutes les autres propriétés (tel que son nom, etc.) sont liées au SID. Les SID sont générés et attribués par le maître RID, un serveur dont le rôle est d’assurer leur conformité. Quand un objet reçoit des droits sur un dossier, son SID et ses droits sont ajoutés à la liste de contrôle d’accès. Cette liste contient toutes les autorisations d’accès à la ressource.

SID, SID_History et migration

Lors de la migration d’un objet grâce à ADMT, une copie de l’objet est créée dans le domaine cible. Cette copie possède un nouvel SID dépendant de sa destination. Toutefois, cet objet sera immédiatement capable d’accéder à toutes les ressources pour lesquels l’original possédait des droits. Lors de sa création, un attribut sIDHistory à été créé et rempli avec le SID du compte original. Ce sIDHistory est intégré aux tickets Kerberos, et permet au nouveau compte d’être identifié « en tant que » son ancienne identité. Ce processus permet d’éviter les interruptions de service, et permet aux administrateurs de réaliser une migration transparente. Une fois la migration des objets terminée, il convient toutefois de migrer les ACLs, afin de remplacer les SIDs du domaine source par ceux du domaine cible. Subinacl permet de faire la correspondance entre le sAMAccountName (nom du compte), identique entre les deux domaines, pour remplacer les SID du domaine source par les SID du domaine cible. Dans certains cas, en raison d’une erreur ou de l’absence du domaine d’origine, il n’est pas possible de contacter l’autorité permettant la traduction sAMAccountName en SID. Dans cette situation, il n’est normalement pas possible de migrer les ACLs, car la correspondance entre les SAMs des deux domaines n’est pas réalisable.

Conséquences des ACLs non-migrées

La première conséquence visible par les administrateurs de la non-migration des ACLs sera l’absence de traduction des SIDs en SAM dans les ACLs windows. Bien que n’impactant pas les utilisateurs, ce résultat est loin d’être trivial, car il rend l’administration des ressources quasi-impossible. Dans certains cas, l’accumulation de sIDHistory peut entraîner un dépassement de la taille du ticket Kerberos. Lorsque cette situation se produit, les utilisateurs ne sont plus capables d’ouvrir de session en raison d’une erreur Kerberos. La taille du ticket peut être réduite en purgeant l’attribut sIDHistory, mais les utilisateurs perdent alors tous les droits dont ils disposaient sur les ressources, nécessitant une ré-attribution manuelle. Il est facile de comprendre à quel point ces effets peuvent être désastreux pour l’activité d’une entreprise.

Utilisation de subinacl en mode déconnecté.

Toutes les commandes référencées dans cet article requièrent subinacl, téléchargeable depuis le site web de Microsoft, ou inclus dans Windows Server 2003 Resource Kit Tools. Ces commandes sont exécutées dans une invite de commande cmd, depuis le dossier subinacl. http://www.microsoft.com/en-us/download/details.aspx?id=23510   Dans ce type de situation, il est possible de palier à l’indisponibilité du domaine source en créant un fichier d’entrée permettant de faire correspondre les SAMs des deux domaines.

Sauvegarde des autorisations présentes sur les ressources

Avant toute exécution de subinacl en mode remplacement, j’effectue une sauvegarde des ACLs en place sur les ressources actuelles. Cette action, bien que consommatrice de temps, est à mon sens indispensable, car elle permet de restaurer les ACLs dans leur état initial si la migration ne se déroule pas comme prévu. Gardez à l’esprit que ces opérations ne font pas partie d’une migration normale, et sont généralement effectuées sur un environnement de production trop important pour se permettre un temps d’arrêt ou une restauration de serveur. Cette sauvegarde peut être réalisée grâce à  subinacl : Sauvegarde des autorisations de partage (si la ressource est un partage) subinacl /noverbose /errorlog=[path\logfile.txt] /share [targetpath] /display > [path\saveshare.txt] Sauvegarde des autorisations sur la racine de la ressource subinacl /noverbose /errorlog=[path\logfile.txt] /file [targetpath]  /display > [path\savefile.txt] Sauvegarde des autorisations sur le contenu de la ressource subinacl /noverbose / errorlog=[path\logfile.txt] /subdirec [targetpath]\*.* /display > [path\savepath.txt]   En cas de besoin dans la suite du processus, il sera possible de revenir à l’état sauvegardé grâce aux commandes suivantes : Restauration des autorisations de partage (si la ressource est un partage) subinacl /outputlog=[path\outputfile.txt] /errorlog=[path\logfile.txt] /playfile [path\saveshare.txt] Restauration des autorisations sur la racine de la ressource subinacl /outputlog=[path\outputfile.txt] /errorlog=[path\logfile.txt] /playfile [path\savefile.txt] Restauration des autorisations sur le contenu de la ressource subinacl /outputlog=[path\outputfile.txt] /errorlog=[path\logfile.txt] /playfile [path\savepath.txt]

Création du fichier entrée

Le fichier d’entrée (.txt) devra comprendre les SID de tous les objets listés dans les ACLs des ressources à migrer, au format suivant :

_cachefileonly_=s-1-9-cacheonly [Domain]=SID [Domain\UserName | Server\UserName]=SID [Domain\UserName | Server\UserName]=SID

Il existe plusieurs méthodes pour remplir ce fichier. L’une d’entre elles consiste à utiliser PowerShell pour cette collecte d’information, grâce aux commandes Get-ADUser et Get-ADGroup Get-ADUser -filter <votre filtre> | ft SamAccountName , SID Get-ADGroup -filter <votre filtre> | ft SamAccountName , SID Une fois le fichier d’entrée renseigné avec les SAMs et les SIDs de deux domaines, le traitement peut être lancé.

Exécution de Subinacl en mode déconnecté

Subinacl recherchera la correspondance entre les SAMs dans le fichier d’entrée. Lorsque le paramètre /offlinesam est présent Subinacl ne recherche pas les SAMs, même si un des domaines est disponible. Il convient donc de renseigner toutes les informations nécessaires dans le fichier d’entrée. Migration des autorisations de partage (si la ressource est un partage) Subinacl /outputlog=[path\outputfile.txt] /errorlog=[path\logfile.txt] /offlinesam=[path\offlinesamfile.txt] /share [targetpath] /changedomain=[sourcedomain]=[tagetdomain] Migration des autorisations sur la racine de la ressource Subinacl /outputlog=[path\outputfile.txt] /errorlog=[path\logfile.txt] /offlinesam=[path\offlinesamfile.txt] /file [targetpath] /changedomain=[sourcedomain]=[tagetdomain] Migration des autorisations sur le contenu de la ressource Subinacl /outputlog=[path\outputfile.txt] /errorlog=[path\logfile.txt] /offlinesam=[path\offlinesamfile.txt] /subdirect [targetpath]\*.* /changedomain=[sourcedomain]=[tagetdomain]   A l’issue de la migration, les ressources possèdent des autorisations correspondantes au domaine cible. Il est alors possible de purger les sIDHistory, et de nettoyer les ACLs.

En conclusion

Ce type d’opération m’a déjà permis d’obtenir de bons résultats dans des cas où il était impossible d’accéder au domaine source. Toutefois, il est bien plus simple et efficace de migrer les ACLs en même temps que les objets. Si subinacl est toujours un outil pratique et robuste, il accuse son âge pour ce qui est de sa vitesse d’exécution. Il n’est pas étrange pour subinacl de travailler pendant plusieurs heures, voir jours sur des ressources de taille importante.