PI Services

Introduction

Si l’on pouvait autrefois dire qu’il n’était pas possible de cloner un contrôleur de domaine a moins de vouloir voir son infrastructure Active Directory comprise, on ne peut plus dire la même la chose aujourd’hui.

En effet, avec la génération 2012 de Windows Server apporte le support des contrôleurs de domaine virtualisé (on parlera alors de vDC). Ce support donc comprend la tolérance aux snapshots ainsi qu’au clone de contrôleur de domaine.

Dans ce billet, nous attarderons donc sur la procédure à suivre pour cloner un contrôleur de domaine.

Fonctionnement

Il faut tout d’abord savoir que cette opération nécessite un niveau de forêt en Windows Server 2012 ainsi qu’une préparation au préalable.

Lors de cette préparation, un fichier de configuration au format XML, sera généré dans C:\Windows\NTDS.

Au redémarrage du contrôleur de domaine va donc lire le contenu du fichier de configuration et s’adaptera pour s’ajouter en tant que contrôleur de domaine supplémentaire.

Dans les informations de configuration, il est possible de changer le nom de la machine, de modifier sa configuration IP ou encore de spécifier un site Active Directory.

En cas d’incohérence, le contrôleur de domaine démarrera en mode de restauration.

Enfin, il faut savoir que le clone de contrôleur virtuel ne supporte pas tous les services et fonctionnalité pouvant être ajouté à Windows Server (par exemple la fonctionnalité SNMP). Si des applications non supportées sont présentes, la génération du fichier de configuration ne sera pas permise à moins qu’une exclusion définie.

Mise en place

Le clonage d’un contrôleur doit être effectué dans l’ordre suivant :

Ajout des permissions Active Directory

Ajouter le contrôleur de domaine qui servira de base pour le clonage dans le groupe « Cloneable Domain Controllers »

Contrôle de conformité

Puis, sur ce contrôleur de domaine, réalisez la commande Get-ADDCCloningExcludeApplicationList pour obtenir la liste des services et application non supportée par le clonage.

Les résultats affichés doivent être désinstallé ou placé dans un fichier d’exception pouvant être généré automatiquement grave à l’argument –GenerateXML de la commande précédente.

Le fichier d’exclusion sera alors généré dans le répertoire NTDS.

Génération du fichier de configuration

Puis générez le fichier de configuration de clonage à l’aide de la commande New-ADDCCloningConfigFile.

Il est possible de définir de nouveaux paramètres grâce à l’argument –Static et des configurations configurations éditables :

· Pour un nouveau nom de machine, employez l’argument –CloneComputerName

· Pour une nouvelle configuration IP, employez les arguments –Ipv4Address, -IPv4DNSResolver, -IPv4DefaultGateway.

· Pour que le nouveau contrôleur de domaine intègre un autre site Active Directory, utilisez l’argument –Site.

Clonage de la machine virtuelle

Pour finir l’opération, clonez votre machine virtuelle par l’intermédiaire de vos outils de gestion d’hyperviseurs, déplacez là si nécessaire et enfin allumez là. Votre contrôleur de domaine adaptera alors sa configuration pour ne pas causer de conflit dans votre forêt Active Directory.

Fonctionnement

Les contrôles d’accès dynamiques sont une nouveauté introduite avec Windows Server 2012 qui se base sur les concepts de classifications et d’accès centralisé.

Les classifications sont, rappelons-le, des attributs permettant de catégoriser un objet, elles sont aujourd’hui couramment utilisées dans les systèmes de messagerie.

Les accès centralisés sont tout simplement le fait que les stratégies et règles d’accès sont stockées sur les contrôleurs de domaine Active Directory.

Prérequis

La mise en place d’une infrastructure repose sur l’emploi de revendication par le biais de Kerberos. Cette technologie n’est cependant prise en charge uniquement sur les systèmes d’exploitation Windows 8 (pour les clients) et Windows Server 2012 (pour les serveurs).

Il sera donc nécessaire d’utiliser des contrôleurs de domaine Active Directory dont le niveau fonctionnel de forêt est supérieur ou égal à « Windows Server 2012 ».

De plus, les serveurs de fichiers nécessitent le service de rôle FSRM.

Mise en place

Pour cela nous allons donc devoir définir des propriétés de ressources et d’utilisateurs, qui serviront de correspondance à une règle.

Par la suite nous pourrons agréger nos règles dans une stratégie.

Stratégie qui sera publiée sur les serveurs de fichiers, puis appliquées sur les ressources.

Les utilisateurs qui respecteront les propriétés définis auront donc accès aux ressources en fonction des permissions établies dans les règles.

Dans le billet suivant, nous mettrons en place pas à pas un système d’autorisation n’autorisant uniquement les utilisateurs à accéder aux fichiers qui sont dans le même département et la même compagnie que celle définie dans la classification.

Configuration des utilisateurs

Attribution des propriétés d’organisation

Par exemple, l’utilisateur User1, ayant les champs Department et Company respectivement définis sur « Administration » et « PIServices », ne pourra accéder qu’aux ressources ayant les même valeurs.

Définition des types de revendication.

Afin que l’utilisateur puisse communiquer ses propriétés Department et Company, ce dernier doit étendre son ticket Kerberos avant les revendications correspondantes.

Pour cela, ajoutez les types de claims correspondant dans la section Active Directory > Dynamic Access Control > Claim Types.

Dans le cas présent, il s’ajout d’une revendication « company » et d’une seconde « department ».

Configuration des ressources

Définition des propriétés de ressource

A présent, créez des propriétés de ressources depuis la section Active Directory > Dynamic Access Control >Ressource Property.

Microsoft met à disposition un certain nombre de propriétés de ressources, libre à vous de les personnaliser ou d’en créer de nouvelles.

Dans le cadre de notre exemple, nous allons activer et personnaliser les propriétés de ressources « Company » et « Department ».

La personnalisation consiste à ajouter, éditer ou supprimer des valeurs suggérées, qui seront proposée lors de la classification de la ressource.

Configuration de l’accès

Définition des Règles d’accès centralisées

Une fois que les propriétés de ressources sont éditées, il suffit de les ajouter dans une règle d’accès centralisée.

Cette dernière pourra donc être créée depuis la section Active Directory > Dynamic Access Control > Central Access Rules.

Nous allons donc créer une règle s’appliquant aux ressources (donc fichiers) dont la classification « Company » correspondra à « PIServices ».

Pour cela, éditez les ressources cibles pour y intégrer la condition Ressource.Company Equals « PIServices » depuis l’assitant.

Enfin, dans les permissions, intégrez le groupe d’utilisateurs qui doit avoir le droit d’accès à la ressources et spécifiez les contraintes de revendications.

Dans notre cas, il faut que l’utilisateur soit dans la même compagnie et le même département que le fichier.

Définition des Stratégies d’accès centralisées

Enfin, agrégez les règles dans une nouvelle stratégie depuis la section Active Directory > Dynamic Access Control > Central Access Policies.

Publication des Stratégies d’accès centralisées

Pour que les serveurs de fichiers chargent les stratégies d’accès, créez une nouvelle GPO, qui injectera les stratégies définies aux serveurs correspondant au périmètre de votre GPO.

Activation du support des revendications auprès des systèmes du domaine

Pour que les systèmes de votre parc étendent le ticket Kerberos, activez l’option « KDC support for claims, compound authentication and Kerberos armoring » sur l’ensemble de votre domaine Active Directory.

Application de la classification sur la ressource

Enfin, testons nos configurations.

En effectuant un clic droit « propriétés », nous appliquerons des valeurs aux classifications disponibles.

Puis depuis les paramètres de sécurité avancée, il sera nécessaire de définir la stratégie précédemment créée.

Note : si vos stratégies ne sont pas disponibles effectuez la commande PowerShell suivante sur le serveur de fichier : Update-FsrmClassificationPropertyDefinition.

Les évolutions

Il est aujourd’hui possible d’utiliser le (Microsoft File Server Resource Manager) FSRM pour classifier automatiquement les dossiers et documents et réduire drastiquement le temps d’administration lié à l’application des permissions.