Невозможно включить объект типа в System.DirectoryServices.AccountManagement.GroupPrincipal

Я использую метод UserPrincipal.Current.ToString() в домене для получения текущего входа в домен пользователя с допустимым доменом. но когда я показываю его в строке, которая дает ошибку при размещении на сервере IIS:

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

Ответ 1

У меня такая же проблема. Он отлично работал на моем локальном компьютере, но при развертывании его в IIS на сервере он не удался. В конце концов, мне пришлось изменить две вещи, чтобы заставить ее работать:

  1. Измените аутентификацию на "Аутентификация Windows" (инструкции)

  2. Вместо использования тока, делая это в два этапа: (источник)

PrincipalContext ctx = new PrincipalContext(ContextType.Domain);

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

И, наконец, чтобы получить имя (или любую другую информацию), я использовал user.DisplayName.

Ответ 2

Я видел это исключение при работе под IIS 7 в Windows 7.

System.Security.Principal.WindowsIdentity.GetCurrent(). Имя возвращает "IIS APPPOOL\ASP.NET v4.0".

Это не настоящая учетная запись пользователя, которая частично объясняет, что происходит, хотя IMHO UserPrincipal.Current должен обрабатывать эту ситуацию более изящно.

Я думаю, что это ошибка, и создали ошибку в Connect:

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

В качестве обходного пути используйте System.Security.Principal.WindowsIdentity.GetCurrent() чтобы получить идентификатор IIS AppPool.

Ответ 3

Проблема здесь в том, что свойство 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