Guide pratique pour optimiser les performances pour l’authentification NTLM à l’aide du paramètre MaxConcurrentApi

Cet article explique comment optimiser les performances pour l’authentification NTLM à l’aide du paramètre MaxConcurrentApi.

S’applique à : Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 2688798

Introduction

Une augmentation de la consommation des technologies de l’information d’entreprise (augmentation du nombre d’appareils destinés aux consommateurs tels que les smartphones et les tablettes utilisés dans l’entreprise) a conduit à augmenter le nombre de scénarios dans lesquels les entreprises peuvent rencontrer une augmentation importante de l’authentification héritée dans leurs environnements d’entreprise. Cette augmentation de l’authentification héritée peut entraîner des problèmes de performances tels que des retards ou des délais d’attente pour les clients.

Lorsque vous découvrez des délais d’expiration ou des retards d’authentification (également appelés goulots d’étranglement MaxConcurrentApi) dans un environnement, le moyen classique de résoudre le problème consiste à déclencher le nombre maximal de threads de travail autorisés qui service cette authentification. Pour ce faire, modifiez la valeur de Registre MaxConcurrentApi, puis redémarrez le service Net Logon sur les serveurs.

Il peut être difficile d’identifier les serveurs victimes du goulot d’étranglement et les serveurs qui sont réellement à l’origine des retards de goulot d’étranglement. Cet article explique comment optimiser les performances pour l’authentification NT LAN Manager (NTLM) à l’aide du paramètre MaxConcurrentApi. Cet article contient des conseils pour les administrateurs sur l’identification des serveurs sur lesquels la valeur MaxConcurrentApi doit être levée et la quantité à laquelle cette valeur doit être définie.

Résolution

Pour résoudre ce problème, vous devez passer en revue les données de performances qui ont été extraites de tous les serveurs impliqués dans le scénario. Ensuite, vous pouvez essayer d’augmenter le paramètre MaxConcurrentApi sur les serveurs qui affichent une perte de performances.

Il existe Netlogon des événements disponibles qui signalent des problèmes d’authentification NTLM. Consultez :
2654097 Nouvelles entrées du journal des événements qui effectuent le suivi des retards et des échecs d’authentification NTLM dans Windows Server 2008 R2 sont disponibles

Les événements indiquent l’activité pour deux compteurs :

• Événements 5818/5819 : Il existe des « serveurs de sémaphore », si les événements sont activés.
• Événements 5816/5817 : Il existe des « délais d’expiration du sémaphore ».

Afin de déterminer la meilleure valeur MaxConcurrentApi pour vos serveurs, plusieurs points de données doivent être rassemblés et calculés à l’aide d’une formule. Les données à utiliser pour estimer MaxConcurrentApi sont les suivantes :

• Net Logon sémaphore acquiert
• Sémaphore Net Logon time-outs
• Temps de conservation moyen du sémaphore Net Logon
• Durée de la journalisation des performances terminée, mesurée en secondes

Une fois les données obtenues, la formule suivante peut être utilisée pour estimer la valeur MaxConcurrentApi correcte :(semaphore_acquires + semaphore_time-outs) * average_semaphore_hold_time / time_collection_length = <New_MaxConcurrentApi_setting
Après avoir collecté les données de performances Net Logon à partir du moment où le serveur était sous charge d’authentification, vous devez déterminer la durée du processus de collecte de données en examinant les heures de début et de fin de l’affichage en ligne.

La durée moyenne de conservation du sémaphore peut être déterminée en modifiant l’affichage par défaut de l’affichage En ligne à l’affichage Rapport dans Perfmon.msc. Par exemple, envisagez le scénario suivant :

• La valeur du sémaphore est 8 286.
• La valeur des délais d’expiration du sémaphore est 883.
• La durée moyenne de conservation du sémaphore est .5 (c’est-à-dire, une demi-seconde).
• La durée de création de rapports est de 90 secondes.

Dans ce scénario, la formule serait la suivante :
(8 286 + 883) *.5 / 90 =< 51

Si la valeur dérivée de la formule est supérieure ou égale à 150, vous devez ajouter d’autres serveurs pour traiter la charge d’authentification héritée.

Si la valeur est inférieure à 150, vous devez remplacer la valeur de Registre MaxConcurrentApi sur ce serveur par la valeur suggérée par la formule ou par une valeur plus élevée.

Pour modifier le paramètre MaxConcurrentApi, procédez comme suit :

1. Cliquez sur Démarrer, puis sur Exécuter, tapez regedit, puis cliquez sur OK.

2. Recherchez la sous-clé de Registre suivante, puis cliquez dessus : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

3. Dans le menu Edition, pointez sur Nouveau, puis cliquez sur Valeur DWORD.

4. Tapez MaxConcurrentApi, puis appuyez sur Entrée.

5. Dans le menu Edition, cliquez sur Modifier.

6. Tapez le nouveau paramètre MaxConcurrentApi dans decimal, puis cliquez sur OK.

7. À l’invite de commandes, tapez la commande suivante, puis appuyez sur Entrée :
   net stop netlogon

8. Tapez la commande suivante, puis appuyez sur Entrée :
   net start netlogon

Plus d’informations

Vous pouvez utiliser l’article suivant de la Base de connaissances pour identifier plus en détail les symptômes côté client des goulots d’étranglement d’authentification hérités :
975363 Vous êtes invité par intermittence à entrer des informations d’identification ou des délais d’attente lorsque vous vous connectez aux services authentifiés Le goulot d’étranglement d’authentification peut se trouver sur plusieurs serveurs dans le scénario. Par conséquent, vous devez vous assurer que tous les serveurs dans un scénario donné ont leurs données de performances examinées pendant qu’ils sont occupés à traiter des charges lourdes.

Les compteurs pour l’acquisition de sémaphore, pour les délais d’attente du sémaphore et pour le temps de conservation moyen du sémaphore doivent être examinés sur tous les serveurs d’applications, contrôleurs de domaine et contrôleurs de domaine approuvés impliqués dans la maintenance des demandes client.

Les données de performances doivent être suivies pendant que les serveurs sont soumis à une charge importante. Une charge importante se produit lorsque les serveurs voient le plus de demandes client. Par exemple, dans un scénario de serveur de messagerie, le meilleur moment pour collecter les données de performances est quand les utilisateurs arrivent au travail et case activée leurs messages électroniques.

Les éléments supplémentaires à prendre en considération sont les suivants :

• Aucune valeur signifie qu’aucune action n’est nécessaire. Les compteurs Sémaphore Holders et Sémaphore Hold Time n’affichent aucune valeur, sauf s’il y a une charge soutenue sur un serveur. Si aucune valeur n’est présente, aucune modification de la valeur MaxConcurrentApi n’est nécessaire.

• Une taille ne convient pas à tous. La valeur MaxConcurrentApi peut être différente pour chaque serveur. Cette situation peut être due à l’authentification de plusieurs serveurs d’applications auprès d’un seul contrôleur de domaine ou à des scénarios similaires dans lesquels plusieurs serveurs fournissent un volume de charge plus important avec lequel le contrôleur de domaine doit traiter.

• Fiducies. Si les utilisateurs qui sont authentifiés proviennent de domaines approuvés, cela peut entraîner des retards plus longs, car le contrôleur de domaine local doit attendre la réponse du contrôleur de domaine approuvé avant que le contrôleur de domaine local fournisse la réponse au serveur d’applications.

• Latence du réseau. La latence du réseau peut également jouer un rôle majeur dans la cause des goulots d’étranglement MaxConcurrentApi. Ce problème peut se produire lorsque le sémaphore MaxConcurrentApi utilise un compteur de délai d’attente basé sur le temps afin que les clients n’attendent pas indéfiniment l’authentification héritée.

• Collocation. Si la latence du réseau existe et provoque des retards et des goulots d’étranglement lors de l’exécution des threads MaxConcurrentApi, une solution courante consiste à placer les serveurs au même emplacement physique afin de réduire la latence réseau. Dans un modèle de domaine dans lequel un domaine approuvé a des serveurs CAS Microsoft Exchange, par exemple, et le domaine de l’utilisateur se trouve dans une autre région ou un autre site Active Directory, cela signifie que les contrôleurs de domaine de l’utilisateur sont situés dans le même emplacement physique et le même site Active Directory que les serveurs d’administration centrale Exchange et leurs contrôleurs de domaine.

• Retard possible en aval. Si la valeur du compteur Sémaphore Waiters est continuellement supérieure à 0 (zéro) pour un moment donné et que la valeur des sémaphores Holders est inférieure au paramètre MaxConcurrentApi sur ce serveur, le goulot d’étranglement ne se trouve pas sur ce serveur. Dans ce cas, recherchez le contrôleur de domaine qui est cité dans le nom du compteur répertorié comme nom de domaine complet de l’ordinateur hôte. Les données de performances des serveurs de sémaphore et des titulaires de sémaphore de ce contrôleur de domaine doivent être examinées.

• Modifications de la charge ou de la configuration réseau. Les modifications ultérieures apportées à la charge en cours de maintenance ou aux configurations réseau peuvent produire une latence réseau et nécessiter une nouvelle évaluation du paramètre MaxConcurrentApi correct. Pour les environnements dans lesquels le volume d’authentification hérité est vu dans la mesure où les paramètres MaxConcurrentApi sont examinés, nous vous recommandons vivement de surveiller et d’examiner en permanence les compteurs d’objets de performance Net Logon. Vous pouvez le faire à l’aide de collecteurs de données Perfmon.msc personnalisés planifiés, à l’aide de Microsoft System Center Operations Manager ou d’autres méthodes.

• Windows Server 2008 maximum. Le paramètre maximal autorisé pour MaxConcurrentApi dans Windows Server 2008 et dans les versions ultérieures de Windows est 150. Appliquez le correctif logiciel décrit dans l’article suivant de la Base de connaissances pour avoir le paramètre 150 maximum disponible si le serveur que vous utilisez n’exécute pas Windows Server 2008 R2 :
  975363 Vous êtes invité par intermittence à entrer des informations d’identification ou des délais d’expiration lorsque vous vous connectez aux services authentifiés

• Windows Server 2003 maximum. Le paramètre maximal autorisé pour MaxConcurrentApi dans Windows Server 2003 et dans les versions antérieures est 10.

• Windows Server 2012 et versions ultérieures Par défaut. La valeur par défaut de MaxConcurrentApi a été modifiée dans Windows Server 2012. Il est de 10 pour les serveurs membres et les contrôleurs de domaine. Il reste à 1 pour les stations de travail membres.

• Windows Server 2003 et compteurs de performances. La version d’origine de Windows Server 2003 ne contenait pas les compteurs de performances Net Logon. Vous pouvez appliquer un correctif logiciel pour l’ajouter.

L’identification des clients ou services non autorisés ou inconnus qui effectuent une authentification NTLM répétée et continue peut être utile lorsque vous souhaitez réduire la charge globale de l’authentification NTLM et, par conséquent, réduire le nombre d’utilisations du sémaphore MaxConcurrentApi. L’authentification répétée de cette manière peut être identifiée à l’aide de la journalisation de débogage du service Net Logon. Pour plus d’informations sur l’utilisation du fichier Netlogon.log pour déboguer le service Net Logon, cliquez sur le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :
109626 Activation de la journalisation du débogage pour le service Net Logon

Le compteur Perfmon.msc pour les authentifications NTLM sous l’objet Security System-Wide Statistics ne reflète pas le nombre d’utilisations du thread suivi MaxConcurrentApi. Il n’existe aucune corrélation un-à-un entre l’utilisation du sémaphore MaxConcurrentApi affichée dans le compteur de performances Net Logon et les incréments du compteur d’authentification NTLM. Le compteur d’authentification NTLM n’est pas utile pour déterminer la meilleure valeur MaxConcurrentApi.

En outre, il est probable que les délais d’expiration des performances d’authentification hérités liés à MaxConcurrentApi soient affichés, mais pas reflétés dans un compteur de performances autre que le compteur Net Logon. Cela signifie que d’autres métriques de performances, telles que l’utilisation du processeur et l’utilisation du disque et du réseau, peuvent ne pas afficher de charge, même si la charge MaxConcurrentApi est importante et que les utilisateurs rencontrent des problèmes.

Une procédure de réduction supplémentaire peut être effectuée sur les contrôleurs de domaine qui ont des entrées dans leur journal de débogage du service Net Logon qui indiquent que les clients envoient <null>\username au lieu de domainname\username. Cette procédure est décrite dans l’article suivant de la Base de connaissances Microsoft :
923241 Le processus Lsass.exe peut cesser de répondre si vous avez de nombreuses approbations externes sur un contrôleur de domaine Active Directory