tag:blogger.com,1999:blog-5092972944722879737.post577317147653530936..comments2023-06-06T13:29:57.630+03:00Comments on Stump's Workshop: Имперсонация и делегирование в ASP.NETSergey Rozovikhttp://www.blogger.com/profile/13717493609449785600noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-5092972944722879737.post-60134326381434330382008-10-02T17:02:00.000+04:002008-10-02T17:02:00.000+04:00Спасибо! :)>1. Аутентификация по клиентским сер...Спасибо! :)<BR/><BR/><I>>1. Аутентификация по клиентским сертификатам настраивается [...]<BR/></I><BR/>Да-да, это понятно. Я просто описал ситуацию.<BR/><BR/><I><BR/>>2. "Страница запрашивает у пользователя пароль, находит соответствующего пользователя в AD" - а вот это уже зачем? <BR/></I><BR/>Похоже, я имел в виду что-то вроде мэппинга, о котором Вы сказали ниже.<BR/><BR/><I><BR/>Не понятно пользователь все же есть в AD или нет? <BR/></I><BR/>Пользователь есть в AD, но его машина не входит в AD, т.к. не находится в локальной сети, может находиться вообще где угодно и в своей ОС он может быть авторизован под каким угодно именем.<BR/><BR/><I><BR/>В п.1 уже выполнена аутентификация по сертификату, зачем второй раз аутентифициорваться? <BR/></I><BR/>Здесь используется двойная защита: для входа в систему требуется сертификат и пароль. Информация о том, авторизован ли сейчас пользователь хранится в Session[], поэтому, пока веб-сессия жива, мы можем считать, что пользователь авторизован. Далее: в пределах данного веб-проекта (на этом же сервере, в этом же каталоге) имеется веб-служба, а на клиентской машине имеется ActiveX-компонент, который с этой веб-службой работает. Этот компонент должен работать с веб-сервисом под тем же пользователем (т.е. с тем же сертификатом и паролем). Если с сертификатом более-менее понятно, то с паролем возникают вопросы: мы не должны передавать пароль компоненту и не должны второй раз спрашивать пароль у пользователя. Я предположил возможность передачи ключа веб-сессии от веб-приложения компоненту и далее веб-сервису, чтобы веб-приложение могло использовать данные сессии, но оказалось, что у веб-приложения и у веб-сервиса разные пространства сессий и даже когда используется один и тот же ключ сессии, сессии у них получаются разные. В конце концов я решил реализовать это через хранение сессионных данных в БД.<BR/><BR/><I><BR/>В IIS можно настроить маппинг клиентских сертификатов на учетные записи AD. <BR/></I><BR/>Мне кажется, это помогло бы мне решить мою проблему! Не подскажите, куда ткнуться, чтобы разобраться в этом вопросе подробнее? :)<BR/><BR/><I><BR/>Выберите какой либо один способ аутентификации: по сертификату или windows basic. <BR/></I><BR/>Аутентификация однозначно по сертификату.<BR/><BR/><I><BR/>3.4.5.6 Избежать запроса имени пользователя и пароля клиентским ActiveX можно только при Forms аутентификации с использованием куков.<BR/></I><BR/>Да, я примерно так и предполагаю - передавать ID сессии через куки плюс подтверждение сертификатом.<BR/><BR/>Еще раз спасибо! :)<BR/><BR/>С уважением,<BR/>Дмитрий П.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5092972944722879737.post-60095684654808996392008-10-02T16:13:00.000+04:002008-10-02T16:13:00.000+04:00Отвечаю.1. Аутентификация по клиентским сертификат...Отвечаю.<BR/>1. Аутентификация по клиентским сертификатам настраивается в свойствах сайта на IIS, в приложении ничего делать для этого не надо.<BR/>2. "Страница запрашивает у пользователя пароль, находит соответствующего пользователя в AD" - а вот это уже зачем? Не понятно пользователь все же есть в AD или нет? В п.1 уже выплнена аутентификация по сертификату, зачем второй раз аутентифициорваться? В IIS можно настроить маппинг клиентских сертификатов на учетные записи AD. Если нужно аутентифицировться пользователем AD из-за пределов локальной сети можно использовать Windows basic режим, его поддерживает и IE и Firefox. Выберите какой либо один способ аутентификации: по сертификату или windows basic. Идея с отправкой пароля на страницу и последующит логином в AD очень плохая, хотя и реализуемая через LogonUser.<BR/>3.4.5.6 Избежать запроса имени пользователя и пароля клиентским ActiveX можно только при Forms аутентификации с использованием куков, либо открывая анонимный доступ. <BR/>Вот так, как-то.Sergey Rozovikhttps://www.blogger.com/profile/13717493609449785600noreply@blogger.comtag:blogger.com,1999:blog-5092972944722879737.post-13563520474466638042008-10-02T14:55:00.000+04:002008-10-02T14:55:00.000+04:00Здравствуйте!А не подскажите, как реализовать прим...Здравствуйте!<BR/><BR/>А не подскажите, как реализовать примерно такую схему:<BR/><BR/>1. Клиент через HTTPS (с предоставлением клиентского сертификата) подключается к IIS (на сервере, подключенном к AD) с компьютера, не входящего в AD, и запрашивает ASP-страницу. <BR/><BR/>2. Страница запрашивает у пользователя пароль, находит соответствующего пользователя в AD и исполняется с его правами (в т.ч. обращается к MSSQL).<BR/><BR/>3. В теле ответа на запрос сервер возвращает некий ActiveX.<BR/><BR/>4. Этот ActiveX обращается к веб-службе на том же сервере.<BR/><BR/>5. Веб-служба обрабатывает запрос с правами того же пользователя. При этом пароль у пользователя второй раз не спрашивается.<BR/><BR/>6. Единожды авторизовавшись, клиент работает с веб-сервером под тем же пользователем, пока не закроется соответствующая веб-сессия (ну, или не закроется браузер).<BR/><BR/><BR/>Т.е. основная проблема - сделать так, чтобы единожды авторизовавшись (один раз попросив у пользователя пароль) клиентская часть могла использовать на сервере различные веб-приложения и веб-службы с теми же правами, но при этом от самого пользователя не требовалось никаких дополнительных действий по настройке своей системы, а так же не было необходимости устанавливать соответствие между учетной записью на компьютере пользователя и учетной записью на сервере.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5092972944722879737.post-44184394198330042662008-08-28T15:33:00.000+04:002008-08-28T15:33:00.000+04:00"Если имперсонация выключена. для доступа к файлу ..."Если имперсонация выключена. для доступа к файлу используется учетная запись рабочего процесса."<BR/>Действительно всё в порядке, большое спасибо! Когда нужный процесс не был найден в диспетчере, стало ясно, что проверять это под имперсонализацию под отладчиком не выйдет, так как он-то запущен тем пользователем, которому всё можно.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5092972944722879737.post-47193290265191794992008-08-28T13:13:00.000+04:002008-08-28T13:13:00.000+04:00Если имперсонация выключена. для доступа к файлу и...Если имперсонация выключена. для доступа к файлу используется учетная запись рабочего процесса. Не надо в этом сомневаться :)<BR/>Надо очень аккуратно смотреть на все настройки. Определяющими являются три момента:<BR/>- действительно ли выключена имперсонация (может быть включена в вышестоящем конфиге)<BR/>- под какой учеткой исполняется процесс ASP.NET (смотрим в диспетчере задач)<BR/>- реальное состояние NTFS ACL для интересующего нас файла.Sergey Rozovikhttps://www.blogger.com/profile/13717493609449785600noreply@blogger.comtag:blogger.com,1999:blog-5092972944722879737.post-43417205878625928372008-08-28T12:47:00.000+04:002008-08-28T12:47:00.000+04:00"По умолчанию имперсонация выключена. Для того, чт..."По умолчанию имперсонация выключена. Для того, чтобы включить механизм имперсонации для web приложения необходимо поместить в секцию его web.config следующий тэг:<BR/>identity impersonate="true"<BR/><BR/>Следовательно, если не прописывать этот тэг вообще или поставить false, имперсонация будет выключена? И доступ к ресурсам будет выполняться от имени учётной записи, под которой работает ASP?<BR/>Используется windows аутентификация, в web.config имперсонация отключена, разрешение для доступа к папке и файлу выдано только одному пользователю домена. При этом приложение спокойно получает доступ к этому файлу, хотя вроде бы ему должно быть отказано в доступе, так как учётной записи ASP не выданы соответствующие разрешения.<BR/>Подскажите пожалуйста, что препятствует корректной работе?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5092972944722879737.post-62788544680052158552007-11-09T23:34:00.000+03:002007-11-09T23:34:00.000+03:00> Подскажите, где найти данные настройки в случае ...> Подскажите, где найти данные настройки в случае XP.<BR/><BR/>Компьютер под XP тоже может выступать в качестве сервера. Главное чтобы он состоял в домене AD. <BR/>Все эти настройки производятся через оснастку "Users and Computers" на контроллере домена или на любом компьютере где установлены средства администрирования AD. И, естественно, для этого надо иметь права адинистратора домена.Sergey Rozovikhttps://www.blogger.com/profile/13717493609449785600noreply@blogger.comtag:blogger.com,1999:blog-5092972944722879737.post-30036077230478580262007-11-09T18:51:00.000+03:002007-11-09T18:51:00.000+03:00"Для сервера должна быть включена опция «Trust com..."Для сервера должна быть включена опция «Trust computer for delegation» (настраивается через оснастку MMC «Active Directory Users and Computers»). А для учетных записей пользователей в AD должен быть сброшен флаг «Account is sensitive and cannot be delegated» (настраивается там же)"<BR/><BR/>Подскажите, где найти данные настройки в случае XP.Anonymousnoreply@blogger.com