Kann Objekt des Typs in System.DirectoryServices.AccountManagement.GroupPrincipal

Question

nicht umwandeln. Ich verwende Methode UserPrincipal.Current.ToString() in Domäne, um den aktuellen angemeldeten Domänenbenutzer mit gültiger Domäne abzurufen. aber wenn ich es in einem String seiner geben Fehler angezeigt, wenn in IIS Server gehostet:

Unable to cast object of type 'System.DirectoryServices.AccountManagement.GroupPrincipal' 
      to type 'System.DirectoryServices.AccountManagement.UserPrincipal'. 

Answer 1

ich hatte das gleiche Problem. Es funktionierte perfekt auf meinem lokalen Computer, aber wenn es auf dem Server auf IIS bereitgestellt wurde, schlug es fehl. Am Ende musste ich zwei Dinge ändern, damit es funktioniert:

1. ändern Sie die Authentifizierung auf „Windows-Authentifizierung“ (how-to)

2. Anstelle der Verwendung von Strom, es in zwei Schritten vorgehen: (source

   )

PrincipalContext ctx = new PrincipalContext(ContextType.Domain);

UserPrincipal user = UserPrincipal.FindByIdentity(ctx, User.Identity.Name);

Und um endlich den Namen (oder andere Informationen) zu bekommen, habe ich user.DisplayName.

Answer 2

Ich habe diese Ausnahme gesehen, wenn unter IIS 7 unter Windows 7.

System.Security.Principal .WindowsIdentity.GetCurrent(). Name gibt "IIS APPPOOL \ ASP.NET v4.0" zurück.

Dies ist not a real user account, was teilweise erklärt, was geschieht, obwohl IMHO UserPrincipal.Current anmutiger mit dieser Situation umgehen sollte.

Ich denke, es ist ein Fehler und haben einen Fehler auf Connect erstellt:

http://connect.microsoft.com/VisualStudio/feedback/details/748790/userprincipal-current-throws-invalidcastexception

Als Abhilfe können System.Security.Principal.WindowsIdentity.GetCurrent() verwenden, um die Identität eines IIS AppPool zu erhalten.

Answer 3

Das Problem hier ist, dass die UserPrincipal.Current Eigenschaft versucht, auf den Kontext des aktuellen Threads zuzugreifen. Ohne ASP.NET-Identitätswechsel bedeutet dies jedoch, dass die Identität die konfigurierte Identität des Anwendungspools ist. Selbst mit dem Identitätswechsel von ASP.NET muss es auf das Active Directory in irgendeiner Weise zugreifen und muss sich daher beim Domänencontroller authentifizieren. Wenn die ausgewählte Authentifizierungsmethode in IIS dies nicht vorsieht, ist ein ähnlicher Fehler wahrscheinlich.

Nach meiner Erfahrung, nur "BASIC" Authentifizierung und eine 100% korrekt implementierte Version von "KERBEROS" wird funktionieren. Beachten Sie, dass Kerberos nicht wirklich kompatibel mit der Art und Weise ist, wie Anwendungspools und SPNs behandelt werden und wahrscheinlich fehlschlagen. NTLM - der Fallback für die Windows-Authentifizierung in IIS - funktioniert nicht, da das Kennwort auf dem Server fehlt.

Eine gute Lese über die HTTP/Kerberos Probleme ist: http://blogs.msdn.com/b/friis/archive/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iis-ie.aspx