Использование DefaultCredentials и DefaultNetworkCredentials - PullRequest
28 голосов
/ 29 июня 2009

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

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

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

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

 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

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

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

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

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

  1. Мы где-то читали о «олицетворении пользователей», нужно ли где-то устанавливать это в Windows Service ?

  2. Можно ли предоставить доступ к встроенной учетной записи NetworkService удаленному серверу IIS?

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

Ответы [ 3 ]

8 голосов
/ 11 апреля 2010

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

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

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

0 голосов
/ 06 апреля 2010

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

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

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

0 голосов
/ 31 марта 2010

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

...