Plan du site  
français  English
pixel
pixel

Articles - Étudiants SUPINFO

Chapitre 02 - Storage Management

Introduction

Dans ce second chapitre du cours d'introduction à Windows Serveur, nous allons aborder les fondamentaux de la pièce maîtresse d'une insfrastructure Microsoft : Active Directory Domain Services.

Dans un premier temps, il sera expliqué pourquoi Active Directory a sa place et pourquoi il est si important de le maîtriser. Composé de plusieurs services, Active Directory peut à lui seul transformer la manière dont est géré un sytème d'information.

La seconde moitié du cours est dédiée à la création et l'administration de l'infrastructure proposée par le rôle Active Directory Domain Services.

Qu'est-ce qu'Active Directory ?

Déjà dans le premier chapitre, Active Directory était mentionné et c'est normal car il est très compliqué de parler d'une infrastructure Microsoft sans évoquer cette pièce angulaire du sytème d'information. Mais alors qu'est-ce que c'est ? A quoi ça sert ? Pourquoi le mettre en place ?

Tout d'abord, il faut savoir qu'Active Directory n'est pas un mais plusieurs Rôles. Il y a au total 5 rôles Active Directory :

  • Active Directory Domain Services (AD DS)

  • Active Directory Certificate Services (AD CS)

  • Active Directory Federation Services (AD FS)

  • Active Directory Lightweight Directory Services (AD LDS)

  • Active Directory Right Management Services (AD RMS)

Les noms des rôles étant un peu longs, on utilisera très souvent les abréviations notées ci-dessus entre parenthèses.

[Note]

Par abus de langage ou par simplicité, quand on parle d'Active Directory ou d'AD, c'est dans 99% des cas pour parler d'Active Directory Domain Services.

[Note]

Dans ce cours, on abrégera d'ailleurs Active Directory Domain Services par AD DS ou AD. Pour les autres services, on utilisera l'abréviation "longue".

Le premier rôle AD cité ci-dessus, AD DS, est de loin le plus important. Il est présent dans tout les systèmes d'information qui utilisent Windows Serveur. On peut le comparer à un annuaire téléphonique ou une liste de contacts pour les plus jeunes qui n'auraient pas connu l'annuaire. C'est le rôle que nous allons aborder dans ce cours car il est très important pour la suite.

[Note]

Si vous souhaitez étudier en profondeur les possibilités d'AD DS, vous pouvez consulter le cours dédié suivant : https://www.supinfo.com/cours/3MSA

Le second, Active Directory Certificate Services ou AD CS, est également important et sera utile dans de nombreux cas. Il permet de gérer les certificats digitaux utilisés dans le système d'information. Un certificat peut être utilisé pour protéger un site web ou pour établir une connexion réseau sécurisée... Pour vous en convaincre, vous pouvez vous rendre sur votre navigateur préféré (IE ou Edge :) ) et vous rendre sur https://www.google.fr.

En cliquant sur le cadenas en haut à droite du lien, il est possible d'afficher le certificat qui sécurise le site web de Google. C'est avec un service semblable à AD CS que ce certificat a été généré.

Active Directory Federation Services est un rôle qui va permettre de déléguer l'authentification à un partenaire et/ou faire Single Sign-On (SSO). Le SSO est très utilisé aujourd'hui. Vous l'utilisez sûrement sans vous en rendre compte. Par exemple, de plus en plus de sites web vous proposent de vous authentifier avec votre compte Facebook ou Google.

Prenons ici l'exemple de Viadeo, un réseau social professionnel :

Ce type d'authentification SSO vous permet de ne pas multiplier vos comptes et de vous authentifier sur de multiples plateformes avec le même identifiant et le même mot de passe.

Ensuite, il y a le rôle AD LDS. Ce rôle est un peu plus complexe à aborder si vous débutez avec les systèmes Windows. C'est un annuaire comme AD DS mais principalement utilisé par les applications tiers qui ne respecteraient pas les contraintes de gestion classiques d'Active Directory Domain Services. Il est moins utilisé mais est très pratique dans le cas où l'entreprise aurait besoin d'un extranet par exemple.

Enfin, il y a AD RMS pour Right Management Services. Ce service permet de gérer des droits plus précis sur les documents partagés dans l'entreprise. Par exemple, on peut interdire l'impression sur un document pour certaines personnes.

Maintenant, que les présentations sont faites, on va particulièrement s'intéresser à AD DS.

Fonctionnement sans AD DS

Un système d'information ou plus simplement deux ordinateurs connectés en réseau qui fonctionnent sans AD DS vont chacun gérer leurs comptes d'accès. Dans une maison où il y a deux ordinateurs, un portable et un fixe par exemple, si je veux me connecter au fixe, je ne vais pas utiliser le même compte que pour me connecter sur l'ordinateur portable.

[Note]

Cela a un peu changé depuis Windows 8 qui permet d'utliser un compte Microsoft (comme Outlook) sur n'importe quel ordinateur Windows

C'est le fonctionnement normal de ce que l'on appelle le Workgroup.

Le schéma ci-dessus montre ce fonctionnement. L'utilisateur A ne peut se connecter que sur l'ordinateur A. Son compte n'est pas disponible sur l'ordinateur B. Il pourrait se connecter sur l'ordianteur B avec un compte différent géré par l'ordinateur B.

Dans quel cas utiliser le mode Workgroup ? Simplement quand chacun a son propre ordinateur et qu'il n'y en a pas beaucoup à gérer. Garder le fonctionnement Workgroup dans le contexte familial et privé est également conseillé.

Quels sont les désavantages du fonctionnement Workgroup ? Dans le cas d'une entreprise, ce mode de fonctionnement est complexe à configurer et à maintenir. Si vous souhaitez que vos utilisateurs puissent se connecter sur n'importe quel ordinateur et retrouver ses données, vous devez créer un compte pour chaque utilisateur sur chaque ordinateur. Quand il y a 2 utilisateurs pour 2 ordinateurs, il n'y a que 4 comptes à gérer mais pour 10, il y en a 100. C'est à la fois une perte de temps et une source d'erreur considérable.

Active Directory Domain Services va résoudre ce problème.

Présentation d'AD DS

Comme écrit plus haut, Active Directory Domain Services, AD DS, est un annuaire. Un serveur avec le rôle AD DS va donc contenir tous les utilisateurs de l'entreprise. Son but sera de centraliser la gestion de ces comptes et d'autoriser ou non ces comptes à accéder à des ressources informatique sur le réseau.

Plus précisément, AD DS ne va pas contenir que des utilisateurs et des ordinateurs mais tous les objets du système d'information de l'entreprise : imprimantes, groupes...

L'intégration et l'organisation de ces objets dans AD DS donneront une représentation logique des objets physiquement présents dans l'entreprise.

Le premier objectif d'AD DS est de centraliser les objets. Cela apporte deux avantages :

  • Création et administration des objets simplifiés.

  • Unicité et standardisation de l'information

L'AD DS, quand il est mis en place, doit devenir la source d'information unique pour les autres ressources comme :

  • Le logiciel des Ressources Humaines

  • Le site intranet

  • La messagerie

  • ...

Afin de ne pas démultiplier les informations et les bases de données, il est important que les autres outils se basent sur AD DS.

[Note]

Aujourd'hui et depuis longtemps maintenant, beaucoup de logiciels permettent l'utilisation d'AD DS.

Le second objectif d'AD DS, c'est l'authentification. C'est une partie importante car c'est le serveur avec le rôle AD DS qui va valider qu'un compte peut se connecter à une ressource.

Par exemple, AD DS validera le compte de Madame Michu quand elle souhaitera se connecter sur l'ordinateur A.

Pour cela, il faut que le compte et l'ordinateur soient dans le même espace d'authentification.

Architecture logique et architecture physique

Pour bien comprendre comment fonctionne Active Directory, il faut distinguer les composants logiques et les composants physiques.

Architecture logique

Le domaine

Le domaine Active Directory est le composant logique principal. Il correspond à un espace d'authentification. Tous les objets du domaine seront dans le même espace d'authentification. Pour que Mme Michu puisse se connecter à son ordianteur, il faut que son compte et le compte d'ordinateur soient dans le même domaine et donc le même espace d'authentification.

Le nom du domaine est très important. Il doit correspondre à un nom DNS résolvable au sein du réseau de l'entreprise et à l'extérieur (sur internet). Par exemple, l'entreprise Contoso pourra avoir comme nom de domaine contoso.com, contoso.fr... Même si techniquement c'est possible, il ne faut pas utiliser un nom de domaine que l'entreprise ne possède pas sur internet (comme google.fr par exemple).

Sur un schéma, un domaine est représenté par un triangle plein et avec son nom. Sur un schéma d'architecture logique, on ne représente normalement pas les objets contenus dans le domaine.

La forêt

On peut assez facilement vulgariser cette notion en disant que la forêt entoure le domaine. Sur Active Directory, c'est un peu le cas également à la différence que les arbres de notre forêt seront constitués de plusieurs domaines reliés entre eux.

La forêt est l'enveloppe globale de notre infrastructure Active Directory. Dans cette enveloppe, on va pouvoir y placer nos différents domaines et les relier pour étendre ou contraindre l'espace d'authentification.

La forêt est représentée par un triangle vide englobant un ou plusieurs domaines.

On remarque plusieurs choses sur ce schéma.

Premièrement, le domaine contoso.com est relié à deux domaines enfants que l'on appelle sous-domaines. ny.contoso.com et la.contoso.com (respectivement New-York et Los Angeles) ont une relation de confiance (lien) avec le domaine parent contoso.com. L'espace d'authentification est élargi. Cependant, cela ne veut pas forcément dire qu'un utilisateur de ny.contoso.com a accès aux ressources de contoso.com. Il faut avant tout donner les autorisations nécéssaires.

Second point, on aperçoit un autre domaine dans cette forêt : filiale.fr. Ce domaine avec le sous-domaine nantes.filiale.fr forment un autre arbre de la forêt. Il y a également une relation (lien) entre filiale.fr et contoso.com afin d'élargir la zone d'authentification. On pourrait donc autoriser des utilisateurs de nantes.filiale.fr à accéder à des resources de ny.contoso.com via ce lien.

Dernier point, le contoso.com en haut du triangle représente le nom de la forêt. La forêt est créée en même temps que le premier domaine et prend donc le nom de ce domaine "principal".

Les sites

Les sites Active Directory sont des composants logiques présents dans des architectures plus complexes. Les sites sont des représentations logiques du réseau physique de l'entreprise.

Si une entreprise a un serveur à Paris et un serveur à New-York, il serait intéressant que les utilisateurs de Paris utilisent le serveur de Paris et les utilisateurs de New-York celui de New-York. C'est pour cela que les sites Active Directory existent.

Cette notion de site est détaillée dans le cours 3MSA - Microsoft Windows Server Active Directory disponible : https://www.supinfo.com/cours/3MSA

Architecture Physique

Les composants logiques étudiés ci-dessus doivent prendre vie sous la forme de composants physiques pour exister dans le système d'information de l'entreprise.

Le Domain Controller

C'est le composant physique principal d'une architecture Active Directory. Comme son nom l'indique, il va héberger un domaine. C'est en fait simplement un serveur Windows avec le rôle Active Directory Domain Services installé.

Le domaine hébergé sur un serveur peut être un domaine parent, enfant ou principal (premier domaine d'une forêt).

Mais alors quelle est la différence entre un domaine et un Domain Controller ?

L'un est logique, l'autre est physique. La différence est importante car vous pouvez avoir plusieurs Domain Controllers pour un seul domaine.

De plus, des Domain Controllers (abrégés DC) peuvent héberger le même domaine sur des sites différents.

Sur ce schéma, on a deux DCs qui hébergent chacun le domaine contoso.com. Cependant, ils sont physiquement dans des lieux séparés. Pour le domaine enfant, seul un DC est présent à New-York.

Il y a également un Domain Controller un peu particulier qu'on appelle le RODC pour Read Only Domain Controller ou contrôleur de domaine en lecture seule en français.

Comme son nom l'indique, il occupe les mêmes fonctions qu'un Domain Controller classique mais les modifications ne peuvent pas être effectuée sur ce DC.

Le Global Catalog

Le Global Catalog sera présent sur un Domain Controller. Il y en a forcément au moins un dans une forêt. Ce catalogue contient tout les objets de la forêt, utilisateurs, ordinateurs... Cependant, il n'enregistre pas tous les attibuts de ces objets. L'objectif est d'avoir un catalogue léger permettant de faciliter la recherche dans des environnements complexes.

On pourrait le comparer à un index de la forêt Active Directory.

Le DNS

Le DNS pour Domain Name System est obigatoire pour le fonctionement d'AD DS. Un serveur DNS externe au serveur AD DS peut être utilisé (Windows ou Linux). Cependant, il est possible d'installer le rôle DNS en même temps qu'un Domain Controller. Cela permet à AD DS d'être directement intégré au DNS sans configuration supplémentaire.

Installation

Niveaux fonctionnels et Maîtres d'opérations

Niveaux fonctionnels

Les niveaux fonctionnels dans AD DS peuvent être comparés à la version du rôle.

Chaque nouvelle version du système d'exploitation Windows Serveur apporte des nouveautés au rôle Active Directory Domain Services. Donc chaque version de Windows Serveur créé une nouvelle version d'ADDS et donc un nouveau niveau fonctionnel.

Le numéro de version (ou niveau fonctionnel) reprend d'ailleurs le nom de la version de Windows Serveur. La version Windows Serveur 2012 R2 apporte le niveau fonctionnel 2012 R2 à Active Directory.

Lors de l'installation d'une nouvelle infrastructure ADDS, il est conseillé de choisir le dernier niveau fonctionnel disponible pour bénéficier des dernières nouveautés du rôle. C'est plus compliqué dans le cas d'une installation avec un domaine existant.

Windows Serveur 2012 R2 est compatible avec les versions précédentes mais vous ne pourrez pas bénéficier des dernières fonctionnalités apportées au rôle. Il faut donc bien distinguer la différence entre la version du système et la version du rôle.

Il est possible d'avoir un système Windows Server 2012 R2 avec un niveau fonctionnel AD DS Windows 2008. La version 2012 supporte le niveau fonctionnel 2008 donc ça fonctionne mais sans les nouveautés de 2012 R2.

En résumé, quand on veut changer la version du système d'exploitation pas de problème. Les nouveaux systèmes sont compatibles avec les anciens niveaux fonctionnels dans la limite du "raisonnable": Windows Serveur 2012 n'est plus compatible avec le niveau fonctionnel de Windows 2000.

Si par contre je souhaite avoir le dernier niveau fonctionnel pour bénéficier des dernières nouveautés, c'est plus complexe. En effet, les anciens Système d'Exploitation ne sont pas compatibles avec les nouveaux niveaux fonctionnels. Dans ce cas, il faut migrer tous les systèmes d'exploitation hébergeant le domaine avant d'augmenter le niveau fonctionnel. Si par exemple, vous avez 3 DCs en version 2008 R2 et que vous souhaitez avoir le niveau fonctionnel 2012, vous devez migrer de 2008 vers 2012 en gardant le niveau fonctionnel de 2008. Si vous augmentez le niveau fonctionnel avant d'avoir migré les autres serveurs, ils deviendront inutilisables car non compatibles. Quand tous les DCs sont migrés, il est possible d'augmenter le niveau fonctionnel sans risque.

Rappelez-vous : Le nouveau Système est compatible avec les anciens niveaux fonctionnels. Le nouveau niveau fonctionnel n'est pas compatible aves les anciens Systèmes.

Les types de niveau fonctionnel

Il existe 2 types de niveau fonctionnel:

  • Le niveau fonctionnel de Domaine

  • Le niveau fonctionnel de Forêt

Comme leurs noms l'indiquent, ces types de niveau fonctionnel apportent des nouveautés soit au niveau de la forêt soit au niveau du domaine. Il faut faire attention au type de niveau fonctionnel que vous souhaitez augmenter. En effet, en augmentant le niveau fonctionnel d'une forêt dans une architecture AD DS complexe, tous les domaines de cette forêt seront impactés. De plus, il faut s'assurer que tous les Domain Controllers de tous les domaines ont été migrés vers la version supportant le nouveau niveau fonctionnel de la forêt. Sinon, ces domaines pourraient ne plus être disponibles.

De plus, sachez que vous ne pouvez pas avoir un niveau fonctionnel de forêt supérieur à un niveau fonctionel de domaine.

Augmenter le niveau fonctionnel

Pour augmenter le niveau fonctionnel d'un domaine, il faut se rendre dans la console Active Directory Users and Computers.

Sur cette capture, on voit que le niveau fonctionnel actuel est Windows Server 2008. On peut l'augmenter vers les versions 2008 R2, 2012 ou 2012 R2 car la version Windows Serveur la plus récente installée est 2012 R2.

On pourrait se demander pourquoi la version 2003 n'est pas proposée alors que Windows Serveur 2012 est compatible avec ce niveau fonctionnel ? Simplement car on ne peut pas descendre de niveau fonctionnel. Attention donc quand vous augmentez un niveau fonctinonel, il n'est pas possible de revenir en arrière.

Pour augmenter le niveau fonctionnel de la forêt, il faut se rendre dans la console Active Directory Domains and Trusts.

Les Maîtres d'opérations

Dans une architecture avec plusieurs DCs pour un domaine et/ou plusieurs domaines dans une forêt, lorsqu'il y a des modifications des configurations, ajouts d'utilisateurs... il faut qu'un des serveurs AD DS prenne le dessus pour éviter des potentiels conflits.

Pour cela, un serveur AD DS peut héberger un maître d'opérations qui aura un rôle plus important lors de modifications ou autres actions sur l'infrastructure. Il y a 5 maîtres d'opérations :

  • Maître de schéma

  • Maître d'attribution des noms de domaine

  • Maître RID

  • Maître émulateur du contrôleur principal de domaine

  • Maître d'infrastructure

Les 2 premiers sont des maîtres de forêt. Il n'existe qu'en 1 seul exemplaire par forêt. Le maître de schéma gère les mises à jour de configurations sur l'ensemble de la forêt. Le maître d'attribution des noms de domaine intervient lors de l'ajout d'un domaine dans la forêt.

Les 3 derniers sont des maîtres de domaine. Il en existe 1 par domaine dans la forêt. Le maître RID gère l'attribution des Identifiants des objets d'ADDS (utilisateurs, ordinateurs). Le Maître PDC emulator assure la compatibilité avec les versions antérieures. Enfin, le Maître d'infrastructure permet la synchronisation des mises à jour ou création d'objets entre les Domain Controllers.

[Note]

Pour avoir plus de détails sur les maîtres d'opérations, vous pouvez consulter le cours 3MSA - Microsoft Windows Active Directory.

Migration vers Windows Serveur 2012

On pourrait légitimement se demander pourquoi appréhender les concepts de migration dans ce cours d'introduction. Pourtant, c'est une notion essentielle pour les tous administrateurs/ingénieurs Système. En effet, il est plutôt rare qu'un Active Directory ne soit pas déjà présent dans une entreprise. C'est pourquoi les deux principales activités à réaliser sur un ADDS sont l'administration quotidienne des objets de l'AD (utilisateurs, ordinateurs...) et la migration vers un système plus récent.

Quand une migration est planifiée dans une entreprise (2008 vers 2012 par exemple), Active Directory Domain Services est le premier rôle à migrer !

Introduction

Il existe plusieurs moyens pour migrer le rôle Active Directory vers une version plus récente. Cependant, avant toute migration, il y a quelques prérequis à respecter.

Le premier est de s'assurer qu'une sauvegarde récente et fiable des serveurs existe. Il est très intéressant de tester une restauration sur un réseau séparé avant de commencer la migration. En effet, s'il y a un problème lors de la migration et que la sauvegarde ne fonctionne pas, les utilisateurs ne pourront plus se connecter à leurs ordinateurs, consulter leurs e-mails ou encore accéder à leurs fichiers.

Ensuite, il faut s'assurer que l'infrastructure actuelle n'a pas d'erreur avec les commandes :

Enfin, comme mentionné plus haut, ADDS est dépendant du service DNS. Il faut donc être certain qu'un serveur DNS sera toujours disponible pendant la migration.

Méthode 1 : Ajouter un nouveau contrôleur de domaine

La première méthode est une des plus simple à mettre en place.

Il suffit d'ajouter un contrôleur de domaine à l'infrastructure existante avec l'ensemble des options que peut avoir un DC : ADDS avec DNS et Global Catalog. Ensuite, il faut faire "pointer" les autres serveurs et ordinateurs vers ce nouveau DC.

Il faut également que les maîtres d'opérations soient migrés vers ce serveur.

Quand ceci est réalisé, les autes vontrôleurs de domaine peuvent être destitués et éteints.

Il y a plusieurs avantages à utiliser cette méthode :

  • Pas d'interruption de service lors de la migration

  • Nouveau serveur (physique ou virtuel)

Méthode 2 : Créer une nouvelle forêt

La seconde méthode consiste à créer une nouvelle forêt et migrer les objets de l'ancienne forêt vers la nouvelle. Cette méthode demandera un travail de test et de planification plus important.

Microsoft met à disposition l'outil Active Directory Migration Tool (ADMT) pour la migration des objets entre forêts. Cet outil est très utile lors de restructuration de l'architecture ADDS et lors de migration.

Avantages de cette méthode :

  • Nouveau serveur (physique ou virtuel)

  • Nouvel environnement ADDS

  • Possibilité de changer le nom de domaine/forêt

  • Retour en arrière facile, si problème

Cependant, cette méthode peut provoquer des interruptions de service ou des complications pour les utilisateurs suite à un changement de domaine ou de nom de domaine.

Méthode 3 : Mettre à niveau les contrôleurs de domaine

La dernière méthode consiste à mettre directement à niveau le système d'exploitation avec le rôle ADDS installé. La méthode est quasiment la même qu'une installation d'un Windows Serveur (vu dans le chapitre précédent) à la différence que le rôle avec sa base de données sera conservé.

Cette migration est rapide. En effet, le temps de migration est semblable à une installation donc environ 15-20 minutes.

Cependant, il n'y a pas de possibilité pour revenir facilement en arrière (sauf sauvegarde).

Quelle méthode choisir ?

A titre personnel, je privilégierais les 2 premières méthodes. S'il n'y a pas de besoin particulier de remaniement de l'architecture d'ADDS, la première méthode sera la meilleure. Elle permet de procéder par étape en s'assurant d'avoir une solution de secours.

En cas de changement de nom de domaine ou réorganisation de l'architecture, le seconde méthode devra être utilisée. Dans ce cas, il faut faire un test en environnement clos pour établir une procédure pas à pas de la migration.

Dans tous les cas, rendez-vous sur Technet pour avoir les prérequis et procédures pour ces 3 méthodes.

Objets ADDS

Dans cette partie, plusieurs objets Active Directory Domain Services seront décrits :

  • Utilisateurs

  • Ordinateurs

  • Unités d'Organisation (Organizational Units ou OU)

Utilisateurs

L'objet utilisateur est probablement le plus important de l'Acive Directory. Un utilisateur dans ADDS correspond souvent à un utilisateur physique. Par exemple, Mme MICHU, assistante de direction, aura son compte dans Active Directory à son nom. Ce compte lui permettra de se connecter à son ordinateur ou encore accéder aux fichiers partagés.

La gestion des Utilisateurs peut se faire via les consoles Active Directory Users and Computers ou Active Directory Administrative Center.

Lors de la création d'un nouvel utilisateur, les informations essentielles seront demandées :

  • Noms : prénom, nom, initiales et nom complet

  • Noms d'ouverture de session

  • Mot de passe

  • Options de mot de passe

Il y a beaucoup de propriétés accessibles après la création de l'utilisateur.

On remarque qu'il y a 2 options de connexion. En effet, il y a le "User Logon Name" et le "User Logon Name (pre-Windows 2000)".

On préférera utiliser le User Logon Name. Le "pre-Windows 2000" est utilisé dans une architecture avec la technologie NetBIOS, ce qui n'est normalement plus le cas aujourd'hui.

[Note]

Pour plus d'informations sur ces deux "User Logon Name" : https://technet.microsoft.com/en-us/library/cc739093(v=ws.10).aspx

Pour plus d'informations sur NetBIOS : https://technet.microsoft.com/en-us/library/cc940063.aspx

[Note]

Si vous ne voyez pas tous ces onglets lors de l'affichage des propriétés d'un utilisateur, il faut activer le mode avancé :

Ordinateurs

Les ordinateurs sont les autres composants importants de votre architecture ADDS. En effet, vos utilisateurs vont dans beaucoup de cas se connecter sur un ordinateur en utilisant leur compte de domaine. Ils vont ainsi pouvoir récupérer, sur cet ordinateur, leur environement de travail.

Comme étudié au début de ce chapitre, par défaut, un ordinateur gère lui même l'authentification des utilisateurs (comme sur votre ordinateur personnel). Pour les ordinateurs de l'entreprise, il faudra donc spécifier l'autorité d'authenfication ADDS : on dit joindre un ordinateur au domaine.

Lorsque cette jonction au domaine est réalisée, l'ordinateur peut déléguer l'authentification à un contrôleur de domaine. Les utilisateurs pourront donc se connecter sur l'ordinateur avec un compte de domaine. Cependant, pour des raisons d'administration et en cas de problème, il est toujours possible de s'authentifier sans un compte de domaine : on parle ici d'une authentification locale.

L'intégration/jonction au domaine se fait en accédant aux "Paramètres système avancés" dans le panneau de configuration "System".

Ensuite en cliquant sur "Modifier", il est possible de changer le Nom de l'ordinateur et de spécifier un domaine.

Notez qu'il est important d'avoir une convention de nommage pour les ordinateurs (comme pour les utilisateurs) afin de retrouver facilement l'ordinateur dans l'ADDS (ce qui n'a pas été fait dans le screenshot).

Une convention de nommage pourrait par exemple être de cette forme :

  • Ordinateurs de bureau : WKSXXX. Ce qui donnerait : WKS001, WKS002...

  • Ordinateurs portables : LAPXXX : LAP001, LAP002...

  • Serveurs : SRVXXX : SRV001... ou encore VMXXX pour une machine virtuelle ou intégrer le rôle du serveur dans le nom comme SRV-AD-001...

Unités d'organisation

Une unité d'organisation, Organizational Unit ou OU peut être comparée à un dossier.

Les OUs peuvent contenir des utilisateurs, des ordinateurs et d'autres OUs.

Ce "dossier" va donc avoir 3 rôles :

  • L'organisation

  • La délégation de droit

  • L'application des stratégies de groupe

L'organisation est très importante dans une architecture AD DS. En effet, au fil du temps, de plus en plus d'objets vont venir s'ajouter dans votre Active Directory. Les OUs vont vous permettre de retrouver rapidement ces objets.

Les OUs vous permettront également de déléguer des droits d'administration à d'autres utilisateurs. Dans une entreprise assez conséquente, vous ne serez probablement pas le seul à administrer le système d'information de l'entreprise. Il est également important de ne pas donner trop de droits à des utilisateurs. Avec une architecture d'OU correcte, vous pourrez déléguer les droits minimum sur les objets contenus dans l'OU.

Dans ce shéma, on voit qu'on a délégué des droits à Marc pour réinitialiser les mots de passe des utilisateurs des Ventes. Gene quant à lui peut modifier les groupes AD (les groupes sont étudiés dans la prochaine partie). On pourrait imaginer que Marc est le chef du service des Ventes et Gene serait responsable RH. Cela permet aux utilisateurs de gérer certaines tâches d'administration simple.

Ce genre d'exemple est souvent donné par Microsoft. En réalité, on donne rarement des droits d'admnistration à des utilisateurs non familiarisés avec ce genre d'outils. Cependant, on aurait pu imaginer déléguer des droits de réinitialisation de mot de passe aux personnes du support informatique.

Enfin , les OUs nous permettent d'appliquer des stratégies de groupe. Les stratégies de groupes seront évoquées plus tard dans un chapitre dédié à l'administration d'Active Directory. Pour le moment, vous pouvez considérer ces stratégies de groupe comme un ensemble de paramètres qui s'appliqueront aux objets présents dans l'OU. Il est donc important d'organiser nos OUs en fonction des stratégies que l'on appliquera.

[Note]

Les OUs sont protégées contre la suppression accidentelle. Ce qui est normal car en cas de mauvaise manipulation, on pourrait ainsi supprimer l'ensemble des objets contenus dans l'OU. Pour supprimer une OU, il faut activer le mode Avancé et décocher l'option de protection dans les paramètres de l'OU.

Les Groupes

Les groupes sont également des objets Active Directory, au même titre que les utilisateurs ou les ordinateurs étudiés précédemment.

Comme son nom l'indique, un groupe va rassembler plusieurs objets AD DS. Par exemple, on pourrait avoir un groupe qui rassemble tous les utilisateurs du service des Ressources Humaines ou un groupe avec tous les ordinateurs du service Développement.

Les groupes par défaut

On va distinguer principalement 6 groupes par défaut :

  • Tout le monde : Tous les utilisateurs du domaine, les invités et les utilisateurs des autres domaines

  • Utilisateurs authentifiés : Comme Tout le monde sans les invités

  • Utilisateurs du domaine : Tous les utilisateurs du domaine

  • Administrateurs du domaine : Utilisateurs avec un contrôle total sur le domaine

  • Administrateurs de l'entreprise : Utilisateurs avec un contrôle total sur toute la forêt

  • Administrateurs du schéma : Utilisateurs pouvant modifier les configurations avancées de la forêt

Dans ce cours, on va utiliser le compte Administrateur qui fait automatiquement partie des Administrateurs du domaine, Administrateurs de l'entreprise et du schéma. Cet adminsitrateur a l'ensemble de ces rôles puisque c'est le premier compte de notre nouveau domaine dans une nouvelle forêt. Ce n'est pas toujours le cas lors de l'ajout d'un nouveau domaine.

Les groupes Tout le monde et Utilisateurs authentifiés sont à utiliser avec précaution car ils concernent beaucoup d'utilisateurs. De plus, les membres de ces groupes sont dynamiquement ajoutés au groupe. Donc dès la création d'un nouvel utilisateur, il devient automatiquement membre du groupe Utilisateurs authentifiés. Vous pouvez donc donner des accès sans vous en rendre compte.

Les types de groupes

Il y a 2 types de groupe :

  • Sécurité

  • Distribution

Le premier type est Sécurité. Un groupe de ce type va nous permettre de donner des droits aux utilisateurs de ce groupe.

Admettons que vous souhaitiez donner accès au dossier partagé "Logiciels" à toutes les personnes du service IT. Donner des droits pour chaque personne du service peut être assez long et ennuyeux. Si vous avez un groupe de sécurité rassemblant l'ensemble des personnes du service IT, il suffira de donner des droits à ce groupe pour que tous ses membres aient accès au dossier.

Les groupes de distribution permettent de créer des listes de diffusion pour les services de messagerie comme Exchange. Ils ne permettent pas de donner des droits d'accès.

[Note]

Les groupes de sécurité peuvent également être utilisés comme liste de diffusion

L'étendue d'un groupe

Les groupes ont également une portée dans notre architecture que l'on appelle étendue.

Il existe 4 étendues :

  • Locale / Local Group

  • Domaine local / Domain Local Group (DLG)

  • Globale / Global Group (GG)

  • Universelle / Universal Group (UG)

En fonction de son étendue, un groupe pourra s'appliquer sur un domaine ou sur l'ensemble de la forêt. De la même manière en fonction de son étendue, certains objets ne pourront pas être ajoutés au groupe.

Table 1.1. Limitations des étendues

  Peut être utilisé dans Peut avoir des membres de
Domaine local Le domaine où il est créé seulement Toute la forêt
Globale Toute la forêt Du domaine où il est créé seulement
Universelle Toute la forêt Toute la forêt


Exemple de lecture du tableau : si je créé un groupe avec une étendue Domaine Local dans le domaine contoso.com, alors je pourrai ajouter des utilisateurs de mon domaine et du domaine nantes.contoso.com pour leur donner accès à un dossier partagé sur le domaine contoso.com uniquement.

On pourrait se demander : Quelle étendue choisir ? Pourquoi ne pas utiliser que des groupes Universels ?

Tout d'abord, on va chercher à limiter au maximum les possibilités d'application d'un groupe. Par exemple, si le groupe n'est pas utlisé en dehors du domaine, il faudra utiliser une étendue Domaine Local.

Bonnes pratiques

Pour savoir quelle étendue choisir pour un groupe, nous allons voir les bonnes pratiques (Best Practises) d'utilisation données par Microsoft.

Ce schéma représente la bonne pratique à respecter lorsqu'on met en place une architecture de groupe AD DS.

On remarque une première chose que l'on n'a pas évoquée avant : il est possible de mettre des groupes dans les groupes !

Ensuite, on remarque que 2 groupes sont utilisés pour que nos utilisateurs aient accès au dossier partagé.

Dans un premier temps, on va créer des groupes de rôle. Ces groupes correspondent aux rôles/statuts d'un ensemble d'utilisateurs de l'entreprise : Ventes, RH, IT, Dev...

Ces groupes de rôle seront membres de groupes d'accès. Ce sont sur ces groupes que l'on configurera le type d'accès à la ressource.

Dans l'exemple du schéma, les collaborateurs des ventes sont ajoutés au groupe Ventes (qui correspond au rôle). Puis ce groupe Vente sera ajouté au groupe "ACL_Sales_Folders_Read". Ce nom un peu barbare à première vue, permet de reconnaître son utilité à la première lecture :

  • ACL : veut dire que ce groupe va donner des droits d'accès

  • Sales : permet de savoir QUI va avoir accès

  • Folders : permet de savoir sur QUOI vont être donnés les accès

  • Read : permet de savoir QUEL type d'accès sera donné

Le groupe "ACL_Sales_Folders_Read" permettra donc aux utilisateurs de Ventes, d'avoir un accès en Lecture sur des Dossiers.

Mais nos étendues dans tout ça ? Quelles étendues ont ces groupes ?

Vous devez retenir l'acronyme suivant : UGDLA :

  • U : Utilisateur

  • G : groupe Globale

  • DL : groupe Domaine Local

  • A : Accès

On peut donc lire : Mon Utilisateur sera membre d'un groupe Globale (Ventes) lui même membre d'un groupe Domaine Local ("ACL_Sales_Folders_Read") qui donnera Accès à la ressource.

Pourquoi utiliser ces étendues ? Pourquoi utiliser cette méthode ?

Pour l'administration d'un nombre d'objets conséquent, il devient très simple de donner des accès avec cette méthode. Si on n'utilisait pas les groupes de rôle, il faudrait ajouter le nouveau collaborateur à tous les groupes d'accès. Ici, en l'ajoutant juste au groupe Ventes, il a automatiquement accès aux ressources de son service.

Pour les étendues, on remarque que le groupe rôle peut contenir uniquement les utilisateurs de son domaine mais peut être utilisé dans toute la forêt. A l'inverse, les groupes d'accès peuvent avoir des membres de toute la forêt mais être utilisés uniquement sur le domaine.

Admettons que les ressources des Ventes soient hébergées dans le domaine contoso.com mais que les commerciaux sont présents dans toutes les agences de contoso (Nantes.contoso.com, Lyon.contoso..., Lille..., Marseille...), on pourra facilement ajouter tous les groupes de rôle des sous-domaines dans le groupe ACL_Sales... de contoso.com.

PowerShell et Active Directory

Comme on l'a évoqué à plusieurs reprises, votre Active Directory va être composé de plusieurs centaines, milliers d'objets. Quand vous devrez effectuer une action sur l'un de ces objets, vous utiliserez l'interface graphique.

Mais dans beaucoup de cas, vous pourriez avoir besoin d'effectuer des actions sur plusieurs objets. S'il y a 10 utilisateurs à modifier, c'est encore jouable mais plus il y en a, plus la tâche va s'avérer être longue et ennuyeuse. En prime, le risque d'erreur est accru. En utilisant PowerShell, on va pouvoir automatiser les actions à effectuer.

La permière chose importante à savoir, c'est que les noms des commandes PowerShell commencent toutes par AD. Si vous vous souvenez du chapitre précédent, il sera facile pour vous de constituer les premières commandes indispensables ou rechercher toutes les commandes relatives à Active Directory Domain Services.

Rappel : rechercher la liste des commandes se fait avec Get-Command.

Donc pour rechercher toutes les commande AD DS : Get-Command *-AD*

La commande vous listera les 157 commandes disponibles pour AD DS.

[Note]

Pourquoi *-AD* et pas *AD* directement ? Simplement car beaucoup de commandes PowerShell commencent par ADD-QuelqueChose. Vous auriez donc des résultats qui ne concernent pas AD DS sans le tiret.

On ne va pas ici détailler les 157 commandes. N'hésitez pas à utiliser le "Get-Help LaCommande" pour avoir des informations sur les commandes AD DS.

Cependant, on va faire un script simple qui va nous permettre d'ajouter des utilisateurs via une liste contenue dans un fichier csv. C'est une des applications les plus courantes sur AD DS.

Dans la capture d'écran ci-dessus, vous voyez l'application PowerShell ISE avec le script, le fichier users.csv et la console avec les utilisateurs créés avec le script.

C'est un script très simple qui a pour objectif de lire un fichier csv contenant des informations sur les utilisateurs et de traiter ces informations en boucle pour créer des comptes AD DS.

[Note]

On peut voir un fichier csv comme un fichier de type "tableur". Ce n'est pas Excel mais le fonctionnement est semblable. Les colonnes sont séparées par des points-virgules et chaque ligne du fichier correspond à une ligne du tableau.

Commençons par décrire le fonctionnement de la première ligne :

La commande utilisée ici est Import-Csv. Cette commande à 2 paramètres : le chemin du fichier à importer et le délimiteur (celui-ci peut varier, entre la virgule et le point-virgule).

Le résultat de cette commande est enregistré dans la variable $listeUSR. On aura donc la liste des utilisateurs contenue dans le fichier csv dans $listeUSR.

[Note]

Le ` (AltGr + 7) est utilisé pour dire à Powershell que la commande n'est pas terminée mais qu'elle continue sur la ligne suivante.

Ensuite, on fait une boucle qui va lire un par un les utilisateurs de la liste. L'utilisateur actuellement lu est stocké dans la variable $usr.

Enfin, on va ajouter cet utilisateur à notre AD DS avec la commande New-ADUser. Plusieurs paramètres sont passés à cette commande :

  • Name : correspond ici au nom d'affichage "Prénom/espace/Nom"

  • AccountPassword : le mot de passe temporaire de l'utilisateur

  • Path : chemin où sera stocké l'utilisateur dans le domaine

  • SamAccountName et UserPrincipalName : identifiant de connexion, ici : "prénom/point/nom"

  • Enable : compte activé

On remarque qu'il y a des paramètres plus complexes que d'autres :

  • "$($usr.Prenom) $($usr.Nom)" : ce paramètre nous permet de récupérer le prénom et le nom lus dans le csv. En plus de ça, on les rassemble avec juste un espace entre les deux, pour créer le nom d'affichage du compte. Il y a la même chose pour le SamAccountName et UserPrincipalName sauf que c'est un point qui sépare le nom et le prénom.

  • (ConvertTo-SecureString -AsPlainText "Passw0rd" -Force) : cette commande PowerShell convertit le texte entre guillemets en un format spécial utilisé par Windows pour stocker les mots de passe de manière sécurisée.

  • $true : c'est une variable prédéfinie de PowerShell qui renvoie TRUE. Il existe $false pour FALSE.

Le paramètre Path est également un peu spécial. C'est le chemin de notre objet dans l'AD DS. Ici, on cherchait à créer nos utilisateurs dans l'OU Employees, il fallait donc spécifier le chemin de cette OU.

Les mots clés du chemin AD DS :

  • DC : pour Domain Component : représente un composant du domaine. Ici, on l'utilise pour le nom de domaine (contoso) et son extension (com)

  • OU : pour Organizational Unit : désignera une unité d'organisation

  • CN : pour Common Name : permettra de spécifier le nom de l'objet recherché

Le chemin est construit du plus bas (OU, utilisateur, ordinateur...) vers le plus haut (domaine)

Prenons un exemple d'utilisation lorsqu'on cherche un compte.

Dans cet exemple, le compte Eva Michu est créé dans l'OU Compta qui fait partie de l'OU Employees du domaine contoso.com.

Le chemin pour y accéder est donc : "CN=Eva Michu,OU=Compta,OU=Employees,DC=contoso,DC=com"

Conclusion

Ce premier chapitre sur Active Directory vous présente les fondamentaux pour se débrouiller avec les composants basiques. Dans un autre chapitre, on abordera des notions supplémentaires d'Active Directory Domain Services.

Dans le chapitre suivant, nous verrons comment récupérer, rechercher et résoudre les erreurs de configurations, d'installations ou de performances de notre serveur.

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels