Mises à jour du composant Directory Services

Auteur : Justin Turner, ingénieur support senior d’escalade auprès du groupe Windows

Cette leçon explique les mises à jour du composant Services d’annuaire dans Windows Server 2012 R2.

Ce que vous allez apprendre

Expliquez les nouvelles mises à jour de composant Services d’annuaire suivantes :

• Expliquez les nouvelles mises à jour de composant Services d’annuaire suivantes :

  • Niveaux fonctionnels de domaines et de forêt

  • Désapprobation de NTFRS

  • Modifications de l'optimiseur de requête LDAP

  • Améliorations de l'événement 1644

  • Amélioration du débit de réplication Active Directory

Niveaux fonctionnels de domaines et de forêt

Vue d’ensemble

Cette section fournit une brève introduction aux changements de niveau fonctionnel de domaine et de forêt.

Nouveaux niveaux DFL et FFL

Avec cette version, il existe de nouveaux niveaux fonctionnels de domaine et de forêt :

• Niveau fonctionnel de la forêt : Windows Server 2012 R2

• Niveau fonctionnel du domaine : Windows Server 2012 R2

Le niveau fonctionnel de domaine Windows Server 2012 R2 permet de prendre en charge les éléments suivants :

1. Protections côté contrôleur de domaine pour les utilisateurs protégés

   Les utilisateurs protégés qui s’authentifient auprès d’un domaine Windows Server 2012 R2 ne peuvent plus effectuer les opérations suivantes :

   • s’authentifier avec l’authentification NTLM ;

   • utiliser les suites de chiffrement DES ou RC4 dans la pré-authentification Kerberos ;

   • être délégués en utilisant la délégation non contrainte ou contrainte ;

   • renouveler les tickets TGT utilisateur au-delà de la durée de vie initiale de 4 heures.

2. Stratégies d'authentification

   Nouvelles stratégies Active Directory basées sur une forêt qui peuvent être appliquées à des comptes dans les domaines Windows Server 2012 R2 pour contrôler les hôtes à partir desquels un compte peut se connecter et appliquer des conditions de contrôle d’accès pour l’authentification auprès de services s’exécutant en tant que compte

3. Silos de stratégies d'authentification

   Nouvel objet Active Directory basé sur une forêt, qui peut créer une relation entre des comptes d’utilisateurs, de services gérés et d’ordinateurs permettant de classer les comptes pour les stratégies d’authentification ou pour l’isolation de l’authentification.

Pour plus d’informations, consultez Guide pratique pour configurer des comptes protégés.

En plus des fonctionnalités ci-dessus, le niveau fonctionnel du domaine Windows Server 2012 R2 garantit que tout contrôleur de domaine du domaine s’exécute Windows Server 2012 R2. Le niveau fonctionnel de forêt Windows Server 2012 R2 ne fournit aucune nouvelle fonctionnalité, mais il garantit que tout nouveau domaine créé dans la forêt fonctionne automatiquement au niveau fonctionnel de domaine Windows Server 2012 R2.

DFL minimum appliqué lors de la création d’un nouveau domaine

Windows Server 2008 DFL est le niveau fonctionnel minimal pris en charge lors de la création d’un nouveau domaine.

Réduction des niveaux fonctionnels de forêt et de domaine

Les niveaux fonctionnels de forêt et de domaine sont définis sur Windows Server 2012 R2 par défaut lors de la création d’un nouveau domaine et d’une nouvelle forêt, mais peuvent être réduits à l’aide de Windows PowerShell.

Pour augmenter ou abaisser le niveau fonctionnel de la forêt à l’aide de Windows PowerShell, utilisez l’applet de commande Set-ADForestMode.

Pour définir le FFL contoso.com en mode Windows Server 2008 :

Set-ADForestMode -ForestMode Windows2008Forest -Identity contoso.com

Pour augmenter ou diminuer le niveau fonctionnel du domaine à l’aide de Windows PowerShell, utilisez l’applet de commande Set-ADDomainMode.

Pour définir le DFL contoso.com en mode Windows Server 2008 :

Set-ADDomainMode -DomainMode Windows2008Domain -Identity contoso.com

La promotion d’un contrôleur de domaine exécutant Windows Server 2012 R2 en tant que réplica supplémentaire dans un domaine existant exécutant 2003 DFL fonctionne.

Création d’un nouveau domaine dans une forêt existante

ADPREP

Aucune opération de domaine ou de forêt n’est ajoutée dans cette version.

Ces fichiers .ldf contiennent des modifications de schéma pour le Service d’inscription d’appareil.

1. Sch59

2. Sch61

3. Sch62

4. Sch63

5. Sch64

6. Sch65

7. Sch67

Dossiers de travail :

1. Sch66

MSODS :

1. Sch60

Silos et stratégies d’authentification

1. Sch68

2. Sch69

Désapprobation de NTFRS

Vue d’ensemble

FRS est déconseillé dans Windows Server 2012 R2. La dépréciation de FRS s’effectue en appliquant un niveau fonctionnel de domaine (DFL) minimal de Windows Server 2008. Cela s’applique uniquement si le nouveau domaine est créé à l’aide du Gestionnaire de serveur ou de Windows PowerShell.

Vous utilisez le paramètre -DomainMode avec les applets de commande Install-ADDSForest ou Install-ADDSDomain pour spécifier le niveau fonctionnel du domaine. Les valeurs prises en charge pour ce paramètre peuvent être un entier valide ou une valeur de chaîne énumérée correspondante. Par exemple, pour définir le niveau de mode de domaine sur Windows Server 2008 R2, vous pouvez spécifier la valeur 4 ou « Win2008R2 ». Lors de l’exécution de ces applets de commande à partir de Windows Server 2012 R2, les valeurs valides incluent celles pour Windows Server 2008 (3, Win2008), Windows Server 2008 R2 (4, Win2008R2) Windows Server 2012 (5, Win2012) et Windows Server 2012 R2 (6, Win2012R2). Le niveau fonctionnel du domaine ne peut pas être inférieur à celui de la forêt, mais il peut être supérieur. Étant donné que FRS est déconseillé avec cette version, Windows Server 2003 (2, Win2003) n’est pas un paramètre reconnu avec ces applets de commande lors de l’exécution à partir de Windows Server 2012 R2.

Modifications de l'optimiseur de requête LDAP

Vue d’ensemble

L’algorithme de l’optimiseur de requête LDAP a été réévalué et optimisé. Il en découle des améliorations des performances au niveau de l’efficacité des recherches LDAP et du temps de recherche LDAP pour les requêtes complexes.

Contexte

La possibilité de rechercher dans Active Directory est un service essentiel fourni par les contrôleurs de domaine. D’autres services et applications métier s’appuient sur les recherches dans Active Directory. Les opérations commerciales peuvent cesser si cette fonctionnalité n’est pas disponible. En tant que service essentiel et fortement utilisé, il est impératif que les contrôleurs de domaine gèrent efficacement le trafic de recherche LDAP. L’algorithme d’optimiseur de requête LDAP tente de rendre les recherches LDAP efficaces autant que possible en mappant des filtres de recherche LDAP à un jeu de résultats qui peut être satisfait via des enregistrements déjà indexés dans la base de données. Cet algorithme a été réévalué et optimisé. Il en découle des améliorations des performances au niveau de l’efficacité des recherches LDAP et du temps de recherche LDAP pour les requêtes complexes.

Détails de la modification

Une recherche LDAP contient :

• Un emplacement (direction NC, unité d’organisation, objet) dans la hiérarchie pour commencer la recherche

• Un filtre de recherche

• Une liste des attributs à retourner

Le processus de recherche peut être résumé comme suit :

1. Simplifiez le filtre de recherche si possible.

2. Sélectionnez un ensemble de clés d’index qui retourne le plus petit ensemble couvert.

3. Effectuez une ou plusieurs intersections de clés d’index pour réduire l’ensemble couvert.

4. Pour chaque enregistrement dans le jeu couvert, évaluez l’expression de filtre ainsi que la sécurité. Si le filtre prend la valeur TRUE et que l’accès est accordé, retournez cet enregistrement au client.

Le travail d’optimisation des requêtes LDAP modifie les étapes 2 et 3 pour réduire la taille de l’ensemble couvert. Plus spécifiquement, l’implémentation actuelle sélectionne les clés d’index en double et effectue des intersections redondantes.

Comparaison entre l’ancien et le nouvel algorithme

La cible de la recherche LDAP inefficace dans cet exemple est un contrôleur de domaine Windows Server 2012. La recherche se termine en environ 44 secondes en raison de l’échec de la recherche d’un index plus efficace.

adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=justintu@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfind.txt

Using server: WINSRV-DC1.blue.contoso.com:389

<removed search results>

Statistics
=====
Elapsed Time: 44640 (ms)
Returned 324 entries of 553896 visited - (0.06%)

Used Filter:
 ( |  ( &  ( |  (cn=justintu)  (postalCode=80304)  (userPrincipalName=justintu@blue.contoso.com) )  ( |  (objectClass=person)  (cn=justintu) ) )  ( &  (cn=justintu)  (objectClass=person) ) )

Used Indices:
 DNT_index:516615:N

Pages Referenced          : 4619650
Pages Read From Disk      : 973
Pages Pre-read From Disk  : 180898
Pages Dirtied             : 0
Pages Re-Dirtied          : 0
Log Records Generated     : 0
Log Record Bytes Generated: 0

Exemples de résultats à l’aide du nouvel algorithme

Cet exemple répète exactement la même recherche que ci-dessus, mais cible un contrôleur de domaine Windows Server 2012 R2. La même recherche se termine en moins d’une seconde en raison des améliorations apportées à l’algorithme d’optimiseur de requête LDAP.

adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=dhunt@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfindBLUE.txt

Using server: winblueDC1.blue.contoso.com:389

.<removed search results>

Statistics
=====
Elapsed Time: 672 (ms)
Returned 324 entries of 648 visited - (50.00%)

Used Filter:
 ( |  ( &  ( |  (cn=justintu)  (postalCode=80304)  (userPrincipalName=justintu@blue.contoso.com) )  ( |  (objectClass=person)  (cn=justintu) ) )  ( &  (cn=justintu)  (objectClass=person) ) )

Used Indices:
 idx_userPrincipalName:648:N
 idx_postalCode:323:N
 idx_cn:1:N

Pages Referenced          : 15350
Pages Read From Disk      : 176
Pages Pre-read From Disk  : 2
Pages Dirtied             : 0
Pages Re-Dirtied          : 0
Log Records Generated     : 0
Log Record Bytes Generated: 0

• Si vous ne parvenez pas à optimiser l’arborescence :

  • Par exemple : une expression dans l’arborescence était sur une colonne non indexée

  • Enregistrer une liste d’index qui empêchent l’optimisation

  • Exposé via le suivi ETW et l’ID d’événement 1644

    

Pour activer le contrôle Stats dans LDP

1. Ouvrez LDP.exe, puis connectez-vous et liez-vous à un contrôleur de domaine.

2. Dans le menu Options, sélectionnez Contrôles.

3. Dans la boîte de dialogue Contrôles, développez le menu déroulant Charger prédéfini, sélectionnez Rechercher des statistiques, puis sélectionnez OK.

   

4. Dans le menu Parcourir, sélectionnez Rechercher

5. Dans la boîte de dialogue Rechercher, sélectionnez le bouton Options.

6. Vérifiez que la case à cocher Étendue est activée dans la boîte de dialogue Options de recherche, puis sélectionnez OK.

   

Try This : utiliser LDP pour retourner des statistiques de requête

Effectuez les opérations suivantes sur un contrôleur de domaine ou à partir d’un client ou d’un serveur joint à un domaine sur lequel les outils AD DS sont installés. Répétez les opérations suivantes pour cibler votre contrôleur de domaine Windows Server 2012 et votre contrôleur de domaine Windows Server 2012 R2.

1. Consultez l’article « Création d’applications plus efficaces avec Microsoft AD » et reportez-vous à cet article si nécessaire.

2. À l’aide de LDP, activez les statistiques de recherche (consultez Activer le contrôle Stats dans LDP)

3. Effectuez plusieurs recherches LDAP et observez les informations statistiques en haut des résultats. Vous répéterez la même recherche dans d’autres activités afin de les documenter dans un fichier texte du Bloc-notes.

4. Effectuer une recherche LDAP que l’optimiseur de requête doit être en mesure d’optimiser en raison des index d’attributs

5. Essayez de créer une recherche qui prend beaucoup de temps (vous souhaiterez peut-être augmenter l’option Limite de temps afin que la recherche n’expire pas).

Ressources supplémentaires

Que sont les recherches Active Directory ?

Fonctionnement des recherches Active Directory

Création d’applications avec Microsoft Active Directory plus efficaces

Les requêtes LDAP 951 581 sont exécutées plus lentement que prévu dans le service d’annuaire AD ou LDS/ADAM et l’ID d’événement 1644 peut être consigné

Améliorations de l'événement 1644

Vue d’ensemble

Cette mise à jour ajoute des statistiques de résultats de recherche LDAP supplémentaires à l’ID d’événement 1644 pour faciliter la résolution des problèmes. En outre, il existe une nouvelle valeur de Registre qui peut être utilisée pour activer la journalisation sur un seuil basé sur le temps. Ces améliorations ont été mises à disposition dans Windows Server 2012 et Windows Server 2008 R2 SP1 via la KB 2 800 945 et seront mises à disposition dans Windows Server 2008 SP2.

Contexte

Lors de la résolution des problèmes de performances d’Active Directory, il apparaît que l’activité de recherche LDAP peut contribuer au problème. Vous décidez d’activer la journalisation afin de voir les requêtes LDAP coûteuses ou inefficaces traitées par le contrôleur de domaine. Pour activer la journalisation, vous devez définir la valeur de diagnostic Field Engineering et spécifier éventuellement les valeurs de seuil des résultats de recherche coûteux/inefficaces. Lorsque vous activez le niveau de journalisation Field Engineering avec la valeur 5, toute recherche qui répond à ces critères est journalisée dans le journal des événements des services d’annuaire avec un ID d’événement 1644.

L’événement contient :

• Adresse IP et port du client

• Nœud de démarrage

• Filtrer

• Étendue de la recherche

• Sélection des attributs

• Contrôles serveur

• Entrées visitées

• Entrées retournées

Toutefois, des données clés sont manquantes dans l’événement, comme le temps passé sur l’opération de recherche et l’index (le cas échéant) utilisé.

Statistiques de recherche supplémentaires ajoutées à l’événement 1644

• Index utilisés

• Pages référencées

• Pages lues à partir du disque

• Pages pré-lues à partir du disque

• Pages propres modifiées

• Pages incorrectes modifiées

• Heure de recherche

• Attributs empêchant l’optimisation

Nouvelle valeur de Registre de seuil basé sur le temps pour la journalisation de l’événement 1644

Au lieu de spécifier les valeurs de seuil des résultats de recherche coûteux et inefficaces, vous pouvez spécifier le seuil de temps de recherche. Si vous souhaitez enregistrer tous les résultats de recherche qui ont pris 50 ms ou plus, vous devez spécifier 50 (décimal)/32 (hex) (en plus de définir la valeur Field Engineering).

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Search Time Threshold (msecs)"=dword:00000032

Comparaison de l’ancien et du nouvel ID d’événement 1644

OLD

NEW

Try This : utiliser le journal des événements pour retourner des statistiques de requête

1. Répétez les opérations suivantes pour cibler votre contrôleur de domaine Windows Server 2012 et votre contrôleur de domaine Windows Server 2012 R2. Observez les ID d’événement 1644 sur les deux contrôleurs de domaine après chaque recherche.

2. À l’aide de regedit, activez la journalisation de l’ID d’événement 1644 à l’aide d’un seuil basé sur le contrôleur de domaine Windows Server 2012 R2 et de l’ancienne méthode sur le contrôleur de domaine Windows Server 2012.

3. Effectuez plusieurs recherches LDAP qui dépassent le seuil et observez les informations statistiques en haut des résultats. Utilisez les requêtes LDAP que vous avez documentées précédemment et répétez les mêmes recherches.

4. Effectuez une recherche LDAP que l’optimiseur de requête n’est pas en mesure d’optimiser, car un ou plusieurs attributs ne sont pas indexés.

Amélioration du débit de réplication Active Directory

Vue d’ensemble

La réplication AD utilise RPC pour son transport de réplication. Par défaut, RPC utilise une mémoire tampon de transmission de 8 Ko et une taille de paquet de 5 Ko. Cela a pour effet net que l’instance d’envoi transmet trois paquets (environ 15 000 de données), puis doit attendre un aller-retour réseau avant d’en envoyer davantage. En supposant un temps d’aller-retour de 3 ms, le débit le plus élevé serait d’environ 40 Mbits/s, même sur les réseaux 1 Gbit/s ou 10 Gbits/s.

Cette mise à jour augmente le débit maximal à environ 600 Mbits/s en modifiant la taille de la mémoire tampon d’envoi RPC de 8 Ko à 256 Ko. Cette modification permet à la taille de la fenêtre TCP d’augmenter au-delà de 8 Ko, ce qui réduit le nombre d’allers-retours réseau.

Ressources supplémentaires

Fonctionnement du modèle de réplication Active Directory