ASP.NET emprunte NT AUTHORITY\IUSR mais l'usurpation d'identité est désactivé. ASP.NET bug?
J'ai un ASP.NET 4.0 application en cours d'exécution sur Windows 7 /IIS 7.5 dans l' "ASP.NET v4.0 Classique" de l'application de la piscine, qui est configuré pour s'exécuter en tant que Service Réseau. L'application dispose d'une Application_EndRequest
gestionnaire qui se connecte à une instance locale de SQL Server. La chaîne de connexion SQL spécifie Integrated Security=SSPI
. Web.config ne pas ont <identity impersonate="true" />
.
Quand je navigue à http://localhost/TestSite/
, l'exception suivante est générée:
System.Data.SqlClient.SqlException (0x80131904): Login failed for user 'NT AUTHORITY\IUSR'.
...
at System.Data.SqlClient.SqlConnection.Open()
at Global.Application_EndRequest(Object sender, EventArgs e)
Cette exception est pas jeté quand je navigue à http://localhost/TestSite/default.aspx
(le document par défaut configuré dans IIS) ou tout autre .page aspx; dans ces cas, l'application correcte de la connexion à SQL Server en tant que "NT AUTHORITY\NETWORK SERVICE", qui est un identifiant valide.
Pourquoi ASP.NET usurper l'identité d' "NT AUTHORITY\IUSR" dans EndRequest même si l'emprunt d'identité est désactivé? Est-ce un bug ASP.NET?
Générales suivantes.asax.cs fichier illustre le problème:
public class Global : HttpApplication
{
public Global()
{
this.BeginRequest += delegate { Log("BeginRequest"); };
this.PreRequestHandlerExecute += delegate { Log("PreRequestHandlerExecute"); };
this.PostRequestHandlerExecute += delegate { Log("PostRequestHandlerExecute"); };
this.EndRequest += delegate { Log("EndRequest"); };
}
protected void Application_EndRequest(Object sender, EventArgs e)
{
try
{
using (SqlConnection connection = new SqlConnection("Server=.;Integrated Security=SSPI"))
{
connection.Open();
}
}
catch (Exception ex)
{
Trace.WriteLine(ex);
}
}
private static void Log(string eventName)
{
HttpContext context = HttpContext.Current;
Type impersonationContextType = typeof(HttpContext).Assembly.GetType("System.Web.ImpersonationContext", true);
Trace.WriteLine(string.Format("ThreadId={0} {1} {2} Impersonating={3}",
Thread.CurrentThread.ManagedThreadId,
context.Request.Url,
eventName,
impersonationContextType.InvokeMember("CurrentThreadTokenExists", BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.GetProperty, null, context, null)));
}
}
Voici la trace de sortie:
ThreadId=3 http://localhost/TestSite/BeginRequest Impersonating=False
ThreadId=3 http://localhost/TestSite/PreRequestHandlerExecute Impersonating=False
ThreadId=7 http://localhost/TestSite/default.aspx BeginRequest Impersonating=False
ThreadId=7 http://localhost/TestSite/default.aspx PreRequestHandlerExecute Impersonating=False
ThreadId=7 http://localhost/TestSite/default.aspx PostRequestHandlerExecute Impersonating=False
ThreadId=7 http://localhost/TestSite/default.aspx EndRequest Impersonating=False
ThreadId=7 http://localhost/TestSite/PostRequestHandlerExecute Impersonating=True
ThreadId=7 http://localhost/TestSite/EndRequest Impersonating=True
System.Data.SqlClient.SqlException (0x80131904): Login failed for user 'NT AUTHORITY\IUSR'.
...
at System.Data.SqlClient.SqlConnection.Open()
at Global.Application_EndRequest(Object sender, EventArgs e)
Noter qu'une demande de TestSite/
(qui est mappé à DefaultHttpHandler
) semble frayer un imbriquée demande à TestSite/default.aspx
(qui est mappé à ASP.default_aspx
). Après ASP.NET termine le traitement TestSite/default.aspx
, il usurpe l'identité "NT AUTHORITY\IUSR" quand il reprend le traitement de la demande de TestSite/
.
Mise à JOUR: j'ai soumis cette question à Microsoft Connect.
Quelle partie? J'ai déjà du Réseau des Services mis en place dans les services IIS et SQL Server.
OriginalL'auteur Michael Liu | 2012-05-09
Vous devez vous connecter pour publier un commentaire.
Le plus probable, les paramètres de votre serveur, du site ou de l'application sont définies de sorte que "l'Authentification Anonyme" mode page de causes demande à être traité comme la IUSR de l'utilisateur. Il n'est pas question que votre application ne demande pas à l'usurpation d'identité; IIS est de forcer. (En passant, "usurpation d'identité" est un terme générique dans Windows-terre, pour autant, un autre utilisateur. Il n'est pas spécifique à ASP.NET.)
Un peu de contexte:
Pour des raisons de sécurité, IIS permet à votre serveur de domaine "anonyme" et "authentifié" demandes en vertu de différentes informations d'identification du système.
Maintenant, dans IIS 7.5, si vous avez à la fois l'authentification anonyme et Formes d'authentification activée (ce qui est typique), avant que votre site web de l'utilisateur se connecte par l'intermédiaire des Formulaires, il considère que votre utilisateur "anonyme". Après votre utilisateur se connecte avec les Formes Auth, elle considère que votre utilisateur "authentifié".
J'ai trouvé ce comportement déroutant au premier abord, parce que c'est un changement de IIS 6.0, ce qui n'était pas au courant de Formes auth, et tous les Formulaires aux utilisateurs Authentifiés d'être anonyme!
Si vous le souhaitez, vous pouvez modifier l'identité sous laquelle les demandes anonymes sont mis en place. Ma préférence (et ça sonne comme le vôtre aussi), c'est qu'ils s'exécutent sous le les mêmes informations d'identification du système que mon site d'application de la piscine. Pour faire IIS faire, procédez de la manière suivante:
Étape 5 confondu moi au début, parce que je pensais que "l'identité du pool d'applications" signifiait "l'application de la piscine pseudo-compte" (une autre nouvelle fonctionnalité dans IIS 7.5). Ce que cela signifie vraiment, bien sûr, est "le même compte de l'application de la piscine est configuré pour s'exécuter sous, tout ce qui est."
Si vous voulez que ce comportement par défaut pour tous vos sites sur ce serveur, ou même juste une seule demande en vertu d'un site particulier, vous pouvez configurer les options d'authentification à ces niveaux. Il suffit de sélectionner le nœud que vous souhaitez configurer dans le volet Connexions, puis répétez les étapes 3 à 6.
Est-ce à expliquer pourquoi j'ai dû ajouter deux "IIS AppPool\<nom>" ET "NT AUTHORITY\IUSR" sécurité des connexions d'accès à ma base de données?
OriginalL'auteur Matthew Schaad
Pourquoi l'application tenter de se connecter en tant que "NT AUTHORITY\IUSR" même si l'application est (probablement) pas à l'aide de l'usurpation d'identité?
Si vous ne
il prend l'identité de l'utilisateur connecté
Si vous ne
il prend l'identité de l'utilisateur défini ci-dessus.
Mais si vous n'avez pas usurper l'identité à tous et à l'utilisation de l'authentification windows, il serait logique qu'il utilise un compte système par défaut.
Je ne sais pas pourquoi il fait la première tentative que IUSR et passe alors automatiquement en mode de RÉSEAU de SERVICE sur les demandes ultérieures. Mais je sais que quand vous sautez d'un serveur à un autre, l'application de la piscine credenticals ne sont PAS utilisés. Sauf si vous définissez un utilisateur représenté comme indiqué ci-dessous, le SERVICE de RÉSEAU par défaut est le compte qui est utilisé pour récupérer des ressources sur le serveur.
J'ai mis à jour ma question avec un peu plus d'informations.
OriginalL'auteur Arcturus