Gemäß dieses Dokuments:
Ich habe folgendes in der web.config festgelegt
Und habe dies auch in der applicationhost.config für IIS Express 7.5 festgelegt
Aber System.Threading.Thread.CurrentPrincipal.Identity entspricht immer noch immer der Windows-Identität des authentifizierten Benutzers, d.h. nicht dem Konto, unter dem IISExpress.exe ausgeführt wird (mein Entwicklerkonto).
Um es klar auszudrücken, ich bin als Konto A angemeldet und IIS Express läuft als Konto A, aber ich rufe meinen Webservice unter Verwendung von Konto B auf (indem ich die Anmeldeinformationen auf HttpWebRequest festlege), aber der serverseitige Code wird als Konto B ausgeführt, d.h. der Thread hat diese ID und ich kann auf Netzwerkressourcen zugreifen.
Ich möchte, dass die Ausführung als Konto A erfolgt (und auf dem Produktionsserver als Dienstkonto) und nur dann eine Impersonierung erfolgt, wenn ich es möchte.
Mache ich etwas falsch oder ist dieser Bereich in IISX nicht perfekt implementiert?
Danke
Luke
Update 1
Also dachte ich, ich hätte herausgefunden, was los war; siehe meine Antwort unten. Das Problem ist, dass es anscheinend in umgekehrter Richtung funktioniert!
string n1 = System.Security.Principal.WindowsIdentity.GetCurrent().Name; // Laufzeitkonto.
string n2 = System.Threading.Thread.CurrentPrincipal.Identity.Name; // Aufrufendes Konto.
var winId = (System.Security.Principal.WindowsIdentity)HttpContext.Current.User.Identity;
System.Security.Principal.WindowsImpersonationContext ctx = null;
try
{
bool b = System.IO.File.Exists(@"d:\p\p.txt"); // true (!)
using (ctx = winId.Impersonate())
{
// Jetzt impersonierend. Zugriff (lokale) Ressourcen unter Verwendung der Identität des authentifizierten Benutzers.
n1 = System.Security.Principal.WindowsIdentity.GetCurrent().Name; // Aufrufendes Konto.
n2 = System.Threading.Thread.CurrentPrincipal.Identity.Name; // Aufrufendes Konto.
b = System.IO.File.Exists(@"d:\p\p.txt"); // false (!)
}
...
Der Ordner d:\p ist nur für den Aufrufenden zugänglich, was bei einem DOS-Test in Ordnung ist, aber von meinem Webservice aus hat er Zugriff und ich vermute, dass dies daran liegt, dass der Thread den Sicherheitskontext des Aufrufers hat, BEVOR ich mit der Impersonierung begonnen habe!
Noch seltsamer ist, dass wenn ich impersoniere, plötzlich den Zugriff darauf verliere!
Ich werde ein Testprojekt auf einem richtigen IIS 7.5-Server erstellen und sehen, ob dies an einem Fehler in IIS Express liegt.
Update 2
Das Problem mit dem Exists-Test wurde zur Hälfte gelöst. Ich habe die Rechte für den Ordner entfernt, aber die Datei selbst hatte immer noch einige Rechte, und die Art und Weise, wie .NET auf Dateien zugreift, ohne den Ordner zu durchqueren, bedeutet, dass es immer noch darauf zugreifen konnte.
Jetzt erhalte ich
b == false // wie erwartet.
...
b == false // unerwartet, nach der Impersonierung sollte ich auf diese Datei zugreifen können.
Ich erwarte, dass die Impersonierung mir Zugriff gibt, sie tut es nicht.
Update 3
Ich habe aufgegeben. Impersonierung funktioniert nicht und ich kann nur annehmen, dass es eine Netzwerkrichtlinie oder eine nicht entdeckbare versteckte Einstellung ist.