Mises à jour du composant Directory Services
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Auteur : Justin Turner, ingénieur support senior d’escalade auprès du groupe Windows
Notes
Ce contenu est écrit par un ingénieur du support client Microsoft et est destiné aux administrateurs expérimentés et aux architectes système qui recherchent des explications techniques plus approfondies des fonctionnalités et des solutions Windows Server 2012 R2 que n'en proposent généralement les rubriques de TechNet. Toutefois, il n'a pas subi les mêmes passes de correction. De ce fait, une partie du langage peut sembler moins finalisée que le contenu de TechNet.
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
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 :
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.
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
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.
Notes
La dépréciation de FRS s’effectue en supprimant la possibilité d’installer un nouveau domaine avec un niveau fonctionnel de domaine inférieur à Windows Server 2008 avec le Gestionnaire de serveur ou via Windows PowerShell.
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.
Sch59
Sch61
Sch62
Sch63
Sch64
Sch65
Sch67
Dossiers de travail :
- Sch66
MSODS :
- Sch60
Silos et stratégies d’authentification
Sch68
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.
Remarque
Du développeur :amélioration des performances des recherches grâce à des améliorations dans le mappage de la requête LDAP à la requête ESE. Les filtres LDAP au-delà d’un certain niveau de complexité empêchent la sélection d’index optimisée, qui réduit considérablement les performances (1 000x ou plus). Cette modification modifie la façon dont nous sélectionnons les index pour les requêtes LDAP afin d’éviter ce problème.
Remarque
Une révision complète de l’algorithme de l’optimiseur de requête LDAP, avec les résultats suivants :
- Temps de recherche plus rapides
- Des gains d’efficacité permettant aux contrôleurs de domaine d’en faire plus
- Moins d’appels de support concernant les problèmes de performances d’AD
- Rétro-portage vers Windows Server 2008 R2 (KB 2862304)
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 :
Simplifiez le filtre de recherche si possible.
Sélectionnez un ensemble de clés d’index qui retourne le plus petit ensemble couvert.
Effectuez une ou plusieurs intersections de clés d’index pour réduire l’ensemble couvert.
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
Ouvrez LDP.exe, puis connectez-vous et liez-vous à un contrôleur de domaine.
Dans le menu Options, sélectionnez Contrôles.
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.
Dans le menu Parcourir, sélectionnez Rechercher
Dans la boîte de dialogue Rechercher, sélectionnez le bouton Options.
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.
Consultez l’article « Création d’applications plus efficaces avec Microsoft AD » et reportez-vous à cet article si nécessaire.
À l’aide de LDP, activez les statistiques de recherche (consultez Activer le contrôle Stats dans LDP)
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.
Effectuer une recherche LDAP que l’optimiseur de requête doit être en mesure d’optimiser en raison des index d’attributs
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.
Remarque
- Des statistiques de recherche LDAP supplémentaires sont ajoutées à l’ID d’événement 1644 pour vous aider à résoudre les problèmes liés aux recherches LDAP inefficaces ou coûteuses
- Vous pouvez maintenant spécifier un seuil de temps de recherche (par exemple Événement de journal 1644 pour les recherches prenant plus de 100 ms) au lieu de spécifier les valeurs de seuil des résultats de recherche coûteux et inefficaces
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
Nouveau...
Try This : utiliser le journal des événements pour retourner des statistiques de requête
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.
À 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.
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.
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.
Remarque
Cette mise à jour remplace le débit de réplication Active Directory maximal de 40 Mbits/s par 600 Mbits/s environ.
- Cela augmente la taille de la mémoire tampon d’envoi RPC, ce qui réduit le nombre d’allers-retours réseau
L’effet sera le plus notable sur un réseau à haut débit et à latence élevée.
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.
Notes
Il n’existe aucun paramètre configurable pour modifier ce comportement.