(Il s'agit d'une question sur un problème vague. J'essaie de présenter toutes les données pertinentes, dans l'espoir que quelqu'un ait des informations utiles ; mes excuses pour la longue description).
Notre application web
Nous avons une application web .NET 4 fonctionnant dans IIS 7.5 et accédant à Active Directory et à une base de données SQL Server.
Cette application Web est exécutée sous une "identité de pool d'applications" virtuelle, en définissant l'identité du pool d'applications de l'application comme suit ApplicationPoolIdentity . Une description concise des identités virtuelles peut être trouvée dans une réponse de StackOverflow L'identité d'un pool d'applications n'est qu'un groupe supplémentaire ajouté aux processus de travail de l'application web qui s'exécute en tant que "service réseau". Cependant, une source suggère vaguement que "Network Service et ApplicationPoolIdentity ont des différences que les documents du site IIS.net ne publient pas". Ainsi, une identité virtuelle pourrait être plus qu'un simple groupe supplémentaire.
Nous avons choisi d'utiliser ApplicationPoolIdentity, par opposition à NetworkService, parce qu'il est devenu la valeur par défaut dans IIS 7.5 (voir, par exemple, ici ), et selon la recommandation de Microsoft : "Cette identité permet aux administrateurs de spécifier des autorisations qui ne concernent que l'identité sous laquelle le pool d'applications s'exécute, ce qui renforce la sécurité du serveur." (de processModel Élément à ajouter pour applicationPools [schéma des paramètres IIS 7]. ) "Les identités de pool d'applications sont une nouvelle fonction d'isolation puissante" qui "rend l'exécution des applications IIS encore plus sûre et fiable. " (extrait de Article de IIS.net "Application Pool Identities" (en anglais) )
L'application utilise l'authentification intégrée de Windows, mais avec <identity impersonate="false"/> Ainsi, ce n'est pas l'identité de l'utilisateur final mais celle du pool d'applications virtuelles qui est utilisée pour exécuter notre code.
Cette application interroge Active Directory en utilisant le System.DirectoryServices c'est-à-dire l'API ADSI. Dans la plupart des cas, cela se fait sans spécifier un nom d'utilisateur/mot de passe supplémentaire ou d'autres informations d'identification.
Cette application se connecte également à une base de données SQL Server en utilisant Integrated Security=true dans la chaîne de connexion. Si la base de données est locale, alors nous voyons que IIS APPPOOL\OurAppPoolName est utilisé pour se connecter à la base de données ; si la base de données est distante, alors le compte machine OURDOMAIN\ourwebserver$ est utilisé.
Nos problèmes
Nous rencontrons régulièrement des problèmes où une installation fonctionnelle commence à échouer de l'une des manières suivantes.
-
Lorsque la base de données se trouve sur un système distant, alors la connexion à la base de données commence à échouer : "Echec de la connexion pour l'utilisateur 'NT AUTHORITY \ANONYMOUS LOGON'. Motif : La validation de l'accès au serveur par jeton a échoué avec une erreur d'infrastructure. Vérifiez les erreurs précédentes". L'erreur précédente est "Error : 18456, sévérité : 14, état : 11." Il semble donc que maintenant
OURDOMAIN\ourwebserver$n'est plus utilisé, mais un accès anonyme est tenté. (Nous avons des preuves anecdotiques que ce problème s'est produit lorsque l'UAC était désactivé, et qu'il a disparu après avoir activé l'UAC. Mais notez que la modification de l'UAC nécessite un redémarrage...) Un problème similaire est signalé dans IIS.net thread "use ApplicationPoolIdentity to connect to SQL" (utiliser ApplicationPoolIdentity pour se connecter à SQL) notamment dans une réponse . -
Les opérations Active Directory via ADSI (System.DirectoryServices) commencent à échouer avec l'erreur 0x8000500C ("Unknown Error"), 0x80072020 ("An operations error occurred."), ou 0x200B ("The specified directory service attribute or value does not exist").
-
La connexion à l'application depuis Internet Explorer commence à échouer, avec des erreurs HTTP 401. Mais si, dans IIS, nous plaçons NTLM avant Negotiate, cela fonctionne à nouveau. (Notez que l'accès à AD est nécessaire pour Kerberos mais pas pour NTLM.) Un problème similaire est rapporté dans Fil de discussion IIS.net "L'authentification de la fenêtre échoue avec l'identité AppPool". .
Notre hypothèse et notre solution de rechange
Au moins, les problèmes d'AD et d'ouverture de session semblent toujours disparaître lorsque l'on passe du pool d'applications ApplicationPoolIdentity au NetworkService. (Nous avons trouvé un rapport confirmant cela.)
Page "Dépannage des problèmes d'authentification sur les pages ASP" propose quelques suggestions concernant les jetons primaires et secondaires, et ce que je trouve encourageant, c'est qu'il établit un lien entre les deux premières de nos erreurs : il mentionne NT AUTHORITY\ANONYMOUS LOGON et les erreurs AD 0x8000500C et "L'attribut ou la valeur du service de répertoire spécifié n'existe pas".
(La même page mentionne également des problèmes de cache de schéma ADSI, mais tout ce que nous pouvons trouver sur ce sujet est ancien. Pour l'instant, nous considérons que ce n'est pas lié).
Sur la base de ce qui précède, notre travail actuel hypothèse est que, seulement lorsqu'il fonctionne sous une identité de pool d'applications virtuelles, notre application web (IIS ? processus de travail ?) perd soudainement son jeton primaire de sorte que IIS ne dispose que d'un jeton secondaire, de sorte que tout accès à Active Directory et à SQL Server se fait de manière anonyme, ce qui entraîne toutes les erreurs susmentionnées.
Pour l'instant, nous avons l'intention de passer d'ApplicationPoolIdentity à NetworkService. Nous espérons que cela fera disparaître tous les problèmes mentionnés ci-dessus. Mais nous ne sommes pas sûrs, et nous aimerions revenir en arrière si possible.
Notre question
L'hypothèse ci-dessus est-elle correcte, et si oui, s'agit-il d'un bogue dans IIS/Windows/.NET ? Dans quelles circonstances cette perte de jeton primaire se produit-elle ?
