Chose promise chose dûe !

Bonjour tout le monde!

je vous avais promis du lourd. Je vous offre du très très lourd !

Il s’agit d’un outil de restauration Active Directory qui devrait en réjouir plus d’un.

Pour les plus pressés, Il est disponible depuis le lien suivant: http://admagicrestore.codeplex.com/

Et pour ceux qui veulent en savoir plus: AD Magic Restore: outil de restauration AD

Je vais essayer de faire une série d’articles complémentaire pour approfondir son utilisation mais pour le moment ca sera tout !

 

A bientôt et… MERCI! Le site a connu encore une progression de sa fréquentation et compte plus de 120 000 visites encore pour cette année.

AD Magic Restore: outil de restauration Active Directory

Sommaire

 

 

Introduction

AD Magic Restore est un outil qui va vous permettre de restaurer rapidement et en toute simplicité vos objets Active Directory de manière complète ou partielle. Il est publie sur Codeplex depuis le lien suivant: http://admagicrestore.codeplex.com/

L’avantage de mon outil par rapport à Corbeille AD (pour ceux qui ont la Corbeille AD…) : la fonctionnalité de comparaison et de restauration granulaire.

L’outil est un script développé en PowerShell. Il dispose d’une interface graphique pour faciliter son usage.

Il s’appuie essentiellement sur les composants et/ou outils suivants:

  • DSAMAIN pour l’instanciation du fichier ntds.dit
  • Les clichés instantanés de volume (volume shadow copy) ou sauvegarde locale réalisé avec Windows Server Backup (le remplaçant de NTBackup)
  • Module PowerShell Active Directory de Microsoft
  • Web Services Active Directory ou service passerelle de gestion Active Directory
  • Esentutil, diskpart…

 

 

Pre-requis et limitations

L’outil exige qu’il soit exécuté à minima sur un serveur membre Windows Server 2008 avec la fonctionnalité Windows ‘AD-Domain-Services’ (module Active Directory et outil DSAMAIN) et que vous disposiez du web service Active Directory sur au moins un de vos contrôleurs de domaine (disponible dès Windows Server 2003 R2). Si vous respectez ces pré-requis, vous pourrez au moins instancier votre base de données depuis un fichier NTDS.DIT récupéré depuis un de vos contrôleurs de domaine restaurer vos objets de votre fichier vers la base de production.

Si vous voulez exploiter les fonctionnalités « Snaphots » ou/et « Backups », il sera impératif d’utiliser l’outil directement depuis un contrôleur de domaine.

L’outil ne fait tous les miracles. Il ne peut pas restaurer un objet purgé. En effet, si votre objet a été purgé de la base, l’outil ne sera pas en mesure de restaurer des attributs tel que le objectSid ou l’objectGUID. Cela signifie que la restauration de vos objets ne pourra se faire une fois que l’objet supprimé à dépasser la valeur de rétention définie par l’attribut « tombstonelifetime » (60 jours ou 180 jours par défaut selon votre environnement).

L’outil a été pas mal éprouvé mais j’ai rajouté au fur et à mesure certaines nouvelles fonctionnalités qui peuvent générer des bugs. Utilisez-le Donc avec précautions. D’ailleurs toute remontée sera la bienvenue (ajout de fonctionnalités, bugs…).

Pour le moment, je n’ai pas pu tout testé mai j’ai déjà quelques autres mises en garde et/ou limitations :

  • Restauration du mot de passe impossible
  • Restauration des clés BitLocker non-testée
  • Restauration de l’attribut « sIDHistory » non-testée
  • Identification des attributs protégés non-exhaustive (possibilité de gérer manuellement une liste d’exceptions depuis la variable « $script:CustomExcludedAttributes »)

 

 

Présentation générale


L’interface graphique est constituée de trois parties principales :

  • « Data Source » (1): sélection de la source de données utilisée par le script pour restaurer vos objets sur votre environnement de production. Vous pouvez utiliser un sauvegarde locale (sauvegarde complète sur un volume dédié avec un point de montage), un cliché instantané (via ntdsutil, mon script), en spécifiant un fichier NTDS.DIT ou en vous connectant à une instance DSAMAIN distante.
  • « Data Destination » (2): sélection de la partition Active Directory de destination. En général vous utiliserez ce qu’on appelle la  partition « default naming context » mais si vous devez restaurer, par exemple un sous-réseau, il faudra passer par la partition de « configuration », pour un enregistrement DNS vous sélectionnerez probablement la partition « domaindnszones » ou « forestdnszones ».
  • « Search » (3): sur les trois, c’est la plus importante. Depuis cette section, vous serez à même de rechercher les objets depuis votre instance AD source et de restaurer les objets ou/et attributs sur l’AD de destination. Les options de comparaison et de restauration sont accessibles à l’aide d’un menu contextuel qui s’affiche lorsque vous faites un clic droit sur l’objet sélectionné.

 

 

La zone « Data Source »

  • Connection : vous pouvez pointer à peu près sur n’importe quelle instance LDAP. La seule condition est de disposer du Web Service Active Directory.

 

  • Exploitation d’une sauvegarde : le script détecte la présence de sauvegardes complètes et stockées sur un volume dédié à l’aide de Windows Server Backup. Pour garantir le fonctionnement de cette fonctionnalité, vous devrez à minima attribuer une lettre de lecteur à ce volume (par défaut ce n’est pas le cas avec Windows Server Backup). Pour faire simple, le script monte le cliché instantané de la sauvegarde sélectionnée. Il monte ensuite le VHD de la sauvegarde à l’aide de « DISKPART »  afin de pouvoir en parcourir le contenu. Enfin, il instancie le fichier « ntds.dit » à l’aide de « DSAMAIN ».

 

  • Exploitation d’un clic instantané : liste les clichés instantanés du volume dédié à votre base Active Directory, monte le cliché sélectionné et l’instancie à l’aide de « DSAMAIN ».

 

  • Exploitation d’un fichier NTDS : vous pouvez spécifier un fichier NTDS de votre choix que l’outil se chargera d’instancier. Les options « Repair file » et « Upgrade database » sont impératives si vous spécifiez un fichier « ntds.dit » provenant d’un contrôleur de domaine Windows Server 2003.

 

Pour finir, vous disposez de deux options spécifiques pour l’exploitation de votre source. La première concernant la durée d’attente avant que l’instanciation soit annulée. Par défaut, elle est définie à 2 minutes mais elle devra sans doute être augmentée si votre base est volumineuse et que vous faire une réparation via l’onglet « File ».

La deuxième option concerne le port sur lequel la base sera instanciée par NTDS.  Je vous conseille de jouer avec en cas de problème pour instancier votre source. Ça peut débloquer pas mal de situations…

 

 

La zone « Data Destination »

Pas besoin de trop s’attarder sur cette partie. Vous disposez par défaut de plusieurs partitions d’application sur Active Directory. Selon le type d’objet à restaurer, il vous faudra sélectionner la bonne. De plus, ce n’est pas très explicite mais en réalité cela détermine aussi la partition source utilisée par le script.

 

 

La zone « Search »

Comme je l’ai dit plus haut, c’est la zone principale du script. C’est à partir d’elle que vous réaliserez les opérations de recherche, de comparaison et de restauration.  Je vais avant tout vous présenter les différents filtres de recherche des objets. A noter que les recherches sont réalisées systématiquement depuis la source de données.

 

  • « Filter » (1) : pour spécifier le nom ou le nom d’ouverture de session (attribut « sAMAccountName ») de l’objet à retrouver depuis votre source de données. Notez que vous pouvez utiliser un « wildcard » (une étoile), pour vos recherches.

 

  • « Container » (2) : pour retourner uniquement les objets situé dans une unité d’organisation spécifique. Vous pouvez le coupler avec les autres options de filtre.

 

  • Les cases à cocher « Login » et « Name » (3) : définis principalement l’attribut utiliser par « Filter » (1). Par défaut, la recherche sera faite exclusivement sur l’attribut Active Directory  « sAMAccountName » (cela correspond à la case à cocher « Login »). Vous pouvez également ajouter dans vos critères de recherche l’attribut Active Directory « Name ». Cela peut s’avérer particulièrement utile pour les objets ne disposant pas de l’attribut « sAMAccountName ».
  • « Result size » (4) : vous permettra de limiter le nombre de résultats retourné sur votre recherche.
  • « Class » (5) : un autre filtre qui offre la possibilité de retourner des objets d’une classe spécifique.  Il s’agit en réalité d’un filtre sur l’attribut Active Directory « objectClass ».
  • Le bouton « Search » (6) et « Cancel » (7) : Lorsque que vous avez spécifié vos critères de recherche, vous pouvez l’exécuter en cliquant sur le bouton « Search ». Pour une raison ou une autre, vous pouvez décider l’annuler à l’aide du bouton « Cancel ».

 

Une fois que la recherche vous retourne le ou les objets voulus, vous pouvez faire apparaître une liste d’actions en sélectionnant l’objet et en réalisant un clic doit depuis la zone de résultat. Un menu contextuel apparait. Les actions disponibles depuis ce menu vont varier en fonction de la nature de l’objet (par exemple s’il s’agit d’un groupe ou d’un compte utilisateur) ou en fonction de son état (objet supprimé ou présent dans l’annuaire de destination.

Exemple 1 : un objet utilisateur supprimé sur votre annuaire de destination.

 

Exemple 2 : un objet groupe existant sur votre annuaire de destination.

 

 

Liste des opérations possibles depuis le menu contextuel

Vous avez donc la possibilité de réaliser différentes actions sur un objet en fonction de son état ou de sa classe. Les actions sont disponibles depuis un menu contextuel qui apparait lorsque vous sélectionnez un objet et que vous faites un clic droit sur un des résultats obtenus dans la zone « Search ».

Les actions sont :

  • « Reanimate » : pour réanimer un objet tombstone.
  • « Restore Object » : pour restaurer de manière complète un objet. Cette action englobe l’action « Reanimate », « Compare » (restauration des attributs), « Restore Memberships » et éventuellement « Restore Members » si l’objet est un groupe ou « Restore Subtree » si l’objet dispose de sous-objet (Unité d’organisation, objet utilisateur, objet ordinateur…).
  • « Compare » : pour comparer les différences entre un objet source et un objet de destination. Il est possible de restaurer les valeurs de chaque attribut de la source vers la destination.

 

  • « Restore Memberships » : pour visualiser les appartenances éventuellement manquantes sur l’objet de destination par rapport à l’objet source. Le cas échéant, vous pouvez restaurer tout ou partiellement ces appartenances.

 

  • « Restore Members » : cette action n’est disponible que pour les objets groupe. Elle permet d’obtenir la liste des membres d’un groupe manquant entre la source et la destination. De la même manière que la fonctionnalité « Restore Memberships », elle vous permet de restaurer tout ou partiellement les membres d’un groupe.

 

  • « Restore Subtree » : Cette action permet de restaurer les objets enfants de l’objet à restaurer. L’action est uniquement disponible si l’objet dispose réellement de sous-enfants. Cela concerne principalement les unités d’organisation mais pas seulement. En effet, par exemple les objets utilisateur et ordinateur sont considérés comme des conteneurs pouvant disposer d’objets enfants.

ATTENTION : cette fonctionnalité peut être utilisée pour restaurer une hiérarchie complète  d’objets mais le script est surtout développé pour de la restauration granulaire. Pour restaurer une hiérarchie complète, je vous conseille vivement d’utiliser une restauration autoritaire.

 

 

Restaurer un objet

Je vous fais maintenant une présentation pas-à-pas d’une restauration d’un objet utilisateur.

La première étape consiste à sélectionner une source de données. Vous avez du choix… dans l’exemple ci-dessous, je choisi un cliché instantané. En cliquant sur le bouton « Connect », le script me monte le cliché instantané et me l’instancie à l’aide de « DSAMAIN ».

 

Ensuite, il faut sélectionner la partition Active Directory de destination depuis la liste déroulante et en cliquant sur le bouton « Select ».

 

Je lance ma recherche (voir la présentation de la zone « Search » pour plus de détails). Faites un clic droit sur l’objet à restaurer et sélectionner l’action « Reanimate ». Vous remarquez sans doute l’action « Restore Object » mais je vous en parlerez un peu plus tard.

 

Le script vous demande une confirmation sur la réanimation de l’objet. Une fois confirmée, le script doit vous retourner le résultat de la réanimation.

 

Pour ceux qui ne savent pas exactement ce qu’est une réanimation, je vais faire simple. Lorsque vous supprimez un objet dans l’AD, il est conservé temporairement  et pour une durée déterminée afin de faire répliquer cette demande de suppression sur l’ensemble des contrôleurs de domaine de votre domaine. Pour limiter l’espace utilisé par cet objet qui est considéré comme supprimé, il est dépourvu de la plus part de ces attributs (par exemple ces appartenances). On peut considérer cet objet comme supprimé mais pas encore purgé et on peut donc intervenir avant la purge pour qu’il redevienne un objet au sens classique du terme. On appelle cette opération une réanimation d’objet tombstone. Par contre, et c’est là que le script intervient, la réanimation ne peut restaurer les attributs qui ont été définitivement supprimés lors de la demande de suppression.

Nous allons restaurer maintenant les attributs de l’objet réanimé. Sélectionnez de nouveau l’objet et Refaites un clic droit sur la zone de résultats. Si tout se passe bien, vous devriez avoir l’action « Compare » qui apparait. Sélectionnez-là.

 

Une nouvelle fenêtre apparait. Elle vous liste l’ensemble des attributs divergents entre la source et la destination. Sélectionnez ceux que vous désirez restaurer et cliquez sur le bouton « Restore ». Le script doit vous retourner le résultat de l’opération.

 

La dernière étape consiste à restaurer les appartenances aux groupes de vos objets. C’est une fonctionnalité  que j’ai décidé de traiter séparément des autres attributs afin de pouvoir avoir une réelle granularité dans la restauration des appartenances.

Faites donc de nouveau un clic droit sur l’objet sélectionné et cliquez sur l’action « Restore Memberships ».

 

Une nouvelle fenêtre apparait. Vous obtenez la liste des groupes auxquels l’objet appartient depuis la source de données. Il vous suffit des sélectionner tout ou une partie de ces groupes et de cliquer sur le bouton « Restore ».

 

Votre objet est restauré ! Pas mal non ? Peut-être un peu fastidieux toutefois… mais vous pouvez faire plus rapide.

Je vous ai montré  dans le détail les étapes de restauration pour que vous ayez une meilleure compréhension de l’outil. Mais, en fait, en sélectionnant l’option « Restore Object », vous faites la réanimation, la restauration des attributs et des appartenances en une seule fois. Encore mieux n’est-ce pas ?

 

 

La zone « Tombstones »

Lorsque vous cliquez sur le bouton « View / Manage » en bas à gauche de la fenêtre principale, vous accédez à une nouvelle fenêtre dédiée aux objets tombstones.

 

Les deux avantages principaux sont :

  • Une recherche directe depuis votre annuaire de production
  • La restauration de plusieurs objets à la fois.

 

La fenêtre « Manage Tombstones » est assez similaire à la zone « Search ». Des fonctionnalités de filtres de recherche pour aider à retrouver rapidement le ou les objets voulus (1). La zone de résultats n’intègre pas de menu contextuel mais, par contre, vous pouvez sélectionner plusieurs objets (3). Une fois fait, vous pouvez choisir soit de réanimer, soit de restaurer (4) les objets sélectionnés.

Passer par « Manage Tombstones » peut s’avérer utile lorsque vous êtes certains de votre source de données. En fait, vous n’avez aucun contrôle sur la source donc il est possible que vous puissiez seulement réanimer vos objets sans en restaurer l’ensemble de leurs attributs. A utiliser donc avec précaution.

Ca bouge !

Bonjour gentil visiteur,

Je suis ravi de t’apprendre que le site à déjà dépassé les 100 000 visites cette année. On devrait donc battre un nouveau record d’affluence sur cette année 2014. Ca fait très plaisir surtout que c’est mon unique salaire !

J’ai ralenti la cadence des publications sur cette année mais je vous prépare quelques petites surprises pour la finir en beauté. Je vous ferai signe via Twitter lorsque le moment sera venu. Mais, je peux d’ores et déjà vous dire que ca vaudrait le coût ! Donc … Follow me !!!

Merci pour votre fidélité et bonne visite!

Audit and disable SSLv2 connections on your domain controllers

SSLv2 is considered as a weak cipher since a long time now but it still enabled by default on your domain controllers.

To disable it, you just have to set the following registry key value (http://support2.microsoft.com/default.aspx?scid=kb;EN-US;245030) :

  • Path : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server
  • Name : Enabled
  • Type : REG_DWORD
  • Data : 0

 

But, before you disable this cipher, you have to be sure that it’s not used anymore … The best way to do the job, is to activate the verbose of the SCHANNEL.

Set the following registry key :

  • Path : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging
  • Name : EventLogging
  • Type : REG_DWORD
  • Data : 4

 

When it’s done, you should received some new events in your System log, with source « Schannel » and event Id « 36880 ».

The message contains the type of cipher used.

In this first example, TLS 1.0 is used.

 

In this second example, SSL 2.0 is used.

 

You just have to audit during a few days the cipher activities on your domain controller then disable the cipher and the schannel verbose mode.

Identify writeable AD attributes with PowerShell

You should be able to retrieve easily the list of attributes which are writeable by using the constructed attribute allowedAttributesEffective (http://msdn.microsoft.com/en-us/library/ms675218(v=vs.85).aspx).

{codecitation style= »brush: PowerShell »}

$ADObject = New-Object system.DirectoryServices.DirectoryEntry (« LDAP://CN=alexandre augagneur,CN=Users,DC=corpnet,DC=net »)

$ADObject.RefreshCache(« allowedAttributesEffective »)

$ADObject.properties.allowedAttributesEffective

{/codecitation}

However, the constructed attribute returns some attributes which can’t be changed… So we have to do something more.

The best way I found is to retrieve all attributes which are protected by the system (http://msdn.microsoft.com/en-us/library/ms680025(v=vs.85).aspx). When it’s done, i’m just removing each of them from the list of allowed attributes returned by the constructed attribute allowedAttributesEffective.

{codecitation style= »brush: PowerShell »}

$SystemOnlyAttributes = @()

$TrulyAllowedAttributes = @()

 

 

# Get the desired object based on its distinguishedName

$ADObject = New-Object system.DirectoryServices.DirectoryEntry (« LDAP://CN=alexandre augagneur,CN=Users,DC=corpnet,DC=net »)

 

# Retrieve the constructed attribute ‘allowedAttributesEffective’

$ADObject.RefreshCache(« allowedAttributesEffective »)

 

# Store the list of allowed attributes  in a variable

$allowedAttributesEffective = $ADObject.properties.allowedAttributesEffective

 

# Retrieve the list of attributes in the schema which are protected

$ObjRootDSE = [ADSI] « LDAP://RootDSE »

$ADSearcher = new-object system.DirectoryServices.DirectorySearcher

$ADSearcher.SearchRoot = [ADSI] « LDAP://$($ObjRootDSE.schemaNamingContext) »

$ADSearcher.PropertiesToLoad.AddRange(@(« ldapdisplayname », »systemonly »))

$ADSearcher.Filter = « (systemonly=TRUE) »

$ADSearcher.FindAll() | %{ $SystemOnlyAttributes += $_.Properties.ldapdisplayname }

 

# Compare the list of allowed attributes returned by the constructed attribute

# with the list of protected attributes collected in the schema

foreach ( $Attribute in $allowedAttributesEffective )

{

if ( $SystemOnlyAttributes -notcontains $Attribute )

{

$TrulyAllowedAttributes += $Attribute

}

}

# The most efficient list of writeable attributes

$TrulyAllowedAttributes

{/codecitation}

 

If you have a better way… you are welcome !

Gérer efficacement la création des snapshots AD

Sommaire

 

 

Introduction

Les clichés instantanés de la base NTDS est une fonctionnalité Windows Server s’appuyant sur NTDSUTIL (un simple front end du VSS shadow copy en réalité) et l’outil DSAMAIN. Le premier permet la création de clichés instantanés du fichier « ntds.dit », le deuxième permet d’instancier la base de données depuis un des clichés réalisés.

J’avais d’ailleurs déjà traité le sujet il y a quelques temps au sein de deux articles :

 

Depuis lors, j’ai gagné un petit peu en expérience et je vais vous montrer comme optimiser la création de vos clichés Active Directory.

 

 

Les problématiques

La première grosse contrainte lorsque vous créer vos clichés instantanés à l’aide de NTDSUTIL est qu’il crée automatiquement un cliché instantané de l’ensemble de vos volumes. D’une part ça ne sert strictement à rien, d’autre part ça peut poser rapidement des problèmes sur la gestion des rotations de vos clichés ainsi que des problèmes d’espace disque.  Cela s’avère d’autant plus vrai lorsque le volume système est impacté…

Ci-dessous, vous voyez un exemple de création d’un cliché à l’aide de NTDSUTIL. Comme je dispose de deux volumes (C:\ et D:\), l’outil prend un cliché de chacun d’entre eux…

 

Le deuxième problème est la gestion des rotations… en effet, on pourrait essayer de fixer un nombre de clichés instantanés cependant cela peut s’avérer rapidement complexe car il faut tenir compte de l’évolution de l’espace disque utilisé sur la partition de votre base Active Directory mais également les autres volumes depuis que NTDSUTIL ne fait pas la différence.

 

 

Problématique 1 : réaliser un cliché d’un seul volume

La première chose à faire est de limiter la réalisation du cliché au seul volume contenant la base Active Directory. Cela induit donc de ne plus utiliser NTDSUTIL. Ça ne pose pas réellement de problème en réalité car les clichés instantanés réalisés par NTDSUTIL n’ont rien de plus que ceux réalisés depuis l’explorateur Windows. La seule chose que réalise NTDSUTIL et qu’il ajoute un TAG supplémentaire pour des besoins de gestion. En effet, lorsque vous utilisez NTDSUTIL pour lister, monter ou supprimer les clichés instantanés Active Directory, il s’appuie sur le TAG « SNAPAD » apposé sur chaque cliché instantané.

La solution que je propose est donc de passer par l’outil DISKSHADOW pour réaliser le cliché instantané qui permet premièrement de se focaliser uniquement sur le volume hébergeant la base NTDS. En second, il permet de continuer de gérer les clichés instantanés depuis NTDSUTIL.

Le script est disponible depuis le lien suivant : http://gallery.technet.microsoft.com/scriptcenter/Script-to-create-Active-2d389218

Ci-dessous, je lance le script pour réaliser un cliché et je liste le cliché créée à l’aide de NTDSUTIL. Nous voyons bien que non seulement il apparait bien depuis NTDSUTIL mais surtout que seul le volume stockant la base Active Directory est concerné.

 

 

Problématique 2 : gestion efficace de la rotation de vos clichés instantanés

Evaluer la taille d’un cliché est quasiment impossible surtout si vous en réalisez plusieurs à la suite. Vous pourriez y arriver au fur à mesure avec un peu de patience et une surveillance soutenue mais ça reste assez inefficace.

Le mieux est de s’appuyer sur ce que Microsoft propose déjà en matière de clichés instantanés. En effet, vous avez la possibilité de réserver un espace dédié à vos clichés et du coup de gérer de manière optimisée le nombre de clichés que vous pouvez conserver.

Pour cela, rien de plus simple. Faites un clic droit sur le volume contenant la base Active Directory et sélectionnez « Configurer les clichés instantanés… ».

 

Depuis la fenêtre « Clichés instantanés », cliquez sur le bouton « Paramètres… ». Une fois dans la fenêtre « Paramètres », définissez une limite pour le stockage des clichés instantanés à l’aide de l’option « Utiliser cette limite : ».

 

De manière automatique, Windows va désormais gérer la rotation tout en garantissant de ne pas dépasser un volume d’espace disque. En clair, lorsque la limite définie sera dépassée, le plus ancien cliché sera supprimé et ainsi de suite.

Identifier les groupes de l’utilisateur courant avec PowerShell

Je vais vous montrer rapidement comment vérifier qu’un utilisateur appartient à un groupe en PowerShell. Cela vous sera sans doute utile pour la mise en place de login script en PowerShell et abandonner les .bat, .kix et tutti quanti.

Premièrement on récupère l’utilisateur Windows courant :

{codecitation style= »brush: PowerShell »}

$CurrentWinId = [System.Security.Principal.WindowsIdentity]::GetCurrent()

{/codecitation}

 

L’objet WindowsIndentity contient la propriété « Groups » listant l’ensemble des appartenances de l’utilisateur. Par contre,  la liste retourne uniquement les groupes par leur SID.

 

Du coup, vous avez deux solutions. La première solution consiste à réaliser une translation SID/Nom à l’aide de la méthode Translate et de stocker le résultat dans un tableau.

{codecitation style= »brush: PowerShell »}

$arrTranslatedGroups = @()

Foreach ($Group in $CurrentWinId.Groups)

{

$arrTranslatedGroups += $Group.translate([System.type]::GetType(« System.Security.Principal.NTAccount »)).Value

}

{/codecitation}

 

Il suffit de vérifier si un groupe est présent à partir du tableau généré à l’aide de l’opérateur « -contains » qui retournera « True » ou « False » :

{codecitation style= »brush: PowerShell »}

$arrTranslatedGroups -contains « NT AUTHORITY\Authenticated Users »

{/codecitation}

 

La deuxième solution consiste a converti dans un premier temps notre objet WindowsIdentity en WindowsPrincipal.

{codecitation style= »brush: PowerShell »}

$CurrentWindowsPrincipal = new-object System.Security.Principal.WindowsPrincipal($CurrentWinId)

{/codecitation}

 

L’objectif étant de pouvoir utiliser la méthode « IsInRole ».

{codecitation style= »brush: PowerShell »}

$CurrentWindowsPrincipal.IsInRole(« CORPNET\group123 »)

$CurrentWindowsPrincipal.IsInRole(« NT AUTHORITY\Authenticated Users »)

{/codecitation}

Ne stockez jamais de mot de passe dans une GPP (les préférences de stratégie de groupe)

Les GPP sont particulièrement utiles pour gérer un bon nombre de composants non pris en charge par défaut dans les objets de stratégies de groupe. Toutefois, dans certains de ces composants, vous pourriez être amené à spécifier des informations d’authentification… ce qu’il ne faut absolument jamais faire !

Les composants concernés sont :

  • Les sources de données
  • Les utilisateurs locaux
  • Les tâches planifiées
  • Les services
  • Les lecteurs réseaux

 

Chacun de ces composants offrent la possibilité de spécifier des informations d’authentification comme ci-dessous.

Si vous spécifiez un mot de passe depuis l’un de ces composants, il est encrypté et puis stocké dans le fichier de configuration (au format XML) du composant.

 

Dans l’exemple ci-dessous, j’ai ouvert le fichier XML « ScheduledTasks.xml » d’une GPO portant l’identifiant unique « A50C7725-0176-4FFF-B40A-F5852C0487B6 » depuis le dossier SYSVOL. Le chemin complet vers ce fichier est  \\mondomaine.fr\SYSVOL\mondomaine.fr\Policies\{A50C7725-0176-4FFF-B40A-F5852C0487B6}\Machine\Preferences\ScheduledTask

 

Comme vous pouvez le voir, le mot de passe est facilement récupérable. Toutefois il est encrypté. Pour autant, cette encryption est complètement inutile car Microsoft a publié la clé d’encryption (http://msdn.microsoft.com/en-us/library/cc422924.aspx).

Du ce fait, il suffit d’utiliser cette clé pour rapidement décrypter le mot de passe. Cerise sur le gâteau, vous avez des scripts pour cela comme par exemple le bout de script ci-dessous (bout de code récupéré depuis le lien https://github.com/mattifestation/PowerSploit/blob/master/Exfiltration/Get-GPPPassword.ps1)

{codecitation style= »brush: PowerShell »}

[CmdletBinding()]

Param (

[string] $Cpassword

)

 

try {

#Append appropriate padding based on string length

$Mod = ($Cpassword.length % 4)

switch ($Mod) {

‘1’ {$Cpassword = $Cpassword.Substring(0,$Cpassword.Length -1)}

‘2’ {$Cpassword += (‘=’ * (4 – $Mod))}

‘3’ {$Cpassword += (‘=’ * (4 – $Mod))}

}

 

$Base64Decoded = [Convert]::FromBase64String($Cpassword)

#Create a new AES .NET Crypto Object

$AesObject = New-Object System.Security.Cryptography.AesCryptoServiceProvider

[Byte[]] $AesKey = @(0x4e,0x99,0x06,0xe8,0xfc,0xb6,0x6c,0xc9,0xfa,0xf4,0x93,0x10,0x62,0x0f,0xfe,0xe8,

0xf4,0x96,0xe8,0x06,0xcc,0x05,0x79,0x90,0x20,0x9b,0x09,0xa4,0x33,0xb6,0x6c,0x1b)

#Set IV to all nulls to prevent dynamic generation of IV value

$AesIV = New-Object Byte[]($AesObject.IV.Length)

$AesObject.IV = $AesIV

$AesObject.Key = $AesKey

$DecryptorObject = $AesObject.CreateDecryptor()

[Byte[]] $OutBlock = $DecryptorObject.TransformFinalBlock($Base64Decoded, 0, $Base64Decoded.length)

return [System.Text.UnicodeEncoding]::Unicode.GetString($OutBlock)

}

 

catch {Write-Error $Error[0]}

{/codecitation}

 

Et voilà le résultat ! C’est génial ou catastrophique… ça dépendra de votre point de vue Coquin


 

Maintenant, il faut trouver des solutions pour remédier à la situation.

La priorité est de faire passer l’information (en faisant tourner mon article par exempleContent) auprès des personnes concernées.

Il existe également une mise à jour de sécurité depuis le 13 mai 2014 (https://technet.microsoft.com/library/security/ms14-025) empêchant de spécifier des informations d’authentification depuis les GPP. La mise à jour est disponible depuis le lien suivant : http://www.microsoft.com/en-us/search/DownloadResults.aspx?q=KB2928120

Une fois installée, premièrement vous avez un message d’avertissement…

 

Et les informations d’authentification sont grisées (évidement ça pose quelques soucis pour les GPPs existantes…).

 

Le petit inconvénient de la KB est qu’il faudra la déployer sur tous les postes d’administration.

 

Enfin, une autre solution consiste à réaliser des scans réguliers de votre SYSVOL à l’aide du script dont je vous ai déjà parlé plus haut (https://github.com/mattifestation/PowerSploit/blob/master/Exfiltration/Get-GPPPassword.ps1). En effet, il permet de scanner l’intégralité du contenu du dossier SYSVOL et extrait les éventuels mots de passe.

 

 

Analyser automatiquement les performances de vos contrôleurs de domaine

Sommaire

 


Introduction

Pour analyser les performances de vos contrôleurs de domaine il existe le collecteur de données « Diagnostics Active Directory ». Il est disponible par défaut sur Windows Server 2008 et est  donc particulièrement utile pour identifier des éventuels problèmes de performances.

Je vais donc dans un premier temps vous montrer à quoi cela ressemble et comment l’utiliser. Ensuite, on ira un peu plus loin afin que vous le lanciez automatiquement et au moment le plus opportun.

 

 

Le collecteur de données « Diagnostics Active Directory »

Introduit sous Windows Server 2003 et connu sous le nom de « Server Performance Advisor » (http://www.microsoft.com/en-us/download/details.aspx?id=15506), il est désormais intégré nativement sous Windows Server 2008 sous la forme d’un collecteur de données et est donc appelé « Diagnostics Active Directory ». Il permet de faire une collecte de données exhaustive sur le contrôleur de domaine et de générer un rapport au format HTML.

De plus, le rapport est particulièrement intéressant car Microsoft à créer un ensemble de règles permettant de mettre en relief ce qui ne va pas (exemple : un manque de mémoire, une requête LDAP malformée ou/et consommatrice…). Il n’est donc pas nécessaire de se creuser la tête pendant des heures sur l’analyse de données.

Pour générer donc un rapport de diagnostiques il faut premièrement lancer la console « Analyseur de performances ». Pour cela, vous pouvez lancer depuis « Démarrer | Exécuter » la commande « perfmon.msc ».

 

Depuis la console « Analyseur de performances », développez l’arborescence « Ensemble de collecteurs de données > Système » et à l’aide d’un clic droit sur  « Active Directory Diagnostics (Diagnostics Active Directory) », sélectionnez « Démarrer ».

 

A la fin de la collecte, un rapport de diagnostiques est disponible depuis « Rapports > Système > Active Directory Diagnostics ».

 

Par défaut, la collecte dure 5 minutes et vous ne pouvez pas la modifier. Si vous voulez l’adapter à vos besoins, alors la seule solution va être de créer un modèle de données personnalisé (dit « utilisateur ») s’appuyant sur le modèle existant (dit « système »). Toutefois, je ne vais pas rentrer plus dans le détail car ce n’est pas l’objet de l’article mais si vous voulez plus d’information sur le sujet, je vous propose déjà l’article suivant : Son of SPA: AD Data Collector Sets in Win2008 and beyond (http://blogs.technet.com/b/askds/archive/2010/06/08/son-of-spa-ad-data-collector-sets-in-win2008-and-beyond.aspx).

Maintenant revenons à nos moutons… Il est particulièrement intéressant de disposer d’un outil de la sorte mais faut-il encore que la collecte soit réalisée au bon moment. L’objectif étant de pouvoir identifier clairement l’origine d’une quelconque défaillance. Et pour cela, il faut que le déclenchement se fasse de manière automatique.

 

 

Présentation de la solution

Généralement, les problèmes de performances sur un contrôleur de domaine se traduisent par une utilisation excessive des ressources CPU par le processus LSASS. Nous allons donc définir une alerte de performance sur la consommation processeur de LSASS qui va, après un certain seuil, déclencher le collecteur de données « Diagnostics Active Directory ».

Pour améliorer la pertinence de notre collecte, l’alerte de performance ne va pas déclencher automatiquement le collecteur de données. Le petit plus de l’article est de passer par le biais d’un script qui prendra en charge le déclenchement de la collecte uniquement après plusieurs alertes.

Prenons un exemple. SCOM, L’outil de supervision Microsoft,  génère par défaut une alerte après avoir collecté, 5 fois d’affilé et sur une fréquence de 5 min, une utilisation du processus LSASS excédant 80% du CPU. Du coup si nous voulons reproduire le même comportement, nous devons enregistrer les différentes alertes remontées par notre alerte de performance durant une période précise. Grâce à ce mécanisme, je vais pouvoir démarrer ma collecte après X alertes sur une période de temps T.

 


Configuration du script

Le script est assez simple. Comme nous le disions un peu plus haut, il va contrôler le nombre d’alertes généré durant une certaine période, et si le seuil est atteint, il lancera le collecteur de données « Diagnostics Active Directory ».

Il est disponible depuis le lien Microsoft Technet : Starting Data Collector Set with PowerShell (managing timeline and sampling) (http://gallery.technet.microsoft.com/scriptcenter/Starting-Data-Collect-Set-1efc0013)

Copiez-le dans le répertoire de votre choix et modifiez-le en fonction de vos besoins.

Les paramètres sont :

  • NbSamples : Le nombre d’alertes nécessaire pour le déclenchement de la collecte (valeur par défaut : 5)
  • Duration : La durée de la période en minutes (valeur par défaut : 25)
  • DCSPath : Le nom du collecteur de données (valeur par défaut : « system\Active Directory Diagnostics »)
  • Notify : Activation de la Notification par message électronique. Vous le recevrez si le collecteur est démarré.

 

Si vous activez le paramètre « Notify », il faudra impérativement assigner les bonnes valeurs aux variables suivantes :

  • SmtpServerName : le nom du serveur SMTP
  • SmtpServerPort : le numéro de port du serveur SMTP
  • SmtpEnableSsl : activation du SSL
  • SmtpServerUsername : nom du compte utilisateur pour l’authentification SMTP
  • SmtpServerPassword : mot de passe du compte utilisateur pour l’authentification SMTP
  • SmtpSender : adresse électronique de l’expéditeur
  • SmtpRecipient : adresse électronique de chaque destinataire (si vous comptez ajouter plusieurs expéditeurs alors il faudra ajouter la liste sous forme d’un tableau)

 

Pour votre information, je me suis appuyé sur la configuration de l’alerte SCOM (l’outil de supervision Microsoft) pour définir à quel moment lancer la collecte. En effet, par défaut SCOM est configuré pour déclencher une action après une capture de 5 alertes toutes les 5 minutes.

 

 

Création de la tâche planifiée

La tâche planifiée est nécessaire pour permettre à l’alerte de performance d’interagir avec le script. En tout cas, c’est la seule solution que j’ai trouvée.

Ouvrez le planificateur de tâches et, à l’aide d’un clic droit, sélectionnez « Créer une tâche… ».

 

Entrez un nom pour cette nouvelle tâche (évitez les espaces) et, éventuellement, une description. Au niveau des options de sécurité, vous pouvez utiliser le compte « Système » et spécifier « Exécuter avec les autorisations maximales ».

 

Par contre, nous ne définirons aucun déclencheur. En effet, le déclenchement de la tâche sera réalisé par l’alerte de performance que nous configurons plus tard.

 

Depuis l’onglet « Actions », cliquez sur le bouton « Nouveau… ».

Pour la définition de la nouvelle action :

  • Action : «  Démarrer un programme »
  • Programme/Script : « powershell.exe »
  • Ajouter des arguments (facultatif) : « -ExecutionPolicy Unrestricted –Command ‘CHEMIN_DU_SCRIPT’ –Notify »

{gallery}88_DCSAD_AUTO/01{/gallery}

 

 

 

 

 

 

 

 

 

Au niveau des autres paramètres, je vous conseillerai à minima de définir  le paramètre « Arrêter la tâche si elle s’exécute plus de » à la valeur « 1 heure ».

 

 

Création de l’alerte de performance

Nous allons maintenant utiliser une alerte de performance en guise de déclencheur pour notre tâche. Notre alerte s’appuiera sur la consommation en processeur du processus LSASS.

Pour cela, il faut passer par la console « Analyseur de performances ». Pour cela, vous pouvez lancer depuis « Démarrer | Exécuter » la commande « perfmon.msc ».

 

Pour créer notre alerte, naviguez jusqu’à « Ensembles de collecteurs de données » et à l’aide d’un clic droit sur « Définis par l’utilisateur », sélectionnez « Nouveau >  Ensemble de collecteurs de données ».

 

Spécifiez le nom de votre alerte de performance. En l’occurrence, j’ai choisi « Alerte Processus LSASS ». Sélectionnez l’option « Créer manuellement (avancé) » et cliquez sur le bouton « Suivant ».

 

Le type de de données à inclure sera « Alerte de compteur de performance ».

 

A l’étape suivante, cliquez sur le bouton « Ajouter… ».

 

Sélectionner le compteur « % temps processeur » sur l’ordinateur local et spécifiez l’instance « lsass ». Cliquez le bouton « Ajouter >> » puis validez.

 

Nous définissons le seuil d’alerte « Au-dessus de 80 ».

 

Notre collecteur de données incluant notre alerte de performance est désormais créée. Il nous reste à préciser l’action à réaliser lorsque que l’alerte est déclenchée. Pour cela, nous allons éditer l’alerte « DataCollector01 » située à l’intérieur de notre de collecteur de données « Alerte Processus LSASS » en cliquant sur « Propriétés » à l’aide d’un clic droit.

 

Depuis l’onglet « Alertes », modifiez la valeur de l’intervalle d’échantillonnage à « 5 Minutes ».

 

Depuis l’onglet « Tâche d’alerte », spécifiez le nom de la tâche planifiée dans le champ « Exécuter cette tâche lorsqu’une alerte est déclenchée : ».

 

La dernière et ultime étape cruciale est le démarrage de la collecte de données pour votre alerte de performance. En effet, il faut que le collecteur soit démarré. Pour cela, fait un clic droit sur votre collecteur de données et sélectionnez l’option « Démarrer ».

 

 

Conclusion

Désormais, en cas de charge prolongé du processus LSASS et en fonction du paramétrage que vous aurez spécifié, le collecteur de données « Diagnostics Active Directory » va se déclencher automatiquement et générer un rapport de performance.

Vous serez désormais en mesure de détecter la cause de vos problèmes de performance !

Réplication AD – l’accès à la réplication a été refusé (Erreur 8453)

Dernièrement, j’ai eu un problème de réplication sur une de mes maquettes. L’erreur remontée par l’outil « repadmin » portait le code erreur « 8453 ». Le message indiquait que « L’accès à la réplication a été refusé ».

 

Fait étrange, une seule partition était concernée. En l’occurrence, il s’agissait de la partition de domaine. La partition de configuration et de schéma se répliquait correctement.

Afin de solutionner mon problème, je me suis référé à la KB Microsoft 2022387 (http://support.microsoft.com/kb/2022387). Hormis un problème de droits avec le compte utilisateur (peu probable étant administrateur du domaine), l’accès refusé pouvait provenir soir d’un problème sur l’attribut « userAccountControl » du compte ordinateur d’un des contrôleurs de domaine incriminé, soit d’un problème de droits sur la partition de domaine.

Le problème sur l’attribut « userAccountControl » ne semblait pas être la cause sachant que certaines partitions se répliquaient correctement. Par acquis de conscience, j’ai toutefois vérifié à l’aide de la commande « dcdiag /test:machineaccount ».

 

J’ai ensuite continué le diagnostic en testant les accès sur l’ensemble de mes partitions Active Directory à l’aide de la commande « dcdiag /test:ncssecdesc ».

BINGO !

 

Le test est particulièrement utile car il permet de lister l’ensemble des droits manquants. On pourrait d’ailleurs confirmer le résultat à l’aide de la commande « dsacls <PARTITION DN> » (distinguishedName de la partition concernée).

 

Clairement, les droits d’accès par défaut doivent être mis à jour sur la partition de domaine. Pour cela, le plus simple est d’utiliser l’outil « ADSIEDIT ».

 

Dans mon exemple, je me connecte donc à la partition de domaine « default naming context ». Dans votre cas, il pourrait peut-être s’agir de la partition de configuration, de schéma ou autre…

 

Il me suffit d’accéder aux propriétés de ma partition, et, depuis l’onglet « Sécurité », rajouter les droits manquants et lister par DCDIAG.

{gallery}87-ADREPL-ACCESSDENIED/01{/gallery}

 

 

 

 

 

 

 

 

 

Le cas échéant, on relance le test « dcdiag /test:ncsecdesc » pour valider que nous n’avons rien oublié.

 

La réplication devrait être de nouveau opérationnelle !

 

Pour votre information, Microsoft liste les droits par défaut pour les trois partitions par défaut d’une forêt: