IIS application utilisant l'identité du pool d'applications perd le jeton principal?
(Il s'agit d'une question concernant un problème vague. J'essaie de présenter toutes les données pertinentes, dans l'espoir que quelqu'un dispose d'informations utiles; excuses pour la longue description.)
Notre application web
Nous avons une application Web .NET 4 exécutée dans IIS 7.5 accédant à Active Directory et à une base de données 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 ne réponse StackOverflow , et le billet de blog auquel elle se réfère: une identité de pool d'applications n'est qu'un groupe supplémentaire qui est ajouté aux processus de travail de l'application Web qui est fonctionnant en tant que "service réseau". Cependant, ne source suggère vaguement que "Network Service et ApplicationPoolIdentity ont des différences que les documents du site IIS.net ne publient pas." Une identité virtuelle peut donc être plus qu'un simple groupe supplémentaire.
Nous avons choisi d'utiliser ApplicationPoolIdentity, par opposition à NetworkService, car il est devenu la valeur par défaut dans IIS 7.5 (voir, par exemple, ici ), et selon la recommandation de Microsoft: "This L'identité permet aux administrateurs de spécifier des autorisations qui ne concernent que l'identité sous laquelle le pool d'applications s'exécute, augmentant ainsi la sécurité du serveur. "(from Élément processModel à ajouter pour applicationPools [Schéma des paramètres IIS 7] )" Application Les identités de pool sont une nouvelle fonctionnalité d'isolation puissante "qui" rend l'exécution IIS encore plus sécurisée et fiable. "(À partir de article IIS.net" Identités du pool d'applications " )
L'application utilise l'authentification Windows intégrée, mais avec <identity impersonate="false"/> , afin que ce ne soit pas l'identité de l'utilisateur final mais l'identité du pool d'applications virtuelles qui soit utilisée 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 endroits, 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 base de données SQL Server à l'aide de Integrated Security=true dans la chaîne de connexion. Si la base de données est locale, nous constatons que IIS APPPOOL\OurAppPoolName est utilisé pour se connecter à la base de données; si la base de données est distante, le compte d'ordinateur OURDOMAIN\ourwebserver$ est utilisé.
Nos problèmes
Nous rencontrons régulièrement des problèmes où une installation de travail commence à échouer de l'une des manières suivantes.
Lorsque la base de données se trouve sur un système distant, la connexion à la base de données commence à échouer: "Échec de la connexion pour l'utilisateur 'NT AUTHORITY\ANONYMOUS LOGON'. Raison: la validation d'accès au serveur basée sur les jetons a échoué avec une erreur d'infrastructure. Recherchez les erreurs précédentes." L'erreur précédente est "Erreur: 18456, gravité: 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 a été 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 "utiliser ApplicationPoolIdentity pour se connecter à SQL" , en particulier dans ne réponse .Les opérations Active Directory via ADSI (System.DirectoryServices) commencent à échouer avec l'erreur 0x8000500C ("Erreur inconnue"), 0x80072020 ("Une erreur d'opération s'est produite.") Ou 0x200B ("L'attribut ou la valeur de service d'annuaire spécifié n'existe pas") .
La connexion à l'application à partir d'Internet Explorer commence à échouer, avec des erreurs HTTP 401. Mais si dans IIS nous mettons ensuite 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 signalé dans Fil IIS.net "Échec de l'authentification de la fenêtre avec l'identité AppPool" .
Notre hypothèse et solution
Au moins, les problèmes AD et de connexion semblent toujours disparaître lors du basculement du pool d'applications d'ApplicationPoolIdentity vers NetworkService. (Nous avons trouvé n rapport confirmant cela.)
La page "" Dépannage des problèmes d'authentification sur ASP Pages " contient quelques suggestions concernant les jetons principaux et secondaires, et ce que je trouve encourageant, c'est qu'elle relie les deux premiers de nos erreurs: il mentionne NT AUTHORITY\ANONYMOUS LOGON accès et erreurs AD 0x8000500C et "L'attribut ou la valeur de service d'annuaire 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 cela n'est pas lié.)
Sur la base de ce qui précède, notre fonctionnement actuel - hypothèse est que, uniquement lors de l'exécution sous une identité de pool d'applications virtuelles, notre application Web (IIS? Processus de travail?) Perd soudainement son jeton principal , de sorte que IIS ne dispose que d'un jeton secondaire, de sorte que tout accès à Active Directory et à SQL Server se fasse 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. Espérons que cela fera disparaître tous les problèmes 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, dans l'affirmative, s'agit-il d'un bogue dans IIS/Windows/.NET? Dans quelles circonstances cette perte de jeton principale se produit-elle?
Grâce au support Microsoft, j'ai découvert que nous avons rencontré le problème décrit dans 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 le changement du mot de passe du compte d'ordinateur (qui par défaut 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 a un correctif attaché à cet article de la base de connaissances. Il n'y a aucune indication quand ce correctif sera intégré dans une livraison officielle et le correctif a déjà 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/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 comme NT AUTHORITY\ANONYMOUS LOGON, mais il est lié à 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 en temps, vous pouvez obtenir cette exception:
Erreur de configuration
L'attribut ou la valeur de service d'annuaire spécifié n'existe pas
Cela est apparemment causé par le problème décrit ici. Un redémarrage le corrige invariablement.