Comment effectuer le réglage des performances pour l’authentification NTLM à l’aide du paramètre MaxConcurrentApi

Cet article explique comment effectuer le réglage des performances pour l’authentification NTLM à l’aide du paramètre MaxConcurrentApi.

Numéro de base de connaissances d’origine : 2688798

Introduction

Une augmentation de la consommation des technologies de l’information d’entreprise (augmentation des appareils orientés consommateurs tels que les smartphones et tablettes utilisés dans l’entreprise) a entraîné l’augmentation du nombre de scénarios dans lesquels les entreprises peuvent rencontrer une forte augmentation 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, la façon classique de résoudre le problème consiste à augmenter le nombre maximal de threads de travail autorisés qui authentification. Pour ce faire, modifiez la valeur de Registre MaxConcurrentApi, puis redémarrez le service Net Logon sur les serveurs.

L’identification des serveurs victimes du goulot d’étranglement et des serveurs qui sont en fait la source des retards de goulot d’étranglement peut être difficile. Cet article explique comment effectuer le réglage des performances pour l’authentification NT LAN Manager (NTLM) à l’aide du paramètre MaxConcurrentApi. Cet article contient des conseils pour les administrateurs qui identifient les serveurs sur lesquels déclencher la valeur MaxConcurrentApi 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 extraites de tous les serveurs impliqués dans le scénario. Ensuite, vous pouvez essayer d’augmenter le paramètre MaxConcurrentApi sur ces serveurs qui montrent une perte de performances.

Des événements sont Netlogon disponibles pour signaler 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 ».

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

• Net Logon sémaphore acquiert
• Délais d’expiration du sémaphore Net Logon
• Temps d’attente de la sémaphore moyenne de connexion net
• 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 <
Une fois que vous avez collecté les données de performances net de connexion à partir du moment où le serveur était sous charge d’authentification, vous devez déterminer la durée du processus de collecte des données en examinant les heures de début et de fin de l’affichage de ligne.

Le temps d’attente moyen du sémaphore peut être déterminé en modifiant l’affichage par défaut de l’affichage de ligne en mode Rapport dans Perfmon.msc. Par exemple, examinez le scénario suivant :

• Le sémaphore acquiert la valeur 8 286.
• La valeur des délais d’expiration du sémaphore est 883.
• Le temps moyen de conservation du sémaphore est .5 (autrement dit, 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 de 150 ou plus, vous devez ajouter d’autres serveurs pour traiter la charge d’authentification héritée.

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

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 Modifier , cliquez sur Modifier.

6. Tapez le nouveau paramètre MaxConcurrentApi en décimal, 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 les symptômes côté client des goulots d’étranglement d’authentification hérités plus en détail :
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 de l’authentification peut se trouver sur plusieurs serveurs dans le scénario. Par conséquent, vous devez vous assurer que tous les serveurs d’un scénario donné ont leurs données de performances examinées pendant qu’ils sont occupés à assurer la maintenance de charges lourdes.

Les compteurs pour l’acquisition du sémaphore, pour les délais d’expiration du sémaphore et pour le temps d’attente 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 clientes.

Les données de performances doivent être suivies pendant que les serveurs sont sous une charge importante. Une charge importante se produit lorsque les serveurs voient la plupart des demandes clientes. Par exemple, dans un scénario de serveur de messagerie, le meilleur moment pour collecter les données de performances est le moment où les utilisateurs arrivent au travail et vérifient leurs messages électroniques.

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

• Aucune valeur ne signifie qu’aucune action n’est nécessaire. Les compteurs de temps de conservation des sémaphores et des titulaires de sémaphore n’affichent aucune valeur, sauf s’il existe 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 une valeur différente pour chaque serveur. Cette situation peut être causée par plusieurs serveurs d’applications qui obtiennent l’authentification à partir d’un seul contrôleur de domaine ou par des scénarios similaires dans lesquels plusieurs serveurs fournissent un plus grand volume de charge 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 réseau peut également jouer un rôle majeur dans l’origine 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 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 dans le même emplacement physique afin que la latence du réseau soit réduite. 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 site Active Directory, cela signifierait placer les contrôleurs de domaine de l’utilisateur 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.

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

• Modifications de la charge ou de la configuration réseau. Les modifications à venir dans la charge en cours de service ou dans les configurations réseau peuvent produire une latence réseau et peuvent entraîner une nécessité de évaluer à nouveau le paramètre MaxConcurrentApi approprié. 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 à l’aide d’autres méthodes.

• Maximum de Windows Server 2008. 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 à des services authentifiés

• Maximum de Windows Server 2003. 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 s’agit de 10 serveurs membres et contrôleurs de domaine. Il reste à 1 pour les stations de travail membres.

• Compteurs de performances et Windows Server 2003. 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 de clients ou de 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 d’authentification NTLM globale et, par conséquent, diminuer 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 du débogage du service d’ouverture de session Net. 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 d’ouverture de session Net

Le compteur Perfmon.msc pour les authentifications NTLM sous l’objet Statistiques à l’échelle du système de sécurité n’est pas une réflexion sur le nombre d’utilisations du thread suivi MaxConcurrentApi. Il n’existe aucune corrélation un-à-un entre l’utilisation du sémaphore MaxConcurrentApi qui est 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 sont visibles, mais pas répercutés dans un compteur de performances autre que le compteur d’ouverture de session net. Cela signifie que d’autres métriques de performances, telles que l’utilisation du processeur et le disque et l’utilisation 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 de Lsass.exe peut cesser de répondre si vous avez de nombreuses approbations externes sur un contrôleur de domaine Active Directory