Problème :

Il existe une limitation à la commande "Get-ADGroupMember" et cette dernière est de 5000, ce qui veut dire que si le groupe détient plus de 5000 membres vous obtiendrez un joli message d'erreur du type :

Get-ADGroupMember : The size limit for this resquest was exceeded

Solution :

Voici une fonction Powershell qui vous permettra de récupérer l'intégralité des membres d'un groupe même s'il y en a 10 000 dedans.

Vous pourrez choisir de retourner :

• Les utilisateurs
• Les groupes
• Le tout

Function Get-AllMembers {
     <#
    .SYNOPSIS
    Return a list of members for a group.

    .DESCRIPTION
    Get-AllMembers is a function that returns a list of members for a specific group.
    
    .PARAMETER Name
    The name of the group you want to get the member list.

    .EXAMPLE
    Get-AllMembers "Domain Admins", "DNS Admins"

    .INPUTS
    String

    .OUTPUTS
        PSCustomObject

    .NOTES
        Author:  ADELAIDE Mathieu
    #>
    PARAM (
        [Parameter(Mandatory = $true, ValueFromPipeline = $true, Position = 0)]
        [STRING]$Name,
        [Parameter(Mandatory = $true, ValueFromPipeline = $true, Position = 1)]
        [ValidateSet("UsersOnly","GroupsOnly","All")]
        [STRING]$Return
        )
    Process {
        $Name | Foreach {
            $GroupName = $_
            $ArrayUsers = @()
            $ArrayGroups = @()
            $ArrayAll = @()
            Try {
                $DistinguishedName = Get-ADGroup -Identity $GroupName -ErrorAction Stop | select -ExpandProperty DistinguishedName
                # Searching all Users who's member of current Group
                Try {
                    $AllUsersMembers = Get-ADUser -LDAPFilter "(&(objectCategory=user)(memberOf=$DistinguishedName))" -ErrorAction Stop
                    $AllUsersMembers | foreach {
                        $ArrayUsers += New-Object psobject -Property @{
                            GroupName = $GroupName
                            DistinguishedName = $_.DistinguishedName
                            Enabled = $_.Enabled
                            GivenName = $_.GivenName
                            Name = $_.Name
                            ObjectClass = $_.ObjectClass
                            ObjectGUID = $_.ObjectGUID
                            SamAccountName = $_.SamAccountName
                            SID = $_.SID
                            Surname = $_.Surname
                            UserPrincipalName = $_.UserPrincipalName
                            }

                        # Collect All
                        $ArrayAll += New-Object psobject -Property @{
                            GroupName = $GroupName
                            DistinguishedName = $_.DistinguishedName
                            Enabled = $_.Enabled
                            GivenName = $_.GivenName
                            Name = $_.Name
                            ObjectClass = $_.ObjectClass
                            ObjectGUID = $_.ObjectGUID
                            SamAccountName = $_.SamAccountName
                            SID = $_.SID
                            Surname = $_.Surname
                            UserPrincipalName = $_.UserPrincipalName
                            }
                        }
                    }
                Catch {
                    Write-Warning -Message "Unable to find all users member of $Name"
                    }
                # Searching all Groups who's member of current Group
                Try {
                    $AllGroupsMembers = Get-ADGroup -LDAPFilter "(&(objectCategory=group)(memberOf=$DistinguishedName))" -ErrorAction Stop
                    $AllGroupsMembers | foreach {
                        $ArrayGroups += New-Object psobject -Property @{
                            GroupName = $GroupName
                            DistinguishedName = $_.DistinguishedName
                            GroupCategory = $_.GroupCategory
                            GroupScope = $_.GroupScope
                            Name = $_.Name
                            ObjectClass = $_.ObjectClass
                            ObjectGUID = $_.ObjectGUID
                            SamAccountName = $_.SamAccountName
                            SID = $_.SID
                            }

                        # Collect All
                        $ArrayAll += New-Object psobject -Property @{
                            GroupName = $GroupName
                            DistinguishedName = $_.DistinguishedName
                            Enabled = $_.Enabled
                            GivenName = $_.GivenName
                            Name = $_.Name
                            ObjectClass = $_.ObjectClass
                            ObjectGUID = $_.ObjectGUID
                            SamAccountName = $_.SamAccountName
                            SID = $_.SID
                            Surname = $_.Surname
                            UserPrincipalName = $_.UserPrincipalName
                            }
                        }
                    }
                Catch {
                    # Return an error message if member not found.
                    Write-Warning -Message "Unable to find all groups member of $Name"
                    }
                }
            Catch {
                # Return an error message if Group was not found.
                Write-Warning -Message "Unable to find $Name"
                }
            
            Switch ($Return) {
                "UsersOnly" {Return $ArrayUsers}
                "GroupsOnly" {Return $ArrayGroups}
                "All" {Return $ArrayAll}
                }

            # Release
            $GroupName = $null
            $DistinguishedName = $null
            $AllUsersMembers = $null
            $AllGroupsMembers = $null
            }
        }
    }

Dans un précédent article j'expliquais comment réaliser un hard match (https://blog.piservices.fr/post/2021/04/01/o365-realiser-un-hard-match).

J'ai récemment eu à me servir de nouveau des cmdlets et ces dernières ne fonctionnaient pas correctement, il est possible de le faire via API Graph, mais les commande Azure AD permettent encore de le faire si besoin.

# Get GUID for User
$User = Get-ADUser jdupont | select ObjectGUID,UserPrincipalName
$Upn = $User.UserPrincipalName
$Guid = $User.ObjectGUID.Guid
 
# Convert GUID to ImmutableID
$ImmutableId = [System.Convert]::ToBase64String(([GUID]($User.ObjectGUID)).tobytearray())
 
# Connect Azure AD
Connect-AzureAD

# Retrieve my user
$User = Get-AzureADUser -SearchString "jdupont @mydomain.com"

# Set ImmutableID to user
Set-AzureADUser -ObjectId $User.ObjectID -ImmutableId $ImmutableId

Dans toute annuaire Active Directory il existe une mauvaise pratique, celle dont je voudrais vous parler aujourd'hui est la non expiration des mots de passe pour un / des comptes du domaine. 

Pourquoi ?

Il existe plusieurs arguments au fait qu'un mot de passe qui n'expire jamais est une mauvaise pratique, je mettrais en avant ici les deux qui me posent le plus problème:

• Tout d'abord un mot de passe qui n'expire jamais a plus de chance d'être "découvert" dans des attaques de type brute force; si on se concentre sur ces comptes en particulier, le fait qu'il n'y ai pas de rotation de mot de passe, laisse une plus grande période de temps à l'attaquant pour le découvrir.
• Si le compte est compromis, l'attaquant a par définition un accès "constant" au SI, puisque tant que la rotation du mot de passe n'aura pas lieu, ce dernier conservera son accès.

Que faire ?

Bien qu'il ne soit pas une bonne pratique d'autoriser la non expiration des mots de passe, je les croise tous le jours dans tout Active Directory, avec toujours "une bonne raison" de l'avoir fait.

En revanche, même s'il n'est pas possible de s'en séparer, il est tout de même bon de mettre en oeuvre quelques bonne pratiques lorsque l'on est dans cette situation :

• Lister les comptes dont le mot de passe n'expire jamais.
• Documenter la cause de cette configuration.
• Documenter leur emploi (raison d'utilisation, application dans lesquelles ils sont utilisés, machines sur lesquelles ils sont utilisés).
• Documenter la date du dernier changement de mot de passe (même si elle peut être retrouvée dans l'AD).
• Documenter une procédure de changement de mot de passe (documentation applicative, processus de dépendance...).
• Indiquer une personne / équipe en mesure de pouvoir réaliser le changement de mot de passe (il se peut qu'il y ai des développeurs, prestataires externes, éditeurs qui se servent de ce mot de passe). 
• Réaliser une rotation du mot de passe manuellement.

Lister les comptes avec Powershell.

# Variables
$RootFolder = "C:\Temp"
$Workefolder = "$RootFolder\NeverExpires"
$LogFolder = "$RootFolder\Logs"
$LogFile = "$LogFolder\NeverExpires.txt"
$AllFolders = $RootFolder, $Workefolder, $LogFolder

# Check and create if needed
foreach ($Folder in $AllFolders) {
    If (!(Test-Path $Folder)) {
        Try {
            New-Item $Folder -ItemType Directory -ErrorAction Stop
            }
        Catch {
            Write-Warning $($_)
            }
        }
    }

# Import module
Try {
    Import-Module ActiveDirectory -ErrorAction Stop
    }
Catch {
    Write-Output "Failed to import module ActiveDirectory" | Add-Content $LogFile
    Exit
    }

# Get Active Directory users that have a password that never expires
Try {
    $AllEnabledUsers = Get-ADUser -Filter {Enabled -eq $true} -Properties PasswordNeverExpires -ErrorAction Stop
    $PasswordNeverExpires = $AllEnabledUsers.Where({$_.PasswordNeverExpires -ne $false})
    }
Catch {
    Write-Output "Failed to collect users" | Add-Content $LogFile
    }

# Export result
$PasswordNeverExpires | Export-Csv "$Workefolder\PasswordNeverExpires.csv" -Delimiter ";" -Encoding UTF8

SYSVOL est un partage de fichier créé par défaut et partagé entre chaque contrôleur de domaines (DC) dans un Active Directory (AD). DFSR est le mécanisme en charge de la réplication du contenu du SYSVOL entre chaque DC. La santé de la réplication DFSR sysvol est essentielle, car certains services de l'AD en dépendent pour leur fonctionnement, tel que les GPO.

Prérequis pour identifier les problèmes de réplication DFSR sysvol et forcer la restauration

• Avoir un compte Domain Admin
• Avoir accès au DC qui a des problèmes de réplications
• Avoir accès à la commande Dfsrdiag depuis le DC qui a des problèmes de réplications, si la commande n'est pas accessible, elle peut être installée depuis Server Manager > Add Roles and Features > Features > Role Administration Tools > File Services Tools > DFS Management Tools

Identifier les problèmes de réplication DFSR sysvol

Pour les exemples qui vont suivre, le DC2 présente des problèmes de réplications DFSR sysvol depuis le DC1 qui est sain. 

Plusieurs éléments qui ne nécessitent pas d'investiguer des logs peuvent alerter d'un problème de réplication DFSR sysvol :

• Lorsqu'une GPO créée sur le DC1 n'est pas accessible depuis le DC2, exemple de message d'erreur dans la console Group Policy Management : The system cannot find the file specified.
• Lorsqu'un fichier est créé dans le SYSVOL du DC1 \\DC1.domain.intern\SYSVOL\domain.intern et qu'il n'est pas répliqué dans le SYSVOL du DC2 \\DC2.domain.intern\SYSVOL\domain.intern
• Lorsque le nombre de GPO du DC1 \\DC1.domain.intern\SYSVOL\domain.intern\Policies est différent du nombre de GPO du DC2 \\DC2.domain.intern\SYSVOL\domain.intern\Policies

Il est possible d'utiliser la console DFS Management pour faire des tests de réplication, mais ceux-ci ne sont pas assez granulaires.

Depuis le DC qui a des problèmes de réplications, dans une invite de commande PowerShell, la commande Dfsrdiag est utilisée pour avoir un état des lieux du statut des objets en attente de réplication.

PS C:\Windows\system32> Dfsrdiag replicationstate
Summary

  Active inbound connections: 0
  Updates received: 0

  Active outbound connections: 0
  Updates sent out: 0

Operation Succeeded

Le résultat de la commande précédente montre une réplication saine. Lorsque des objets sont en attente de réplication, la liste des objets non répliqués s'affiche.
La valeur de Sending member indique le DC (par exemple DC1) depuis lequel le DC actuel (par exemple DC2) essaye de répliquer les objets du SYSVOL.

Le paramètre syncnow de la commande Dfsrdiag peut être utilisé pour tenter de forcer la réplication des objets en attente.

Dfsrdiag syncnow /partner:DC1.domain.intern /time:5 /RGName:"Domain System Volume"

#synnow permet de forcer la réplication depuis le DC spécifié après le paramètre /partner. Le Sending member précédent peut être utilisé.

#/time est la durée en minutes pendant laquelle la réplication est forcée. 5 minutes sont choisies, car c'est suffisant pour répliquer une centaine d'objets si la réplication fonctionne.

#/RGName est le nom du partage DFS, pour sysvol il s'agit de Domain System Volume

Suite à cette commande, il faut revérifier le statut de la réplication avec la commande Dfsrdiag replicationstate.

Il est possible de tenter la réplication depuis un partenaire différent ou de laisser plus de temps à la réplication.
Si le nombre d'objets en attente de synchronisation ne varie pas, il faut procéder à une restauration du DFSR sysvol.

Forcer la restauration DFSR sysvol d'un contrôleur de domaine

La restauration du DFSR sysvol consiste à faire une synchronisation non authoritative depuis un DC sain. C'est-à-dire que le contenu SYSVOL du DC2 qui a des problèmes de synchronisation sera écrasé par le contenu du SYSVOL du DC1. Les méthodes utilisées précédemment : le fonctionnement par défaut de DFSR et la commande dfsrdiag syncnow tentent de faire des synchronisation avec gestion des conflits, mais certains conflits de versions ne peuvent être résolus par les algorithmes internes.

1. Se connecter au DC2 qui a des problèmes de réplications

2. Ouvrir la console ADSI Edit, faire un clique droit sur ADSI Edit et cliquer sur Connect to..

3. Dans Connection Point choisir Select a well known Naming Context puis choisir Default naming context, dans Computer choisir Select or type a domain or server puis entrer le nom du DC qui a des problèmes de réplication puis cliquer sur OK

4. Déplier les dossiers Default naming context > <Domain> > OU = Domain Controllers > CN=<Nom du DC qui a des problèmes de réplications> > CN =DFSR-LocalSettings > CN = Domain System Volume > faire un clic droit sur CN = SYSVOL Subscription > Properties

5. Dans l'onglet Attribute Editor chercher l'attribut msDFSR-Enabled, faire un clic droit sur cet attribut et changer la valeur de True à False. Cette action à permis de désactiver la réplication DFSR sysvol pour le DC2

6. Depuis le DC2 ouvrir une console PowerShell et entrer la commande

repadmin /syncall /AdP

Cette commande permet de forcer la synchronisation des AD du DC2

7. Depuis le PowerShell du DC2 entrer la commande

Dfsrdiag PollAD

Cette commande permet de récupérer la configuration DFSR sans attendre qu'une réplication AD s'exécute.

8. Il est possible de vérifier que la réplication DFSR a bien été arrêté en consultant l'Event Viewer du DC2 et notamment l'Event ID 4114 dans Applications and Services Logs > DFS Replication

9. Réactiver la synchronisation DFSR sysvol sur le DC2 en suivant les étapes 1 à 5. Cette fois passer la valeur de msDFSR-Enabled de False a True

10. Forcer la réplication AD et DfsrDiag depuis le DC2 avec les commandes des étapes 6 et 7

11. Vérifier le statut de la synchronisation non authoritative DFSR sysvol du DC2 en ouvrant l'Event Viewer depuis le DC2, depuis le dossier Applications and Services Logs > DFS Replication > consulter les logs et notamment la présence de l'Event ID 4614

12. Depuis le DC2 dans une console PowerShell, utiliser la commande Dfsrdiag replicationstate pour vérifier s'il existe toujours des objets non répliqués

13. Faire un test de réplication SYSVOL DFSR en crééant un fichier sur le DC1 (sain) \\DC1.domain.intern\SYSVOL\domain.intern puis se connecter sur le SYSVOL du DC2 (réparé) \\DC2.domain.intern\SYSVOL\domain.intern et vérifier que le fichier est présent

Pour aller plus loin

Documentation officielle Microsoft How to force authoritative and non-authoritative synchronization for DFSR-replicated sysvol replication

Contexte :

Dans le cas ou vous implémentez l'Active Directory Split Model Permission, vous réduisez les permissions de l'Exchange sur L'AD et par conséquent une partie des commandes disponible depuis l'Exchange.

Problème :

La modification doit être faite sur les fiches des objets AD et il faut connaitre l'attribut à modifier.

Par exemple pour autoriser un ou des utilisateur(s) à écrire à une liste de distribution, il faut pour chaque utilisateur ajouter son "DistinguishedName" dans l'attribut "authOrig" de la liste en question.

Solution :

Si vous ne souhaitez pas éditez les fiches AD, aller dans l'onglet éditeur d'attributs et éditer / modifier l'attribut (déjà 4 clics avec la validation) vous pouvez utiliser Powershell avec la ligne de commande suivante :

Set-ADGroup -Identity "SamAccountName_Du_Groupe" -Add @{authOrig=@("DistinguishedName_Du_User")}

Mais si vous devez le faire pour plusieurs utilisateurs et ne pas traiter cela unitairement, il vous est possible d'utiliser la fonction suivante en passant plusieurs utilisateurs pour l'attribut "SamAccountName" séparés par une virgule :

Function Allow-ToSendTo {
    param (
    [Parameter(Mandatory)][String]$GroupName,
    [Parameter(Mandatory)][String[]]$SamAccountName
    )

    Try {
        Get-ADGroup $GroupName -ErrorAction Stop
        foreach ($Sam in $SamAccountName) {
            Try {
                $CurrentUser = Get-ADUser $Sam -ErrorAction Stop
                Try {
                    Set-ADGroup -Identity $GroupName -Add @{authOrig=@($CurrentUser.DistinguishedName)} -ErrorAction Stop
                }
                Catch {
                    Write-Warning $($_)
                    }
            }
            Catch {
                Write-Warning $($_)
            }
        }
    }
    Catch {
        Write-Host "Group Not found sorry" -ForegroundColor Yellow
    }
}

Problématique:  Récuperer et rendre lisible un timestamp représentant la date de modification du password d'un compte AD, renvoyé par l'outil Dsquery (https://ss64.com/nt/dsquery.html)

$user = "johndoe"
$domain = "mydomain.com"

# Executer la commande dsquery pour recuperer l'attribut pwdLastSet
$obj = dsquery * -filter "samaccountname=$user" -attr displayName pwdLastSet -d $domain

# Decouper $obj pour ne recuperer que la chaine correspondant au timestamp
$TimeStamp = $($obj[1] -split " ") | Where-Object {$_ -match '^\d+$'}

# Convertir le timestamp en date avec l'outil w32tm.exe
w32tm.exe /ntte $TimeStamp

Certaines applications pour pouvoir voir communiquer à travers des protocoles SSL sécurisés telles que LDAPS (port 636) et GC over SSL (3269) doivent avoir l'ensemble de la chaîne de certification d'un certificat d'un contrôleur de domaine (DC). L'export des certificats de la chaîne de certification ainsi que la constitution du certificat finale peut se faire à travers les outils natifs de Windows Server.

Exporter un certificat depuis la console de certification

L'ensemble des manipulations décrites peuvent se faire à distance depuis la console de certificat, mais dans un souci de clarté, les actions décrites sont réalisés directement depuis un contrôleur de domaine.

Depuis une invite de commande, entrer la commande suivante

certlm #cmdlet qui permet d'ouvrir la console de certificats avec le contexte de l'ordinateur local, donc ici le contrôleur de domaine

Déployer le dossier Personal puis Certificates

Identifier le certificat qui sert à l'authentification des clients du contrôleur de domaine :

• La colonne Issued To contient habituellement : le FQDN du contrôleur de domaine
• La colonne Intended Purposes contient habituellement : Client Authentication, Server Authentication
• La colonne Certificate Template contient habituellement : Domain Controller

Faire un click droit sur le certificat > All Tasks > Export...

L'utilitaire d'exportation de certificat se lance, choisir de ne pas exporter la clé privée : No, do not export the private key

Choisir un format Base-64 encoded X.509 (.CER)

Choisir un dossier de destination dans lequel exporter le certificat

Finir l'export du certificat via l'utilitaire

Le certificat du contrôleur de domaine a été exporté, il faut désormais exporter les autres certificats de la chaîne de certification : le certificat racine et les certificats intermédiaires 

Exporter chaque certificat de la chaîne de certification

De retour dans la console certlm, faire un click droit sur le certificat > All Tasks > Export...

Ouvrir l'onglet Certification Path, l'ensemble des certificats de la chaîne de certification est listé, le premier de la liste étant le certificat racine, le dernier le certificat du contrôleur de domaine, et les certificats entre les deux sont les certificats intermédiaires.

Cliquer sur le certificat racine puis sur View Certificate, le certificat racine s'affiche alors dans son propre onglet, cliquer sur l'onglet Details puis Copy to File...

Le même utilitaire d'export de certificat s'affiche, compléter l'exporter du certificat racine avec les mêmes options que pour le certificat du contrôleur de domaine en donnant un nom explicite au certificat pour pouvoir le différencier.

Exporter de la même façon l'ensemble des certificats intermédiaires.

Assembler les certificats de la chaîne de certification

Une fois l'ensemble des certificats de la chaîne de certification exportés, il faut les assembler dans un seul certificat.

• Créer un fichier texte et remplacer l'extension .txt par .cer, dans cet exemple, on l'appellera DCCertificateFullChain.cer 
• Ouvrir le certificat racine avec un éditeur de texte comme Notepad et copier coller le contenu dans le certificat jusqu'alors vide DCCertificateFullChain.cer
• Dans le fichier DCCertificateFullChain.cer faire un saut de ligne après ----END CERTIFICATE----
• Ouvrir chaque certificat intemédiaire et les copier coller à la suite du certificat racine dans le fichier DCCertificateFullChain.cer en respectant le saut de ligne
• Finir par le certificat du contrôleur de domaine

Les certificats doivent se suivre comme suit :

Le certificat avec l'ensemble de la chaîne de certification est prêt.

LAPS ou Local Admin Password Solution est une solution développée par Microsoft qui permet de gérer un mot de passe local de chaque ordinateur d'un domaine Active Directory de façon individuel et autonome. Cet article ne couvrira pas la mise en place de LAPS ni son modèle de délégation, mais se focalisera sur la délégation de la récupération d'un mot de passe LAPS d'un objet ordinateur supprimé.

Important : la corbeille Active Directory doit être activée pour récupérer le mot de passe LAPS d'un ordinateur supprimé.

Les méthodes par défaut pour lire le mot de passe LAPS d'un ordinateur supprimé

Par ordre de simplicité, les méthodes classiques sont :

1. Utiliser la console Active Directory Administative Center
2. Utiliser la cmdlet PowerShell Get-ADObject avec le paramètre -IncludeDeleteObjects
3. Utiliser l'utilitaire LDP.exe

Pourquoi ne pas utiliser une de ces méthodes pour lire les mots de passe LAPS des ordinateurs supprimés ? Parce que les droits nécessaires sont Domain Admin. Seul un nombre restreint d'administrateurs doit être membre de ce groupe à haut privilège.

Déléguer la lecture du mot de passe LAPS d'un ordinateur supprimé

Les tâches suivantes doivent être réalisées avec un utilisateur membre du groupe Domain Admin

1. Vérifier que l'utilisateur à la possibilité de voir et modifier les objets dans la corbeille AD

Dans une invite de commande exécuter en tant qu'administrateur, saisir la commande suivante :

dsacls "CN=Deleted Objects,DC=contoso,DC=intern" #Les mots contoso et intern sont à remplacer par le domaine à requêter

#Si le message suivant apparaît, les droits actuels de l'utilisateur sont insuffisants

Insufficient access rights to perform the operation.

The command failed to complete successfully.

Si le message précédent s'affiche et donc que les permissions ne s'affichent pas, il faut s'approprier la propriété du container Deleted Obects

dsacls "CN=Deleted Objects,DC=contoso,DC=intern" /takeownership #commande qui permet de devenir le propriétaire du container Deleted Objects

#Les permissions s'affichent alors, voici un exemple de permission

Owner: CONTOSO\Domain Admins
Group: NT AUTHORITY\SYSTEM

Access list:
{This object is protected from inheriting permissions from the parent}

Allow BUILTIN\Administrators          SPECIAL ACCESS
                                      LIST CONTENTS
                                      READ PROPERTY
Allow NT AUTHORITY\SYSTEM             SPECIAL ACCESS
                                      DELETE
                                      READ PERMISSONS
                                      WRITE PERMISSIONS
                                      CHANGE OWNERSHIP
                                      CREATE CHILD
                                      DELETE CHILD
                                      LIST CONTENTS
                                      WRITE SELF
                                      WRITE PROPERTY
                                      READ PROPERTY

2. Déléguer la lecture des mots de passe LAPS qui se trouvent dans la corbeille AD

Dans une invite de commande exécuter en tant qu'administrateur, saisir la commande suivante :

dsacls "CN=Deleted Objects,DC=contoso,DC=intern" /G CONTOSO\AD-GROUP-LAPS-DELETED-OBJECTS-READ:LCRP # commande qui permet de donner au groupe AD-GROUP-LAPS-DELETED-OBJECTS-READ les autorisations nécessaires pour lire les mots de passe LAPS des objets supprimés LC = list content et RP = read property

# ces permissions sont alors ajoutés à l'access list qui s'affiche

Allow CONTOSO\AD-GROUP-LAPS-DELETED-OBJECTS-READ
                                      SPECIAL ACCESS
                                      LIST CONTENTS
                                      READ PROPERTY

Remarique : il est nécessaire de créer le groupe AD-GROUP-LAPS-DELETED-OBJECTS-READ avant de taper la commande ci-avant, le nom du groupe peut être différent. 

3. Lire le mot de passe LAPS d'un objet ordinateur dans la corbeille AD

Les méthodes habituelles pour lire le mot de passe LAPS tel que LAPS UI ou la console Active Directory Users and Computers ne fonctionnent que sur les ordinateurs présents dans l'Active Directory, il est ainsi recommandé d'utiliser la cmdlet PowerShell Get-ADObject, par exemple :

Get-ADObject -Filter 'msds-LastKnownRDN -like "NameOfTheDeletedComputer"' -IncludeDeletedObjects -Properties ms-mcs-admpwd | Select ms-mcs-admpwd # il faut remplacer NameOfTheDeletedComputer par le nom de l'ordinateur dont le mot de passe LAPS doit être récupéré

# le mot de passe LAPS s'affiche en clair

Remarque : l'utilisateur qui doit récupérer le mot de passe de l'objet ordinateur supprimé doit être membre du groupe auquel la délégation a été fournie, dans cet exemple CONTOSO\AD-GROUP-LAPS-DELETED-OBJECTS-READ

Remarque 2 : l'utilisateur qui doit récupérer le mot de passe de l'objet ordinateur supprimé devait déjà avoir la possibilité de lire le mot de passe LAPS de l'ordinateur avant sa suppression

Cela fait 1 h que vous cherchez dans l'utilitaire de délégation de permission d'Active Directory votre attribut, mais impossible de le trouver ?

Dans un premier temps, il faut savoir que les noms affichés dans cet utilitaire sont sous le format "friendly name" qui n'est pas le nom technique dit "LDAP name". Vous pouvez vous référer à l'article suivant qui fait la correspondance entre les 2 représentations pour les attributs les plus utilisés : tableau de correspondance attribut LDAP et friendly name

Si votre attribut n'est toujours pas visible, c'est parce que par défaut certains attributs sont volontairement cachés.

Afficher un attribut caché dans l'utilitaire de délégation Active Directory

Pour afficher un attribut caché dans l'utilitaire de délégation Active Directory, il faut se connecter à un contrôleur de domaine (DC) et ouvrir le fichier dssec.dat.

Par défaut, celui-ci se trouve sous C:\Windows\System32

Le fichier est divisé par type d'objet LDAP : utilisateur, ordinateur, etc.

Lorsqu'un attribut est égale à 7 l'attribut n'est pas visible dans l'utilitaire de délégation, il faut modifier la valeur à 0 pour le rendre visible.

Exemple sur l'attribut "st" dont le friendly name est "State/Province"

Avant :

Après :

Remarque : les modifications dans le fichier dssec.dat ne sont pas répliqués sur les autres DC, il faut donc réutiliser le même DC pour de futures modifications ou refaire les mêmes manipulations sur le nouveau DC. À noter que cela ne concerne que l'affichage dans l'utilitaire de délégation, toute modification de permission via l'utilitaire est répliquée sur l'ensemble des DC.

Vous êtes-vous déjà mordus les doigts dans l'utilitaire de délégation de permissions Active Directory (AD) en essayant désespérément de savoir à quel attribut LDAP correspond tel attribut sous sa forme "friendly" name ?

Le tableau de correspondance attribut LDAP et friendly name

Remarque : certains attributs ne sont pas disponibles par défaut dans l'utilitaire de délégation de permission, il faut modifier le fichier dssec.dat sur un contrôleur de domaine