SharePoint SE : Guide de dépannage des 7 erreurs fatales d'authentification NTLM

En 2026, l'authentification NTLM ne devrait plus avoir sa place sur une infrastructure critique. Ce protocole historique de Microsoft souffre de défauts majeurs :

1. Performance : Il est beaucoup plus lent que Kerberos.

2. Sécurité : Il est intrinsèquement vulnérable aux attaques par relais (NTLM Relay) et par force brute.

3. Inflexibilité : Il gère très mal les extranets, la traversée de pare-feux complexes, et offre une expérience désastreuse sur les clients mobiles (iOS/iPad) qui ne sont pas joints au domaine. Si vos utilisateurs Apple sont bombardés de fenêtres de connexion (prompts), c'est NTLM le coupable.

La véritable architecture de sécurité moderne (Zero Trust) exige de basculer vers des fournisseurs d'identités approuvés via SAML ou WS-Fed (comme AD FS ou Microsoft Entra ID), ou a minima vers Kerberos.

Pourtant, NTLM reste le choix par défaut de nombreux administrateurs car il s'active d'un simple clic dans l'Administration Centrale de SharePoint, sans configuration préalable complexe. Mais lorsque NTLM casse, le diagnostic est un enfer. Dans SharePoint, les erreurs d'authentification se manifestent de deux façons :

• Un blocage total (Code HTTP 401 – Access Denied).

• Des fenêtres de connexion (pop-ups) aléatoires en pleine navigation.

Le secret du dépannage NTLM ? Le problème est presque toujours externe à SharePoint. Tout se joue dans IIS, Active Directory, le réseau ou la stratégie de sécurité de l'OS (GPO). Voici l'analyse détaillée des 7 causes majeures d'échecs NTLM et comment les résoudre.

1. La mécanique interne : Le "Handshake" NTLM

Avant de dépanner, il faut comprendre la négociation (Challenge/Response) qui s'opère en une fraction de seconde :

1. Le client demande l'accès (Anonyme).

2. Le serveur (IIS) refuse et envoie un défi mathématique, le Challenge (Erreur 401.1 avec entête WWW-Authenticate: NTLM).

3. Le client chiffre ce défi avec son mot de passe et le renvoie (Response).

4. Le serveur transmet cette réponse au contrôleur de domaine (via le service Netlogon) pour validation.

2. Deep Dive : Les 7 causes d'échec de l'authentification NTLM

Erreur n°1 : Le Load Balancer casse le Handshake (Manque d'affinité)

• Le contexte : Vous possédez plusieurs serveurs Web Front-End (WFE) derrière un répartiteur de charge (F5, Kemp, etc.).

• Le problème : L'utilisateur "Alice" entame le dialogue avec le WFE-1 (qui génère le Challenge). Mais au moment où Alice envoie sa réponse, l'équilibreur de charge route le paquet vers le WFE-2. Le WFE-2, n'ayant jamais émis ce défi, rejette logiquement la réponse. L'authentification échoue.

• La solution : Malgré l'arrivée du Distributed Cache, NTLM exige absolument la persistance de session (Sticky Sessions ou Affinity). Configurez votre répartiteur de charge pour maintenir le client sur le même WFE tout au long de sa session TCP.

Erreur n°2 : Blocage par la Stratégie de Sécurité Locale (Logon Type 3)

• Le contexte : Les utilisateurs sont violemment rejetés avec des erreurs "Accès refusé".

• Le problème : L'authentification réseau sous Windows est de type 3 (Logon Type 3). Si une GPO restrictive s'applique aux serveurs WFE, IIS bloquera l'utilisateur.

• La solution : Ouvrez l'Observateur d'événements du WFE (Journal de Sécurité) et cherchez les événements d'échec d'audit. Lancez ensuite secpol.msc sur le serveur. Dans Stratégies locales > Attribution des droits utilisateur, vérifiez que les utilisateurs/groupes figurent dans Accéder à cet ordinateur à partir du réseau et qu'ils ne sont pas listés dans Interdire l'accès à cet ordinateur à partir du réseau.

Erreur n°3 : La guerre des versions (LmCompatibilityLevel)

• Le contexte : Échecs systématiques pour certains clients ou depuis certains réseaux.

• Le problème : Le client, le serveur SharePoint et le contrôleur de domaine ne parviennent pas à se mettre d'accord sur la version de NTLM à utiliser (LM, NTLMv1, NTLMv2).

• La solution : La clé de registre LmCompatibilityLevel (située dans HKLM\SYSTEM\CurrentControlSet\Control\Lsa) dicte ce comportement. Cette valeur doit être homogénéisée (idéalement fixée à 5 par GPO sur toute l'entreprise, pour forcer NTLMv2 et refuser les anciens protocoles).

Erreur n°4 : Problème DNS ou d'approbation de domaine (Erreur 2148074257)

• Le contexte : Concerne souvent les utilisateurs issus de domaines approuvés (Forêts distantes).

• Le problème : Dans vos logs IIS (situés dans C:\inetpub\logs\LogFiles), l'ultime requête NTLM se solde par un code 401.1 avec un sous-statut IIS sc-win32-status de 2148074257 (SEC_E_NO_AUTHENTICATING_AUTHORITY).

• La solution : Le WFE SharePoint ne parvient pas à contacter un contrôleur de domaine autorité pour ce domaine distant. Vous devez corriger votre topologie DNS (Redirecteurs conditionnels) et valider l'intégrité de vos relations d'approbation Active Directory.

Erreur n°5 : Le goulot d'étranglement MaxConcurrentApi

• Le contexte : Dans les grands environnements (ou lors de pics de charge), les utilisateurs reçoivent des pop-ups aléatoires.

• Le problème : Il existe un nombre limité de canaux (threads) alloués au service Netlogon pour traiter les authentifications NTLM simultanées sur les WFE et les DC. Lorsque cette limite est atteinte, les requêtes partent en "timeout".

• L'astuce d'architecture : Sur les sites SharePoint natifs, réduisez le volume de requêtes NTLM en plaçant tous les fichiers de conception (CSS, JS, images) dans des répertoires accessibles de manière anonyme (comme le dossier _layouts). Une seule page peut générer 20 requêtes d'authentification NTLM si ces éléments sont stockés dans des bibliothèques de documents sécurisées.

• La vraie solution : Passez à Kerberos (qui soulage drastiquement Netlogon) ou augmentez la valeur de registre MaxConcurrentApi.

Erreur n°6 : L'Approbation Sélective (Erreur 2148074252 / 0xC0000413)

• Le contexte : Les utilisateurs locaux se connectent, mais ceux d'un domaine approuvé échouent systématiquement.

• Le problème : Les logs IIS révèlent un statut 401.1 avec l'erreur 2148074252 (SEC_E_LOGON_DENIED), et l'Observateur d'événements affiche l'erreur 0xC0000413 (STATUS_AUTHENTICATION_FIREWALL_FAILED). Cela signifie que l'approbation de forêt est configurée en mode "Approbation Sélective" (Selective Authentication).

• La solution : Dans le domaine hébergeant SharePoint, ouvrez la console Utilisateurs et ordinateurs AD, accédez aux propriétés des comptes ordinateurs de vos serveurs WFE, onglet Sécurité, et octroyez explicitement l'autorisation Autorisé à s'authentifier (Allowed to Authenticate) aux utilisateurs distants.

Erreur n°7 : Changement d'IP Client en cours de Handshake (Erreur 2148074248)

• Le contexte : Similaire à l'erreur 1, mais causé par un Proxy ou un VPN côté client. Des pop-ups intermittents apparaissent.

• Le problème : Les logs IIS révèlent une erreur 2148074248 (SEC_E_INVALID_TOKEN). En analysant les lignes du log, on constate que l'IP cliente du premier "Challenge" est différente de l'IP cliente qui envoie la réponse. Pour des raisons de sécurité évidentes, IIS invalide le jeton si l'adresse IP source change en plein milieu de la négociation.

• La solution : Le problème se situe au niveau de l'infrastructure réseau (Reverse Proxy). Ce dernier doit être configuré pour conserver et injecter systématiquement la même IP cliente (via X-Forwarded-For) ou substituer la sienne de manière parfaitement constante tout au long de la session de l'utilisateur.

3. Le Script d'analyse IIS pour NTLM

La lecture des logs IIS à l'œil nu est une punition. Ce script PowerShell parcourt vos journaux IIS à la recherche des codes Win32 spécifiques aux échecs NTLM complexes (Trust, Proxy, Approbation Sélective).

<#
.SYNOPSIS
    Analyse approfondie des logs IIS pour extraire les sous-statuts d'échec NTLM.
#>

$LogDirectory = "C:\inetpub\logs\LogFiles\W3SVC*" # Adaptez selon le site IIS concerné
$StartDate = (Get-Date).AddDays(-1) # Analyse des dernières 24h

Write-Host "Lancement de l'audit des échecs NTLM dans les logs IIS..." -ForegroundColor Cyan

# Dictionnaire des erreurs Win32 fréquentes sous NTLM
$NTLMErrors = @{
    "2148074252" = "SEC_E_LOGON_DENIED (Erreur d'identifiants ou Approbation Sélective)"
    "2148074257" = "SEC_E_NO_AUTHENTICATING_AUTHORITY (Le WFE ne trouve pas le DC distant)"
    "2148074248" = "SEC_E_INVALID_TOKEN (Le jeton est invalide : Changement d'IP Client ?)"
}

# Collecte des fichiers journaux récents
$RecentLogs = Get-ChildItem -Path $LogDirectory -Include "*.log" -Recurse | Where-Object { $_.LastWriteTime -ge $StartDate }

foreach ($Log in $RecentLogs) {
    Write-Host "`nAnalyse du fichier : $($Log.Name)" -ForegroundColor Yellow
    
    # Filtrer les erreurs HTTP 401.1 (Non autorisé)
    $Failures = Select-String -Path $Log.FullName -Pattern " 401 1 " 
    
    foreach ($Line in $Failures) {
        $Columns = $Line.Line.Split(" ")
        # Recherche d'un code Win32 connu dans les colonnes du log W3C
        $FoundCode = $Columns | Where-Object { $NTLMErrors.Keys -contains $_ }
        
        if ($FoundCode) {
            $ClientIP = $Columns[8] # L'index IP peut varier selon le format W3C configuré
            $RequestUrl = $Columns[4]
            Write-Host "-> IP: $ClientIP | URL: $RequestUrl | Cause: $($NTLMErrors[$FoundCode])" -ForegroundColor Red
        }
    }
}
Write-Host "`nAudit IIS terminé. Consultez la documentation Microsoft pour résoudre les codes sc-win32-status." -ForegroundColor Green

Conclusion

Tant que vous maintiendrez NTLM sur votre ferme SharePoint SE, vous subirez ces effets de bord. Si ces stratégies de dépannage (Troubleshooting) permettent de stabiliser la production à court terme, la véritable valeur ajoutée d'un architecte système est de piloter l'obsolescence de ce protocole.

Privilégiez Kerberos pour vos accès intranet purs, et utilisez un Reverse Proxy moderne (comme Web Application Proxy - WAP) ou l'intégration native avec un fournisseur d'identité SAML/OIDC pour toutes les connexions externes et mobiles. C'est l'unique garantie d'un Single Sign-On fluide et sécurisé.