Avez-vous pensé à placer un contrôleur de domaine dans le Cloud ? La question aurait pu paraître déplacée il n’y a pas si longtemps compte tenu du caractère confidentiel que détient un contrôleur de domaine, mais aujourd’hui les mentalités ayant favorablement évolué en faveur du Cloud, cela mérite d’être rediscuté.
Il s’agit de l’objet de ce billet de blog au travers duquel je vous propose une petite réflexion sur le sujet, accompagnée d’informations techniques sur la mise en œuvre de cette solution.
Lors d’opérations de design d’infrastructure liées à Active Directory, il m’est souvent demandé de juger s’il est opportun de conserver un contrôleur de domaine hors du socle de virtualisation pour pallier à toute défaillance éventuelle des hyperviseurs et réduire ainsi les risques de type « Single Point of Failure ». Ma réponse est systématiquement la même : aucun critère technique ne permet d’opter en la faveur ou défaveur de ce choix, mais si vous avez confiance en votre socle de virtualisation, vous pouvez tout y placer et économiser ainsi les couts d’acquisition matérielle et logicielle induits par un serveur physique.
La réponse appartient donc à chacun, mais au cas où il serait jugé pertinent de placer un contrôleur de domaine hors socle de virtualisation, le serveur physique n’est pas la seule option : heureusement il y a le Cloud !
Critères techniques justifiant de ne pas conserver un contrôleur de domaine physique
Il existe des recommandations émanant de Microsoft, actant que le support d’un contrôleur de domaine sur une plateforme virtualisée est soumis à quelques restrictions. Ces restrictions ne sont en fait applicables qu’aux contrôleurs de domaine de version antérieure à Windows 2012, Microsoft ayant fait en sorte que ces « blocages » ne soient plus d’actualité. Pour autant, ces souvenirs sont bien ancrés dans les mémoires et bon nombre de décideurs n’osent pas franchir le pas du « tout virtualisé ». Pour rappel :
-
Pas d’utilisation de SnapShots, ou plus précisément, ne pas appliquer un snapshot sur un contrôleur de domaine
-
Il est nécessaire de conserver un contrôleur de domaine physique lorsque le socle de virtualisation s’exécute sur un cluster Hyper-V
En effet, les services de cluster d’ancienne génération nécessitent la présence d’un contrôleur de domaine pour démarrer. Pas de contrôleur de domaineè pas de cluster, pas de cluster èpas de VMs, la boucle est bouclée.
Désormais, le rôle de contrôleur de domaine est totalement supporté pour Windows 2012 / 2012 R2 sur les hyperviseurs certifiés pour ces versions. Quand bien même vous auriez la mauvaise idée d’y appliquer un snapshot, le mécanisme de protection « virtualization safeguards » gèrerait la situation de façon autonome grâce à l’attribut « VM Generation ID » comme cela est expliqué sur https://technet.microsoft.com/en-us/library/hh831734.aspx. Quant aux services de cluster, ils peuvent désormais démarrer sans la présence d’un contrôleur de domaine, il n’y a donc plus de problème, parole de consultant !
Considérations techniques pour la mise en place d’un contrôleur de domaine dans AZURE
La plateforme AZURE permet l’hébergement de machines virtuelles sur la base d’un catalogue de services proposant des OS Windows récents (2008R2 è 2012 R2). Partant de ce principe, on peut tout à fait attribuer le rôle de contrôleur de domaine a des machines virtuelles s’exécutant dans AZURE, le véritable intérêt étant tout de même que le tenant AZURE soit raccordé à votre Intranet et que les contrôleurs de domaine placés dans AZURE agissent en secours, au cas où….
Il faut cependant considérer quelques spécificités du cloud AZURE avant de décider d’y placer un contrôleur de domaine :
- Toutes les machines virtuelles AZURE sont en adressage dynamique.
- Le disque système des machines virtuelles présente un cache de type « Write Back ».
- Les machines virtuelles disposent d’un disque D : destiné à recevoir le swap et dont le contenu est volatile.
- Le rôle de contrôleur de domaine a pour vocation de servir des requêtes d’authentification et d’appliquer des paramètres de stratégie. Il convient de faire en sorte que ce service soit utilisé de façon adéquate, et d’éviter par défaut de faire transiter ce trafic sur AZURE où le contrôleur de domaine aura plutôt un rôle maintien des services d’annuaire en cas de sinistre (composant PRA).
Adressage IP dynamique.
Pas question d’affecter une adresse IP statique à une machine virtuelle dans AZURE en passant par les paramètres IP de Windows, si vous faites ça, vous aurez la désagréable surprise de voir votre configuration réseau revenir en DHCP toute seule.
Par contre, vous pourrez facilement attribuer une adresse IP permanente à une machine virtuelle en passant par le portail de gestion AZURE ou par une instance PowerShell attachée à votre tenant :
Disque système avec du cache « Write Back » et disque de Swap
Le cache Write Back permet d’améliorer les performances en écriture de façon significative. En revanche, il n’est pas approprié pour le maintien de données transactionnelles de type base de données. En effet, ce mode implique que les transactions d’écriture soient actées par l’application qui les considère alors comme valides. Dans le cas d’un contrôleur de domaine, la base de données NTDS est maintenue par un moteur « Jet » fonctionnant sur ce principe, toute modification d’objet Active Directory donne lieu à une écriture notifiée au contrôleur de domaine qui valide alors la transaction. Si la donnée se trouve dans le cache «Write Back » et qu’une coupure se produit, le risque de corruption de la base est réel.
Il conviendra donc de placer la base NTDS sur un volume distinct, surtout pas sur le volume D : dont le contenu est volatile mais bien sur un volume distinct qui aura été créé exprès et sur lequel nous nous assurerons de ne pas avoir de cache en Write Back.
Isolation des services d’annuaire vis-à-vis de requêtes émanant de l’Intranet
Les services d’annuaire Active Directory reposent sur un espace de noms DNS portant le nom du domaine (FQDN), les clients localisent les services d’annuaire grâce aux services DNS. Dans un environnement multi site, les clients localisent en priorité les contrôleurs de domaine rattachés à leur site. Si aucun n’est disponible, alors une requête est renvoyée à n’importe quel autre contrôleur de domaine, quel que soit sa localisation, et dans notre cas, il peut s’agir du contrôleur de domaine que nous avons mis dans AZURE.
Pour éviter ce comportement « par défaut », il suffit d’indiquer aux contrôleurs de domaine que l’on souhaite « isoler » de ne pas enregistrer leurs enregistrements de service dans la partie globale de la zone « _msdcs », ainsi, ils ne seront localisables que par les clients attachés au même site. Ceci peut être obtenu en modifiant la base de registre du contrôleur de domaine concerné, ou par stratégie de groupe.
Réf : https://support.microsoft.com/en-us/kb/306602 (Article ancien mais toujours d’actualité)
Dans notre cas, nous bloquerons les enregistrements des services suivants (base de registre è HKLM\Software\Policies\Microsoft\Netlogon\Parameters) et cela sera fait par GPO :
Création d’un réseau Virtuel dans AZURE
La première étape technique est de créer un « Vnet » et un « Subnet dans AZURE . Nous allons créer quelque chose qui ressemble à ceci :
- Un réseau Virtuel disposant d’un espace d’adressage 10.100.0.0 /16
- Une référence DNS vers deux serveurs dont un se trouvant dans AZURE
- Un sous réseau 10.100.0.0 24
Voici notre objectif :
Pour arriver à cet objectif, nous passons par le portail « classique » du tenant AZURE (https://manage.windowsazure.com ), dans l’espace « NetWorks » et choisissons l’option « Custom Create »:
A l’issue de cet assistant, nous avons un environnement de réseau nommé « Hybrid Cloud », dont les serveurs DNS sont référencés et sur lequel nous avons créé un premier sous réseau, exactement comme sur le schéma.
Référencement d’un réseau local (Intranet) dans AZURE
La seconde étape est de créer un réseau local correspondant à notre Intranet, c’est-à-dire le sous réseau 192.168.1.0 / 24
Nous allons ajouter quelque chose qui ressemble à ceci : Le Cloud AZURE et notre Intranet, non connectés pour l’instant :
Nous allons donc créer ce réseau local dans AZURE :
Vous aurez noté que j’ai spécifié une adresse « VPN-DEVICE », il s’agit de l’adresse IP externe du routeur de notre DataCenter.
Interconnexion des réseaux
Ça touche à sa fin, nous allons connecter notre Intranet a AZURE. Pour cela, nous allons utiliser la plateforme RRAS de notre intranet (qui pour le moment n’est pas encore configurée) et le service Gateway du cloud AZURE.
Rendez-vous sur le portail AZURE pour modifier notre réseau virtuel, nous allons ajouter la connectivité « Site to Site » (S2S) vers notre Datacenter :
La configuration est alors créée, il reste à créer la Gateway et à configurer notre serveur RRAS.
Pour créer la Gateway, il suffit de cliquer sur « Create Gateway » et de choisir l’option « Dynamic Routing » seule supportée sur la plateforme RRAS (Réf : https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-about-vpn-devices/ )
La création de la Gateway est alors initiée. Cette opération est assez longue, pour ma part a pris une bonne demi-heure durant laquelle la Gateway apparait comme étant en création :
Une fois créée, la Gateway apparait avec son statut ainsi que les statistiques de données véhiculées, pour l’instant rien qui transite car le serveur RRAS n’est pas encore opérationnel:
Reste donc à configurer notre serveur RRAS. Pour cela, nous allons utiliser une fonctionnalité intéressante : la récupération d’un script de configuration, et ça tombe bien, il y en a justement un pour RRAS :
Le script sera exécuté sur notre serveur RRAS, depuis une invite PowerShell en mode privilégié, et notre serveur RRAS se connectera à la Gateway qui apparaitra cette fois ci comme connectée :
Nous voila au terme de la partie réseau, ce qui nous amène à cet état :
Note : le serveur HC-SRV-DC01 va être provisionné à l’étape suivante
Je ne l’ai pas précisé, mais le serveur RRAS doit bien entendu être connecté à l’Internet, soit par une adresse IP publique, soit par une translation d’adresse IP publique (NAT Transversal). Pour ma part, je suis connecté derrière une Box ADSL disposant d’une IP fixe et qui permet de gérer les redirections de ports utilisés pour faire de l’IPSec en mode NatTransversal (UDP 500 et UDP 4500). Ces deux ports sont redirigés vers le serveur RRAS :
Active Directory : Création du site AZURE
Avant de promouvoir un serveur comme contrôleur de domaine dans AZURE, il est important de créer au préalable le site Active Directory correspondant à cet emplacement et de l’associer aux sous réseaux que nous y avons définis.
Ceci se fait comme pour n’importe quel site Active Directory, depuis la console « Sites et Services » de notre domaine existant, nous allons créer le sous réseau puis le site que nous associerons à ce sous réseau :
Création de la machine virtuelle
Comme nous l’avons évoqué précédemment, s’agissant d’un contrôleur de domaine, la machine virtuelle doit être créée en respectant quelques précautions :
- Un disque de données sans cache d’écriture (base de données NTDS)
- Une adresse IP statique
- La connexion au sous réseau que nous avons interconnecté à notre Intranet.
Tout ceci peut être effectué depuis le portail AZURE :
Mais c’est aussi réalisable en PowerShell :
[code language=”powershell”]
#Choix de la soucription AZURE
$subscription="Pass Azure"
$StorageAccount="adstorageaccount"
Select-Azuresubscription -SubscriptionName $subscription –Current
Set-Azuresubscription -SubscriptionName $subscription -CurrentStorageAccountName $StorageAccount
#Choix de la dernière image 2012 R2
$family = "Windows Server 2012 R2 Datacenter"
$image = Get-AzureVMImage | where { $_.ImageFamily -eq $family } | sort PublishedDate -Descending | select -ExpandProperty ImageName -First 1
# Caracétéristiques de la VM
$vmname = "HC-SRV-DC01"
$vmsize = "Basic_A1"
$vm = New-AzureVMConfig -Name $vmname -InstanceSize $vmsize -ImageName $image
$cred = Get-Credential -Message "Type the name and password of the local administrator account."
$vm | Add-AzureProvisioningConfig -Windows -AdminUsername $cred.GetNetworkCredential().Username -Password $cred.GetNetworkCredential().Password
$vm | Set-AzureSubnet -SubnetNames "Subnet-1"
$vm | Set-AzureStaticVNetIP -IPAddress 10.100.0.200
$disksize=20
$disklabel="DCData"
$lun=0
$hcaching="None"
$vm | Add-AzureDataDisk -CreateNew -DiskSizeInGB $disksize -DiskLabel $disklabel -LUN $lun -HostCaching $hcaching
$svcname="ad-hybridcloud"
$vnetname="Hybrid Cloud"
New-AzureVM –ServiceName $svcname -VMs $vm -VNetName $vnetname
[/code]
Ajout du rôle Contrôleur de domaine
Une fois la machine virtuelle provisionnée, l’ajout du rôle contrôleur de domaine se fera de façon traditionnelle par le gestionnaire de serveur ou en PowerShell. Il convient de dissocier :
- L’ajout des binaires nécessaires au rôle (AD-DS et DNS en général)
- La configuration du rôle Contrôleur de domaine
Nous favoriserons l’installation via PowerShell, à lancer depuis une invite PowerShell sur le serveur concerné. Le code PowerShell ci-dessous traite les deux opérations (installation des binaires et configuration du rôle). Notez que le chemin de stockage de la base de données et du dossier Sysvol a été défini sur le disque de données sans cache d’écriture :
[code language=”powershell”]
$Features =@(‘AD-Domain-Services’,’DNS’)
Add-WindowsFeature -Name $Features -IncludeManagementTools
$RecoveryPassword = convertto-securestring "P@ssw0rd" -asplaintext -force
Install-ADDSDomainController `
-DomainName "hybridcloud.local" `
-DatabasePath "F:\AD\NTDS" `
-InstallDns `
-SafeModeAdministratorPassword $RecoveryPassword `
-SiteName "AZURE-DATACENTER" `
-SysvolPath "F:\AD\SYSVOL" `
-Force
[/code]
Une fois le rôle configuré, nous pouvons contrôler l’état de la réplication à l’aide de la commande RepAdmin :
Nous pouvons également vérifier l’état des partages Netlogon et Sysvol, indiquant que le rôle est bien actif :
Et voilà notre contrôleur de domaine opérationnel dans le Cloud AZURE. Il ne reste plus qu’à faire en sorte que les enregistrements de service globaux ne soient pas enregistrés dans la zone _msdcs.
Rien de tel qu’une petite stratégie de groupe pour ça, juste liée aux contrôleurs de domaine AZURE :
Il faut activer le paramètre « DC Locator DNS Records not registered by the DC’s » en y spécifiant les mnémoniques LdapIpAddress Ldap Gc GcIPAddress Kdc Dc DcByGuid Rfc1510Kdc Rfc1510Kpwd Rfc1510UdpKdc Rfc1510UdpKpwd GenericGc :
De cette façon, les enregistrements de service seront bien apportés au site AZURE :
Et pas au niveau du domaine, ou nous n’aurons que les enregistrements de service des contrôleurs de domaine « on premise » :
Conclusion
Nous avons désormais un environnement Active Directory parfaitement opérationnel « on Premise » et dans le Cloud, élaboré en tenant compte des spécificités techniques des machines virtuelles AZURE et des contraintes fonctionnelles des services Active Directory :
