Использование 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 вообще, если ваше планирование довольно базовое (например, ежедневно, еженедельно и т.д.).