Встроенная проверка подлинности Windows в IIS, вызывающая сбой ADO.NET

Question

У нас есть веб-служба .NET 3.5 (, а не WCF), работающая под IIS. Он должен использовать identity impersonate="true" и встроенную аутентификацию Windows для аутентификации в стороннем программном обеспечении. Кроме того, он подключается к базе данных SQL Server с использованием аутентификации ADO.NET и SQL Server (с указанием фиксированного идентификатора пользователя и пароля в строке подключения).

Все работало нормально, пока база данных не была перемещена с SQL Server A на SQL Server B. (Не то же самое, что веб-сервер). Затем веб-служба выдает следующее исключение:

Сетевой или ошибка конкретного экземпляра произошла во время установление соединения с SQL Сервер. Сервер не найден или был недоступен. Убедитесь, что имя экземпляра правильное и что SQL Сервер настроен для разрешения удаленного соединения. (поставщик: именованные трубы Поставщик, ошибка: 40 - Не удалось открыть подключение к SQL Server)

Эта ошибка только возникает, если в файле Web.config указано значение олицетворения личности.

Опять же, строка подключения не изменилась и указывает пользователя. Я проверил строку подключения, и она работает как под олицетворенной учетной записью, так и под учетной записью службы (и с удаленного компьютера, и с сервера).

Что нужно изменить, чтобы заставить это работать с подражанием?

EDIT:

Ремус Русану указал нам правильное направление. Дело дошло до Kerberos - SPN не были настроены для нового сервера. См. Также asp.net через встроенную аутентификацию Windows Kerberos для сервера SQL . Спасибо!

Answer 1

При использовании олицетворения и доступа к ресурсу на другом хосте происходит делегирование (то, что неспециалисты называют «двумя прыжками»).Поскольку делегирование ограничено по умолчанию, аутентификация завершается неудачно, если только явно не включено ограниченное делегирование.

Но подождите, вы говорите, я использую аутентификацию SQL, а аутентификация SQL не является «ресурсом» NTLM / Kerberos.Правда, говорит я, но вы также используете ИМЕННЫЕ ТРУБЫ , а именованные каналы являются ресурсом NTLM / Kerberos, поэтому происходит делегирование * .

См. Как: настроить клиентские протоколы , чтобы убедиться, что SQL Server прослушивает TCP, и настроить клиентские сетевые протоколы , чтобы заставить клиента выбирать определенный протокол.(т.е. не пытайтесь сначала поименовать канал).Вы также можете принудительно установить TCP, просто добавив tcp: перед именем сервера в строке подключения.

Answer 2

Если делегирование является вашей проблемой, см. Эту статью для включения ограниченного делегирования http://msdn.microsoft.com/en-us/library/ms730088.aspx

перейдите в самый низ, чтобы увидеть, как настроить учетную запись для ограниченного делегирования. Я знаю, что это статья WCF, но процесс настройки учетной записи для использования делегирования должен быть таким же.

для получения более подробной информации, перейдите сюда http://technet.microsoft.com/en-us/library/cc739587(WS.10).aspx

В качестве альтернативы, ваш SQL-сервер должен разрешать TCP-доступ и получать к нему доступ, как объяснил Ремус.

Answer 3

Так как он работал, когда SQL Server находился в том же окне, он мог быть подключен к транзакциям.

Может случиться так, что он пытается использовать MSDTC, а выданным им пользователям не хватает некоторых прав.

Еще одна вещь, которую вы можете попробовать - войти на веб-сервер с пользователем, которого вы пытаетесь олицетворять, и посмотреть, сможете ли вы затем подключиться к серверу sql.

Answer 4

вы используете олицетворение в самом веб-сервисе?

Олицетворение в веб-сервисах работает на другом уровне, чем IIS. Чтобы перейти от клиента к веб-службе, вы можете отключить идентификацию = олицетворение и получить маркер пользователя из ServiceSecurityContext даже при включенном анонимном режиме.

Чтобы олицетворять этот токен в веб-службе, получите WindowsCredential из ServiceSecurityContext и вызовите метод credential.Impersonate () в операторе using, установив соединение с базой данных внутри блока using.

public class HelloService : IHelloService
{
    [OperationBehavior]
    public string Hello(string message)
    {
        WindowsIdentity callerWindowsIdentity =
        ServiceSecurityContext.Current.WindowsIdentity;
        if (callerWindowsIdentity == null)
        {
            throw new InvalidOperationException
           ("The caller cannot be mapped to a WindowsIdentity");
        }
        using (callerWindowsIdentity.Impersonate())
        {
            // Access a file as the caller.
        }
        return "Hello";
    }
}

Кроме того, если вам нужен еще один участок процесса (т. Е. Серверная служба находится на другом сервере), вам потребуется использовать делегирование для распространения учетных данных. Вы также можете сделать это декларативно. Смотрите эту статью для получения полной информации: http://msdn.microsoft.com/en-us/library/ms730088.aspx