Нам нелегко изображать, как эти учетные данные возражают работе. На самом деле они не могут работать, как мы ожидали, что они будут работать. Вот объяснение текущей проблемы.
Мы получили 2 сервера, который должен говорить друг с другом через веб-сервисы. Первый (позволяют нам назвать его Server01
) имеет службу Windows, работающую, поскольку NetworkService считают. Другой Server02
имеет ReportingServices, работающий с IIS 6.0. Служба Windows на Server01
попытка состоит в том, чтобы использовать Server02
ReportingServices WebService, чтобы генерировать отчеты и отправить их по электронной почте.
Так, вот то, что мы попробовали до сих пор.
Установка учетных данных во времени выполнения (Это работает превосходное):
rs.Credentials = new NetworkCredentials("user", "pass", "domain");
Теперь, если бы мы могли бы использовать основного пользователя, все были бы в порядке, однако... нам не разрешают. Так, мы пытаемся использовать DefaultCredetials или DefaultNetworkCredentials и передать его Веб-сервису RS:
rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials
Или:
rs.Credentials = System.Net.CredentialCache.DefaultCredentials
Так или иначе не будет работать. Мы всегда получаем 401 Unauthrorized от 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?
Спасибо за чтение!
Все подробности, которые вам нужны, включены в эту очень старую статью
http://msdn.microsoft.com/en-us/library/ms998351 .aspx
Короче говоря, если вы обнаружите, что устранение неполадок, подобных этой, сбивает вас с толку, вам следует сначала внимательно изучить технические детали, связанные с олицетворением ASP.NET.
Вот некоторые вещи, которые вы можете проверить: - установите SPN (имя участника-службы) для службы отчетов; хорошие примеры можно найти в Google; - Разрешить делегирование (ClientCredentials.Windows.AllowImpersonationLevel)
Проблема в том, что вы не можете пройти аутентификацию в IIS или не можете пройти аутентификацию в SSRS? Учетной записи DOMAIN \ MachineName $ может потребоваться разрешение в SSRS для запуска отчета, который вы пытаетесь автоматизировать.
SSRS обычно неплохо справляется с правильной настройкой IIS, так что вам не придется возиться с этими настройками. Я дважды проверил свою установку (это SSRS 2005, в SSRS 2000 все могло работать по-другому, и вы не сказали, какую версию используете), и он настроен на использование проверки подлинности Windows и включен олицетворение. Это означает, что IIS должен в основном просто аутентифицировать ваши учетные данные (проверять правильное имя пользователя / пароль), а не авторизовывать (определять, есть ли у этого пользователя разрешение на запуск рассматриваемого отчета). Затем IIS передает учетные данные в SSRS, у которого есть собственные настройки для определения того, какие учетные записи имеют разрешение на просмотр отчетов.
Кроме того, вы можете автоматизировать отправку отчетов по расписанию непосредственно в SSRS, поэтому вам может вообще не понадобиться служба Windows, если ваше расписание является довольно простым (например, ежедневно, еженедельно и т. Д.).