Я использую метод UserPrincipal.Current.ToString() в домене для получения текущего входа в домен пользователя с допустимым доменом. но когда я показываю его в строке, которая дает ошибку при размещении на сервере IIS:
Unable to cast object of type 'System.DirectoryServices.AccountManagement.GroupPrincipal'
to type 'System.DirectoryServices.AccountManagement.UserPrincipal'.
У меня такая же проблема. Он отлично работал на моем локальном компьютере, но при развертывании его в IIS на сервере он не удался. В конце концов, мне пришлось изменить две вещи, чтобы заставить ее работать:
Измените аутентификацию на "Аутентификация Windows" (инструкции)
Вместо использования тока, делая это в два этапа: (источник)
PrincipalContext ctx = new PrincipalContext(ContextType.Domain);
UserPrincipal user = UserPrincipal.FindByIdentity(ctx, User.Identity.Name);
И, наконец, чтобы получить имя (или любую другую информацию), я использовал user.DisplayName.
Я видел это исключение при работе под IIS 7 в Windows 7.
System.Security.Principal.WindowsIdentity.GetCurrent(). Имя возвращает "IIS APPPOOL\ASP.NET v4.0".
Это не настоящая учетная запись пользователя, которая частично объясняет, что происходит, хотя IMHO UserPrincipal.Current должен обрабатывать эту ситуацию более изящно.
Я думаю, что это ошибка, и создали ошибку в Connect:
В качестве обходного пути используйте System.Security.Principal.WindowsIdentity.GetCurrent() чтобы получить идентификатор IIS AppPool.
Проблема здесь в том, что свойство UserPrincipal.Current попытается получить доступ к контексту текущего потока. Однако без олицетворения ASP.NET это означает, что идентификатор будет идентификатором пула приложений. Даже с олицетворением ASP.NET он должен каким-то образом получить доступ к Active Directory и, следовательно, должен пройти аутентификацию против контроллера домена. Если выбранный метод аутентификации в IIS не предусматривает этого, вероятна аналогичная ошибка.
По моему опыту, будет работать только аутентификация "BASIC" и 100% правильно реализованная версия "KERBEROS". Имейте в виду, что Kerberos на самом деле не совместим с тем, как обрабатываются пулы приложений и SPN, и, скорее всего, они потерпят неудачу. NTLM - это резерв для проверки подлинности Windows в IIS - не будет работать из-за отсутствия пароля на сервере.
Хорошее чтение о проблемах HTTP/Kerberos: http://blogs.msdn.com/b/friis/archive/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iis -ie.aspx