Nie można rzutować obiektu typu w System.DirectoryServices.AccountManagement.GroupPrincipal

Question

Używam metody UserPrincipal.Current.ToString() w domenie, aby pobrać bieżące logowanie użytkownika domeny z prawidłową domeną. ale kiedy jestem Wyświetlanie go w ciąg jego dające błąd podczas hostowane na serwerze IIS:

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

Answer 1

miałem ten sam problem. Działał doskonale na moim komputerze lokalnym, ale po wdrożeniu go do IIS na serwerze nie powiodło się. W końcu musiałem zmienić dwie rzeczy, aby to działało:

1. Zmiana uwierzytelniania do "Windows Authentication" (how-to)

2. Zamiast prąd, robi to w dwóch etapach: (source)

PrincipalContext ctx = new PrincipalContext(ContextType.Domain);

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

I na koniec uzyskać nazwę (lub inne informacje), użyłem user.DisplayName.

Answer 2

Widziałem ten wyjątek, gdy działa w ramach IIS 7 na Windows 7.

System.Security.Principal .WindowsIdentity.GetCurrent(). Nazwa zwraca "IIS APPPOOL \ ASP.NET v4.0".

To not a real user account, co częściowo wyjaśnia, co się dzieje, choć IMHO UserPrincipal.Current powinien obsługiwać tej sytuacji bardziej wdzięcznie.

myślę, że to błąd i stworzyli błąd na Connect:

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

Jako obejście, należy System.Security.Principal.WindowsIdentity.GetCurrent() uzyskać tożsamość IIS AppPool.

Answer 3

Problem polega na tym, że właściwość UserPrincipal.Current będzie próbować uzyskać dostęp do kontekstu bieżącego wątku. Bez personifikacji ASP.NET oznacza to jednak, że tożsamość będzie tożsamością skonfigurowaną puli aplikacji. Nawet w przypadku personifikacji ASP.NET musi on w pewien sposób uzyskać dostęp do Active Directory, a zatem musi uwierzytelnić się na kontrolerze domeny. Jeśli wybrana metoda uwierzytelniania w IIS tego nie zapewnia, prawdopodobny jest podobny błąd.

Z mojego doświadczenia będzie działać tylko "PODSTAWOWE" uwierzytelnianie i 100% poprawnie wdrożona wersja "KERBEROS". Należy pamiętać, że protokół Kerberos nie jest kompatybilny ze sposobem obsługi pul aplikacji i nazw SPN i może się nie udać. NTLM - który jest awarią dla uwierzytelniania systemu Windows w IIS - nie będzie działać z powodu braku hasła na serwerze.

warto przeczytać o problemach HTTP/Kerberos jest: http://blogs.msdn.com/b/friis/archive/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iis-ie.aspx