Introduction

La plupart du temps, les discussions qui tournent autour des infrastructures  Microsoft, parlent de l’annuaire  d’Active directory. Mais force est de constater qu’au fur et à mesure des versions de Windows 2000/2003  il n’existe pas un AD mais véritablement plusieurs versions de l’annuaire Microsoft. 

 De la naissance à Windows 2003 R2

Lieu de naissance : Michigan.

Active Directory est un annuaire LDAP qui originellement est issu du standard X500 créé en 1988 par l'organisation international de standardisation. (ISO) et l'union international des télécommunications  (ITU). X500 Directory Access Protocol était un protocole très complexe et intégrait des fonctionnalités évoluées qui ne trouvait pas écho dans la plupart des environnements client. L'université du Michigan travailla alors vers une simplification de ce protocole. Simplification qui allait de devenir "LightWeight X500 Acces Protocol" . La première version de LDAP fut totalement terminée en 1993 et aboutie à la création de la RFC 1487. Mais malheureusement, dépourvue de fonctionnalité, ce protocole n'a pas vraiment été utilisé. En 1995, arrive une version 2 du protocole LDAP (LDAPv2) qui originellement assurait l'interconnexion entre les clients et les serveurs X500.Les équipes de l'université du Michigan ont alors pensé que si le protocole LDAPv2 était capable de s'interfacer avec les annuaires X500 alors, il pourrait assurer ce rôle. En 1995 apparut ainsi le premier Annuaire LDAP fournie par cette même université.

En 1997, une mise à jour majeure donna naissance à la norme LDAPv3 décrite dans la RFC 2251. Depuis plusieurs compagnies comme Microsoft , SUN, Novell s'emparèrent de ces normes pour fournir des solutions d'annuaires comme Active Directory, Novell Directory Services etc..

L’annuaire Active Directory est comme tout le monde le sait le successeur de l’environnement Windows NT4 qui possédait une base de compte "à plat" sans véritable structure hiérarchique. Plusieurs erreurs de jeunesse ont été évitées grâce notamment à l'environnement Novell qui avait été expérimenté avec l'annuaire NDS quelques années auparavant.

Une des grandes différences porte notamment sur le protocole sous-jacent qui pour Windows NT se base sur NetBios et DNS et TCP/IP pour Active Directory. Les limites de stockages qui pour Windows NT était de 40 Mb et environ 40 000 objets  furent portées à plusieurs millions d'objet et une limite de stockage de 16To dans l'environnement Active Directory.

Windows 2000 / Active Directory 2000 et son mode Mixte.

L'introduction de l'environnement Windows 2000 Server et la promotion d'un nouveau serveur en tant que contrôleur de domaine a introduit une nouvelle notion environnemental appelé mode mixte. Son contraire étant appelé Mode Natif.

Le mode mixte précise notamment que dans le domaine concerné, il existe dans le domaine en place des contrôleurs Windows d'ancienne génération comme Windows 3.51 ou 4.0. Dans le Mode Mixte Windows 2000 émule des anciennes fonctions présentes dans le "monde" Windows NT4 comme la fonction PDC notamment.

Le passage en mode natif est possible mais sans retour possible. Voici les quelques différences que vous pouvez trouver entre les deux modes.

Mode Mixte

·         L'émulateur PDC envoi les modifications vers les contrôleurs secondaires Windows NT4. Les serveurs Windows 2000 utilisent quand a eux un modèle de réplication multi-maitre.

·         Netbios ne peut pas être supprimé.

·         Les groupes universels de sécurité ne sont pas présent. Les groupes de domaine local sont uniquement disponibles sur les DC. Les conversions des groupes ne sont pas accepté.

Native Mode

·         Seuls les contrôleurs Windows 2x sont acceptés dans le domaine.  Tout les DC utilisent la réplication multi-maitres.

·         Netbios peut être désactivé.

·         Les groupes de domaine locaux sont présents dans l'ensemble des machines présentes dans le domaine.

·         Les groupes universels de sécurités peuvent être utilisés. La conversion des groupes est possible.

Avec l'avènement de Windows 2003 serveur les choses ont un petit peu changée et introduisent une notion de niveau fonctionnel.  Si le mode Mixte et natif s'applique au niveau du domaine, les niveaux fonctionnels s'appliquent sur la forêt et le domaine.

La notion de niveau fonctionnel apparait des que l'on introduit un serveur Windows 2003 en tant que Dc au sein d'une forêt active Directory.  Par défaut, le niveau fonctionnel du domaine est fixé à Windows 2000 Mixte et le niveau fonctionnel de la forêt est de type 'Windows 2000'.

Comme la notion de domaine Mixte et Natif, l'augmentation du niveau fonctionnel est a sens unique et aucun retour arrière n'est possible fonctionnellement.

Niveau fonctionnel de domaine :

 

Niveau fonctionnel de forêts

Nouveautés fonctionnelles Actives Directory apportée par Windows 2003 SP1.

Message de sauvegarde dans l'observateur d'événement.

Des messages de sauvegarde sont présents dans l'observateur d'événement si l'active directory n'as pas été sauvegarder à temps.

Support de la virtualisation.

La mise en place du SP1 permet d'envisager la virtualisation des serveurs sur Virtual Server 2005 car celle-ci est désormais supportée par Microsoft

Attributs confidentiels

Certains attributs peuvent être positionnés en confidentiel ce qui ne permet pas leur lecture sans droits appropriés. Par défaut ces attributs ne pouvant être lu uniquement par les administrateurs.

Changement au niveau du  Drag and Drop dans la console Active Directory User et Computer

Possibilité de supprimer les fonctions drag and Drop dans les console User and Computer et possibilité d'afficher des boites de dialogues de confirmation lors de déplacement

Sécurisation de la Réplication  et erreur de réplication

Les données de réplication Metadata sont désormais supprimées concernant les contrôleurs de domaine  supprimé du domaine (Amélioration de ntdsutil cf : http://support.microsoft.com/kb/216498/en-us)

Amélioration de l'installation depuis un média pour les serveurs DNS

Des nouvelles options sont apparues dans le SP1 concernant l'installation des serveurs DNS par un média qui n'oblige plus la réplication complète des zones DomainDNSZone et ForestDNSZones.

Mise à jours des outils

Des nouvelles versions de DCDiag/NTdsUtil/AdPrep sont présentes dans le SP1

Augmentation de la durée de vie  des éléments supprimés

Les nouvelles forêts crées en SP1 bénéficient d'une durée de vie des éléments supprimés de 180 Jours au lieu de 60. Les anciennes forêts ne sont pas concernées.

Conservation du SID History dans le cas d'éléments supprimé.

Le SID History est ajouté aux attributs des éléments supprimés.

Signalisation des problèmes FSMO

Les opérations qui demandent l'accès aux rôles FSMO non présent ou non accessible génèrent un événement  l'observateur d'événement.

Nouveautés fonctionnelles Actives Directory apportée par Windows 2003 R2.

Active Directory Application Mode  (AD ou ADAM)

Active Directory en mode application (ADAM, Active Directory Application Mode) fait partie des services d'annuaire Microsoft totalement intégrés disponibles dans Windows Server 2003. Ce service est spécialement conçu pour les scénarios d'application avec annuaire. ADAM n'est pas exécuté en tant que service du système d'exploitation et ne nécessite donc aucun déploiement sur un contrôleur de domaine. Ce mode d'exécution permet également d'exécuter simultanément plusieurs instances d'ADAM sur un même serveur et de configurer chacune de ces instances indépendamment.

Active Directory Federated Service (ADFS)

 

Les services ADFS sont des services fédérés de gestion des identités de type « authentification unique » (SSO, single sign-on) pour environnements Windows Server. Ils permettent notamment d’authentifier et d’autoriser des utilisateurs accédant à des extranets sur le Web. Ils améliorent la valeur des déploiements Active Directory actuels dans trois cas de figure : extranets B2C, fédérations interentreprises (multi-forêts) et fédérations Internet B2B. Les services d’authentification sur extranets et les services à authentification unique s’ajoutent aux fonctions d’authentification et de distribution de sessions dont Windows dispose déjà pour permettre aux réseaux internes de communiquer avec des réseaux de périmètre en contact avec Internet. La fédération des identités permet à deux entreprises de partager en toute sécurité les informations d’identité Active Directory d’un utilisateur. Elle facilite ainsi la collaboration avec les partenaires et la délégation des tâches de gestion des utilisateurs.

L'introduction d'un serveur Windows 2008 controlleur de domaine se prépare quelque peu. Comme les fois précédente, je parle bien evidement des mises à jour de forêt windows 2000 vers 2003, il convient d'effectuer quelques modifications au schéma de l'Active Directory. l'ADprep n'est pas loin ...

Précaution avant toutes choses, eviter de faire ce genre d'exercice sur une forêt qui présente des problémes de réplication. Donc un peu de méthode avant de vous lancer dans de la mise à jours de shéma, faire un petit bilan de l'Active directory en question avec repadmin et Dcdiag. Juste le temps de vérifier que ce que vous allez mettre à jours... fonctionne bien .... ;-))
une fois que votre AD est en pleine forme,  positionnez vous sur le serveur 2003 maitre d'infrastructure, reperer sur le DVD de Windows 2008 server le répertoire Sources\ADPrep et copier son contenu sur le disque de votre serveur Windows 2003.
Une fois effectué placez vous dans le repertoire en question et lancer la commande Adprep / forestprep. Jusque la me diriez vous rien de nouveau mais attendez un peu la suite . ...

Si vous projettez de mettre en place des serveurs Windows 2008 controlleur de domaine en lecture seul alors... ca change ..
il faut executer la commande adprep /rodcprep. Attention cette dernière commande ne fonctionne pas en conjonction avec la précédente. Elle peut être executée sur n'importe quel DC du domaine à condition que votre compte utilisateur fasse partie du groupe Administrateur de l'entreprise bien sur.
je précise mais cela peut se deviner que le premier DC d'une forêt Windows 2008 toute neuve ne peut pas être un RODC. c'est logique .. mais c'est dit. Par contre cette préparation (/rodcprep) n'est pas nécéssaire si il s'agit d'une nouvelle forêt Windows 2008 toute neuve.

Une fois la préparation de la forêt effectuée, passons aux domaine. la les choses changent un peu.
Connectez vous sur le serveur du domaine qui contient le rôles Maitre d'infrastrucuture. de la même facon que énoncé plus haut , recupérer les bin de ADprep et copiez les dans un répertoire. Tapez ensuite la commande Adprep / domainPrep /gpprep et valider par entrée.

Sur un serveur Windows 2003 il est possible qu'un messsage s'affiche vous informant que cela n'est pas nécéssaire, pas très grave, il faut l'ignorer.

Une fois terminé votre foret et votre domaine est pret pour l'installation d'un DC 2008.

la prochaine on parlera des RODC

Une des problématiques quand il s'agit de déployer un Active Directory, est de mettre en place dans un environnement parfois peu sécurisé des serveurs contrôleur de domaine contenant la quasi totalités des informations de connexion de l'entreprise.  Windows 2008 serveur permet par plusieurs fonctionnalités nouvelles de sécuriser ces plates-formes notamment par la mise en place de serveur contrôleur de domaine en lecture seule. (RODC)

Deux cas de figures sont possibles en fait, soit vous de désirez pas sacrifier la sécurité et vous évitez de positionner des contrôleurs de domaine dans des environnements peu sécurisé. Soit vous pouvez utiliser ces fameux RODC qui sont, je le rappelle, une brique des solutions de sécurité que offre Windows 2008 serveur. Le fait de ne pas positionner des contrôleurs de domaine dans les environnements éloignés et généralement peu sécurisé, vous rend dépendant que la fiabilité et de la bande passante du lien WAN qui relie l'agence au site central ou se trouve généralement les contrôleurs de l'entreprise.

En cas de rupture de lien ou de congestion, les utilisateurs ne pourront plus accéder à leurs serveurs de ressources ou constaterons dans le second cas des accès fortement ralentis.

L'autre problématique que pose les contrôleurs de domaine, est qu'ils peuvent être à la merci d'une erreur humaine faite par un administrateur local membre du groupe des administrateurs du domaine qui aura des répercussions immédiates sur l'Active Directory Corporate.  (Suppression d'OU, Changement de la topologie de réplication etc..). De plus, pour se connecter sur les DC 2003 il faut généralement posséder des droits d'administration du domaine et par conséquent cela peut poser problème surtout lorsqu'il s'agit de responsable ne possédant pas toute la compétence pour administrer l'Active Directory.

Le Scénario RODC à donc été pensé en ce sens. Ce dernier va maintenir une copie locale de tous les objets du domaine en question sauf les informations de type secret (Mot de passe notamment).

Lorsqu'un utilisateur se connecte sur un RODC ce dernier transmet la requête à un contrôleur de domaine non RODC. Vous me direz quel intérêt en cas de panne de la liaison entre l'agence et le site centrale ?.  Patience on n'y arrive.  Il est possible de forcer le RODC à utiliser un cache de mot de passe via une stratégie de réplication de mots de passe que l'on appellera PRP pour Password réplication Stratégie.

Si l'utilisateur est inclus dans la stratégie PRP alors son mot de passe est mis en cache par le RODC. Dans ce cas à la prochaine ouverture de sessions sur le domaine, le RODC n'aura pas l'utilité de requêter un contrôleur de domaine (RWDC : Read Write Domain Contrôler.)

En cas de vol du serveur RODC le risque encouru est donc limité car seuls les utilisateurs qui sont inclus dans cette fameuse stratégie PRP devront changer leurs mots de passe. L'interface graphique offrant la possibilité de visualiser les utilisateurs ayant fait l'objet d'une mise en cache.

Concernant la réplication, le RODC ne réplique pas d'information avec le serveur RWDC. Seule les informations cotée RWDC sont répliquée vers le RODC. Pour les plus anciens ca vous rappelera en le bon vieux le modèle PDC-BDC de l'environnement NT4, sans la sécurité bien sur !

Un autre intérêt des RODC est qu'ils peuvent posséder des prérogatives locale .  Ainsi les administrateurs des agences ou des sites éloignés seront en mesure d'effectuer une certaine maintenance  de leurs  serveurs contrôleur de domaine sans pour cela bénéficier des droits d'administration du domaine.

Déployer un RODC

Avant de vous lancer dans le déploiement d'un RODC, Plusieurs pré-requis sont à vérifier.

• Premièrement vérifiez que le niveau fonctionnel de votre forêt est positionné à minima sur Windows 2003 Serveur. Ce qui signifie grossièrement, que plus aucun contrôleur de domaine Windows 2000 n'existe dans votre forêt.
• Deuxièmement: Préparer votre forêt Windows 2003 ou supérieure à recevoir des contrôleurs de domaine en lecture seule. Pour cela vous devez récupérer sur le DVD de Windows 2008 serveur le répertoire Adprep et le recopier intégralement sur le serveur DC Windows 2003 possédant le rôle de maitre de schéma. Une fois copié, exécuter la commande adprep / rodcprep avec un compte d'administration approprié (Administrateur du schéma).
• Troisièmement: Assurez vous qu'au moins un serveur Windows 2008 en lecture Ecriture existe dans votre forêt.

Une fois ces pré-requis établis vous pouvez lancer l'installation d'un serveur RODC. Ce dernier peut être soit de type Windows 2008 Standard ou Entreprise, ou bien un serveur Core Edition. Pour l'instant.,faisons simple et utilisons une interface graphique fournie par la version Standard ou Entreprise. On passera après a la version Core.

Le processus est relativement simple car il suffit de lors de l'installation des serveurs contrôleurs de domaine de cocher l'option Read-Only domain Controller.

Figure 1 RO1

L'intérêt d'un RODC est que l'on peut déléguer cette tâche à une personne tierce qui ne fait pas partie des administrateurs du domaine, en créant au préalable le compte de l'ordinateur RODC dans le domaine et en précisant quel sera le  compte sera utilisé pour l'installation de cette machine. La seule contrainte qui n'en n'est pas une, est que le serveur en question, le futur RODC, soit à l'installation, dans un groupe de travail et non dans un domaine.

Lors de l'installation le programme Dcpromo vous demandera si vous désirez également ajouter des personnes qui ne seront pas administrateur du domaine, mais qui recevrons des privilèges d'administration de la machine.

Figure 2RO2

A propos de la réplication des mots de passe dans l'environnement RODC

Comme je vous l'ai précisé par ailleurs, il est possible, voir souhaitable dans certain cas, de configurer une stratégie de réplication de mot de passe de façon à ce que le RODC ne soit pas obligé de contacter régulièrement un RWDC.

La stratégie de réplication des mots de passe est déterminée par deux attributs possédant plusieurs valeurs. Ces attributs sont nommés Allowed List et Deny List. Dans le cas ou l'utilisateur est dans la liste autorisée alors les informations de mot de passe sont mise en mode cache dans l'autre cas le RODC devra contacter un serveur RWDC. Dans le cas ou par hasard vous mettriez un compte dans les deux listes.... La liste de refus a préséance.

Une fois votre RODC installé, vous allez devoir gérer ces fameuses PRP. Pour cela Windows 2008 créer deux groupes de sécurité

• Allowed RODC password replication Group
• Denied RODC password replication Group

Figure 3 RO3

Vous pouvez donc une fois votre RODC en place, gérer ces listes d'accès en effectuant un click droit sur le compte d'ordinateur de votre RODC et en sélectionnant l'onglet Password replication policy. 

Figure 4 RO5
Dans la boite de dialogue avancée vous trouverez deux options qui vous permettrons de voir quelle sont les utilisateurs qui sont mis en cache et les utilisateurs qui se sont authentifiés et dont la requête est partie vers un RWDC.  (Accounts that have been authenticated to this read only Domain Controller)

Figure 6 RO6
Il est également possible de precharger des informations de comptes utilisateurs qui seront stockés en cache sur le serveur RODC par l'option Prepopulate.

Figure 7 RO7

Gestion des rôles

La gestion de la machine devra peut être assurée par des personnes qui ne devront pas avoir comme prérogative l'administration du domaine. Pour cela vous avez la possibilité d'ajouter des personnes qui seront administrateur de la machine sans avoir de prérogative sur l'annuaire Active Directory.Pour cela vous devez utiliser la commande dsmgmt depuis le RODC comme le montre la figure suivante :

Figure 8 RO8

Une fois rendu à ce niveau vous pouvez donner accès a des utilisateurs du domaine a cette machine en tant qu'administrateur uniquement de cette dernière. Pour ajouter un utilisateur en tant qu'administrateur de la machine tapez la commande suivante

Add nomdevotreutilisateur suivi du nomdurole

Pour vérifier son appartenance vous pouvez utiliser la commande Show role suivi du nomdurôle.
Une fois votre rôle d'administrateur local Activé  vous pouvez vous connecter avec ce compte, visualiser l'Active Directory mais vous ne pourrez pas le modifier.

Fig ure 9 RO9

Conclusion

La fonction RODC n'est qu'une brique pour la sécurisation de l'environnement ... comment dire.. hostile. Elle doit a mon avis être complétée par d'autre paramétrage logiciel comme les fonctions Core et l'encryption. Mais nous verrons cela une autre fois.