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

Question

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

У нас есть 2 сервера, которым нужно общаться друг с другом через веб-сервисы.Первый из них (давайте назовем его Server01) имеет Службу Windows, запущенную от имени учетной записи NetworkService.Тот , другой Server02 имеет службы отчетов, работающие с 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 неавторизованный из 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 ?

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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