L’application IIS utilisant l’identité du pool d’applications perd le jeton principal?

(Ceci est une question sur un problème vague. J’essaie de présenter toutes les données pertinentes, dans l’espoir que quelqu’un a des informations utiles; excuses pour la description longue.)

Notre application web

Nous avons une application Web .NET 4 exécutée dans IIS 7.5 pour accéder à Active Directory et à une firebase database SQL Server.

Cette application Web s’exécute sous une «identité de pool d’applications» virtuelle, en définissant l’identité du pool d’ applications de l’ application sur ApplicationPoolIdentity . Une description concise des identités virtuelles peut être trouvée dans une réponse StackOverflow et dans l’article de blog auquel elle fait référence: une identité de pool d’applications n’est qu’un groupe supplémentaire ajouté aux processus de travail de l’application Web exécutée en tant que “service réseau”. Cependant, une source suggère vaguement que “Network Service et ApplicationPoolIdentity ont des différences que les documents de site IIS.net ne publient pas”. Une identité virtuelle peut donc être plus qu’un groupe supplémentaire.

Nous avons choisi d’utiliser ApplicationPoolIdentity, par opposition à NetworkService, car il est devenu par défaut dans IIS 7.5 (voir par exemple ici ) et selon les recommandations de Microsoft: “Cette identité permet aux administrateurs de spécifier des permissions uniquement liées à l’identité sous laquelle l’application le pool fonctionne, augmentant ainsi la sécurité du serveur. ” (from ProcessModel Element pour add pour applicationPools [Schéma de parameters IIS 7] ) “Les identités de pool d’applications sont une nouvelle fonctionnalité d’isolation puissante qui rend la gestion des applications IIS encore plus sûre et fiable. ” )

L’application utilise l’authentification Windows intégrée, mais avec , de sorte que l’identité de l’utilisateur final mais l’identité du pool d’applications virtuelles ne sont pas utilisées pour exécuter notre code.

Cette application interroge Active Directory à l’aide des classes System.DirectoryServices , c’est-à-dire l’API ADSI. Dans la plupart des cas, cela se fait sans spécifier de nom d’utilisateur / mot de passe supplémentaire ou d’autres informations d’identification.

Cette application se connecte également à une firebase database SQL Server à l’aide d’ Integrated Security=true dans la chaîne de connexion. Si la firebase database est locale, nous voyons que IIS APPPOOL\OurAppPoolName est utilisé pour se connecter à la firebase database; Si la firebase database est distante, le compte d’ OURDOMAIN\ourwebserver$ est utilisé.

Nos problèmes

Nous rencontrons régulièrement des problèmes où une installation en cours de fonctionnement échoue de l’une des manières suivantes.

  • Lorsque la firebase database se trouve sur un système distant, la connexion à la firebase database échoue: “Échec de la connexion de l’utilisateur ‘NT AUTHORITY \ ANONYMOUS LOGON’. Raison: La validation de l’access au serveur par jeton a échoué avec une erreur d’infrastructure. L’erreur précédente est “erreur: 18456, gravité: 14, état: 11.” Il semble donc que OURDOMAIN\ourwebserver$ ne soit plus utilisé, mais que l’access anonyme soit tenté. (Nous avons des preuves anecdotiques que ce problème est survenu lorsque le contrôle de compte d’utilisateur a été désactivé et qu’il s’est éteint après l’activation du contrôle de compte utilisateur. Notez que le changement du contrôle de compte utilisateur nécessite un redémarrage …) se connecter à SQL ” , en particulier dans une réponse .

  • Les opérations Active Directory via ADSI (System.DirectoryServices) échouent avec l’erreur 0x8000500C («Erreur inconnue»), 0x80072020 («Une erreur d’opération s’est produite») ou 0x200B («L’atsortingbut ou la valeur du service d’annuaire spécifié n’existe pas») .

  • La connexion à l’application depuis Internet Explorer commence à échouer, avec des erreurs HTTP 401. Mais si dans IIS nous plaçons ensuite NTLM avant de négocier, alors cela fonctionne à nouveau. (Notez que l’access à AD est nécessaire pour Kerberos, mais pas pour NTLM.) Un problème similaire est signalé dans le thread IIS.net “Authentification de la fenêtre échec avec l’identité AppPool” .

Notre hypothèse et solution de rechange

Au moins, les problèmes d’AD et de connexion semblent toujours disparaître lors du passage du pool d’applications de ApplicationPoolIdentity à NetworkService. (Nous avons trouvé un rapport le confirmant.)

La page “Dépannage des problèmes d’authentification sur les pages ASP” contient des suggestions relatives aux jetons principal et secondaire, et ce que je trouve encourageant est qu’il relie les deux premières erreurs: il mentionne l’access NT AUTHORITY\ANONYMOUS LOGON et les erreurs AD 0x8000500C “L’atsortingbut ou la valeur du service d’annuaire spécifié n’existe pas”.

(La même page mentionne également les problèmes de cache de schéma ADSI, mais tout ce que nous pouvons trouver sur ce sujet est ancien.

Sur la base de ce qui précède, notre hypothèse de travail actuelle est que, uniquement sous une identité de pool d’applications virtuelles, notre application Web (processus de travail IIS?) Perd soudainement son jeton principal , de sorte que IIS ne dispose que d’un jeton secondaire. l’access à Active Directory et à SQL Server est effectué de manière anonyme, ce qui entraîne toutes les erreurs ci-dessus.

Pour l’instant, nous avons l’intention de passer d’ApplicationPoolIdentity à NetworkService. J’espère que cela fera disparaître tous les problèmes ci-dessus. Mais nous ne sums pas sûrs et nous aimerions revenir si possible.

Notre question

L’hypothèse ci-dessus est-elle correcte et, dans l’affirmative, s’agit-il d’un bogue dans IIS / Windows / .NET? Dans quelles circonstances cette perte de jeton primaire se produit-elle?

    Grâce au support technique Microsoft, j’ai découvert que nous avions rencontré le problème décrit dans l’ article KB2545850 de la Base de connaissances Microsoft . Cela se produit uniquement lorsque ApplicationPoolIdentity est utilisé. Cela se produit très facilement, à savoir après que le mot de passe du compte de la machine a été modifié (ce qui se produit automatiquement tous les 30 jours), puis IIS est redémarré (par exemple, via iisreset ). Notez que le problème disparaît après un redémarrage, selon Microsoft et nos observations.

    Selon Microsoft, il n’est pas possible de vérifier si votre Windows / IIS est entré dans cet état.

    Microsoft dispose d’un correctif associé à cet article de la base de connaissances. Il n’y a aucune indication lorsque ce correctif sera intégré à une livraison officielle et le correctif est déjà âgé de 10 mois. Dans notre cas spécifique, nous avons décidé de passer à NetworkService à la place.

    Voir https://serverfault.com/a/403534/126432 pour mes commentaires sur le même problème / la même solution.

    L’utilisation du correctif que vous avez lié m’a permis de faire fonctionner ApplicationPoolIdentity comme le disent les documents. Ce correctif ne décrit pas spécifiquement une solution pour accéder aux ressources réseau en tant que NT AUTHORITY \ ANONYMOUS LOGON, mais elle est liée à la modification du mot de passe de l’ordinateur. En fin de compte, cela a fonctionné pour moi, du moins jusqu’à présent.

    Ceci est également pertinent pour Umbraco utilisant l’authentification Active Directory. De temps à autre, vous pouvez obtenir cette exception:

    Erreur de configuration

    L’atsortingbut ou la valeur du service d’annuaire spécifié n’existe pas

    Ceci est apparemment causé par le problème décrit ici. Un redémarrage corrige toujours le problème.