Cette analyse émet une alerte quand la condition Nombre maximal d'API simultanées est atteinte.
Si des clients connaissent des interruptions au niveau de l'authentification Windows, d'Exchange, de SharePoint + LOB à cause de la valeur par défaut faible de MaxConcurrentAPI, qui est un plafond pour le nombre maximal de validations de mot de passe PAC NTLM ou Kerberos qu'un serveur peut gérer simultanément,
Considérez le scénario suivant :
Vous avez une ou plusieurs forêts qui disposent de plusieurs domaines.
Il existe des combinaisons d'utilisateurs et de ressources (telles que des applications ou des serveurs proxy) dans des domaines différents.
Les utilisateurs d'un domaine distant envoient un grand nombre de demandes d'ouverture de session NTLM à un serveur de ressources qui exécute Windows Server.
Dans ce scénario, le NTLM demande une expiration du délai d'attente. Par exemple, les clients Exchange ne s'authentifient pas sur le serveur Exchange quand ce problème se produit. Par conséquent, les utilisateurs ne peuvent pas accéder à leurs boîtes aux lettres, et Microsoft Outlook semble cesser de répondre.
Ce problème se produit, car la limitation de l'API NTLM est atteinte.
La prolifération des dispositifs générant une charge au niveau de l'authentification conduit à une augmentation du nombre de pannes dans les grandes organisations.
Les économies d'échelle obtenues par le cloud surchargent l'infrastructure Windows qui exploite Active Directory.
BPOS et Office 365 ont déjà augmenté cette valeur à 10 et 150 respectivement. Un correctif de Registre a été largement déployé via des engagements de cas CSS.
Augmentez la valeur de Registre MaxConcurrentApi sur le ou les serveurs qui constatent le problème. Pour modifier le paramètre MaxConcurrentApi, procédez comme suit :
1. Cliquez sur Démarrer, sur Exécuter, tapez « regedit », puis cliquez sur OK.
2. Recherchez la sous-clé de Registre suivante, puis cliquez dessus :
3. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
4. Dans le menu Edition, pointez sur Nouveau, puis cliquez sur Valeur DWORD.
5. Tapez « MaxConcurrentApi » et appuyez sur Entrée.
6. Dans le menu Edition, cliquez sur Modifier.
7. Tapez le nouveau paramètre MaxConcurrentApi en décimal, puis cliquez sur OK.
8. À l'invite de commandes, tapez la commande suivante et appuyez sur Entrée :
9. net stop netlogon
10. Entrez la commande suivante, puis appuyez sur Entrée :
11. net start netlogon
Vérifiez que le réseau entre le serveur et ses contrôleurs de domaine (ou contrôleurs de domaine approuvé, si la condition a été vue sur un contrôleur de domaine) ne subit aucune latence. Une latence du réseau peut provoquer ou aggraver le problème.
Pour les applications et services qui utilisent NTLM, il suffit de les configurer pour utiliser l'authentification Kerberos à la place. Les méthodes à suivre sont uniques à ces applications.
Si la validation PAC Kerberos est considérée comme un symptôme, désactivez la validation PAC Kerberos si le service le permet. Cette opération doit être effectuée sur le serveur sur lequel apparaît l'événement de système Kerberos 7.
Remarque : La validation PAC Kerberos ne peut pas être désactivée pour les pools d'applications IIS ou pour certains services liés à Exchange.
Remarque : Pour déterminer la valeur à définir pour le paramètre MaxConcurrentApi dans votre environnement, reportez-vous à l'article de Base de connaissances ci-dessous.
Knowledge Base Article: 2688798
Comment effectuer le réglage des performances pour l'authentification NTLM en utilisant le paramètre MaxConcurrentApi.
Plus d'informations
Pour plus d'informations à ce sujet, consultez l'article TechNet ci-dessous. Configuring MaxConcurrentAPI for NTLM Pass-Through Authentication (Configuration de MaxConcurrentAPI pour l'authentification directe NTLM).
Target | Microsoft.Windows.Server.10.0.OperatingSystem | ||
Parent Monitor | System.Health.AvailabilityState | ||
Category | StateCollection | ||
Enabled | True | ||
Alert Generate | True | ||
Alert Severity | MatchMonitorHealth | ||
Alert Priority | Normal | ||
Alert Auto Resolve | True | ||
Monitor Type | Microsoft.Windows.Server.MaxConcurrentAPI.MonitorType | ||
Remotable | True | ||
Accessibility | Public | ||
Alert Message |
| ||
RunAs | System.PrivilegedMonitoringAccount |
<UnitMonitor ID="Microsoft.Windows.Server.10.0.MaxConcurrentAPI.Monitor" Accessibility="Public" Enabled="true" Target="ServervNext!Microsoft.Windows.Server.10.0.OperatingSystem" ParentMonitorID="SystemHealth!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="WindowsServer!Microsoft.Windows.Server.MaxConcurrentAPI.MonitorType" ConfirmDelivery="false" RunAs="System!System.PrivilegedMonitoringAccount">
<Category>StateCollection</Category>
<AlertSettings AlertMessage="Microsoft.Windows.Server.10.0.MaxConcurrentAPI.Monitor.AlertMessage">
<AlertOnState>Error</AlertOnState>
<AutoResolve>true</AutoResolve>
<AlertPriority>Normal</AlertPriority>
<AlertSeverity>MatchMonitorHealth</AlertSeverity>
<AlertParameters>
<AlertParameter1>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</AlertParameter1>
</AlertParameters>
</AlertSettings>
<OperationalStates>
<OperationalState ID="MaxConcurrentAPIAvailable" MonitorTypeStateID="Success" HealthState="Success"/>
<OperationalState ID="MaxConcurrentAPIReached" MonitorTypeStateID="Error" HealthState="Error"/>
</OperationalStates>
<Configuration>
<DiagnosticMode>0</DiagnosticMode>
<IntervalSeconds>900</IntervalSeconds>
<SyncTime/>
<TimeoutSeconds>300</TimeoutSeconds>
<ThresholdWaiters>50</ThresholdWaiters>
<ThresholdTimeouts>2000</ThresholdTimeouts>
</Configuration>
</UnitMonitor>