Comment déléguer la gestion d'une liste de distribution dans Exchange 2010 ?

Préambule : le modèle de permissions RBAC d'Exchange 2010

Si vous désirez donner la possibilité à vos utilisateurs finaux de gérer leurs listes de distribution, il faut d'abord que vous sachiez que la manière de faire ça dans Exchange 2010 est complètement différente que dans les versions précédentes d'Exchange.

En effet, le modèle de permissions dans Exchange 2010 est basé sur le RBAC (Role Based Access Control). Ceci permet la gestion très fine des permissions. L'intérêt sera évidemment de déléguer des tâches très précises à des utilisateurs à différents niveaux dans l'entreprise.


Le modèle RBAC appliqué à la délégation de gestion d'une liste de distribution

Imaginons qu'un département a besoin de gérer une liste de distribution fréquemment mise à jour. Il est peu intéressant de laisser cette tâche entre les mains d'un administrateur de messagerie Exchange ou même des membres du helpdesk de votre entreprise.

On veut donc donner la possibilité au gestionnaire de cette liste de distribution le droit d'ajouter et de retirer des membres de cette liste.


1) Donner le droit de gestion de la liste à votre utilisateur

Ceci peut se faire via l'ADUC, l'ADAC, mais également via la console EMC (Exchange Management Console).

Nous allons réaliser l'opération via cette dernière.

Recipient Configuration > Distribution Group > 'Votre liste de distribution" > Properties

Cliquez sur l'onglet Group Information et ensuite il vous suffit d'ajouter l'utilisateur gestionnaire de cette liste de distribution.

Via Powershell

Set-DistributionGroup -Identity "DistributionList01" –ManagedBy "Pierre-Alexandre Braeken" -BypassSecurityGroupManagerCheck

2) Le rôle de gestion MyDistributionGroups n'est pas suffisamment granulaire

Rendons-nous sur notre console ECP (Exchange Control Panel) afin de définir un rôle de gestion dont l'objectif est la gestion des membres de la liste de distribution dont notre utilisateur est responsable.

ECP > Role & Auditing > Default Role Assignment Policy > Details

On tombe très rapidement sur ce rôle de gestion : MyDistributionGroups. Mais nous n'allons pas pouvoir l'utiliser. En effet, ce rôle permet à un utilisateur de créer et supprimer des listes de distribution. Ce rôle n'est donc pas assez restrictif puisque nous ne voulons permettre à notre utilisateur que l'ajout/suppression des membres de la liste de distribution.

3) Il nous faut créer notre propre rôle de gestion

Nous allons devoir créer notre propre rôle de gestion, et c'est ici qu'on va pouvoir apprécier la puissance du modèle de permissions RBAC d'Exchange 2010.

Let's Powershell !

Ouvrez une invite Exchange Management Shell.

New-ManagementRole -Name MyDistributionGroupsMembers -Parent MyDistributionGroups

Cette commande permet la création d'un rôle enfant du rôle vu précédemment. Nous devons donc logiquement retirer les possibilités de création/suppression d'une liste de distribution à ce nouveau rôle.

Vous pouvez également ajouter une description à votre nouveau rôle grâce au paramètre Description. La description devra être entourée de " ".

Powershell est à nouveau notre ami et nous entrons les deux commandes suivantes :

Remove-ManagementRoleEntry MyDistributionGroupsMembers\New-DistributionGroup -Confirm:$false

Remove-ManagementRoleEntry MyDistributionGroupsMembers\Remove-DistributionGroup -Confirm:$false

Nous sommes fin prêts désormais à assigner ce nouveau rôle que nous venons de créer à notre policy par défaut.

Nous avons encore besoin d'un peu de Powershell pour ceci :

New-ManagementRoleAssignment -Role MyDistributionGroupsMembers -Policy "Default Role Assignment Policy"

Si nous retournons à nouveau éditer notre policy "Default Role Assignement Policy", nous voyons que notre rôle a bien été ajouté comme enfant du rôle MyDistributionGroups.

Vos utilisateurs responsable de listes de distribution peuvent désormais ajouter/supprimer des membres des celles-c !

Windows Server 2012 : Supprimer un contrôleur de domaine corrompu, hors service, en panne de l'Active Directory + seize des rôles FSMO

Scénario

J'ai une infrastructure composée de 3 DC : DC01, DC02, DC03

Le scénario est le suivant :

Le DC01 possède les 5 rôles FSMO.

La zone DNS est intégré à l'active directory et se situe donc dans la partition d'application de notre base Active Directory.

Les DC02 et DC03 sont deux RWDC.

DC01 tombe en panne. Il est irrécupérable. Nous n'avons pas de backup de ce DC.

Nous allons donc devoir :

1) Réaliser le seizing des 5 rôles FSMO
2) Supprimer le DC de notre base Active Directory.

1) Seizing des rôles FSMO

Nous nous connectons au DC02 (un Domain Controller fonctionnel de votre infrastructure, sur lequel vous désirez seizer les rôles FSMO) pour réaliser les opérations qui vont suivre.

Une fois connecté à DC02, lancer un command prompt et entrez la commande "ntdsutil".

Ensuite, entrez la commande "roles". Le prompt affiche désormais "fsmo maintenance:".  Arrivé à ce stade, on peut interroger le système à propos des options disponibles en entrant le symbole "?".

On peut voir que différentes options sont proposées. D'une part, on a toutes les opérations de seizing et d'autre part, les opérations de transfert. Il y a également la commande "Connections" qui va nous servir dès maintenant afin de nous connecter au DC02.

Ok, nous encodons donc la commande "Connections".

Le prompt attend maintenant de nous que nous lui indiquions à quel DC se connecter en mentionnant "server connections: _". On encode la commande suivante "connect to server DC02".

Nous avons connecté ntdsutil à notre DC02. On peut quitter l'utilitaire de connexion en encodant la commande "q".

C'est le moment de réaliser le seizing. Les différentes commandes sont :

seize naming master

seize PDC

seize RID master

seize schema master

seize infrastructure master

Nous commençons par le rôle domain naming master en encodant la commande suivante : "seize naming master". Un message de confirmation nous demande si on est bien certain de vouloir réaliser l'opération qui consiste à demander à DC02 de seizer le rôle domain naming role. On clique sur "Yes".

Voici ce que vous pourrez voir au niveau du prompt. On peut observer que ntdsutil tente d'abord de transférer le rôle. Il rencontre une erreur et seulement ensuite, entreprend le seizing du rôle. Nice.

Il vous faut répéter cette étape avec les 4 autres rôles FSMO pour finalement obtenir tous vos rôles seizés.

Pour les plus paranoïaques d'entre-vous, vous pouvez encore vérifier que DC02 détient les rôles que vous venez de seizer en entrant la commande suivante : 

netdom query /domain:labo fsmo

Il faut remplacer labo par votre nom de domaine.

Ok, nous voici rassuré. Nous allons pourvoir passer à la deuxième partie de notre test.

2) Supprimer le DC de notre base Active Directory.

Selon Technet, il n'y a plus lieu de réaliser un metadata cleanup après la suppression forcée d'un DC.

When you use Remote Server Administration Tools (RSAT) or the Active Directory Users and Computers console (Dsa.msc) that is included with Windows Server 2008 or Windows Server 2008 R2 to delete a domain controller computer account from the Domain Controllers organizational unit (OU), the cleanup of server metadata is performed automatically. Previously, you had to perform a separate metadata cleanup procedure.

Nous allons donc tenter de vérifier ceci afin de voir si les différents enregistrements DNs sont bien purgés.

Avant la suppression de notre DC01, nous prenons un peu la température en vérifiant quelques enregistrements DNS (ici les ressources SRV). On voit bien les enregistrements relatifs à notre DC01.

Je n'ai pas une capture de l'ensemble des enregistrements, mais on a bien saisi l'idée ;-)

Au niveau enregistrement DNS A et NS, pas de problème c'est bien là également.

Selon Technet, on peut utiliser les RSAT, l'ADUC, ADSS ainsi que ntdsutil. On a choisi l'ADUC. Repérer votre DC, et clic droit > "Delete".

Un premier warning nous demande si on veut vraiment supprimer notre DC01. On  répond "Yes". On est venu spécialement pour ça ;-)

Un nouvel avertissement nous prévient qu'il faut utiliser dcpromo lorsqu'on veut dé-commissionner un DC. Il nous faut donc cocher la case "This Domain Controller is permanently offline and can no longer be demoted using the Active Directory Domain Services Installation Wizard (DCPROMO)".

Et on clique sur "Delete".

Il s'agit en plus d'un catalogue global. Une nouvelle demande de confirmation apparaît, on clique sur "Yes".

C'est parti pour un check du DNS. Tout a l'air bien purgé.

Ici, on a encore un enregistrement NS, on va laisser le scavenging agir.

Pareil ici.

Un petit tour au niveau de ADSS nous montre par contre la présence du DC01 dans les serveurs présents dans mon site. Je choisi donc de le supprimer "Delete".

On répond au message d'avertissement par un "Yes".

Allons-y pour les vérifications au niveau réplications (vous pouvez répéter la même opération sur le DC03).

repadmin /showrepl

dcdiag /test:replications

dcdiag /test:netlogons

Pour terminer les vérifications j'ai créé une OU, sur le DC02 et, après la réplication, l'OU est bien apparu sur le DC03.

Cloner un contrôleur de domaine Windows Server 2012 avec Hyper-V (VM-GenerationID)

Préambule : VM-GenerationID

Une des raisons évidente de la virtualisation est l'indépendance des machines virtuelles avec le hardware. Il est donc beaucoup plus simple de gérer le clone d'une VM (Virtual Machine) dans une infrastructure virtualisée.

Mais peut-on cloner n'importe quelle VM ?

La réponse à cette question n'est pas simple. La réponse la plus intelligente devrait être de dire comme bien souvent : "Ça dépend".

Jusqu'à la version 2012 de Windows Server, le clonage d'une VM hébergeant ADDS (Active Directory Domain Services) était à proscrire. En effet, en opérant un clone ou un restore d'un domain controller (avant la version 2012 windows server), on risquait à coup sûr de provoquer un "USN Rollback".

Un des bénéfices majeurs qu'apporte Microsoft à la version 2012 de sa version Server est le VM-GenerationID.

Ce numéro est un identifiant codé sur 128 bits fourni par l'hyperviseur à travers un driver spécifique.

On peut voir ici de quoi il s'agit en explorant le device manager d'une machine virtuelle hostée grâce à un hyperviseur Hyper-V tournant sur une machine Windows 8. Vous pouvez consulter ici comment a été montée cette infrastructure virtuelle.

Si vous voyez le device "Microsoft Hyper-V Generation Counter", votre hyperviseur va pouvoir gérer le VM-GenerationID et de ce fait, vous allez pouvoir cloner un Domain Controller.

Le VM-GenerationID est généré et enregistré sur le Domain Controller comme un attribut de la base Active Directory. Cet attribut n'est pas répliqué.

Le VM-GenerationID est enregistré dans la base NTDS.dit de l'ad sous la forme de l'attribut msDS-GenerationID.

Vous pouvez le voir en vous connectant sur le DC que vous voulez observer et en affichant ses attributs. On peut facilement le faire via l'ADAC ou l'ADUC.

1) Prérequis

Il y a des prérequis à respecter pour pouvoir cloner un DC.

• Comme on vient de le voir, votre hyperviseur doit supporter le VM-GenerationID. C'est le cas pour Hyper-V tournant pour Windows 8 mais également sur Windows Server 2012. VMWare dit le supporter, on y reviendra dans un futur article.
• Le DC source doit tourner sous Windows Server 2012
• Le DC source ne peut pas hoster le rôle PDC emulator. De plus, le DC hostant ce rôle doit être disponible et doit tourner sous Windows Server 2012.

Donc, si on compte bien, vous devez avoir au minimum deux DCs dans votre infrastructure pour pouvoir commencer le clonage d'un DC.

2) Préparation du DC source

Afin de cloner un DC, vous devez d'abord le préparer à être cloner. La première étape est d'ajouter votre DC source au groupe de sécurité "Cloneable Domain Controllers". Vous avez plusieurs options pour  ça. 

La première via l'ADAC ou même l'ADUC.

La deuxième façon de faire est de le faire via powershell.

Add-ADGroupMember "Cloneable Domain Controllers" "CN=DC02,OU=Domain Controllers,DC=LABO,DC=COM"

Ok, notre DC source est désormais membre du groupe de sécurité "Cloneable Domain Controllers". On va pouvoir continuer à le préparer.

Technet nous apprend qu'il y a lieu de lancer une première commande avant de commencer le processus de clonage. En effet, nous avons besoin de déterminer quels sont les programmes et services qui ne sont pas présent dans le fichier "DefaultDCCloneAllowList.xml" ou dans un fichier personnalisé par l'utilisateur "CustomDCCloneAllowList.xml" et de ce fait non supporté par le processus de clonage car non évalués.

Get-ADDCCloningExcludedApplicationList

Chez moi le résultat de la commande est net : "No excluded applications were detected". On peut donc avancer. Néanmoins, dans certains cas vous devrez lancer une seconde commande afin de générer votre propre fichier .xml contenant la liste des applications ou services que vous voulez ajouter car supportés.

Voici un exemple (lancée sur une infra tournant sous ESXi 5.1).

On lance donc une seconde commande afin de générer le fichier .xml

Get-ADDCCloningExcludedApplicationList -GenerateXml

On retrouve bien le fichier "CustomDCCloneAllowList.xml" sous "C:\Windows\NTDS\".

Pour terminer cette préparation, il ne nous reste qu'une seule commande à lancer.

New-ADDCCloneConfigFile -Static -IPv4Address "192.168.1.12" -IPv4DNSResolver "192.168.1.10" -IPv4SubnetMask "255.255.255.0" -CloneComputerName "DC03" -IPv4DefaultGateway "192.168.1.1" -SiteName "Default-First-Site-Name"

Cette commande va générer un nouveau fichier .xml  : "DCCloneConfig.xml". Ici, on a spécifié le nom du futur DC cloné et sa configuration réseau.

Le DC cloné doit se trouver dans le même site.

Si on édite le fichier de la configuration de la machine virtuelle DC02

On retrouve bien le numéro "genreration_id" avec pour valeur hexadécimale "5683b796635a6015936e3117daa5b751".

La valeur définie pour l'attribut msDS-GenerationId est 51 B7 A5 DA 17 31 6E 93. En inversant la valeur trouvée dans le fichier xml de la machine virtuelle on retrouve bien la même valeur 936e3117daa5b751 -> 51b7a5da17316e93

3) Export de la VM préparée et import dans une nouvelle VM

Éteignons le DC DC02 qu'on vient de préparer.

Au niveau d'Hyper-V, sélectionner la VM à exporter (ici DC02) et choisissez l'option d'"Export..."

Il suffit ensuite de spécifier l'endroit où vous désirez exporter votre VM.

J'ai pour ma part créer un dossier Export sous le dossier Labo sur mon disque G:\ qui est en réalité un disque virtuel sur un Nas Synology.

Laissez ensuite l'export se dérouler et quand celui-ci sera terminé, vous pourrez voir l'arborescence que Hyper-V a créé pour vous.

Un .vhdx a bien été exporté.

Et le fichier de configuration .xml.

Ok, on peut passer à l'import. Sélectionner votre noeud et "Import Virtual Machine...".

Le processus d'importation ne comporte rien de particulier "Next >"

"Browse".

On sélectionne le dossier racine de la VM clonée, ici DC02. 

 "Next >".

Hyper-V détecte une VM. et  "Next >" ;-)

On demande à Hyper-V de nous créer un nouvel ID.  "Next >".

>Et on store la VM où on désire. "Next >"

Ainsi que l'emplacement du .vhdx. "Next >"

C'est terminé. Vous pouvez voir le review de l'importation. Cliquez sur "Finish".

Hyper-V commence le processus d'importation

Une fois l'importation terminée, si vous éditez le fichier de configuration .xml de la VM importée, vous pourrez observer que le generation_id a bien été modifié.

.xml de DC02 

.xml de DC03 (VM importée)

On peut renommer notre VM, faites un clic droit sur la VM fraîchement importée et cliquez sur "Rename..."

C'est fait. Démarrez le DC02 et ensuite le DC03.

Démarrage de DC03...

Le DC a détecté qu'il était un clone, il commence donc le processus de clonage.

DC03 redémarre une fois.

On peut voir le nouveau DC dans Sites and Services.

On le voit bien aussi dans l'ADUC et l'ADAC.

Si on édite les propriétés du DC03 (DC résultant du clonage), on peut voir que le VM-GenerationID est bien différent du DC source DC02.

4) Processus détaillé du clonage

Technet nous explique parfaitement ce qu'il se passe lors du process de clonage. Voici le schéma édité par Microsoft pour expliquer celui-ci.

5) Le clonage s'est mal passé ?

Dans le cas où votre clonage s'est mal passé, le DC source va redémarré en mode DSRM. Vous devrez vous loguer en local et supprimé le flag relatif au mode DSRM avant de pouvoir relancer un clonage et après avoir corrigé l'erreur qui vous a empêché de cloner correctement le DC source.

Vous pouvez le faire de deux façons.

a) Via Msconfig

b) Si vous êtes en CORE, via le command shell

bcdedit.exe /deletevalue safeboot

6) Conclusion

Nous en avons terminé avec ce tutoriel.

Nous pouvons voir le grand intérêt de l'ajout du VM-GenerationID par Microsoft puisque cela nous ouvre également la voie au snapshot d'un AD.

En effet, précédemment ceci pouvait mener à des incohérences graves dans notre base AD comme le montre ce schéma (source).

Ce qui est désormais géré comme le montre le schéma suivant (source).