Unable to cast object of type in System.DirectoryServices.AccountManagement.GroupPrincipal

Question

I am Using Method UserPrincipal.Current.ToString() in Domain to Get Current Logged in Domain User with Valid Domain. but when i am Displaying it in a string its giv

Answer 1

I have seen this exception when running under IIS 7 on Windows 7.

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

This is not a real user account, which partly explains what is happening, though IMHO UserPrincipal.Current should handle this situation more gracefully.

I think it's a bug and have created a bug on Connect:

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

As a workaround, use System.Security.Principal.WindowsIdentity.GetCurrent() to get the identity of an IIS AppPool.

Answer 2

I had the same problem. It worked perfectly on my local machine but when deployed it to IIS on the server it failed. In the end I had to change two things to make it work:

1. Change the Authentication to "Windows Authentication" (how-to)

2. Instead of using current, doing it in two steps: (source)

PrincipalContext ctx = new PrincipalContext(ContextType.Domain);

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

And to finally get the name (or any other info), I used user.DisplayName.

Answer 3

The issue here is that the UserPrincipal.Current property will try to access the context of the current thread. Without ASP.NET impersonation however, it means that the identity will be the application pool's configured identity. Even with ASP.NET impersonation, it has to access the Active Directory in some way and thus needs to authenticate against the domain controller. If the selected authentication method in IIS doesn't provide for that, a similar error is likely.

In my experience, only "BASIC" authentication and a 100% correctly implemented version of "KERBEROS" will work. Keep in mind that Kerberos is not really compatible with the way application pools and SPNs are handled and is likely to fail. NTLM - which is the fallback for Windows authentication in IIS - will not work due to lack of password on the Server.

A good read about the HTTP/Kerberos problems is: http://blogs.msdn.com/b/friis/archive/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iis-ie.aspx