Exporter (0) Imprimer
Développer tout

Annexe A : Informations générales sur la mise à niveau de domaines Active Directory vers des domaines AD DS Windows Server 2008

Mis à jour: février 2010

S'applique à: Windows Server 2008, Windows Server 2008 R2

Avant de commencer le processus de mise à niveau de votre environnement Active Directory Windows 2000 ou Windows Server 2003 vers les services de domaine Active Directory (AD DS) de Windows Server 2008, familiarisez-vous avec certains points importants qui affectent ce processus.

Outil de préparation Active Directory

Pour préparer les forêts et les domaines Windows 2000 ou Windows Server 2003 à la mise à niveau vers les services de domaine Active Directory de ou à l’introduction d’un contrôleur de domaine Windows Server 2008, vous devez utiliser l’outil de préparation Active Directory (Adprep.exe). Adprep.exe se trouve dans le dossier \sources\adprep du DVD du système d’exploitation Windows Server 2008.

L’outil Adprep.exe prépare les forêts et les domaines pour une mise à niveau des services de domaine Active Directory en effectuant une série d’opérations avant l’installation du premier contrôleur de domaine Windows Server 2008. Ces opérations comprennent les suivantes :

  • Extension de votre schéma actuel avec de nouvelles informations de schéma fournies par l’outil Adprep.exe tout en conservant les modifications de schéma antérieures dans votre environnement.

  • Redéfinition des autorisations sur des conteneurs et des objets de tout l’annuaire pour améliorer la sécurité et l’interopérabilité avec les domaines .

  • Copie des outils d’administration pour gérer les domaines sur l’ordinateur local.

Pour plus d’informations sur l’utilisation de l’outil Adprep.exe pour préparer votre environnement, voir Préparer votre infrastructure pour la mise à niveau.

Partitions d’annuaire d’applications pour le système DNS

Les partitions d’annuaire d’applications permettent de stocker les données spécifiques aux applications qui peuvent être répliquées sur un ensemble spécifique de contrôleurs de domaine dans la même forêt. Si au moins un contrôleur de domaine de votre forêt exécute Windows Server 2008 et que le maître d’opérations des noms de domaine exécute également Windows Server 2008, vous pouvez profiter des partitions d’annuaire d’applications.

Par exemple, vous pouvez utiliser des partitions d’annuaire d’applications pour stocker les données DNS (Domain Name System) sur des contrôleurs de domaine Windows Server 2008. Des partitions d’annuaire d’applications spécifiques au système DNS sont automatiquement créées dans la forêt et dans chaque domaine lorsque le service Serveur DNS est installé sur des contrôleurs de domaine Windows Server 2008 nouveaux ou mis à niveau. Si la création des partitions d’annuaire d’applications échoue pendant l’installation des services de domaine Active Directory, le système DNS tente de créer les partitions à chaque fois que le service démarre. La création et la suppression de partitions d’annuaire d’applications (dont les partitions d’annuaire d’applications DNS par défaut) exigent que le détenteur du rôle de maître d’opérations des noms de domaine réside sur un contrôleur de domaine Windows Server 2008.

Voici les partitions d’annuaire d’applications spécifiques au système DNS qui sont créées au cours de l’installation des services de domaine Active Directory :

  • ForestDnsZones : partition d’annuaire d’applications à l’échelle de la forêt qui est partagée par tous les serveurs DNS d’une même forêt

  • DomainDnsZones : partitions d’annuaire d’applications à l’échelle du domaine pour chaque serveur DNS d’un même domaine

Enregistrements de ressources de service (SRV)

Le service Net Logon d’un contrôleur de domaine Windows Server 2008 utilise des mises à jour dynamiques pour inscrire les enregistrements de ressources de service (SRV) dans la base de données DNS. Un enregistrement de ressource SRV sert à mapper le nom d’un service (tel que le service LDAP (Lightweight Directory Access Protocol)) avec le nom d’ordinateur DNS d’un serveur qui offre ce service. Dans un réseau Windows Server 2008, un enregistrement de ressource LDAP permet de localiser un contrôleur de domaine. Une station de travail qui se connecte à un domaine Windows Server 2008 interroge DNS sous la forme générale suivante pour rechercher un enregistrement de ressource de service :

_<Service>._<Protocol>.<DnsDomainName>

<Service> est le service demandé, <Protocol> le protocole demandé et <DnsDomainName> le nom DNS complet du domaine AD DS.

Les serveurs AD DS proposent le service LDAP par le biais du protocole TCP, par conséquent les clients peuvent trouver un serveur LDAP en recherchant un enregistrement de la forme suivante dans DNS :

_ldap._tcp.<DnsDomainName>

noteRemarque
Les chaînes de service et de protocole requièrent un trait de soulignement ( _ ) comme préfixe pour éviter les éventuelles collisions avec les noms existants de l’espace de noms.

Ce format s’applique aux implémentations de serveurs LDAP autres que les contrôleurs de domaine Windows Server 2008 ainsi qu’aux implémentations possibles des services d’annuaire LDAP qui utilisent des serveurs de catalogue global n’exécutant pas Windows Server 2008.

sous-domaine _msdcs.nom_domaine

Ce sous-domaine spécifique à Microsoft permet la localisation des contrôleurs de domaine qui tiennent des rôles spécifiques à Windows Server 2008 dans le domaine. Il permet également la localisation des contrôleurs de domaine à partir de l’identificateur global unique (GUID) lorsqu’un domaine a été renommé.

Pour faciliter la localisation des contrôleurs de domaine Windows Server 2008, le service Net Logon (en plus des enregistrements au format standard _Service._Protocole.<NomDomaineDns>) inscrit également des enregistrements de ressources de service (SRV) qui identifient les pseudonymes de type de serveur connus, à savoir « dc » (contrôleur de domaine), « gc » (catalogue global), « pdc » (contrôleur de domaine principal) et « domains » (GUID), en tant que préfixes dans le sous-domaine _msdcs.<nom_domaine>. Pour permettre la localisation des contrôleurs de domaine par type de serveur ou par identificateur global unique (« dctype » abrégé), les contrôleurs de domaine Windows Server 2008 inscrivent les enregistrements de ressources de service sous la forme suivante dans le sous-domaine _msdcs.<nom_domaine> :

_Service._Protocol.DcTyle._msdcs.<DnsDomainName>

Sous-domaine _msdcs.domaine_racine_forêt

Le sous-domaine _msdcs.domaine_racine_forêt stocke des enregistrements de ressources à l’échelle de la forêt qui présentent un intérêt pour les clients et les contrôleurs de domaine de toute la forêt. Par exemple, tous les contrôleurs de domaine de la forêt inscrivent les enregistrements de ressources alias (CNAME) et LDAP, Kerberos et GC SRV dans ce sous-domaine. Les enregistrements de ressources alias (CNAME) sont utilisés par le système de réplication pour localiser les partenaires de réplication et les enregistrements de ressources GC SRV sont utilisés par les clients pour consulter les serveurs de catalogue global.

Pour que la réplication soit possible entre deux contrôleurs de domaine, y compris deux contrôleurs de domaine d’un même domaine, ils doivent être en mesure de consulter les enregistrements du localisateur à l’échelle de la forêt. Pour qu’un nouveau contrôleur de domaine participe à la réplication, il doit être en mesure d’inscrire ses enregistrements à l’échelle de la forêt dans DNS et les autres contrôleurs de domaine doivent pouvoir les consulter. Par conséquent, les serveurs DNS de référence du sous-domaine _msdcs.domaine_racine_forêt doivent être disponibles pour la réplication et les recherches de catalogue global.

Pour cette raison, nous vous recommandons de créer une zone _msdcs.domaine_racine_forêt distincte et de définir son étendue de réplication de façon à ce qu’elle soit répliquée sur tous les serveurs DNS de la forêt.

Certaines organisations exécutant Active Directory sous Windows 2000 ont déjà créé une zone _msdcs.domaine_racine_forêt pour aider les clients à localiser plus efficacement les contrôleurs de domaine. Si cette zone existe déjà dans votre environnement Windows 2000, nous vous recommandons de la déplacer vers la partition d’annuaire d’applications ForestDnsZones à partir du moment où tous les contrôleurs de domaine de la forêt exécutent Windows Server 2008. En outre, pour chaque domaine de la forêt, déplacez la zone _msdcs.<nom_domaine> vers la partition d’annuaire d’applications DomainDnsZones de ce domaine.

Le déplacement des zones DNS intégrées à Active Directory vers les partitions d’annuaire d’applications à l’échelle du domaine et à l’échelle de la forêt offre les avantages suivants :

  • Dans la mesure où la partition d’annuaire d’applications à l’échelle de la forêt peut être répliquée en dehors d’un domaine spécifique et où le déplacement de la zone _msdcs.domaine_racine_forêt vers la partition d’annuaire d’applications à l’échelle de la forêt entraîne sa réplication sur tous les contrôleurs de domaine de la forêt qui exécutent le service Serveur DNS, il n’est pas nécessaire de recourir au transfert de zone DNS pour répliquer les informations du fichier de zone sur les serveurs DNS qui se trouvent à l’extérieur du domaine.

  • La réplication à l’échelle du domaine peut être ciblée pour réduire le trafic de réplication étant donné que les administrateurs peuvent spécifier quels contrôleurs de domaine, parmi ceux qui exécutent le service Serveur DNS, sont autorisés à recevoir les données de zone DNS.

  • La réplication à l’échelle de la forêt peut être ciblée pour réduire le trafic de réplication étant donné que les données DNS ne sont plus répliquées dans le catalogue global.

  • Les enregistrements DNS situés sur les serveurs de catalogue global de la forêt sont supprimés, ce qui réduit la quantité d’informations répliquées avec le catalogue global.

Pour plus d’informations sur l’utilisation de partitions d’annuaire d’applications pour stocker les données DNS, voir Déplacer les données DNS vers des partitions d’annuaire d’applications DNS.

Fréquence de la réplication intrasite

Les contrôleurs de domaine Windows 2000 qui sont mis à niveau vers Windows Server 2008 conservent une fréquence de réplication intrasite par défaut de 300/30. En d’autres termes, les modifications apportées aux services de domaine Active Directory sont répliquées sur tous les autres contrôleurs de domaine d’un même site 5 minutes (300 secondes) après la modification, avec un décalage de 30 secondes avant de notifier le prochain contrôleur de domaine, tant que le niveau fonctionnel de la forêt n’est pas défini sur Windows Server 2008. Lorsque le niveau fonctionnel de la forêt est augmenté au niveau Windows Server 2008, la fréquence de réplication des services de domaine Active Directory passe à 15/3, le paramètre par défaut de Windows Server 2008. Cela signifie que les modifications sont répliquées sur tous les contrôleurs de domaine d’un même site 15 secondes après la modification, avec un décalage de 3 secondes avant de notifier le prochain contrôleur de domaine. Si vous aviez modifié le paramètre de fréquence de réplication par défaut de 300/30 dans Windows 2000, il ne prend pas la valeur par défaut de 15/3 dans Windows Server 2008 après la mise à niveau. Par contre, une nouvelle installation de Windows Server 2008 utilise toujours le paramètre de fréquence de réplication intrasite de 15/3.

ImportantImportant
Ne modifiez pas la fréquence de réplication intrasite par défaut de 300/30 sur les contrôleurs de domaine Windows 2000. À la place, mettez à niveau votre domaine Windows 2000 vers Windows Server 2008 et augmentez le niveau fonctionnel de la forêt à Windows Server 2008 pour profiter de la fréquence de réplication intrasite de 15/3.

Nouveaux groupes et nouvelles appartenances de groupe créés après la mise à niveau du contrôleur de domaine principal

Après avoir mis à niveau le contrôleur de domaine Windows 2000 détenant le rôle de maître d’opérations d’émulateur de contrôleur de domaine principal (PDC) (également appelé rôle d’opérations à maître unique flottant ou FSMO) dans chaque domaine de la forêt vers Windows Server 2003, un certain nombre de nouveaux groupes, de groupes connus et de groupes intégrés sont créés. En outre, de nouvelles appartenances de groupe sont établies. Si vous transférez le rôle de maître d’opérations d’émulateur de contrôleur de domaine principal à un contrôleur de domaine Windows Server 2003 ou Windows Server 2008 au lieu de le mettre à niveau, ces groupes seront créés lors du transfert du rôle. Parmi les nouveaux groupes, les groupes connus et les groupes intégrés, on peut citer les suivants :

  • Builtin\Utilisateurs du Bureau à distance

  • Builtin\Opérateurs de configuration réseau

  • Utilisateurs de l’Analyseur de performances

  • Utilisateurs du journal de performance

  • Builtin\Générateurs d’approbations de forêt entrante

  • Builtin\Utilisateurs de l’Analyseur de performances

  • Builtin\Utilisateurs du journal de performance

  • Builtin\Groupe d’accès d’autorisation Windows

  • Builtin\Serveurs de licences des services Terminal Server

Les nouvelles appartenances de groupe comprennent les suivantes :

  • Si le groupe Tout le monde se trouve dans le groupe Accès compatible pré-Windows 2000, le groupe Ouverture de session anonyme et le groupe Utilisateurs authentifiés sont également ajoutés au groupe Accès compatible pré-Windows 2000.

  • Le groupe Serveurs réseau est ajouté à l’alias Analyseur de performances.

  • Le groupe Enterprise Domain Controllers est ajouté au groupe d’accès d’autorisation Windows.

En outre, lorsque vous mettez à niveau le contrôleur de domaine Windows 2000 qui détient le rôle de maître d’opérations d’émulateur de contrôleur de domaine principal dans le domaine racine de la forêt, les entités de sécurité supplémentaires ci-dessous sont créées :

  • Service local

  • Service réseau

  • Authentification NTLM

  • Une autre organisation

  • Ouverture de session interactive à distance

  • Authentification SChannel

  • Cette organisation

Après avoir mis à niveau le contrôleur de domaine Windows Server 2003 détenant le rôle de maître d’émulateur de contrôleur de domaine principal dans chaque domaine de la forêt vers Windows Server 2008, après avoir transféré le rôle de maître d’opérations d’émulateur de contrôleur de domaine principal à un contrôleur de domaine ou après avoir ajouté un contrôleur de domaine en lecture seule à votre domaine AD DS Windows Server 2008, les nouveaux groupes, groupes connus et groupes intégrés ci-dessous sont créés :

  • Builtin\IIS_IUSRS

  • Builtin\Opérateurs de chiffrement

  • Groupe de réplication dont le mot de passe RODC est autorisé

  • Groupe de réplication dont le mot de passe RODC est refusé

  • Contrôleurs de domaine en lecture seule

  • Builtin\Lecteurs des journaux d’événements

  • Contrôleurs de domaine d’entreprise en lecture seule (créé uniquement dans le domaine racine de la forêt)

  • Builtin\Accès DCOM au service de certificats

Les nouvelles appartenances de groupe sont les suivantes :

  • L’entité de sécurité IUSR est ajoutée au groupe Builtin\IIS_IUSRS.

  • Les groupes suivants sont ajoutés au Groupe de réplication dont le mot de passe RODC est refusé :

    • Propriétaires créateurs de la stratégie de groupe

    • Administrateurs du domaine

    • Éditeurs de certificats

    • Contrôleurs de domaine

    • Krbtgt

    • Administrateurs de l’entreprise

    • Administrateurs du schéma

    • Contrôleurs de domaine en lecture seule

  • L’entité de sécurité Service réseau est ajoutée au groupe Builtin\Utilisateurs du journal de performance.

  • De plus, les nouvelles entités de sécurité supplémentaires ci-dessous sont créées dans le domaine racine de la forêt :

  • IUSR

  • Droits du propriétaire

  • L’entité de sécurité Well-Known-Security-Id-System prend le nom de Système.

    noteRemarque
    Si vous transférez le rôle de maître d’opérations d’émulateur de contrôleur de domaine principal depuis un contrôleur de domaine Windows 2000 vers un contrôleur de domaine , tous les nouveaux groupes, groupes connus, groupes intégrés et nouvelles appartenances de groupe mentionnés ci-dessus seront créés.

Considérations relatives aux stratégies de sécurité lors de la mise à niveau de Windows 2000 vers Windows Server 2003

La signature des paquets SMB (Server Message Block) et la signature des canaux sécurisés sont des stratégies de sécurité qui sont activées par défaut sur les contrôleurs de domaine Windows Server 2008. Pour permettre aux clients exécutant des versions antérieures de Windows de communiquer avec des contrôleurs de domaine exécutant Windows Server 2008, il peut être nécessaire de désactiver temporairement ces stratégies de sécurité pendant le processus de mise à niveau.

Signature des paquets SMB

La signature des paquets SMB est un mécanisme de sécurité qui protège l’intégrité des données du trafic SMB entre les ordinateurs clients et les serveurs, et qui empêche les attaques de logiciels malveillants en fournissant une certaine forme d’authentification mutuelle. Ce mécanisme consiste à placer une signature de sécurité numérique dans chaque paquet SMB, laquelle est ensuite vérifiée par le récepteur. La signature des paquets SMB côté serveur est imposée par défaut sur les contrôleurs de domaine Windows Server 2008, c’est-à-dire qu’elle doit être activée sur tous les clients.

Les clients exécutant Windows NT 4.0 avec Service Pack 2 (SP2) (ou version antérieure) ou certains systèmes d’exploitation non-Microsoft ne prennent pas en charge la signature des paquets SMB. Ces clients ne seront pas en mesure de s’authentifier sur un contrôleur de domaine Windows Server 2008. Pour garantir la réussite de l’authentification, mettez ces clients à niveau vers une version ultérieure du système d’exploitation ou du Service Pack. Toutefois, si vous ne pouvez pas les mettre à niveau, vous pouvez leur permettre de s’authentifier en configurant la signature des paquets SMB sur tous les contrôleurs de domaine Windows Server 2008 de façon à ce qu’elle soit autorisée, mais pas obligatoire.

Pour plus d’informations sur la configuration de la signature des paquets SMB sur les contrôleurs de domaine Windows Server 2008, voir Modifier les stratégies de sécurité par défaut sur les contrôleurs de domaine Windows Server 2008.

Signature et chiffrement des canaux sécurisés

Lorsqu’un ordinateur devient membre d’un domaine, un compte d’ordinateur est créé. À chaque fois que l’ordinateur démarre, il utilise le mot de passe du compte d’ordinateur pour créer un canal sécurisé avec un contrôleur de domaine de son domaine. Ce canal sécurisé sert à assurer des communications sécurisées entre un membre d’un domaine et un contrôleur de domaine de ce domaine. La signature des canaux sécurisés est imposée par défaut sur les contrôleurs de domaine Windows Server 2008, c’est-à-dire que tous les clients doivent activer la signature et le chiffrement des canaux sécurisés.

Les clients exécutant Windows NT 4.0 avec Service Pack 3 (SP3) ou version antérieure ne prennent pas en charge la signature des canaux sécurisés. Ces clients ne seront pas en mesure d’établir des communications avec un contrôleur de domaine Windows Server 2008. Pour garantir la réussite de la communication, mettez ces clients à niveau vers une version ultérieure du système d’exploitation ou du Service Pack. Toutefois, si vous ne pouvez pas les mettre à niveau, vous devez désactiver la signature des canaux sécurisés sur tous les contrôleurs de domaine Windows Server 2008 pour ne pas être obligé de signer ou de chiffrer le trafic traversant le canal sécurisé.

Pour plus d’informations sur la configuration de la signature des canaux sécurisés sur les contrôleurs de domaine Windows Server 2003, voir Modifier les stratégies de sécurité par défaut sur les contrôleurs de domaine Windows Server 2008.

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft