Impersonation и CredentialCache.DefaultCredentials дает HTTP 401 Unauthorized

Как сказал @Michael Levy, это проблема с двойным прыжком. Это означает, что если вы не настроите Kerberos (Negotiate), NTLM, вероятно, будет использоваться в среде Windows под управлением IIS, имея клиента с браузером на машине A, пытающейся получить доступ к веб-сайту на машине B, будет иметь доступ к сайту, НО, когда это сайт попытается связаться со службой на компьютере C, вместо этого следует использовать учетные данные пула.

То же самое верно и для веб-сайта A, вызывающего службу B, которая, в свою очередь, вызывает службу C.

При настройке Kerberos для веб-сайтов следует учитывать несколько вещей. Во-первых, нужно знать, ферма это или нет. Если это так, вы должны определить общего пользователя для пула для всех машин, входящих в ферму. Это необходимо, поскольку Kerberos использует доменное имя для идентификации принципала, используемого для шифрования токенов безопасности. Если у вас были разные пользователи на разных машинах одной фермы, поскольку все они будут доступны через одно и то же доменное имя, все запросы будут искать та же запись. Более подробную информацию можно найти здесь: Kerberos и балансировка нагрузки.

Например, предположим, что у вас есть сайт с myApp.intranet в качестве URL-адреса. В AD у вас будет SPN, установленный, например, на myUser в домене MyDomain (setspn -S MyDomain \ myUser HTTP / myapp.intranet). Когда запрос отправляется в KDN (см. Ссылки на kerberos в конце для получения дополнительной информации о KDN), он всегда будет возвращать токен, зашифрованный с помощью myUser, но IIS попытается расшифровать его с помощью разных пользователей. Может возникнуть соблазн создать несколько SPN для одной и той же службы (HTTP / myapp.intranet), но это приведет к ошибке KRB.

Кроме того, если вы используете IIS 7+, вам нужно будет указать небольшую деталь в своем ApplicationHost.config, если вы хотите оставить аутентификацию в режиме ядра включенной (что настоятельно рекомендуется): useAppPoolCredentials = true. Это значение должно быть установлено в конфигурации \ system.webServer \ security \ authentication \ windowsAuthentication. Это потому, что по умолчанию Проверка подлинности в режиме ядра будет использовать учетную запись компьютера, а не учетную запись пула, и это вернет нас к многопользовательскому сценарию.

Во всех случаях Доверяйте этому пользователю для .. . на вкладке «Делегирование» участника AD необходимо включить, чтобы делегирование работало. Затем вам нужно решить, хотите ли вы использовать общее или ограниченное делегирование.

Как я сказал ранее, вам также необходимо установить SPN для нужного пользователя и нужной службы. Пользователя довольно легко идентифицировать, так как это будет тот, который вы определили в своем пуле, но служба может быть немного сложной в зависимости от вашей конфигурации. DNS, браузер и, возможно, другие переменные могут изменить то, что следует использовать. Наши испытания и ошибки показали следующее:

• Если ваша запись DNS является записью A, вы используете ее напрямую
• Если ваша запись является CName, в наших тестах использовалась запись A, связанная с ней.
• У нас были случаи, когда использовалось CName, и казалось, что это связано с версией браузера.

Обратите внимание: если имя участника-службы не задано специально и вы заходите на свой веб-сайт через имя NetBIOS, будет запрошена служба HTTP / машины, и что по умолчанию Служба HOST (поиск дополнительных) может использоваться вместо HTTP, чтобы HOST / машина использоваться. Это может быть полезно для легкой настройки в небольшой сети.

Также следует иметь в виду, что если вы хотите ограничить время простоя при переходе с NTLM на Kerberos, вы должны сначала изменить ApplicationHost, а затем использовать SetSPN. Вы также можете отключить согласование перед любым действием и оставить только NTLM, пока все не будет настроено, а затем, если возможно, включить только согласование (без NTLM). Это должно заставить клиентов изменить способ доступа к вашему сайту. Если вы этого не сделаете, похоже, что механизм кеширования на какое-то время будет работать с NTLM.

Надеюсь, это поможет. Если у вас все еще есть проблема с настройкой Kerberos, WireShark станет вашим самым верным другом. Вы можете найти информацию о том, как отлаживать Kerberos на следующих страницах: - Отладка Kerberos для веб-сайта - Отладка проблем AD с Kerberos (один из них - максимальный размер токена) - Инструменты Kerberos и другие ссылки - Отладка Kerberos общего захвата сети

Вы использовали netmon или wirehark, чтобы убедиться, что учетные данные передаются? Что вам сообщает журнал поставщика услуг? Также убедитесь, что в web.config (или другом .config) не настроен тег олицетворения.

РЕДАКТИРОВАТЬ:

Возможно, блок HostingEnvironment.Impersonate (), который по умолчанию использует идентификатор пула приложений или идентификатор любого пользовательского токена, который вы ему передаете.

Это классическая проблема с двойным прыжком - вы не можете использовать учетные данные пользователя, полученные в результате олицетворения, для доступа к другому серверу, если делегирование Kerberos не настроено должным образом в вашем домене. Дубликат этого вопроса

Согласно следующей статье MSDN, не будет работать для протоколов HTTP и FTP. Вам нужно будет явно предоставить учетные данные при подключении к удаленному серверу.

@ Майкл Книскерн - Это, безусловно, возможно с HTTP. Функция олицетворения передаст учетные данные из приложения ASP.Net в IIS. При встроенной проверке подлинности Windows учетные данные конечного пользователя будут использоваться вместо учетной записи ASPNET по умолчанию (или учетной записи, прикрепленной к пулу приложений). Я полагаю, что упоминание HTTP и FTP в той статье MSDN было направлено на DefaultNetworkCredentials.