Identifier les connexions établies entre ordinateurs et contrôleurs de domaine Active Directory

Sommaire

 

 

Introduction

Beaucoup s’appuient sur la variable d’environnement %LOGONSERVER% pour identifier le contrôleur de domaine utilisé par un ordinateur. Premièrement, Il faut savoir que cette variable d’environnement n’est pas mise à jour et donc pas toujours très fiable. De plus, même en identifiant le contrôleur de domaine avec lequel le canal sécurisé a été établi, d’autres services liés à Active Directory ne sont pas assujettis forcément à cette information.

Nous allons donc voir comme recueillir les informations de la manière la plus pertinente et la plus complète possible.

 

 


Etablissement du canal de communication sécurisé

Lorsque vous démarrez votre station de travail, un canal sécurisé est établi avec un contrôleur de domaine. Ce processus est sous la responsabilité du service NETLOGON qui initialise également la variable d’environnement %LOGONSERVER%.

Pour consulter la valeur de %LOGONSERVER%, ouvrez une invite de commandes et tapez la commande « set logonserver ».

{gallery}49_DCLINKSPC/01{/gallery}

 

 

 

 

Comme nous le disions en introduction, la valeur de la variable d’environnement %LOGONSERVER% n’est pas mise à jour. Il se peut donc que le canal sécurisé ait été établi avec un autre contrôleur de domaine entre le moment où la variable d’environnement %LOGONSERVER% a été initialisée et le moment où vous la consultez. De ce fait, il est préférable de s’appuyer sur l’outil dédié NLTEST (disponible par défaut sur les postes Windows 7 et intégré aux support tools pour Windows XP).

Pour connaître le contrôleur de domaine partenaire du canal sécurisé établi avec votre poste de travail, utilisez la commande « nltest /sc_query:[MONDOMAINE] ».

{gallery}49_DCLINKSPC/02{/gallery}

 

 

 

 

Notez également que la commande ci-dessus permet de connaître le statut actuel du canal sécurisé. Il est aussi possible de contrôler l’état de la connexion à l’aide de la cmdlet PowerShell « Test-ComputerSecureChannel » intégré au module PowerShell ActiveDirectory de Microsoft (disponible sur Windows 7 et Windows 2008 R2).

{gallery}49_DCLINKSPC/03{/gallery}

 

 

 

 

Afin de confirmer ce mécanisme, vous pouvez, à tout moment, réinitialiser le canal sécurisé à l’aide de la commande « nltest /sc_reset:[MONDOMAINE] ». Vous pouvez voir que dans notre exemple ci-dessous, à aucun moment la variable %LOGONSERVER% est identique aux résultats retournés par NLTEST. En conclusion, nous ne pouvons définitivement pas nous fier à elle.

{gallery}49_DCLINKSPC/04{/gallery}

 

 

 

 

 

 


Les services annexes

Outre l’établissement du canal sécurisé, d’autres services sont utilisés au sein d’un environnement Active Directory. Nous avons, entre autres, les dossiers partagés SYSVOL et NETLOGON, l’application des stratégies de groupe, le serveur de temps et l’authentification Kerberos. Tous ces services peuvent être utilisés indépendamment les uns des autres (en fonction de leur configuration, des temps de réponse…) par les ordinateurs du domaine.

Nous avons un exemple concret avec les dossiers partagés SYSVOL et NETLOGON. Sans entrer dans le détail, chaque contrôleur de domaine dispose d’un partage SYSVOL et NETLOGON qu’il met à la disposition des ordinateurs du domaine. Ils permettent par exemple de stocker la partie dite « fichiers » des stratégies de groupe, les scripts de connexion… Ses partages s’appuient sur DFS pour les publier sur un espace de nom commun (le nom de domaine Active Directory) et pour se répliquer entre chaque contrôleur de domaine.

On pourrait donc s’attendre à ce que, sur chaque ordinateur du domaine, le dossier SYSVOL et NETLOGON pointent sur le même contrôleur de domaine cependant ce n’est pas toujours le cas. Un ordinateur peut pointer sur deux contrôleurs de domaine différents à un instant donné.

{gallery}49_DCLINKSPC/05{/gallery}

 

 

 

 

 

 

 

 

 

Il peut être également intéressant de vérifier depuis quel contrôleur de domaine les stratégies de groupe sont appliquées au démarrage du poste. Il suffit d’utiliser la commande « gpresult /r ».

{gallery}49_DCLINKSPC/06{/gallery}

 

 

 

 

 

 

 

 

 

Chaque poste du domaine synchronise son temps à l’aide d’un serveur de temps. Pour consulter le serveur de temps utilisé par le poste de travail, nous avons à notre disposition l’outil « w32tm » qui permet, entre autres, de connaître la source de temps de notre poste à l’aide de la commande « w32tm /query /status ».

{gallery}49_DCLINKSPC/07{/gallery}

 

 

 

 

Enfin, concernant l’authentification Kerberos, il n’est pas vraiment possible de savoir quel serveur KDC a fourni le ticket au client Kerberos hormis en réalisant une capture réseau. Toutefois, vous pouvez identifier quel serveur KDC est ciblé par la machine à l’aide de la commande « nltest /dsgetdc:corpnet.net /kdc ».

{gallery}49_DCLINKSPC/08{/gallery}

 

Gérez vos serveurs 2008 à distance avec la console « Server Manager » de Windows Server 2012

La console « Server Manager » de Windows Server 2012 nous permet de gérer plusieurs serveurs et, entre autres, des serveurs sous Windows  Server 2008 / 2008 R2 (même Windows Server 2003 mais de manière toutefois nettement plus limitée).

Pour cela, il va être nécessaire d’installer certaines mises à jour :

  1. Le .Net Framework 4
  2. Le Windows Management Framework 3.0 (intègrant entre autres PowerShell V3, Windows « PowerShell Web Service » et surtout le « Server Manager CIM Provider »)
  3. Le hotfix disponible depuis http://go.microsoft.com/fwlink/p/?LinkID=245487 pour corriger certains problèmes relatifs à la collecte des données des compteurs de performances.

Remarque: Le Windows Management Framework 3.0 n’est pour l’instant disponible qu’en version anglaise (version Release Candidate). Lors de nos tests, il n’a pas été possible de l’installer sur une version de Windows Server 2008 R2 en version française.

Une fois les prérequis ci-dessus respectés, il suffit d’ajouter vos serveurs à la console « Server Manager » de Windows Server 2012. Pour cela, il faut se rendre dans « Manage | Add Servers » et rechercher les serveurs à ajouter en fonction des critères désirés.

{gallery}48_SRVMAN_2012/01{/gallery}

 

 

 

 

 

 

Dans l’exemple ci-dessous, nous avons ajouté le serveur « DC03 »  dont le système d’exploitation est Windows Server 2008 R2. Nous avons toutefois rencontré un problème de communication. Cela est dû au fait qu’il est nécessaire d’activer Windows Remote Management (WinRM) sur chaque serveur à gérer. Vous pouvez le configurer de manière basique mais rapide à l’aide de la commande « winrm qc » depuis une invite de commandes ou une console PowerShell.

{gallery}48_SRVMAN_2012/02{/gallery}

 

 

 

 

 

 

Le serveur sous Windows 2008 R2 est désormais gérable depuis la console « Server Manager ». Vous pouvez commencer par lancer les collectes à l’aide des Best Pratices Analyzer depuis « All Servers » ou pour chacun des rôles présents (exemple : DNS / AD DS / IIS…).

{gallery}48_SRVMAN_2012/03{/gallery}

 

 

 

 

 

 

 

Si vous désirez plus de détails sur BPA vous pouvez consulter l’article Technet Run Best Practices Analyzer Scans and Manage Scan Results.

Liste des articles sur les objets Tombstone

Bonjour tout le monde,

après quelques mois de labeur, nous pouvons enfin clôturer le sujet des objets Tombstone au sein d’Active Directory:

Bonne lecture à tous !

Réanimation des objets Tombstone

Sommaire

 

 

Introduction

Nous avons pu voir dans une série d’articles la nature et le rôle des objets Tombstone au sein de l’annuaire Active Directory. Désormais, il est temps de clôturer ce sujet et de vous présenter ce que l’on appelle communément la « réanimation » des objets Tombstone.

 

 


Qu’est-ce que la réanimation des objets Tombstone ?

Comme nous l’avons vu précédemment, un objet Tombstone est un objet qui a reçu une demande de suppression et qui est conservé temporairement dans la base Active Directory pour des besoins de réplication. Un objet Tombstone n’est rien d’autre qu’un objet standard (utilisateur, groupe, ordinateur..) qui est déplacé vers un conteneur spécifique (« deleted objects ») et qui subit quelques transformations.

Bien que les objets Tombstone soient cachés, il est possible de les consulter et même de les modifier afin qu’ils ne soient plus considérés comme des objets Tombstone. C’est cette opération que nous désignons comme étant une réanimation des objets Tombstone.

 

 


Processus de réanimation des objets Tombstone

De manière simplifiée, la différence entre un objet Tombstone et un objet standard peut être vue comme une manipulation de seulement deux attributs : distinguishedName et isDeleted.  Dans les faits, un objet Tombstone à l’attribut isDeleted défini et il est déplacé dans le conteneur « deleted objects » du domaine (modification du RDN et du distinguishedName).  Pour plus de détail voir notre article Le processus de suppression d’objets au sein de Active Directory (Les objets tombstone).

Ci-dessous, vous pouvez voir un exemple d’un objet Tombstone avec la liste complète de ses attributs retournée grâce à la cmdlet PowerShell « Get-ADObject ».

{gallery}47_REANIMATE_TS/01{/gallery}

 

 

 

 

 

 

Pour pouvoir réanimer un objet Tombstone, nous pouvons donc conclure qu’il suffit de supprimer son attribut isDeleted et de modifier son distinguishedName pour qu’il ne soit plus placé dans le conteneur « deleted objects ».

 

 

 

Réanimation d’un objet Tombstone avec LDP

Tous les articles relatifs à la réanimation d’objets au sein d’Active Directory s’appuient dans un premier temps sur LDP car il permet en réalité d’avoir une bonne compréhension du mécanisme propre à la réanimation.

Dans un premier temps, il faut pouvoir visualiser le conteneur « deleted object » à l’aide de l’outil LDP. En effet, sachant que le conteneur est caché par défaut, il faut réaliser quelques manipulations. Nous décrivons les étapes pour visualiser son contenu depuis notre article Visualiser le conteneur « Deleted Objects ».

Une fois dans le conteneur « deleted objects », nous allons sélectionner l’objet à réanimer et choisir l’option « Modifier » à l’aide d’un clic droit sur l’objet concerné.

{gallery}47_REANIMATE_TS/02{/gallery}

 

 

 

 

 

 

 

Depuis la fenêtre modifier de LDP, nous allons créer les deux entrées relatives à la suppression de l’attribut « isDeleted » et la modification (ou remplacement) de l’attribut « distinguishedName ».

Pour chaque attribut, spécifiez le nom de l’attribut, la nouvelle valeur (uniquement pour distinguishedName), l’opération à réaliser et ensuite cliquez sur le bouton « Entrer ».  Reportez-vous aux imprime-écrans ci-dessous pour plus de détail.

{gallery}47_REANIMATE_TS/03{/gallery}

 

 

 

 

 

 

 

 

Une fois les deux entrées saisies, cochez la case « Etendu » et cliquez enfin sur le bouton « Exécuter » pour réanimer l’objet.

{gallery}47_REANIMATE_TS/04{/gallery}

 

 

 

 

 

 

 

 

 

 

Réanimation d’un objet Tombstone avec ADRestore

Il est intéressant de connaitre le processus de réanimation d’un objet Tombstone avec l’outil LDP mais cela reste peu convivial pour ce genre d’opérations. Il existe un outil incontournable proposé par Microsoft (en réalité l’outil a été développé par SysInternals et racheté par la suite par Microsoft) qui se nomme ADRestore. Il s’agit d’un outil en ligne de commande permettant de rechercher des objets Tombstone et de les réanimer automatiquement le cas échéant.

Vous pouvez le récupérer ici. Son usage est très simple. Il suffit de saisir la commande ‘ADRestore –r « ma recherche »’ pour lancer la recherche du ou des objets Tombstone que vous désirez réanimer.

Remarque: si vous ne précisez aucune recherche après ADRestore –r, l’outil va lister tous les objets Tombstone présents dans le domaine.

{gallery}47_REANIMATE_TS/05{/gallery}

 

 

 

 

 

 

Bien entendu, ADRestore n’est pas le seul outil à notre disposition. Il existe d’ailleurs plusieurs outils avec interface graphique simplifiant d’autant plus la recherche et la réanimation d’objets Tombstone. Citons par exemple l’outil gratuit de Quest « Object Restore for Active Directory ».

Vous pouvez également consulter notre article (en anglais) sur la restauration d’un objet Tombstone à l’aide de PowerShell et de l’assembly .Net S.DS.P.

 

 

 

Les limites de la réanimation d’un objet Tombstone

La réanimation des objets Tombstone simplifie grandement la restauration d’objets sachant qu’il n’est pas nécessaire de passer par une sauvegarde, une restauration système et surtout de travailler sur un contrôleur de domaine hors ligne. Toutefois, comme par nature les objets Tombstone ne conservent que très peu d’attributs lors de leur réanimation, vous perdrez un grand nombre d’information. Les attributs plus contraignant dans ce genre de cas sont les attributs member et memberOf relatifs aux appartenances aux/des groupes Active Directory.

Malgré la simplicité et la rapidité de la réanimation des objets Tombstone, ce dernier point en fait une solution de restauration incomplète et, de ce fait, il faudra s’appuyer sur d’autres solutions comme les exportations ldif ou csv. Vous pourrez également vous appuyer sur les snapshots AD que nous présentons dans nos articles Snapshots AD: Gérer les clichés instantanés Active Directory et Snapshots AD: Exploiter les clichés instantanés Active Directory.

How to pass an array or multidimensional array as arguments to a scriptblock

As the MS PowerShell Team explained in the article How to pass arguments for remote commands, if you are invoking remote commands (invoke-command cmdlet) or starting a background job (start-job cmdlet) you want probably to use local values as arguments.

To manage this, both cmdlets have the option –argumentlist which is permitting to precise an array of arguments to be accessed inside your scriptblock using $args variable.

Example 1:

 

Code:

{codecitation style= »brush:PowerShell »}

$ProcessName = « winlogon »

Invoke-Command -ComputerName DC02 -ScriptBlock { Get-Process -Name $args[0] } -ArgumentList $ProcessName

{/codecitation}

 

 

Example 2:

 

Code:

{codecitation style= »brush:PowerShell »}

$ScriptBlock = {

Import-Module ActiveDirectory

Get-ADUser -Filter « sAMAccountName -eq ‘$($args[0])' » -SearchBase $args[1]

}

Invoke-Command -Computer DC02 -ScriptBlock -ArgumentList « aaugagneur », »OU=CORPNET,DC=corpnet,DC=net »

{/codecitation}

 

 

$args is a variable created automatically by PowerShell which handles any parameters passed as arguments with the option –Argumentlist.

Since the variable $args is an array, you will have issues to pass an array as an argument. Basically, It treats each element of your array as a specific argument.

 

If you want to pass your complete array as a specific argument, you will need to use the syntax (,$MyArray) for –Argumentlist parameter.

Example 3:

 

Code:

{codecitation style= »brush:PowerShell »}

$Array = @(« red », »blue », »green »)

Invoke-Command -ComputerName DC02 -ScriptBlock { Write-Host « 1st item: $($args[0]) »; Write-Host « 2nd item: $($args[1]) »; Write-Host « 3nd item: $($args[2]) » } -argumentList (,$Array)

{/codecitation}

 

 

Example 4:

 

Code:

{codecitation style= »brush:PowerShell »}

$Array = @(« red », »blue », »green »)

Invoke-Command -ComputerName DC02 -ScriptBlock { Write-Host « 1st item: $($args[0][0]) »; Write-Host « 2nd item: $($args[0][1]) »; Write-Host « 3nd item: $($args[0][2]) » } -argumentList (,$array)

{/codecitation}

Reanimate Active Directory tombstone objects with PowerShell (using System.DirectoryServices.Protocols)

Introduction

During a couple of days, I was searching a way for reanimating tombstone objects using only the Active Directory module for Windows PowerShell and, for some reasons, I did not want to use any additional Quest cmdlets or SDM Software cmdlets.

 

 

Retrieve tombstone objects with PowerShell

To get all tombstone objects within a domain, you just have to type the command: get-adobject -filter ‘isDeleted -eq $true’ –IncludeDeletedObjects

 

The option –IncludeDeletedObjects permits to explore the hidden container “cn=deleted objects” of the domain. The filter ‘isDeleted -eq $true’ will focus on tombstone objects.

As Reminder, the major difference between a tombstone object and a standard object is the attribute isDeleted (set to true for tombstone objects) and the parent container (a tombstone object is always placed into the container deleted objects).

Remark: the parent container of an object is partially defined by its distinguishedName.

 

 

Reanimate tombstone objects with PowerShell

Now we want to simply reanimate a specific tombstone object by changing its parent container and its isDeleted attribute but we are not able to manage them with the set-adobject cmdlet. There is no –IncludeDeletedObjects option for it and the tombstone object is just “not found”.

 

Finally, I have found a .Net function (Resurrecting tombstones in Active Directory or ADAM) that I have converted to PowerShell and it is working fine from my side.

{codecitation style= »brush: PowerShell »}

function Reanimate-Object()

{

Param

(

[Parameter(Mandatory=$true)]

[String] $Dn,

 

[Parameter(Mandatory=$true)]

[String] $NewDn,

 

[Parameter(Mandatory=$true)]

[String] $LdapServer,

 

[Int] $LdapPort = 389

)

 

try

{

# Delete the attribute isDeleted

$LdapAttrIsDeleted = New-Object -TypeName System.DirectoryServices.Protocols.DirectoryAttributeModification

$LdapAttrIsDeleted.Name = « isdeleted »

$LdapAttrIsDeleted.Operation = « Delete »

 

# Replace the attribute distinguishedName

$LdapAttrDn = New-Object -TypeName System.DirectoryServices.Protocols.DirectoryAttributeModification

$LdapAttrDn.Name = »distinguishedname »

$LdapAttrDn.Add($NewDn) | Out-Null

$LdapAttrDn.Operation = « Replace »

 

# Create modify request

$LdapModifyRequest = New-Object -TypeName System.DirectoryServices.Protocols.ModifyRequest($Dn,@($LdapAttrIsDeleted,$LdapAttrDn))

$LdapModifyRequest.Controls.Add((New-Object System.DirectoryServices.Protocols.ShowDeletedControl)) | Out-Null

 

# Establish connection to Active Directory

$LdapConnection = new-object System.DirectoryServices.Protocols.LdapConnection(new-object System.DirectoryServices.Protocols.LdapDirectoryIdentifier($LdapServer))

 

# Send modify request

[System.DirectoryServices.Protocols.DirectoryResponse]$modifyResponse = $ldapConnection.SendRequest($ldapModifyRequest)

 

# Return result

if ( $modifyResponse.ResultCode -eq « Success » )

{

Write-Host « object reanimated as $($NewDN). »

}

else

{

Write-Host « $($modifyResponse.ErrorMessage) »

}

}

catch

{

Write-Host « $($_.Exception.Message) »

}

}

{/codecitation}

 

To use this function, you just have to:

  • Load the .Net assemblies and the Active Directory module for Windows Powershell.
  • Retrieve the specified tombstone object.
  • Defined the new distinguishedName attribute based on the actual CN and lastKnownParent attribute.
  • Call the function with the correct parameters.

{codecitation style= »brush: PowerShell »}

# Load Active Directory Module for Windows PowerShell

Import-Module ActiveDirectory

 

# Load assemblies

[System.Reflection.assembly]::LoadWithPartialName(« system.directoryservices ») | Out-Null

[System.Reflection.assembly]::LoadWithPartialName(« system.directoryservices.protocols ») | Out-Null

 

# Retrieve deleted object

$ADObject = Get-ADObject -Filter ‘sAMAccountName -eq « aaugagneur »‘ -IncludeDeletedObjects -Property *

 

# Define regular expression to capture CN attribute

[regex] $RegexDnTombstones = « (?<CN>CN=.*)\\0ADEL.* »

 

# Define new distinguishedName attribute based on captured CN attribute and lastKnownParent attribute

$NewDn = (($RegexDnTombstones.Match($ADObject.distinguishedName)).Groups[« CN »].value)+ », »+($ADObject.lastKnownParent)

 

# Call function

Reanimate-Object -Dn $ADObject.distinguishedName -NewDn $NewDn -LdapServer « localhost »

{/codecitation}

 

 

If you want to explore deeper S.DS.P you can check another example from Microsoft Script Center: Using System.DirectoryServices.Protocols from Powershell