MSSQL, Web-сервис, Win-форма и имперсонация

[Vladimir Aranovich]

Приветствую Вас, _All_!

Строится сабж-приложение. MSSQL, Web-сервис и клиент работают на разных
компьютерах в домене AD. Hа сервере Windows-авторизация.
Хочется, чтобы Web-сервис обращался к MSSQL от имени пользователя-клиента.
Как этого добиться?
Содержание web.config по-умолчанию.
О строке <identity impersonate="true"/> знаю. Это не помогает, Web-сервис
ломится к БД от аккаунта, под которым запущен IIS.
Помогите вылечить.


С уважением, /Владимир./

[Sam Andrews]

Wed Jul 27 2005 23:05, Vladimir Aranovich wrote to All:

VA> Хочется, чтобы Web-сервис обращался к MSSQL от имени
пользователя-клиента.
VA> Как этого добиться?
VA> Содержание web.config по-умолчанию.
VA> О строке <identity impersonate="true"/> знаю. Это не помогает,
VA> Web-сервис ломится к БД от аккаунта, под которым запущен IIS.
VA> Помогите вылечить.

<identity impersonate="true" userName="username" password="pass"/>

с уважением, Andrews...

[Andrzej Novosiolov]

Post by Vladimir Aranovich
Строится сабж-приложение. MSSQL, Web-сервис и клиент работают на разных
компьютерах в домене AD. Hа сервере Windows-авторизация. Хочется, чтобы
Web-сервис обращался к MSSQL от имени пользователя-клиента.

Анонимный доступ к каталогу веб-сервиса запрещён (в IIS configuration -
Directory Security)? Клиент по умолчанию первым делом пробует зайти анонимно,
и если получается - то авторизоваться и не пытается.

Кроме того, credentials при создании экземпляра Web Reference надо передавать
явно:

Dim ws As New appWS.AppService
ws.Credentials = (New System.Net.CredentialCache).DefaultCredentials
ws.PreAuthenticate = True

И ещё один подводный камень: стандартная Windows authentication не позволяет
double-hop authorization. То есть если клиент, сервис и SQL сервер - на трёх
разных машинах, то веб-сервис сможет получить, проверить и имперсонировать
логин/пароль клиента, а вот передать их дальше на SQL сервер - уже нет. Не
помню, помогает ли здесь AD. По-моему, нет. Нужно поднимать в домене Kerberos
для авторизации.

[Vladimir Aranovich]

Салют тебе, Sam!


VA>> Хочется, чтобы Web-сервис обращался к MSSQL от имени

SA> пользователя-клиента.

VA>> Как этого добиться?
VA>> Содержание web.config по-умолчанию.
VA>> О строке <identity impersonate="true"/> знаю. Это не помогает,
VA>> Web-сервис ломится к БД от аккаунта, под которым запущен IIS.
VA>> Помогите вылечить.

SA> <identity impersonate="true" userName="username" password="pass"/>

Спасибо. Hо это ответ на какой-то другой вопрос :)
Доступ к БД хочется получить от имени _конкретного_ клиента, а заранее
предопределенного. Увы ...

[Vladimir Aranovich]

Приветствую Вас, _Andrzej_!

/цитата сокращена/

AN> Анонимный доступ к каталогу веб-сервиса запрещён (в IIS configuration
AN> - Directory Security)? Клиент по умолчанию первым делом пробует зайти
AN> анонимно, и если получается - то авторизоваться и не пытается.

Hе написал, но было уже исполнено.

AN> Кроме того, credentials при создании экземпляра Web Reference надо
AN> передавать явно:

AN> Dim ws As New appWS.AppService
AN> ws.Credentials = (New System.Net.CredentialCache).DefaultCredentials
AN> ws.PreAuthenticate = True

Аналогично.

AN> И ещё один подводный камень: стандартная Windows authentication не
AN> позволяет double-hop authorization. То есть если клиент, сервис и SQL
AN> сервер - на трёх разных машинах, то веб-сервис сможет получить,
AN> проверить и имперсонировать логин/пароль клиента, а вот передать их
AN> дальше на SQL сервер - уже нет. Hе помню, помогает ли здесь AD.
AN> По-моему, нет. Hужно поднимать в домене Kerberos для авторизации.

А вот это уже принципиально. При работе с СОМ+ пробовал решить проблему
имперсонизации - тоже увы. Более того, действовали на пару с админом домена и
инструкцией от MS по настройке Kerberos. Результат - увы.
Видимо наивно надеялся, что IIS и ASP.NET могут решить эту проблеиу по-своему.
Очень не хочется использовать Kerberos - нет уверенности, что удастся
вопроизвести среду разработки на объекте внедрения. Я сторонник легкой
переносимости.
Придется, видимо, к БД ломиться админом, а вот что можно делать решать в
Web-сервисе на уровне принадлежности групаам AD.
А может есть что-то типа ролей, как в СОМ+ ?
Спасибо.


AN> --
AN> 2:463/1124.5, ICQ 8481158, LJ user: andrzejn, http://surf.to/andrzej
AN> --- ifmail v.2.15dev5.3
AN> * Origin: SoftElegance (2:5020/400)


С уважением, /Владимир./

[Andrzej Novosiolov]

Post by Vladimir Aranovich
Придется, видимо, к БД ломиться админом, а вот что можно делать решать в
Web-сервисе на уровне принадлежности группам AD.

В конечном итоге мы так и сделали. Разве что на БД мы заходим всё же не от
имени админа, а под специально созданным логином с минимально необходимыми
правами.

Post by Vladimir Aranovich
А может есть что-то типа ролей, как в СОМ+ ?

Кое-какие роли в .NET есть - см. в MSDN статью "Building Secure ASP.NET
Applications: Authentication, Authorization, and Secure Communication". Мы у
себя делали custom роли, хранящиеся в базе данных.

[Vladimir Aranovich]

Приветствую Вас, _Andrzej_!

/цитата сокращена/

Post by Vladimir Aranovich
Придется, видимо, к БД ломиться админом, а вот что можно делать
решать в Web-сервисе на уровне принадлежности группам AD.

AN> В конечном итоге мы так и сделали. Разве что на БД мы заходим всё же
AN> не от имени админа, а под специально созданным логином с минимально
AN> необходимыми правами.

Во-во. У тоже мечта такая, чтобы всем (кроме админа) в БД были видны только
view, SP и Function. Hо у меня, пока что-то не получается. :-)

Post by Vladimir Aranovich
А может есть что-то типа ролей, как в СОМ+ ?

AN> Кое-какие роли в .NET есть - см. в MSDN статью "Building Secure
AN> ASP.NET Applications: Authentication, Authorization, and Secure
AN> Communication". Мы у себя делали custom роли, хранящиеся в базе
AN> данных.

Это что-то типа матрицы пользователь/функция/полномочия ?

P.S. Кстати, сегодня вроде-бы добил имперсонацию/делегирование в 3-х звенке на
3-х разных машинах. Пришлось подергать Kerberos и настройки AD. Буду в
понедельник мучить в разных комбинациях чтобы полностью удостовериться.

С уважением, /Владимир./

[Alexander Rozenbaum]

Приветствую тебя, Novosiolov Andrzej. Тут я заметил, что 28 Jul 05 11:48:30 ты понаписал:
AN> И ещё один подводный камень: стандартная Windows authentication не
AN> позволяет double-hop authorization. То есть если клиент, сервис и SQL
AN> сервер - на трёх разных машинах, то веб-сервис сможет получить,
AN> проверить и имперсонировать логин/пароль клиента, а вот передать их
AN> дальше на SQL сервер - уже нет. Hе помню, помогает ли здесь AD.
AN> По-моему, нет. Hужно поднимать в домене Kerberos
AN> для авторизации.

Это не "стандартная Windows authentication" не дает, а устаревший начиная с
Windows 2000 протокол аутентификации NTLM. C использованием Kerberos (штатный
способ аутентификации в доменах Windows 2000 и старше) все замечательно
работает. Правда надо сделать еще 2-3 тедлодвижения:
1. в AD разрешить машине, на которой работает web-сервис, производить
имперсонацию (либо, если сервис от какого-то выделенного аккаунта, то для этого
аккаунта).
2. Если Web-сервис работает не в "web-узле по умолчанию", то для его веб-узла
администратор домена должен зарегистрировать соответствующий SPN (secure
principal name).
3. Пользователи, которые проходят имперсонацию на сервисе, не должны быть
помечены в AD как "sensitive account", так как это запрещает проведение
делегирования.

Короче, читайте MSDN и TechNET, они содержат массу информации, только ее найти
трудно.

Всего тебе самого самого... ну чего бы тебе хотелось? Ах не надо??!!??