Использование DefaultCredentials и DefaultNetworkCredentials

Нам сложно определить, как работают эти учетные данные. На самом деле они могут не работать, как мы ожидали, что они будут работать. Здесь объясняется текущая проблема.

У нас есть 2 сервера, которым нужно общаться друг с другом через webservices. Первая из них (пусть называется Server01) имеет службу Windows, работающую как учетная запись NetworkService. Другой Server02 имеет службы ReportingServices, работающие с IIS 6.0. Служба Windows в Server01 пытается использовать Server02 ReportingServices WebService для создания отчетов и отправки их по электронной почте.

Итак, вот что мы пробовали до сих пор.

Установка учетных данных во время выполнения (Это отлично работает):

 rs.Credentials = new NetworkCredentials("user", "pass", "domain");

Теперь, если бы мы могли использовать общий пользователь, все было бы хорошо, однако... нам не разрешено. Итак, мы пытаемся использовать DefaultCredetials или DefaultNetworkCredentials и передавать его в RS Webservice:

rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials

Или:

rs.Credentials = System.Net.CredentialCache.DefaultCredentials

В любом случае это не сработает. Мы всегда получаем 401 Unautrrorized от IIS. Теперь мы знаем, что если мы хотим предоставить доступ к ресурсу, зарегистрированному как NetworkService, нам нужно предоставить его DOMAIN\MachineName$ (http://msdn.microsoft.com/en-us/library/ms998320.aspx):

Предоставление доступа к удаленному SQL Server

Если вы обращаетесь к базе данных на другом сервере в том же домене (или в доверенном домене), сетевые учетные данные учетной записи сетевой службы используются для аутентификации в базе данных. Учетные записи учетной записи сетевой службы имеют форму DomainName\AspNetServer $, где DomainName является доменом сервера ASP.NET, а AspNetServer - вашим именем веб-сервера.

Например, если приложение ASP.NET запускается на сервере с именем SVR1 в домене CONTOSO, SQL Server видит запрос доступа к базе данных из CONTOSO\SVR1 $.

Мы предположили, что предоставление доступа таким же образом с IIS будет работать. Однако это не так. Или, по крайней мере, что-то не установлено правильно, чтобы он правильно аутентифицировался.

Итак, вот несколько вопросов:

Мы где-то читаем о "олицетворениях пользователей", нужно ли это установить где-нибудь в службе Windows?
Можно ли предоставить доступ к встроенной учетной записи NetworkService на удаленном сервере IIS?

Спасибо за чтение!

Ответ 1

Все детали, которые вам нужны, включены в эту очень старую статью,

http://msdn.microsoft.com/en-us/library/ms998351.aspx

Вкратце, когда вам не смущает устранение таких проблем, вам следует вначале тщательно просмотреть технические детали за олицетворением ASP.NET.

Ответ 2

Вот некоторые вещи, которые вы можете проверить: - установить SPN (имя участника услуги) для службы отчетов; вы можете найти хорошие примеры в google; - Разрешить делегирование (ClientCredentials.Windows.AllowImpersonationLevel)

Ответ 3

Проблема в том, что вы не выполняете аутентификацию в IIS или не выполняете аутентификацию в SSRS? Учетной записи DOMAIN\MachineName $может потребоваться разрешение в SSRS для запуска отчета, который вы пытаетесь автоматизировать.

SSRS обычно выполняет довольно хорошую работу по правильной настройке IIS, поэтому вам не нужно связываться с этими настройками. Я дважды проверил мою установку (это SSRS 2005, в SSRS 2000, возможно, работала по-другому, и вы не сказали, какую версию вы используете), и она настроена на использование проверки подлинности Windows и активирование олицетворения. Это означает, что IIS должна в основном просто аутентифицировать ваши учетные данные (подтверждение правильного имени пользователя/пароля), а не авторизацию (определение того, имеет ли этот пользователь разрешение на запуск рассматриваемого отчета). Затем IIS передает учетные данные в SSRS, у которого есть свои собственные настройки для определения того, какие учетные записи имеют разрешение на просмотр отчетов.

Кроме того, вы можете автоматизировать отправку отчетов по расписанию непосредственно в SSRS, так что вам может не понадобиться служба Windows вообще, если ваше планирование довольно базовое (например, ежедневно, еженедельно и т.д.).