PI Services

Le blog des collaborateurs de PI Services

Active Directory - Accéder aux principaux outils d'administration AD en ligne de commande

Marre de devoir attendre que le bureau Windows Server 2016/2019 se charge pour chercher votre console d'administration ou peur que le simple fait d'ouvrir la recherche Windows de Windows Server 2012 freeze votre session ?

Voici la liste des commandes les plus utiles pour accéder aux outils d'administration Windows :

 

Active Directory Domains & Trust DOMAIN.MSC
Active Directory Sites & Services DSSITE.MSC
Active Directory Users & Computers DSA.MSC
Certificates snap-in ERTMGR.MSC
Certification Services CERTSRV.MSC
Command Prompt CMD.EXE
Computer Management COMPMGMT.MSC
Device Manager DEVMGMT.MSC
DHCP Manager DHCPMGMT.MSC
Disk Defragmenter DFRG.MSC
Disk Management DISKMGMT.MSC
Distributed File System DFSGUI.MSC
DNS Manager DNSMGMT.MSC
Domain Controller Security Policy DCPOL.MSC
Domain Security Policy DOMPOL.MSC
Event Viewer EVENTVWR.MSC
Hardware and software configuration information MSINFO32.EXE
Internet Authentication Service IAS.MSC
Internet Information Service (\Windows\system32\inetsrv) INETMGR
local Group Policy Editor GPEDIT.MSC
Local Security Policy SECPOL.MSC
Local Users and Groups LUSRMGR.MSC
Microsoft Management Console MMC.EXE
Performance Monitor PERFMON.MSC
Remote Desktop MSTSC
Resultant Set of Policy RSOP.MSC
Routing and Remote Access RRASMGMT.MSC
Run Registry Editor REGEDIT.EXE
Service Configuration SERVICES.MSC
Shared Folders FSMGMT.MSC
Terminal Services TSCC.MSC

Active Directory GPO - Faire du security filtering

Security filtering quésaco ?

 

Les GPO ou group policy management permettent de modifier le comportement des ordinateurs d'un parc Active Directory (AD), allant du simple changement d'écran à l'installation d'un logiciel.
Les GPO sont liés (link) à des Organizational Unit (OU) qui contiennent des objets utilisateurs et/ou ordinateurs.

Il existe des cas ou on souhaiterait appliquer une GPO à une population restreinte d'ordinateurs contenu dans une OU qui contient des ordinateurs qui ne doivent pas recevoir la GPO. C'est la que le filtre de sécurité (security filtering) entre en jeu, à travers l'appartenance à un groupe AD, on peut restreindre l'application d'une GPO aux membres du groupe.

Configurer une GPO pour faire du security filtering

 

Les étapes suivantes ne seront pas évoquées :

  • Création d'une GPO
  • Linker la GPO sur une OU
  • Ajout d'un objet utilisateur/ordinateur dans un groupe de sécurité

 

Etape 1 : modifier les security filtering de la GPO dans l'onglet Scope

 

Voici la configuration par défaut du security filtering d'une nouvelle GPO :

 

Authenticated Users indique que la GPO s'appliquera à n'importe tout objet utilisateur et/ou ordinateur qui sont contenus dans les OU ou la GPO est linkés.

 

On va donc supprimer Authenticated Users et ajouter notre propre groupe de sécurité (Group-Security-Filtering-Test) dans lequel on aura placé un object utilisateur/ordinateur.

A noter que la GPO n'a pas besoin d'être linké sur l'OU qui contient le groupe, elle doit cependant être linkée à l'OU qui contient les utilisateurs/ordinateurs du groupe.

 

Etape 2 : modifier les security filtering de la GPO dans l'onglet Delegation

 

Il faut ensuite se rendre dans l'onglet Delegation et ajouter Authenticated Users (ou Utilisateurs Authentifiés), pour rappel Authenticated Users inclut les utilisateurs et les ordinateurs, inutile donc de chercher un groupe Authenticated Computers inexistant.

 

Il nous est ensuite demander quelle permission on souhaite donner au groupe Authenticated Users on choisit Read

 

Dans l'onglet Delegation on a indiqué à quelle population a le droit de lire la GPO, c'est la configuration effectuée dans l'onglet Scope qui détermine si la GPO doit s'appliquer ou non à l'utilisateur/ordinateur

Powershell : Trouver la date de dernière connexion d'un utilisateur.

Comme vous le savez l'un des attributs qui nous est le plus important pour déterminer l'inactivité d'un compte est l'attribut "LastLogon", ce dernier permet de connaitre la dernière authentification valide d'un compte Active Directory.

Le problème c'est que ce dernier n'est pas répliqué entre les DCs, attention je parle bien du "LastLogon" et non le "LastLogonTimeStamp" qui lui l'est mais, ne détient pas la valeur réelle de la dernière authentification réussie.

Le "LastLogon" n'est pas répliqué entre les DCs pour une raison simple, éviter les "tempêtes" de réplication entre les DCs, imaginez, à chaque ouverture / déverrouillage de session cette valeur change, si vous pensez au nombre de fois que sont déverrouillées des sessions à la journée, cela vous donne une idée des réplications qui seraient nécessaires, par conséquent cet attribut n'est pas répliqué.

Ce qui pose donc problème c'est qu'il n'est pas possible d'avoir la réelle valeur de "LastLogon" sans devoir interroger l'intégralité des DCs et faire une comparaison de cette dernière.

Voici un script qui fera les requêtes et comparaisons pour vous, toutefois gardez à l'esprit qu'il va pour chaque utilisateur demander la valeur de l'ttribut "LastLogonà chaque DC, par conséquent ce script peut prendre plus ou moins de temps à s'exécuter en fonction du nombre d'utilisateur et du nombre de DCs.

$Array = @()
$AllDC = Get-ADDomainController -Filter * | sort Name | select Name
$AllEnabledUsers = Get-ADUser -Filter {Enabled -eq $true} | select Samaccountname

$AllEnabledUsers | select -First 5 | foreach {
    $CurrentUser = $_.Samaccountname
    $RealLastLogon = $null

    $AllDC | foreach {
        $CurrentDC = $_.Name

        Try {
            $Logon = Get-ADUser $CurrentUser -Properties LastLogon -Server $CurrentDC
            $LastLogon = [Datetime]::FromFileTime($Logon.LastLogon)
            If ($LastLogon -gt $RealLastLogon) {
                $RealLastLogon = $LastLogon
                }

            # Release variable
            $LastLogon = $null
            }
        Catch {
            Write-Warning $($_)
            }

        # Release variable
        $CurrentDC = $null
        }
    
    # Store Data
    $Array += New-Object psobject -Property @{
        DistinguishedName = $Logon.DistinguishedName
        Enabled = $Logon.Enabled
        GivenName = $Logon.GivenName
        Name = $Logon.Name
        ObjectClass = $Logon.ObjectClass
        ObjectGUID = $Logon.ObjectGUID
        SamAccountName = $Logon.SamAccountName
        SID = $Logon.SID
        Surname = $Logon.Surname
        UserPrincipalName = $Logon.UserPrincipalName
        LastLogon = $RealLastLogon
        }
        
    # Release Variables
    $CurrentUser = $null
    $RealLastLogon = $null
    }

Il ne vous restera qu'a examiner la sortie en rappelant la variable "$Array" ou à l'exporter dans un CSV comme ci-dessous par exemple.

$Array | Export-Csv C:\Temp\AllUsersWithLastLogon.csv -Delimiter ";" -Encoding UTF8 -NoTypeInformation

 

Si la valeur "LastLogon" est égale à "01/01/1601 01:00:00" cela veut dire que le compte ne s'est jamais connecté

Active Directory – Comment afficher la clé de récupération Bitlocker

Lorsque Bitlocker est activé sur le poste de travail / ordinateur portable de votre entreprise, vous devez disposer d’une solution pour obtenir la clé de récupération du disque dur. Dans certains cas, Bitlocker peut demander à l’utilisateur la clé de récupération s’il détecte un comportement spécifique tel que des modifications de partition.

Si vous n'avez pas la solution MBAM (Microsoft BitLocker Administration and Monitoring) en place pour centraliser la gestion de Bitlocker, la solution la plus simple consiste à utiliser soit la console Utilisateurs et ordinateurs Active Directory soit la console de modification ADSI.

Cela ne peut être possible que si vous définissez dans la GPO de stocker la clé de récupération dans Active Directory.

Utilisation de la console Utilisateurs et ordinateurs Active Directory:

Pour utiliser la console Utilisateurs et ordinateurs Active Directory, il faut installer un plug-in pour afficher les informations de clé de récupération Bitlocker. Il est intégré dans les fonctionnalités depuis Windows Server 2008.

Après l’installation, fermez et ouvrez à nouveau Utilisateurs et ordinateurs Active Directory.

Un nouvel onglet est maintenant disponible sur l’objet ordinateur : Bitlocker Recovery

Utilisation de la console de modification ADSI:

Pour afficher la clé de récupération Bitlocker depuis la console de modification ADSI, il suffit d'ouvrir cette dernière avec un compte qui a les droits et chercher le nom d'ordinateur sous l'unité d'organisation cible.

Cliquez sur le nom d'ordinateur concerné, puis double-cliquez sur le dernier objet du volet droit  

Ensuite, cherchez l'attribut msFVE-RecoveryPassword pour avoir la valeur de la clé de récupération Bitlocker

Droits de délégation nécessaire pour afficher la clé de récupération Bitlocker:

Pour visualiser la clé de récupération Bitlocker, il faut avoir des droits administrateur de domaine. Sinon si vous souhaitez donner les droits nécessaires pour afficher ces informations à quelqu'un qui n'est pas administrateur de domaine, il faut lui déléguer certains droits sur l'unité d'organisation ciblée.

  • Faites un clic droit sur l’unité d’organisation ciblée et sélectionnez Delegate Control...
  • Ajoutez des groupes qui doivent afficher la clé de récupération

  • Sélectionnez Create a custom task to delegate

  • Choisissez Only the following objects in the folder: et cochez "msFVE-RecoveryInformation objects"
 

  • Donnez le contrôle total sur cet objet

Sources:

https://www.manishbangia.com/how-to-get-bitlocker-recovery-password-from-active-directory/#jp-carousel-3904 
http://www.alexandreviot.net/2015/06/10/active-directory-how-to-display-bitlocker-recovery-key/ 

Powershell : Change the owner of my AD objects

Comme évoqué dans l'article  "Powershell : Who's the owner of my AD objects", il est possible que votre AD contienne des objets dont le propriétaire ne soit aucun des suivants :

  • "Enterprise Admins"
  • "Domain Admins"
  • "Administrators"

Afin de remettre "Domain Admins" comme propriétaire des objets, nous utiliserons Powershell pour chacun des types d'objets.

Attention : La variable $NoGood est issue des scripts du précédent article, pensez à vérifier ce qu'elle retourne au préalable.

Unités d'organisation

# Organizational Units
$NoGood | foreach {
    # Current OU
    $DistinguishedName = $_.DistinguishedName

    # Change Owner
    Try {
        # Define Target
        $TargetObject = Get-ADOrganizationalUnit -Identity $DistinguishedName
        $AdsiTarget = [adsi]"LDAP://$($TargetObject.DistinguishedName)"

        # Set new Owner
        $NewOwner = New-Object System.Security.Principal.NTAccount("DOMAINXXX", "Domain Admins")
        $AdsiTarget.PSBase.ObjectSecurity.SetOwner($NewOwner)
        $AdsiTarget.PSBase.CommitChanges()
        }
    Catch {
         Write-Warning $($_)
         $DistinguishedName
        }

    # Release variable
    $DistinguishedName = $null
    }

Les groupes

# Group
$NoGood | foreach {
    # Current Group
    $SamAccountName = $_.SamAccountName

    # Change Owner
    Try {
        # Define Target
        $TargetObject = Get-ADGroup $SamAccountName
        $AdsiTarget = [adsi]"LDAP://$($TargetObject.DistinguishedName)"

        # Set new Owner
        $NewOwner = New-Object System.Security.Principal.NTAccount("DOMAINXXX", "Domain Admins")
        $AdsiTarget.PSBase.ObjectSecurity.SetOwner($NewOwner)
        $AdsiTarget.PSBase.CommitChanges()
        }
    Catch {
        Write-Warning $($_)
        $SamAccountName
        }
    
    # Release variable
    $SamAccountName = $null
    }

Les utilisateurs

# Users
$NoGood | foreach {
    # Current User
    $SamAccountName = $_.SamAccountName

    # Change Owner
    Try {
        # Define Target
        $TargetObject = Get-ADUser $SamAccountName
        $AdsiTarget = [adsi]"LDAP://$($TargetObject.DistinguishedName)"

        # Set new Owner
        $NewOwner = New-Object System.Security.Principal.NTAccount("DOMAINXXX", "Domain Admins")
        $AdsiTarget.PSBase.ObjectSecurity.SetOwner($NewOwner)
        $AdsiTarget.PSBase.CommitChanges()
        }
    Catch {
        Write-Warning $($_)
        $SamAccountName
        }
    
    # Release variable
    $SamAccountName = $null
    }

 

Les ordinateurs

# Computers
$NoGood | foreach {
    # Current  Computer
    $SamAccountName = $_.SamAccountName

    # Change Owner
    Try {
        # Define Target
        $TargetObject = Get-ADComputer $SamAccountName
        $AdsiTarget = [adsi]"LDAP://$($TargetObject.DistinguishedName)"

        # Set new Owner
        $NewOwner = New-Object System.Security.Principal.NTAccount("DOMAINXXX", "Domain Admins")
        $AdsiTarget.PSBase.ObjectSecurity.SetOwner($NewOwner)
        $AdsiTarget.PSBase.CommitChanges()
        }
    Catch {
        Write-Warning $($_)
        $SamAccountName
        }

    # Release variable
    $SamAccountName = $null
    }

 

O365 : Réaliser un hard match

 

Comme expliqué dans l'article précédent "O365 : Soft Match (SMTP) et Hard Match (ImmutableID)" le Hard Match intervient lorsque le Soft Match n'a pas fonctionné.

Les étapes à suivre sont les suivantes:

  1. Récupérer le GUID du compte dans l'Active Direcotry
  2. Convertir ce dernier en ImmutableID
  3. Appliqué cet ImmutableID au compte Azure Active Directory
  4. Relancer une synchronisation via Ad connect 

Voici donc les commandes pour cela.

# 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 MsolService
Connect-Msolservice

# Set ImmutableID to msoluser
Set-MsolUser -UserPrincipalName $Upn -ImmutableId $ImmutableId

 

Et voila, vous n'avez plus qu'a relancer une Synchor AD Connect via la commande suivante.

Start-ADSyncSyncCycle -PolicyType Delta

 

 

Powershell : Who's the owner of my AD objects

Lors de la création d'un objet Active Directory, un propriétaire est inscrit dans l'attribut "Security Descriptor" ce dernier dépend de "qui" a créé le compte.

 

  • Dans un AD sans délégation de droits d'administration.

Si l'utilisateur qui créé l'objet est membre du groupe :

  • "Enterprise Admins" et "Domain Admins" : Le propriétaire sera le groupe "Domain Admins"
  • "Domain Admins" : Le propriétaire sera le groupe "Domain Admins"

  • "Enterprise Admins" : Le propriétaire sera le groupe "Enterprise Admins"

  • Dans un AD avec délégation de droits d'administration.

Lorsque l'on délègue les droits de création d'objets dans Active Directory, le compte utilisé pour créer des objets sera définit comme propriétaire de ces derniers.

Si par exemple je délègue la création d'objets de type "Users" au groupe "SG-Users-Management" et que le membre "Thomas DUPONT" créé un utilisateur, ce dernier sera propriétaire de l'objet utilisateur.

Si demain "Thomas DUPONT" n'est plus membre du groupe (pour n'importe quelle raison), il ne sera plus en mesure de créer / Modifier / Supprimer d'utilisateurs (jusque la tout va bien c'est ce que l'on désire), MAIS (et oui il y en a toujours un) ce ne sera pas vrai pour tous les objets créés par "Thomas DUPONT" précédemment.

Pourquoi ?

Et bien simplement parce que ne l'oublions "Thomas DUPONT" est le propriétaire des objets qu'il a créé, par conséquent il possède par défaut le droit de lecture et modification de l'objet.

Et donc ?

Ne l'oublions pas, le droit "Modify" permet de gérer les autorisations sur un objet, par conséquent il est donc possible pour "Thomas DUPONT" de se donner un droit "Full Control" sur ces objets.

Mais alors comment on identifie ces objets ?

Voici comment vérifier qui est le propriétaire des objets présents dans Active Directory.

  • Dans Active Directory Users and Computers

Comme nous l'avons vu plus haut il est possible via la console Active Directory Users and Computers de voir qui est le propriétaire d'un objet en passant par l'onglet "Security" puis "Advanced", mais bon pour un objet à la limite mais on va pas passer tous les objets à la main, c'est la qu'entre en jeu la seconde solution "Powershell".

  • Avec powershell

 Avec Powershell, il suffit d'utiliser la commande "Get-Aduser" et de récupérer la propriété "nTSecurityDescriptor

$User = Get-ADUser mlemoine -Properties nTSecurityDescriptor

 Ok, mais on en fais quoi de ça me direz vous, c'est pas faux ça nous aide pas trop, alors complétons la commande comme suivant :

$User = Get-ADUser mlemoine -Properties nTSecurityDescriptor
$User.nTSecurityDescriptor.owner

C'est déjà mieux, mais si on vérifiait tout l'AD.

# Create Array
$Array = @()

# Collect AD infos
$Domain = Get-ADDomain | select -ExpandProperty NetBIOSName
$AllUsers = Get-ADUser -Filter * -Properties nTSecurityDescriptor

# Store Info
$AllUsers | foreach {
    $DistinguishedName = $_.DistinguishedName
    $GivenName = $_.GivenName
    $Name = $_.Name
    $ObjectClass = $_.ObjectClass
    $ObjectGUID = $_.ObjectGUID
    $SamAccountName = $_.SamAccountName
    $SID = $_.SID
    $Surname = $_.Surname
    $UserPrincipalName = $_.UserPrincipalName
    $nTSecurityDescriptor = $_.nTSecurityDescriptor
    
    
    $Array += New-Object psobject -Property @{
        DistinguishedName = $DistinguishedName
        GivenName = $GivenName
        Name = $Name
        Owner = $nTSecurityDescriptor.owner
        ObjectClass = $ObjectClass
        ObjectGUID = $ObjectGUID
        SamAccountName = $SamAccountName
        SID = $SID
        Surname = $Surname
        UserPrincipalName = $UserPrincipalName
        }
    
    $DistinguishedName = $null
    $GivenName = $null
    $Name = $null
    $nTSecurityDescriptor = $null
    $ObjectClass = $null
    $ObjectGUID = $null
    $SamAccountName = $null
    $SID = $null
    $Surname = $null
    $UserPrincipalName = $null
    $CurrentUser = $null
    $nTSecurityDescriptor = $null
    }

Bon maintenant qu'on a stocké les donnés, il faudrait les exploiter :

# How many Accounts were returns ?
Write-Host $Array.Count -ForegroundColor Yellow

# How many Accounts need to be reviewed ?
$NoGood = $Array.Where({(($_.Owner -ne "$Domain\Domain Admins") -and ($_.Owner -ne "$Domain\Enterprise Admins") -and ($_.Owner -ne "BUILTIN\Administrators"))})
Write-Host $NoGood.count -ForegroundColor Cyan

Apparement j'ai 12 comptes sur les 6031 de mon AD qui n'ont pas "Domain Admins", "Enterprise Admins" ou "Administrators" comme Owner, voyons voir cela.

$NoGood | ft Name,Owner

Ah, attention on voit bien que qu'il y a des objets liés à Exchange, je vais donc ajouter un filtre.

$Filter = $NoGood.Where({$_.Name -notlike "HealthMailbox*"})

Et voilà, je n'ai plus qu'un objet, super.

Il est possible d'appliquer la même mécanique aux éléments ci-dessous en modifiant la requête :

  • Unités d'Organisation
  • Groupes
  • Ordinateurs

 Unités d'Organisation

# Create Array
$Array = @()

# Collect AD infos
$Domain = Get-ADDomain | select -ExpandProperty NetBIOSName
$AllOU = Get-ADOrganizationalUnit -Filter * -Properties nTSecurityDescriptor

# Store Info
$AllOU | foreach {
    $City = $_.City
    $Country = $_.Country
    $DistinguishedName = $_.DistinguishedName
    $ManagedBy = $_.ManagedBy
    $Name = $_.Name
    $nTSecurityDescriptor = $_.nTSecurityDescriptor
    
    
    $Array += New-Object psobject -Property @{
        City = $City
        Country = $Country
        DistinguishedName = $DistinguishedName
        ManagedBy = $ManagedBy
        Name = $Name
        Owner = $nTSecurityDescriptor.owner
        }
    
    $City = $null
    $Country = $null
    $DistinguishedName = $null
    $ManagedBy = $null
    $Name = $null
    $nTSecurityDescriptor = $null
    }

# How many Accounts were returns ?
Write-Host $Array.Count -ForegroundColor Yellow

# How many Accounts need to be reviewed ?
$NoGood = $Array.Where({(($_.Owner -ne "$Domain\Domain Admins") -and ($_.Owner -ne "$Domain\Enterprise Admins") -and ($_.Owner -ne "BUILTIN\Administrators"))})
Write-Host $NoGood.count -ForegroundColor Cyan

 

Groupes

# Create Array
$Array = @()

# Collect AD infos
$Domain = Get-ADDomain | select -ExpandProperty NetBIOSName
$AllGroups = Get-ADGroup -Filter * -Properties nTSecurityDescriptor

# Store Info
$AllGroups | foreach {
    $DistinguishedName = $_.DistinguishedName
    $GroupCategory = $_.GroupCategory
    $GroupScope = $_.GroupScope
    $Name = $_.Name
    $ObjectClass = $_.ObjectClass
    $ObjectGUID = $_.ObjectGUID
    $SamAccountName = $_.SamAccountName
    $SID = $_.SID
    $nTSecurityDescriptor = $_.nTSecurityDescriptor
    
    
    $Array += New-Object psobject -Property @{
        DistinguishedName = $DistinguishedName
        GroupCategory = $GroupCategory
        GroupScope = $GroupScope
        Name = $Name
        ObjectClass = $ObjectClass
        ObjectGUID = $ObjectGUID
        SamAccountName = $SamAccountName
        SID = $SID
        Owner = $nTSecurityDescriptor.owner
        }
    
    $DistinguishedName = $null
    $DNSHostName = $null
    $Enabled = $null
    $Name = $null
    $ObjectClass = $null
    $ObjectGUID = $null
    $SamAccountName = $null
    $SID = $null
    $nTSecurityDescriptor = $null
    }

# How many Accounts were returns ?
Write-Host $Array.Count -ForegroundColor Yellow

# How many Accounts need to be reviewed ?
$NoGood = $Array.Where({(($_.Owner -ne "$Domain\Domain Admins") -and ($_.Owner -ne "$Domain\Enterprise Admins") -and ($_.Owner -ne "BUILTIN\Administrators"))})
Write-Host $NoGood.count -ForegroundColor Cyan

 

Ordinateurs

# Collect AD infos
$Domain = Get-ADDomain | select -ExpandProperty NetBIOSName
$AllComputers = Get-ADComputer -Filter * -Properties nTSecurityDescriptor

# Store Info
$AllComputers | foreach {
    $DistinguishedName = $_.DistinguishedName
    $GroupCategory = $_.GroupCategory
    $GroupScope = $_.GroupScope
    $Name = $_.Name
    $ObjectClass = $_.ObjectClass
    $ObjectGUID = $_.ObjectGUID
    $SamAccountName = $_.SamAccountName
    $SID = $_.SID
    $nTSecurityDescriptor = $_.nTSecurityDescriptor
    
    
    $Array += New-Object psobject -Property @{
        DistinguishedName = $DistinguishedName
        DNSHostName = $DNSHostName
        Enabled = $Enabled
        Name = $Name
        ObjectClass = $ObjectClass
        ObjectGUID = $ObjectGUID
        SamAccountName = $SamAccountName
        SID = $SID
        Owner = $nTSecurityDescriptor.owner
        }
    
    $DistinguishedName = $null
    $DNSHostName = $null
    $Enabled = $null
    $Name = $null
    $ObjectClass = $null
    $ObjectGUID = $null
    $SamAccountName = $null
    $SID = $null
    $nTSecurityDescriptor = $null
    }

# How many Accounts were returns ?
Write-Host $Array.Count -ForegroundColor Yellow

# How many Accounts need to be reviewed ?
$NoGood = $Array.Where({(($_.Owner -ne "$Domain\Domain Admins") -and ($_.Owner -ne "$Domain\Enterprise Admins") -and ($_.Owner -ne "BUILTIN\Administrators"))})
Write-Host $NoGood.count -ForegroundColor Cyan



O365 : Soft Match (SMTP) et Hard Match (ImmutableID)

Lorsque l'on utilise Active Direcotry et Azure Active Directory, il se peut que l'on soit confronter à des conflits car l'utilisateur existe déjà dans les deux environnements (selon divers scénarios).

Quand il s'agit bien du même utilisateur (et non pas un homonyme) il est important  de créer un "matching" entre les deux comptes pour que l'AD Connect puisse les voir comme un seul et même compte et les synchroniser.

Pour ce faire il existe deux méthodes:

  1. Le Soft Match appelé aussi SMTP Matching
  2. Et le Hard Match (basé sur l'ImmutableID)

Le Soft Match

Le soft match appelé aussi "smpt matching" consiste à s'appuyer sur l'adresse SMTP de l'utilisateur pour faire l'association entre les deux comptes.

Ce dernier est censé fonctionner dans la plupart des cas, mais pour cela il y a quelques conditions à respecter. 

  1. L'utilisateur doit posseder une adresse email sur Microsoft Exchange Online.
    1. s'il s'agit d'un contact ou d'un groupe à extension de messagerie le soft match sera basé sur l'attribt "proxyaddresses"
  2. Vous ne devrez pas modifier l'adresse SMTP principale de l'utilisateur durant l'opération.
  3. Les adresses SMTP sont considérées comme unique assurez vous que seul cet utilisateur possède cette adresse.

Le Hard Match

Le hard match entre en action lorsque le soft match n'a pas réussi, ce dernier consiste à récupérer le GUID du compte Active Directory pour le transformer en ImmutableID et enfin l'appliquer au compte Azure Active Directory.

Cette opération permettera de faire la liaison entre les deux comptes pour n'en faire qu'un synchronisé.

ADMT : Contrôleur de domaine à utiliser lors d'une migration ordinateur

Durant une migration ordinateur avec l'outil ADMT d'un domaine source vers un domaine cible, il est possible de rencontrer l’erreur ci-dessous :

ERR3:7075 Failed to change domain affiliation, hr=80070005 Access is denied

Cette erreur sera enregistrée dans le fichier log de migration ADMT sous c:\windows\admt\logs.

Lors de la migration des objets ordinateurs avec ADMT, l'outil demande de choisir les contrôleurs de domaine source et cible à utiliser. Le choix du DC cible est très important !

Il ne faut pas choisir n'importe quel DC cible, il faut plutôt utiliser le nom du DC où la configuration ci-dessous a été faite.

Resolution de l'erreur:

Cette erreur peut être résolue par deux méthodes :

1. Activer la stratégie de groupe (GPO) suivante sur tous les contrôleurs de domaine cible (Default domain policy) :

“Computer Settings\Windows Settings\Security Settings\Local Policies\Security Options\NetWork Access: Named Pipes that can be accessed anonymously” avec au moins les services “netlogon,lsarpc” inclus.

2. Choisir un des contrôleurs de domaine cible (qui sera utilisé lors de la migration ordinateur) et créer la clé de registre suivante : "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionPipes" avec les valeurs "netlogon,lsarpc"

Source : https://santhoshsivarajan.wordpress.com/2010/10/30/admt-err37075-failed-to-change-domain-affiliation-access-is-denied/

Explication de l’erreur:

ADMT agents sync the computer with the target domain using anonymous connections to the LSARPC and NETLOGON named pipes on the target domain's DC.

Source : https://social.technet.microsoft.com/Forums/ie/en-US/304f25a2-cb85-4570-b616-669a5a874ba0/admt-computer-migration-failures?forum=winserverMigration

 

Remarque :

Le fait d'installer l'outil ADMT PES (Paswword Export Server) sur un contrôleur de domaine, la clé de registre ci-dessus sera créée automatiquement.

Active Directory : Restaurer des objets de la corbeille sous 2008

Quand on a l'habitude d'utiliser la console Active Directory Administrative Center pour restaurer des objets AD et que l'on désire restaurer des objets AD sur un Active Directory sous Windows server 2008, on peut se sentir décontenancer.

Eh oui pas de console ADAC sur Windows Server 2008, bon alors on fait quoi ? Powershell !!!

Pour lister tous les objets de la corbeille :

# List All Deleted objects
$AllDeletedObjects = Get-ADObject -ldapFilter:"(msDS-LastKnownRDN=*)" –IncludeDeletedObjects -Properties *

Ensuite libre à vous de filtrer sur les types d'objets, nom et autres propriétés.

# List All Deleted Groups
$DeletedGroups = $AllDeletedObjects | Where {$_.ObjectClass -eq "group"}

Et enfin restaurer ce qui vous intéresse dans l'OU de destination qui convient (ici le groupe "GS-Office-E3" restaurer dans l'OU "RestaurationPlace")

$ToRestore = $DeletedGroups | Where {$_.Name -like "GS-Office-E3"}
$DeletedGroups | Restore-ADObject -TargetPath "OU=RestorationPlace,DC=Demo,DC=corp"