Azure AD Connect – Installation et migration de v1.6 vers v2

AAD-Logo

En partant d’une installation d’Azure AD Connect 1.6 installé précédement dans l’article :

Nous allons réaliser une nouvelle installation d’Azure AD Connect sur un nouveau serveur et réaliser la migration de l’ancien serveur vers ce nouveau serveur.

Azure AD Connect est une composante de l’identité à considérer dans le tier 0 de votre infrastructure si ce modèle est en place. Par conséquent les opération réalisées sont toutes exécutées avec un compte “Domain Admin” / “Enterprise Admin”.

PICTO_AVERTISSEMENT

La version 1.X d’Azure AD Connect est supportée jusqu’au 31 aout 2022.

Il conviendra de migrer version la version 2.X avant cette date si.

Download

Pour commencer, nous allons télécharger le fichier msi d’Azure AD Connect. Pour ce faire se rendre sur le lien ci-dessous.

Ce KB Microsoft référence l’ensemble des versions d’AADC.

Deux versions d’AADC cohabitent pour le moment jusqu’à aout 2022. Comme explique en introduction, la version 1.X (1.6.16.0) est déployée sur un autre serveur et réalise la synchronisation. 

Cliquer sur le lien pour télécharger les binaires de va version 2.

AADC2_download_0010
2.x

Prérequis

Avant de lancer l’installation, quelques prérequis sont nécessaires.

Des informations supplementaires sur les prérequis sont disponible dans le KB Microsoft :

RSAT ADDS

Pour commencer, nous allons installer les RSAT sur le serveur AADC. Ceux-ci ne sont pas indispensables, mais simplifient grandement les opérations sur AD.

Pour ce faire, lancer depuis PowerShell la commande ci-dessous :

Install-WindowsFeature -Name RSAT-AD-Tools
AADC1.6_prerequisits_0010
RSAT ADDS
Création d'un compte de service managé pour AADC (ADSync)

Le service AADC (ADSync) nécessite un compte de service pour s’exécuter sur la machine.

Dans la mesure où le serveur AADC de cette maquette est joint dans le domaine AD, nous allons créer un compte de type GMSA pour celui-ci.

Import-Module ActiveDirectory


Get-KdsRootKey
#Check if necessary ?
#Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))
#Get-KdsRootKey


$Param = @{
    Name = 'gMSA-AADC02'
    Description = 'Service account for AADC'
    DNSHostName = 'gMSA-AADC02.teddy.lan'
    PrincipalsAllowedToRetrieveManagedPassword = 'AADC02$'
}

New-ADServiceAccount @Param  -PassThru

Get-ADServiceAccount -Identity $Param.Name
AADC2_gmsa_0010
GMSA
Export de la configuration d'AADC

Depuis le serveur Azure AD Connect d’origine, il va être nécessaire d’exporter la configuration de celui-ci.

Cet export permet de concervé entre autre les règles personnalisées.

cd "C:\Program Files\Microsoft Azure Active Directory Connect\Tools"
.\MigrateSettings.ps1

Une fois la configuration exportée, copier le répertoire contenant ‘export sur le nouveau serveur AADC.

Récupération du compte ADConnector

Depuis le serveur d’origine, il est nécessaire de récupérer le compte ADConnector qui permet de faire la liaison entre Azure AD Connect et Active Directory.

Pour se faire depuis le serveur d’origine lancer le script ci-dessous :

Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"

Get-ADSyncADConnectorAccount
TLS1.2

Azure AD Connect v2 utiliser TLS1.2, il est obligatoire d’activer celui-ci sur votre server. Toutes les informations à ce sujet sont disponibles dans le KB MS :

Microsoft met le script ci-dessous pour activer TLS1.2 :

If (-Not (Test-Path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319'))
{
    New-Item 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
}
New-ItemProperty -Path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Name 'SystemDefaultTlsVersions' -Value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -PropertyType 'DWord' -Force | Out-Null

If (-Not (Test-Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319'))
{
    New-Item 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
}
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Name 'SystemDefaultTlsVersions' -Value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -PropertyType 'DWord' -Force | Out-Null

If (-Not (Test-Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server'))
{
    New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force | Out-Null
}
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Name 'Enabled' -Value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Name 'DisabledByDefault' -Value '0' -PropertyType 'DWord' -Force | Out-Null

If (-Not (Test-Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client'))
{
    New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force | Out-Null
}
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Name 'Enabled' -Value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Name 'DisabledByDefault' -Value '0' -PropertyType 'DWord' -Force | Out-Null

Write-Host 'TLS 1.2 has been enabled. You must restart the Windows Server for the changes to take affect.' -ForegroundColor Cyan

Bien que ce ne soit pas un prérequis, je vous conseille de désactiver par la même occasion TLS1.0 ET TLS1.1 sur vos environnements.

Pensez à réaliser cette opération sur Azure AD Connect et aussi sur ADFS + WAP si vous utilisez ces technologies. 

Un peu de lecture dans le KB Microsoft :

Installation d'Azure AD Connect

La première étape pour avoir un Azure AD Connect fonctionnel est l’installation des binaires.

Lancer le fichier “AzureADConnect.msi” préalablement téléchargé.

Dès que la première phase d’installation est terminé et que le wizzard propose d’accèpter la licence, fermer Azure AD Connect, puis relancer Azure AD Connect avec le paramètre “/InteractiveAuth“.

cd "C:\Program Files\Microsoft Azure Active Directory Connect\"
.\AzureADConnect.exe /InteractiveAuth

Accepter la licence.

Séléctionner “Customize”.

Dans la fenètre “Install required components”, saisir les informations ci-dessous :

  • Use an existing service account –> Managed Service Account –> Renseigner le compte GMSA créé en prérequis.
  • Import synchronization settings –> renseigner le chenin du fichier “MigratedPolicy.json”.

Le fichier “MigratedPolicy.json” est dans le répertoire d’export de la configuration réalisé lors des prérequis.

Puis cliquer sur “Install”.

Laisser séléctionné “Password Hash Synchronization”.

Se loguer sur Azure AD à l’aide d’un compte “Global Administrator”.

Pour la connection à Active Directory, renseigner le compte ADConnector récupéré lors des phases de prerequis.

S’assurer que les deux options sont séléctionnées :

  • Start the synchronization process when configuration completes.
  • Enable stagging mode.

Le Stagging mode permet la “cohabitation” avec l’ancien serveur et “simulant” une synchronisation sans la réaliser en production.

Après quelques instants, la configuration est terminée.

Nous pouvons noté dans la dernière ligne, que l’import de la configuration a bien été réalisée.

Quelques vérifications

Synchronization Service

Du coté du service de synchronisation, nous pouvons constater que uniquement le opérations d’import et de synchronisation ont lieu. Les opérations d’export, ne sont pas réalisées pour le moment (le Stagging mode étant activé).

Il est important de vérifier que lors des projection dans le metaverse, les objets sont bien synchronisés. Et surtout qu’il n’y est pas de suppression massive d’objets. Ce qui est synonyme de mauvaise configuration d’AADC et surtout un risque de supprimer les compte du coté d’AzureAD.

Configuration d'AADC

Dans la configuration d’Azure AD Connect, nous pouvons vérifier /constater que la configuration a bien été reprise.

Par exemple, je ne synchronise pas l’ensemble des OU de l’AD ou encore je synchronise un custom attribut de mon AD.

Azure AD Connect Configuration Documenter

Microsoft met à disposition sur GitHub l’utilitaire “Azure AD Connect Configuration Documenter” afin de vérifier les différence entre deux configuration d’Azure AD Connect. Cet utilitaire à la comme juge de paie.

 

Sur les deux serveurs AADC (v1.x et v2) exporter la configurationd es serveurs à l’aide des commandes PowerShell :

Import-Module ADSync

$ExportPath = "c:\temp\ADSyncCfg\$($env:COMPUTERNAME)"

Get-ADSyncServerConfiguration -Path $ExportPath

ls $ExportPath

Puis copier l’export de l’ancien server sur le nouvau serveur à coté de l’export de la configurationd e celui-ci.

Télécharger l’utilitaire “Azure AD Connect Configuration Documenter” depuis :

$DLFile = "c:\temp\AADCCfgDocumenter.zip"
$DLURI = "https://github.com/microsoft/AADConnectConfigDocumenter/releases/download/v1.20.0917.0/AzureADConnectSyncDocumenter.zip"
$ExtractPath = "c:\temp\AADCCfgDocumenter\"

function download() {$ProgressPreference="SilentlyContinue"; Invoke-WebRequest -Uri $DLURI -OutFile $DLFile}
download

Expand-Archive -Path $DLFile -DestinationPath $ExtractPath

Puis copier les export réalisés précédament dans le répertoire :

  • .\AADCCfgDocumenter\Data\

Puis éditer le fichier :

  • .\AADCCfgDocumenter\AzureADConnectSyncDocumenter-Contoso.cmd

Pour remplacer “Contoso\Pilot” et “Contoso\Production” par les nom des répertoires contenant les exports.

Et enfin éxécuter le fichier “AzureADConnectSyncDocumenterCmd.exe”.

Le rapport html est disponible dans le répertoire :

  • .\AADCCfgDocumenter\Report\

Parcourir le rapport en s’assurant qu’il n’y est pas d’écart majeur. Vu que nous somme sur une montée de version et un changement de serveur, il y a des différences entre les deux export relatif à cette modification, ceux-ci est normal. Un petit script additionnel est présent dans le rapport afin de mettre en évidence les différences.

A ce stade ci, nous pouvons affirmer que la configuration de la version 1.x a bien été reprise sur le nouveau serveur et que le risque d’erreur de synchronisation est faible.

Nous allons pouvoir basculer notre nouveau serveur en production et retirer l’ancien serveur.

Bascule de Stagging à Production

La bascule d’un serveur à l’autre se déroule en 3 étapes. Pendant la bascule et l’heure qui suit, il peut y avoir un peu de flottement au niveau de l’état de synchronisation surtout pour la mise à jour des mot de passe (PHS).

  • La première étape consiste à passer l’ancien serveur en Stagging mode.
  • La seconde étape consiste à sortir le nouveau serveur du Stagging mode.
  • La troisième étape consiste à nettoyer et supprimer l’ancien serveur.
Ancien serveur passage en Stagging mode

Lancer Azure AD Connect, aller dans la configuration et séléctionner “Configure staging mode”.

S’authentifier puis activer le mode staging.

Cliquer sur configure pour basculer le serveur en staging mode.

Après quelques instants, le serveur doit avoir configurer ça configuration.

Les opération de synchronisation sue le serveur doivent continuer à tourner, mais sans réaliser d’export.

Nouveau serveur quitter le Stagging mode

Lancer Azure AD Connect, aller dans la configuration et séléctionner “Configure staging mode”.

S’authentifier puis désactiver le mode staging.

Cliquer sur “Configure”. Après quelques instants, la configuration du serveur est terminée.

Si l’on se rend dans “Synchronization service”, nous pouvons constater que les étapes d’export sont désormais réalisées.

Etendre environ une heure, le temps que tous les jobs de synchronisation est tournés.

Puis lancer un diagnostic de synchronisation des mot de passe. Afin de s’assurer que tout est belle est bien fonctionnel. Créer un nouveau compte coté AD et vérifier le bonfonctionnement de celui-ci avec les service O365 peut-être un test supplémentaire.

Invoke-ADSyncDiagnostics -PasswordSync
Ancien serveur nettoyage et suppression

Quelques jours après la pascule, il est possible d’arréter définitivement l’ancien serveur AADC et de le supprimer.

Pour réaliser dans le plus proprement cette opération avec le moin de nettoyage manuel à faire, lancer la désinstallation d’Azure AD Connect depuis l’ancien serveur.

Puis sur Active Directory, supprimer :

  • Le compte gMSA rattaché au service ADSync de l’ancien serveur.
  • Le compte ordinateur du serveur.

Puis sur AzureAD, supprimer le compte :

  • “On-Premises Directory Synchronization Service Account” corespondant à l’ancien serveur (Sync_AADC01_xxxxxxxxxx@domain.onmicrosoft.com).

Et voilà la migration est terminée 🙂

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *