Имеем код обработчика запросов прокси сервера (исходники 4-ки пока недоступны, поэтому самому восстановить полную логику работы обработчика запроса достаточно нетривиально..
: http-proxy\OnRequest
...
IsCachedFile
IF
S" FileIsOlderThanHours: {CacheAge}" EVALUATE
IF RefreshCache ELSE SendFromCache THEN
THEN
URL EvalACL 0= IF DROP EXIT THEN ( acl_flags )
( acl_flags ) DUP arR AND 0= \ URL есть в ACL, и права чтения его нет
IF UID @ IF arX AND IF UID 0! S" ProxyUnauthorized PROXY_ACL" EVALUATE \ перелогиниться
ELSE ProxyAccessDenied THEN
ELSE arX AND IF S" ProxyUnauthorized PROXY" EVALUATE
ELSE ProxyAccessDenied THEN
THEN
ELSE DROP THEN
;
Собственно почему проверка на ACL происходит уже после проверки на наличие файла в кэше и обновление последнего в случае необходимости?
RefreshCache и SendFromCache не производит никаких сетевых операций, а только устанавливает переменные (как и все действия в OnRequest).
А проверки эти производятся до ACL, т.к. правила ACL могут учитывать факт наличия кэшированного объекта и, допустим, смягчать политику для каких-то категорий пользователей.
dandy пишет: исходники 4-ки пока недоступны
Это исходники 3-ки уже недоступны, т.к. давно заменены на 4-ку — они (прокси-часть) доступны по прежнему адресу на CVS на acfreeproxy.sf.net.
dandy пишет: восстановить полную логику работы обработчика запроса достаточно нетривиально
Как раз на порядок проще, чем в E3. Собственно вся логика обработчика запроса полностью находится в этой маленькой функции "http-proxy\OnRequest", которую вы цитируете. Незнакомыми (по E3) командами там могут быть только SelectTPlan и GetHostRubric, которые наверное не требуют пояснения благодаря понятному имени и тривиальному использованию в этой функции.
Ок. С этим понятно, спасибо!
Андрей, а что надо сделать чтобы включить в Е4 вторизацию в AD? При создании проекта/домена тип авторизации даже не спрашивается, а потом ни в свойствах проекта, ни в свойствах домена его сменить с E4Auth на что-либо другое невозможно.
И можно ли привязывать учетную запись в проекте/домене к учетной записи в AD?
P.S. сервер с прокси введен в AD, но контроллером домена не является
dandy пишет: что надо сделать чтобы включить в Е4 вторизацию в AD?
Ничего специального делать не надо. Если пароль не совпал с сохраненным в базе, то производится проверка в AD, результат проверки опять же кэшируется локально (т.к. опыт использования AD-авторизации в E3 показал, что во многих ЛС AD тугодум). Детально этот процесс описывался недавно в другой теме.
это все замечательно, но вот как привязать доменных пользователей (пользователей AD) к проекту и назначить им роли ни в одной теме форума, как и в "документации" (подсказках) самого сервера об этом вообще ничего не сказано...
Есть предположение, что их (пользователей) нужно еще локально дублировать, но это (при количестве пользователей >100) становится удручающим, а инструментов импорта из AD я так же не нашел...
Нет, так тоже не получается... есть Windows домен paints, авторизация в котором, согласно логам проходит (т.е. прокси через NTLM авторизует пользователей). Создал проект test в нем домен paints и локальных пользователей domain_user (такой же пользователь есть в AD) и notdomain_user. При авторизации последнего в логе получаю:
dandy пишет: но вот как привязать доменных пользователей (пользователей AD) к проекту и назначить им роли ни в одной теме форума, как и в "документации" (подсказках) самого сервера
'подсказка на главном экране консоли управления' пишет: Для добавления пользователя в группу или подключения к проекту можно перетащить мышью название его учетной записи из списка в средней панели на название группы или проекта в дереве левой панели. Аналогично производится подключение доменов к проектам.
dandy пишет: инструментов импорта из AD я так же не нашел
Пользователи NT-доменов автоматически импортируются при установке Eserv/4. Если E4 ставится с нуля, то они импортируются в автоматически создаваемый проект, имя которого совпадает с именем машины. Если при установке указывается импорт из E3, то имена проектов совпадают с именами источников авторизации E3, при этом источники авторизации со способом авторизации auth_nt импортируются как NT-домены, и в дальнейшем E4 опознает их как NT-синхронизируемые домены по наличию пользователя iusr_имямашины. Далее во время работы (авторизации пользователей в любом из протоколов) при необходимости производится автосинхронизация учетных записей, как описано в указанной выше теме форума.
Андрей, повторю вопрос еще раз: но вот как привязать доменных пользователей (пользователей AD) к проекту и назначить им роли
под доменными пользователя я понимаю пользователей AD ! которых с "списке в средней панели нет". Еще раз перефразирую ворос так:
как привязать пользователей Active Direcotory, которые авторизуются с использованием NTLM, но которых НЕТ в списке локальных пользователей Eserv (если их добавлять, то роли все равно для них не устанавливаются — см. выше)
dandy пишет: автризация проходит, но ни проекта, ни роли пользователю не назначаются, соотвественно согласно ACL он блокируется
В E3 пользователи внешних источников авторизации (не E3-MD5) существовали "виртуально" — в памяти в контексте сессии. В E4 любой авторизованный пользователь (независимо от того, как авторизованный) обязательно имеет "материальное" отражение в локальных списках учетных записей. Т.е. этого domain_user@paints вы найдёте среди учетных записей, и в свойствах учетной записи можете указать его роль.
dandy пишет: которые авторизуются с использованием NTLM, но которых НЕТ в списке локальных пользователей Eserv
dandy пишет: domain_user@paints (1,1,/,_5(0))
По приведенному логу читаем "пользователь_domain_user@в_домене_paints (NTLM_UID=1,ESERV_UID=1, проект_не_назначен/роль_не_назначена, в_интернет_не_пускает_правило_ACL_номер_5)". Следовательно пользователь этот ЕСТЬ в списке локальных пользователей, под номером 1. Раз пользователь вне проектов, то искать его в дереве проектов нет смысла — ищите в корне (в консоли управления нажмите на "Пользователи") или поиском по имени (в левом верхнем углу поле ввода "Поиск"). Найдёте учетную запись, установите проект/роль — и всё заработает. Интересно, каким образом этот первый пользователь у вас создавался, что получился таким "отвязанным"... Лог установки E4 не сохранился? (E4-setup.log в каталоге, откуда вы запускали Eserv424-setup.exe).
на клиенте (на машине из AD и из-под пользователя AD) настраиваем браузер на использование NTLM (любой браузер — Firefox или IE)
подключаемся к любому сайту через прокси
В логах видим такую картину:
2010-10-15 17:58:16; 172.16.1.99;98;0;1;16;- (0,0,/,) TCP_DENIED/407 139 GET http://pagead2.googlesyndication.com/pagead/imgad?id=CO24soS1_ZCtngEQoAEY2AQyCOBYrRlYVVMn DIRECT/ - 0 98 98 08-00-27-F4-CE-EC unknown() 8687;76687;0;0 0;;(172.16.1.99,19114);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-15 17:58:16; 172.16.1.99;85;0;4;593;amatveev@PAINTS (1,1,/,) TCP_MISS/200 1353 GET http://dd.c5.b8.a1.top.mail.ru/counter?id=1596877;t=210;js=13;r=http%3A//yandex.ru/yandsearch%3Ftext%3D12345678910111213141516171819202122232425262728293031%26lr%3D2;j=false;s=1280*899;d=24;rand=0.00848402216403854 DIRECT/94.100.185.26 image/gif 0 172.16.1.254 85 85 08-00-27-F4-CE-EC NTLM(amatveev) 2281;6259;4021;70198 1;;(amatveev@PAINTS,206679);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-15 17:58:16; 172.16.1.99;99;0;1;15;- (0,0,/,) TCP_DENIED/407 424 GET http://www.gcl.ru/main/banners/type_7/163.gif DIRECT/ - 0 99 99 08-00-27-F4-CE-EC NTLM() 28266;41600;0;0 1;;(172.16.1.99,19253);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-15 17:58:16; 172.16.1.99;86;0;4;672;amatveev@PAINTS (1,1,/,) TCP_MISS/200 942 GET http://gamesportal.lt/images/bottombg.jpg DIRECT/207.182.135.3 image/jpeg 0 172.16.1.254 86 86 08-00-27-F4-CE-EC NTLM(amatveev) 1401;4532;2462;7376 1;;(amatveev@PAINTS,206679);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-15 17:58:16; 172.16.1.99;97;0;3;437;amatveev@PAINTS (1,1,/,) TCP_MISS/200 1120 GET http://counter.rambler.ru/top100.scn?1629150&rn=221954669&rf=http%3A%2F%2Fyandex.ru%2Fyandsearch%3Ftext%3D12345678910111213141516171819202122232425262728293031%26lr%3D2&pt=Flash%20%D0%B8%D0%B3%D1%80%D1%8B%20%2F%20Flash%20%D0%B8%D0%B3%D1%80%D1%8B%20%2F%20%D0%92%D1%81%D0%B5%20%D0%B6%D0%B0%D0%BD%D1%80%D1%8B&en=windows-1251&fv=10.0%20r42&ja=0&cd=24-bit&sr=1280x899&la=ru&tz=-240 DIRECT/81.19.88.80 image/gif 0 172.16.1.254 97 97 08-00-27-F4-CE-EC NTLM(amatveev) 2562;8517;4334;8553 1;;(amatveev@PAINTS,215930);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-15 17:58:16; 172.16.1.99;95;0;3;390;amatveev@PAINTS (1,1,/,) TCP_MISS/200 776 GET http://pagead2.googlesyndication.com/pagead/js/abg.js DIRECT/74.125.77.166 text/javascript; 0 172.16.1.254 95 95 08-00-27-F4-CE-EC NTLM(amatveev) 1989;10933;5848;8317 1;;(amatveev@PAINTS,217283);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-15 17:58:17; 172.16.1.99;100;0;1;16;- (0,0,/,) TCP_DENIED/407 424 GET http://gameboss.ru/gfx/small/894-small_pic.jpg DIRECT/ - 0 100 100 08-00-27-F4-CE-EC NTLM() 26500;43687;0;0 1;;(172.16.1.99,19677);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-15 17:58:17; 172.16.1.99;101;0;1;109;- (0,0,/,) TCP_DENIED/407 424 GET http://gameboss.ru/gfx/small/191-small_pic.jpg DIRECT/ - 0 101 101 08-00-27-F4-CE-EC NTLM() 4510;7436;0;0 1;;(172.16.1.99,20101);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-15 17:58:17; 172.16.1.99;102;0;1;0;- (0,0,/,) TCP_DENIED/407 424 GET http://gameboss.ru/gfx/small/339-small_pic.jpg DIRECT/ - 0 102 102 08-00-27-F4-CE-EC NTLM() 424;699;0;0 1;;(172.16.1.99,20525);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-15 17:58:17; 172.16.1.99;103;0;1;0;- (0,0,/,) TCP_DENIED/407 139 GET http://www.gcl.ru/main/banners/type_1/1096.gif DIRECT/ - 0 103 103 08-00-27-F4-CE-EC unknown() 139;541;0;0 0;;(172.16.1.99,20949);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-15 17:58:17; 172.16.1.99;100;0;2;109;amatveev@PAINTS (1,1,/,) TCP_MISS/200 5874 GET http://gameboss.ru/gfx/small/894-small_pic.jpg DIRECT/195.209.228.190 image/jpeg 0 172.16.1.254 100 100 08-00-27-F4-CE-EC NTLM(amatveev) 75307;22948;7576;74923 3;;(amatveev@PAINTS,221102);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-15 17:58:17; 172.16.1.99;102;0;2;31;amatveev@PAINTS (1,1,/,) TCP_MISS/200 4238 GET http://gameboss.ru/gfx/small/339-small_pic.jpg DIRECT/195.209.228.190 image/jpeg 0 172.16.1.254 102 102 08-00-27-F4-CE-EC NTLM(amatveev) 136709;57741;19064;135741 3;;(amatveev@PAINTS,221102);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-15 17:58:17; 172.16.1.99;101;0;2;31;amatveev@PAINTS (1,1,/,) TCP_MISS/200 3825 GET http://gameboss.ru/gfx/small/191-small_pic.jpg DIRECT/195.209.228.190 image/jpeg 0 172.16.1.254 101 101 08-00-27-F4-CE-EC NTLM(amatveev) 123387;57741;19064;122419 3;;(amatveev@PAINTS,221102);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-15 17:58:17; 172.16.1.99;96;0;3;672;amatveev@PAINTS (1,1,/,) TCP_MISS/200 981 GET http://gamesportal.lt/ads/adman.php DIRECT/207.182.135.3 text/html 0 172.16.1.254 96 96 08-00-27-F4-CE-EC NTLM(amatveev) 1459;5242;2459;3471 1;;(amatveev@PAINTS,217283);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
страница грузится, но частями, а браузер постоянно дает сообщения с просьбой авторизоваться. Как это вообще работает — непонятно! так как список локальных пользователей пуст, а в каталоге E4\conf\lists\ файла accounts.db3 вообще нет!
Его там и не должно быть. В Eserv файл с таким именем не используется.
dandy пишет: список локальных пользователей пуст
Где именно вы его смотрите? В дереве слева нажать на "Пользователи"... А проект "post-office" (в приведенном логе установки запись о его создании) тоже отсутствует?
Интересно было бы взглянуть еще на acWEB\acWEB.log и CONF\lists\directory.db3 (пришлите, пожалуйста, на support@eserv.ru).
с файлом напутал.. но и в таблице пользователей в directory.db3 никаких упоминаний о пользователях из AD, в том числе и том, что авторизовался на прокси через NTLM по приведенному выше логу, нет. А проект post-office есть, но в нем только локальные NT пользователя (пользователей AD там нет)
Ну вот. Я под конец недели торможу, а вы меня не поправляете. NTLM — это ведь такая штука, что пароли на сервер не передаются, т.е. Eproxy и кэшировать-то в этом случае нечего.
Отделил NTLM от "простоNT" авторизации. Теперь в acWEB4.log должна попадать детальная диагностика "по обозначенным выше моментам". Испытайте, пожалуйста, и присылайте лог, если что.
dandy пишет: по приведенному логу видно, что авторизация по NTLM проходит через раз...
По приведенному логу этого не видно, там никак не отражаются этапы авторизации. По строкам "407" можно сказать только то, что прокси не пускает неавторизованных (или частично авторизованных, как в случае с многошаговым NTLM-ным challenge-response, которые тоже все по 407 отвечаются, пока идёт процесс).
поставил, попробовал .... новый пользователь с ролью NT-imported создался
NTLM: Пользователя amatveev нет в локальной БД (gid=1 )
Добавляю в проект N1 с ролью 'NT-imported'.
AddUser:amatveev,6356ab3d02a1a82438666b8593c5cc44
- OK! uid=4
NTLM: Пользователь amatveev есть в локальной БД (uid=4 gid=1 role=NT-imported).
NTLM: Пользователь amatveev есть в локальной БД (uid=4 gid=1 role=NT-imported).
NTLM: Пользователь amatveev есть в локальной БД (uid=4 gid=1 role=NT-imported).
NTLM: Пользователь amatveev есть в локальной БД (uid=4 gid=1 role=NT-imported).
NTLM: Пользователь amatveev есть в локальной БД (uid=4 gid=1 role=NT-imported).
NTLM: Пользователь amatveev есть в локальной БД (uid=4 gid=1 role=NT-imported).
NTLM: Пользователь amatveev есть в локальной БД (uid=4 gid=1 role=NT-imported).
NTLM: Пользователь amatveev есть в локальной БД (uid=4 gid=1 role=NT-imported).
NTLM: Пользователь amatveev есть в локальной БД (uid=4 gid=1 role=NT-imported).
NTLM: Пользователь amatveev есть в локальной БД (uid=4 gid=1 role=NT-imported).
NTLM: Пользователь amatveev есть в локальной БД (uid=4 gid=1 role=NT-imported).
NTLM: Пользователь amatveev есть в локальной БД (uid=4 gid=1 role=NT-imported).
но, пользователя в интернет пускает частично, т.е. постоянно выдает окно авторизации, но тем не менее часть страницы отображает (часть запросов проходит)
лог:
2010-10-19 13:21:51; 172.16.1.99;19;0;1;0;- (0,0,/,) TCP_DENIED/407 139 GET http://www.kalibrovkaspb.ru/scan.htm DIRECT/ - 0 19 19 08-00-27-F4-CE-EC unknown() 139;476;0;0 0;;(172.16.1.99,316195);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-19 13:21:52; 172.16.1.99;20;0;1;15;- (0,0,/,) TCP_DENIED/407 424 GET http://www.kalibrovkaspb.ru/scan.htm DIRECT/ - 0 20 20 08-00-27-F4-CE-EC NTLM() 28266;37333;0;0 1;;(172.16.1.99,316334);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-19 13:21:52; 172.16.1.99;20;0;2;63;amatveev@paints (1,1,/NT-imported,) TCP_MISS/200 4311 GET http://www.kalibrovkaspb.ru/scan.htm DIRECT/90.156.201.69 text/html; 0 172.16.1.254 20 20 08-00-27-F4-CE-EC NTLM(amatveev) 68428;24000;7031;67952 3;;(amatveev@paints,88368);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-19 13:21:53; 172.16.1.99;21;0;1;0;- (0,0,/,) TCP_DENIED/407 139 GET http://www.kalibrovkaspb.ru/1.css DIRECT/ - 0 21 21 08-00-27-F4-CE-EC unknown() 139;524;0;0 0;;(172.16.1.99,316758);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-19 13:21:53; 172.16.1.99;20;0;3;31;amatveev@paints (1,1,/NT-imported,) TCP_MISS/304 254 GET http://www.kalibrovkaspb.ru/1.css DIRECT/90.156.201.69 - 0 172.16.1.254 20 20 08-00-27-F4-CE-EC NTLM(amatveev) 8193;68387;28516;145322 1;;(amatveev@paints,92679);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-19 13:21:54; 172.16.1.99;22;0;1;0;- (0,0,/,) TCP_DENIED/407 139 GET http://www.kalibrovkaspb.ru/_images/scan.jpg DIRECT/ - 0 22 22 08-00-27-F4-CE-EC unknown() 139;462;0;0 0;;(172.16.1.99,316897);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-19 13:21:54; 172.16.1.99;23;0;1;0;- (0,0,/,) TCP_DENIED/407 424 GET http://www.kalibrovkaspb.ru/_images/scan.jpg DIRECT/ - 0 23 23 08-00-27-F4-CE-EC NTLM() 424;546;0;0 1;;(172.16.1.99,317036);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-19 13:21:54; 172.16.1.99;23;0;2;250;amatveev@paints (1,1,/NT-imported,) TCP_MISS/200 27712 GET http://www.kalibrovkaspb.ru/_images/scan.jpg DIRECT/90.156.201.69 image/jpeg 0 172.16.1.254 23 23 08-00-27-F4-CE-EC NTLM(amatveev) 110848;5936;1716;110728 3;;(amatveev@paints,92933);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-19 13:21:54; 172.16.1.99;20;0;4;3500;amatveev@paints (1,1,/NT-imported,) TCP_MISS/200 372 GET http://counter.yadro.ru/hit?t26.1;rhttp%3A//www.kalibrovkaspb.ru/;s1280*899*24;uhttp%3A//www.kalibrovkaspb.ru/scan.htm;h%u041A%u0430%u043B%u0438%u0431%u0440%u043E%u0432%u043A%u0430%20%28%u043F%u0440%u043E%u0444%u0438%u043B%u0438%u0440%u043E%u0432%u0430%u043D%u0438%u0435%29%20%u0441%u043A%u0430%u043D%u0435%u0440%u043E%u0432%20%u0432%20%u0421%u0430%u043D%u043A%u0442-%u041F%u0435%u0442%u0435%u0440%u0431%u0443%u0440%u0433%u0435;0.809101672049753 DIRECT/88.212.196.69 image/gif 0 172.16.1.254 20 20 08-00-27-F4-CE-EC NTLM(amatveev) 106;858;497;1386 1;;(amatveev@paints,120645);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
2010-10-19 13:24:14; 172.16.1.99;44;0;1;32;- (0,0,/,) TCP_DENIED/407 139 GET http://forum.eserv.ru/ DIRECT/ - 0 44 44 08-00-27-F4-CE-EC unknown() 4343;28500;0;0 0;;(172.16.1.99,317460);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
Всё нормально. Вот возьмем три строки про kalibrovkaspb/scan: 1) сначала браузер отправляет неавторизованный запрос, Eproxy не пускает, просит авторизацию (с указанием списка поддерживаемых методов), 407, unknown(), 2) браузер передает первую стадию NTLM, прокси отвечает дайджестом, 407, NTLM(), 3) браузер передает финальный ответ NTLM-авторизации, поток авторизован, запрос выполняется, 200, NTLM(amatveev).
Можете включить PROXY[DebugNtlm]=1 и посмотреть внутренности процесса. Методом авторизации в прокси поставьте "NTLM", а не "NTLM/Basic", чтобы Basic точно не путался под ногами.
По поводу окна авторизации — его в случае NTLM вообще не должно быть (в этом вся "прелесть" NTLM), но Firefox и Опера так не считают. См. пост.
ок. для тестирования оставил только NTLM, при попытке подключить с машины из AD — происходит авторизация и в инет пускает, но при попытке подключиться с машины не в AD получаю в логе:
NTLM: Пользователя ANONYMOUS LOGON нет в локальной БД (gid=1 )
Добавляю в проект N1 с ролью 'NT-imported'.
AddUser:ANONYMOUS LOGON,1f037dbe7db73ccdb4caf8e91c1d8c39
NTLM: Пользователя ANONYMOUS LOGON нет в локальной БД (gid=1 )
Добавляю в проект N1 с ролью 'NT-imported'.
AddUser:ANONYMOUS LOGON,b6a8b3101e0dca0ea94d8647562c478d
NTLM: Пользователя ANONYMOUS LOGON нет в локальной БД (gid=1 )
Добавляю в проект N1 с ролью 'NT-imported'.
AddUser:ANONYMOUS LOGON,a6e6e1c4272b6bca32ac4e74fb4a7213
что в итоге дало мне 3! уч. записи ANONYMOUS LOGON Это так задумано?
Кроме того в логе проскакивают:
ntlm_thread2_err:583
ntlm_thread2_err:583
ac пишет: По поводу окна авторизации — его в случае NTLM вообще не должно быть (в этом вся "прелесть" NTLM), но Firefox и Опера так не считают. См. пост.
Андрей, при включении опции network.auth.force-generic-ntlm=true FF 3.6.10 вообще перестает авторизовываться на Eproxy через NTLM
Методом авторизации в прокси поставьте "NTLM", а не "NTLM/Basic", чтобы Basic точно не путался под ногами.
Если вообще убрать BASIC, то как тогда добиться такого: если текущий пользователь входит в AD и подключается к прокси, то авторизация проходит через NTLM (т.е. скрыта от пользователя), но если подключение происходит с недоменной учетной записи (например, новый ПК или серевер), то прокси спросит принудительно пароль (через метод BASIC) и пользователь его введет в окне браузера?
Без Basic этого не добиться, да (разве что еще IP-авторизацией). Отключить basic я предлагал для "просмотра внутренностей процесса" (для гарантии, что браузер не переключится на basic, если NTLM не получается). А в обычной работе, конечно, он полезен.
dandy пишет: Андрей, при включении опции network.auth.force-generic-ntlm=true FF 3.6.10 вообще перестает авторизовываться на Eproxy через NTLM
В общем, бардак у них с NTLM.
dandy пишет: ntlm_thread2_err:583
Это Eserv детектирует вторую попытку NTLM-авторизации в одном коннекте, считает это ошибкой клиента, о чем считает своим долгом предупредить. Тем не менее продолжает процесс авторизации и, если в логе далее нет "AcceptSecurityContexterror", то ошибка успешно обойдена. Наверное этот вывод тоже заберу под флаг NtlmDebug, чтобы не мусорил.
ac пишет: Тогда давайте текущий directory.db3 на support@.
данные выслал
ac пишет: В общем, бардак у них с NTLM.
но пользователям-то что делать? Сейчас получается, что при загрузке страницы часть запросов прокси отфутболивает по 407, что приводит к тому, что страница загружается частично. И чтобы нормально ее (страницу) загрузить, надо по 2-3 раза страницу рефрешить. Ну, это ведь не дело ... к тому же установка на скорую руку squid-a с авторизацией в домене показала, что тот же самый FF начинает себя чувствовать гораздо лучше (по крайней мере страницы отрисовывает полностью)
dandy пишет: установка на скорую руку squid-a с авторизацией в домене показала, что тот же самый FF начинает себя чувствовать гораздо лучше
Расскажите, как на скорую руку установить squid с NTLM-авторизацией — тогда наверное смогу сравнить их сессии и найти отличия. У меня ни разу не получилось добиться от squid'а работы с ntlm
dandy пишет: IE окно с авторизацией не выдает и страницу грузит полностью.
Т.е. читаю так, что на текущий момент проблем у связки IE+E4 не выявлено.
dandy пишет: а вот второй с uNtlmStep == 1 уже "понял", что перед ним NTLM
Потоки 90 и 91 связаны (судя по URL) — в 90м Firefox получил отлуп (с указанием методов авторизации), отключился, и в 91м сразу начал с авторизацией.
dandy пишет: при авторизации — (0,0,/,) выдал TCP_HIT/200, с чего бы это?
Точно, с текущим конфигом выдача из кэша возможна без авторизации. Чтобы это отключить, надо заменить в OnStartupIF S" ProxyUnauthorized PROXY" EVALUATE THEN на IF S" ProxyUnauthorized PROXY" EVALUATE EXIT THEN.
dandy пишет: Запостил и случайно удалил вместо редактирования свое сообщение можно восстановить?
Я уже на него успел ответить Вот на что отвечал:
ac пишет: Так может оно вообще уже напрочь не работает? (А то, что показывает — берет из кэша). InternetExplorer как себя ведёт в той же ситуации?
я вам сразу сказал, что NTLM в E4 работает крайне странно...
IE ведет себя на порядок лучше (407) ошибки в логе прокси есть, но хоть окно с авторизацией не выдает (этот момент буду наблюдать дальше) и, вроде, страницу грузит полностью.
Андрей, тогда объясните мне вот такой кусок лога:
2010-10-19 19:31:30; 172.16.1.99;87;0;3;500;amatveev@paints (1,1,/NT-imported,_1(4)) TCP_CLIENT_REFRESH/301 587 GET http://newsrss.bbc.co.uk/rss/russian/news/rss.xml DIRECT/92.123.155.67 text/html; 0 172.16.1.254 87 87 08-00-27-F4-CE-EC NTLM(amatveev) 1174;6626;3336;1892 3;;(amatveev@paints,761298959);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
[b]2010-10-19 19:31:31; 172.16.1.99;90;0;1;0;- (0,0,/,) TCP_DENIED/407 107 GET http://wsrss.bbc.co.uk/russian/index.xml DIRECT/ - 0 90 90 08-00-27-F4-CE-EC unknown() 107;794;0;0 0;;(172.16.1.99,2217515);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10[/b]
2010-10-19 19:31:31; 172.16.1.99;80;0;4;546;amatveev@paints (1,1,/NT-imported,_1(4)) TCP_CLIENT_REFRESH/301 478 GET http://www.bbc.co.uk/russian/index.xml DIRECT/212.58.244.69 text/html; 0 172.16.1.254 80 80 08-00-27-F4-CE-EC NTLM(amatveev) 875;8236;5142;48666 3;;(amatveev@paints,761315129);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
[b]2010-10-19 19:31:31; 172.16.1.99;91;0;1;328;- (0,0,/,) TCP_HIT/200 275177 GET http://wsrss.bbc.co.uk/russian/index.xml DIRECT/ application/xml 0 91 91 08-00-27-F4-CE-EC NTLM() 838954;2710;0;0 1;;(172.16.1.99,2217622);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10[/b]
собственно интересуют два потока: 90 и 91 (ранее их ID в логе не встречаются)
90-ый был отфутболен с TCP_DENIED/407, UsedAuthMethod == unknown и uNtlmStep == 0 , а вот второй (91-ый) с uNtlmStep == 1 уже "понял", что перед ним NTLM (UsedAuthMethod == NTLM), но! при авторизации — (0,0,/,) выдал TCP_HIT/200, с чего бы это?
dandy пишет: Андрей, при включении опции network.auth.force-generic-ntlm=true FF 3.6.10 вообще перестает авторизовываться на Eproxy через NTLM
Сейчас проверил Firefox/4.0b6 — NTLM-авторизация на E4 срабатывает только при network.auth.force-generic-ntlm=true. Может еще от комбинаций версий ОС (клиентской и AD) как-то зависит.
Opera 10.62 окно с запросом пароля выводит, но никаких доп.настроек не требует, работает из коробки.
Safari 5.0.2 работает с NTLM прозрачно — пароль не спрашивает, как и IE.
Chrome 8.0.552.5 dev тоже всё нормально, без вопросов.
С последним обновлением FF, на удивление, стал работать гораздо лучше — окно авторизации перестало появляться (думаю, это был эффект, как раз от выдачи страницы из кэша прокси для неавторизованных сессий), да и страницы стали грузиться целиком
Осталась только проблема со связкой авторизаций "NTLM,Basic"
Авторизация по NTLM проходит "тихо", ничего не спрашивая, а при подключении с машины не входящей в AD появляется окно авторизации, но только никакие авторизационные данные локальных (из пользователей самого Eserv-a) пользователей (пробовал с указанием локального домена и без него) не подходят. Подходят только логины и пароли пользователей AD
в логе для попыток авторизоваться через окно авторизации в браузере получаю:
при первой попытке открыть запрошенный URL прокси в лог записал первую строку, а браузер выдал окно авторизации. После ввода параметров (master@127.0.0.1 <- домен по умолчанию в Е4) прокси записал в лог последние 2 строки и браузер опять выдал окно авторизации. Судя по логу, прокси даже не попытался "опознать" локальный домен и авторизовать сессии в режиме BASIC, а должен был...
Прокси использует Basic-авторизацию, если клиент передает соответствующий заголовок. В данном случае не прокси не пытался, а клиент. А при NTLM прокси просто тупо передает все пакеты авторизации соответствующим функциям винды, не пытаясь заглядывать внутрь, потому что ловить там нечего — те хэши, которые там передаются вместо пароля, для прокси (в данном случае играющего роль man-in-midle между клиентом и AD ) ничего не значат.
Передаваемый открытым текстом логин прокси видит, его он и пишет в скобках после NTLM, но проверить его правильность без пароля не может. А логин это может быть "с потолка". На моей машине, например, так и получается (с тех пор, как прошлой осенью разработчики FF фактически поломали, точнее заменили, отлично до того работающий свой NTLM-клиент) — при первой (автоматической) попытке NTLM-авторизации Firefox передает в прокси логин 'cherezov', хотя ни в локальной SAM, ни в сетевом AD такого NT-логина вообще нет. Под 'cherezov' я вхожу только в VPN, да и то не в ЛС, а в провайдерскую сеть Соответственно винда такой левый логин проверить по AD не может, отвергает, прокси соответственно тоже, вот тут и появляется окно запроса пароля.
Вообще в текущей ситуации с FF вы ничего не выиграете от NTLM по сравнению с Basic, т.к. запрос пароля в FF случается в любом случае, и basic при локальной неудаче проверит пароль в AD, т.е. сработает (с точки зрения пользователя) так, как сработал бы NTLM. Разница получается только в возможностях перехвата паролей — но эта разница для хакера, а не для пользователя. Для пользователя же Linux (в вашем логе) получается, что FF вообще не удается авторизоваться по NTLM, потому что при поломке NTLM новые авторы FF вообще не нашли способа передать введенный пользователем пароль. Под Windows этот способ есть — пятый параметр функции AcquireCredentialsHandle (Eserv его тоже использует при проверке авторизации по SAM при работе без AD), а в Linux'е для защиты от упомянутой "reflection vulnerability" старый способ отключили, а нового не подключили...
Kerberos и Negotiate упаковываются внутрь NTLM-пакетов (NTLMSSP), согласовываются в первых тактах взаимодействия, для прокси и браузера это прозрачно (если при инициализации "контекста безопасности" на сервере Eserv вместо просто "NTLM" указывает явно "Negotiate", то размер NTLM challenge становится толще, больше никакой разницы не видно). Сам сервер, на котором установлен Eserv, если этот сервер входит в AD-домен, при недоступности 88го порта AD проводит авторизацию через LDAP, причем использует при авторизации тот же NTLM (в этом я убеждаюсь, когда вместо AD ставлю Eserv), значит не считает его (NTLM) уязвимым/устаревшим и т.д.
Этот NTLMSSP в винде везде, куда ни плюнь, поэтому собственно и пришлось реализовать его поддержку (еще несколько лет назад — как вариант acl-plugin'а для Eproxy). Польза от него не только для "ленивых" пользователей, не желающих вводить пароль к прокси даже один раз, но и (в большей даже степени) — для тех сетевых сервисов, которым нужен HTTP (для обновлений, допустим), а прокси не пускает без пароля (а спросить пароль не у кого, если это системная служба). Раньше в таких случаях спасала IP-авторизация, теперь и NTLM, т.к. те сервисы, которые используют реализацию MS HTTP, даже "не замечают" того, что проходят через прокси, да еще и с авторизацией (прокси автоматом опознаётся через WPAD, авторизация автоматом проходит через NTLM), не требуют никаких телодвижений ни от пользователя, ни от админа.
Смотря что понимать под усилением безопасности... WebDav работает поверх HTTP, и в особых отдельных средствах не нуждается, по-моему. Если речь о безопасной аутентификации, то там достаточно SSL/TLS, тогда пароль можно передавать обычным Basic-способом. С другой стороны само наличие паролей и сертификатов уже можно считать опасностью — пароль можно подобрать, а сертификат стащить... Поэтому особо помешанные на безопасности банки используют out-of-band-схемы авторизации — передачу дополнительной информации по другим каналам — одноразовые пароли на карточках и в sms, и т.п. (зверски неудобно для пользователя, как и капчи). В итоге не протоколы уже усложняют, а сам доступ к протоколам Так что по части усложнения жизни народу Kerberos уже давно не перспективен Рано или поздно и доступ к интернету начнут лицензировать, и без спец-прав или спец-паспорта туда не пускать. Как в GSM-сети.
ну да а ntlm поверх tcp/ip
траффик в России ну оочень дорог! а попыток левых авторизаций больше чем вирусов!
"Рано или поздно и доступ к интернету начнут лицензировать"-вернемся к фидонет или к нашему вернее к нашей первой советской разроботке интернет сети(шутка)! а в частности, дискусия по прокси очень интересная тем более для меня — собираюсь покупать и мне важно стабильность безопасность функциональность — именно в таком порядке.
ac пишет: Прокси использует Basic-авторизацию, если клиент передает соответствующий заголовок. В данном случае не прокси не пытался, а клиент. А при NTLM прокси просто тупо передает все пакеты авторизации соответствующим функциям винды, не пытаясь заглядывать внутрь, потому что ловить там нечего — те хэши, которые там передаются вместо пароля, для прокси (в данном случае играющего роль man-in-midle между клиентом и AD ) ничего не значат.
...
ac пишет: Для пользователя же Linux (в вашем логе) получается, что FF вообще не удается авторизоваться по NTLM, потому что при поломке NTLM новые авторы FF вообще не нашли способа передать введенный пользователем пароль. Под Windows этот способ есть — пятый параметр функции AcquireCredentialsHandle
Вроде все логично и даже виновного нашли... вот только если поменять порядок авторизации на Eserv-e на "Basic,NTLM", то
а) в линуксе FF сразу дает окно ввода пароля и пароль локального Eserv пользователя ( в домене 127.0.0.1) подходит (чего не было при "NTLM,Basic") и дальше загрузка всех страниц происходит молча (по введенной 1 раз авторизации) — т.е. либо FF вдруг стал передавать введенный пользователем пароль (или всегда передавал?), либо Eserv вдруг научился его откуда-то доставать ...
б) Под Windows — IE молча авторизовался по NTLM и отдал страницу, а вот FF так же, как и в линуске, выдал окно с авторизацией и на попытку отказа, предлагал его снова и снова (в логах Eserv-а записей о NTLM вообще не было)
ac пишет: dandy пишет: Андрей, при включении опции network.auth.force-generic-ntlm=true FF 3.6.10 вообще перестает авторизовываться на Eproxy через NTLM
В общем, бардак у них с NTLM.
Андрей, какая странная штука попалась на глаза: при включении network.auth.force-generic-ntlm=true Wireshark на ответ сервера
dandy пишет: вот только если поменять порядок авторизации на Eserv-e на "Basic,NTLM", то
Из этого эксперимента можно сделать только один вывод — Firefox использует только первый из предложенных в списке методов аутентификации. Т.е. для него "Basic,NTLM"=="Basic", поэтому он и окно пароля сразу выводит, и NTLM при неудаче не испытывает. И с этим Basic работает нормально, как всю жизнь с ним нормально работал.
dandy пишет: в порядке бреда, можно попробовать сборку, которая отрезает лишние пробелы в заголовках ответов сервера...
Можно попробовать... Я даже когда-то пробовал — не помню, правда, для чего, с какими результатами, и почему остановился именно на варианте с пробелом.
ac пишет: Из этого эксперимента можно сделать только один вывод — Firefox использует только первый из предложенных в списке методов аутентификации. Т.е. для него "Basic,NTLM"=="Basic", поэтому он и окно пароля сразу выводит, и NTLM при неудаче не испытывает. И с этим Basic работает нормально, как всю жизнь с ним нормально работал.
наверное, в стандарте поведение в подобном случае четко не регламентируется
ac пишет: Можно попробовать... Я даже когда-то пробовал — не помню, правда, для чего, с какими результатами, и почему остановился именно на варианте с пробелом.
dandy пишет: наверное, в стандарте поведение в подобном случае четко не регламентируется
Может и четко регламентируется, но не за каждой буквой лезут в стандарт, особенно если популярный софт, с которым приходится быть совместимым, этого стандарта не придерживается. Тем более что меняются/исправляются/дополняются стандарты регулярно. Вот тот же NTLM вообще стандартом никогда не был — сначала сторонним (не-MS) разработчикам приходилось его reverse-engineering'ить, и только в последние 2-3 года MS начала публиковать свои бывшие ранее закрытыми спецификации.
Особых изменений, кроме как отсутствие жалоб Wireshark-a на Malformed Packet в сборке с обрезанием пробела, не замечено, как, собственно, и каких-либо проблем
dandy пишет: Анонимусы-то больше не размножаются, зато размножаются другие учетки. При авторизации по NTLM (успешной) новая учетная запись будет добавлена в список пользователей с ролью NT-Imported. Но если в списке учетных записей ее отключить (убрать флаг активности) и опять попробовать авторизоваться, но сервер создаст новую учетную запись с тем же именем и той же ролью NT-Imported.
А в acWEB.log что конкретно при этом пишется? Там вообще есть спец.обработка этой ситуации...
Вообще для NT-Imported можно установить минимальные права, тогда не будет никаких сюрпризов при автоимпорте.
ac пишет: А в acWEB.log что конкретно при этом пишется? Там вообще есть спец.обработка этой ситуации...
нет, в логе тишина и покой, а вот пользователь гость@paints появляется (плодится) снова и снова. А хочется ведь совершенно логичной вещи — если пользователь авторизовался (пусть по NTLM), но локальная учетка (в Есерв) отключена, то доступ блокируется. А получается, что если для роли NtImported есть что-то разрешенное, то будет создан дубликат локальной учетки, но уже не отключенный
ac пишет: Вообще для NT-Imported можно установить минимальные права, тогда не будет никаких сюрпризов при автоимпорте.
у меня как раз и выставлено для NtImported минимальные права на доступ к прокси (в инет можно только роли NnImported, а остальным нельзя). Но некоторых с NtImported (например гостей — гость@доменNT мне бы не хотелось пускать по понятным причинам, а так как эта запись появляется в списке локальных пользователей автоматически, то логичный способ закрыть доступ — отключить эту учетную запись, а не получается ...
Логичнее в ACL этой учётке запретить выход наружу. А отключать не совсем логично, поскольку в домене-то она не отключена, и авторизация-то на самом деле происходит, и деваться некуда — надо это с чем-то сопоставлять.
dandy пишет: нет, в логе тишина и покой, а вот пользователь гость@paints появляется (плодится) снова и снова.
В логе все-равно должно записаться что-то вроде этого: NT-пользователь не зарегистрирован! Добавляю в проект N1 с ролью 'NT-imported'. Это независимо от PROXY[DebugNtlm], хотя его тоже можно включить, чтобы подробности посмотреть.
Защита от дубликатов там на уровне БД по уникальности "имя:пароль:проект". Если авторизация прозрачная NTLM без пароля, то пароль пустой, все равно должно работать отсечение дублей. В общем, хорошо бы лог достать.
А кто под Гостем работает — программа обновления какая-нибудь (куда по логу он ломится?).
NTLM: Пользователя гость нет в локальной БД (gid=1 )
Добавляю в проект N1 с ролью 'NT-imported'.
AddUser:гость,6946d261e825e74bcd79d3e99ab2b88e
- OK! uid=45
NTLM: Пользователя гость нет в локальной БД (gid=1 )
Добавляю в проект N1 с ролью 'NT-imported'.
AddUser:гость,951c04661a70dfeb04b2921647391fc4
- OK! uid=46
NTLM: Пользователя гость нет в локальной БД (gid=1 )
Добавляю в проект N1 с ролью 'NT-imported'.
AddUser:гость,0a74913b0a7adabe0bc6155680695fbc
- OK! uid=47
а работает так Linux машина не введенная в домен...
Вот, нашел, вроде, закономерность:
подключаюсь браузером FF в Linux (ПК в домен не введен), NTLM не проходит и браузер спрашивает авторизацию (выдает окно для ввода логина и пароля) — realm пустой, а значит это запрос на авторизацию в AD
когда я ввожу логин и пароль _локального_ пользователя Есерв-а и создается "новый гость" (причем странно, логин и пароль я ввожу каждый раз один и тот же, а md5 хэш в логе всегда разный... — похоже на проблему FF, ссылку на которую вы приводили выше)
P.S. может стоит "ловить" дубликаты по связке логин:роль ?
с этим обновлением вернулась старая проблема с неучтенным "гостем", которого пускает в инернет всегда и никак не фиксирует его наличие в списке пользователей.
Прокси: авторизация: NTLM, basic
Пароль на доступ к HTTP-PROXY: Да
Проверка доступа: Ресурс/Роль/ACL
*/NT-imported/4
*/admin/4
*/Гость/0
в списке пользователей нет ни одного гостя (только реальные пользователи AD)
подключаюсь пользователем НЕ ИЗ AD! — пускает... в логе acweb.log чисто (нет ни слова про добавление нового пользователя) и в списке пользователей так же его нет. В логе прокси:
2011-02-04 17:58:53; 172.16.1.88;346;0;3;3812;гость@mk-ent-fs-1 (1,1,/,[NULL],) TCP_CLIENT_REFRESH/304 276 GET http://i032.radikal.ru/1101/97/094a1e146f2bx.jpg DIRECT/81.176.238.14 - 0 192.168.1.1 346 346 00-1D-70-BE-64-18 NTLM(гость) 72;853;211;64 3;;(гость@mk-ent-fs-1,3777172);Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Андрей, Вы же сами говорили, что Есерв для любого пользователя которого он смог авторизовать (например по NTLM) создает внутреннюю учетную запись в своей локальной базе. Здесь же "гость" в локальной базе Есерв-а НЕ создается! Поэтому ему нельзя дать НИ роли, НИ, соответственно, навесить ограничений.
ac пишет: В E4 любой авторизованный пользователь (независимо от того, как авторизованный) обязательно имеет "материальное" отражение в локальных списках учетных записей. Т.е. этого domain_user@paints вы найдёте среди учетных записей, и в свойствах учетной записи можете указать его роль.
т.е. я ожидал увидеть в логе что-то вроде:
NTLM: Пользователя Гость нет в локальной БД ... Добавляю в проект N1 с ролью 'NT-imported'. AddUser:Гость,...- OK! uid=...
Это результат борьбы с вашими прежними проблемами — размножением гостей
dandy пишет: Здесь же "гость" в локальной базе Есерв-а НЕ создается!
Потому что оно невозможно без размножения (в принятой в E4 схеме разрешения неуникальности имён — нескольких одинаковых имён с разными паролями). Но ничто не мешает вам создать в базе Eserv'а гостя вручную.
Я конечно попробую этот вариант, но мне не совсем понятен один момент: сейчас уникальность определяется связкой имя:пароль:проект (т.е. в одном проекте может быть два! пользователя с одним именем, но разными паролями) в чем здесь смысл? Почему нельзя использовать классический подход, когда уникально имя? (т.е брать уникальность по связке имя:проект) ?
Андрей, а можно ли для определенной группы (роли) добавить возможность (через ACL?) как действие выдавать запрос на авторизацию? т.е. для прав доступа 0 иметь возможность задать, выдавать ли вместо отказа окно авторизации или нет.
Как обычно, торможу по пятницам. Есть ведь более простой способ запросить перелогиниться — просто поставить флажок "X" в этом ACL. Помню, что где-то писал об этом в документации, но сейчас сам не нашел Напишу на более видном месте.
dandy пишет: Я конечно попробую этот вариант, но мне не совсем понятен один момент: сейчас уникальность определяется связкой имя:пароль:проект (т.е. в одном проекте может быть два! пользователя с одним именем, но разными паролями) в чем здесь смысл? Почему нельзя использовать классический подход, когда уникально имя? (т.е брать уникальность по связке имя:проект) ?
dandy пишет: Почему нельзя использовать классический подход, когда уникально имя?
Имя не уникально. Я Андрей, и вы Андрей. "Классически" имена уникальны только в пределах какого-то контекста. Наличие технической возможности иметь разные пароли для одного логина дает нам ещё одну степень свободы, не отнимая имеющиеся. Там, где важны уникальные имена (для однозначной визуальной идентификации в условиях "невидимости" пароля для идентифицирующего) мы можем проверять уникальность имени — например, так делается на форуме. А в других случаях нам полезна неуникальность:
при импорте (или переносе) пользователей из двух несвязанных ранее источников в один;
в распределенной системе, когда моментальная синхронизация списков невозможна;
при автосоздании пользователей — чтобы вновь созданный с другим паролем пользователь не приводил к неработоспособности предыдущего его логина (и срочной перенастройке почтового клиента и т.д.)
при смене пароля, если уведомление/запрос на подтверждение посылается на тот же Email;
при необходимости предоставления одному и тому же логину в одном и том проекте другой роли (например, временного повышения полномочий, как в виндовом UAC) достаточно создать тот же логин с другой ролью, а для их отличия использовать разные пароли;
поддержка дополнительных способов авторизации, где вообще нет пароля или он неизвестен серверу (X.509,дайджесты,OpenID и т.п.); что не должно мешать тому же пользователю явно авторизоваться с паролем в тех случаях, когда того требует выбранный протокол; вместо добавления нового столбца для каждой новой схемы просто размножаем учетную запись и в поле пароля пишем хэш источника для связывания, т.е. plugin'ы авторизации не требуют изменения общей схемы БД;
и т.п.
В общем "много — не мало", лучше чтобы было. В большинстве случаев эти внутренние механизмы могут быть полностью скрыты от пользователей, поэтому не должны приводить к какой-то путанице.
Спасибо за разъяснения, но считаю, что такая позиция достаточно спорная, особенно в свети того, что Есерв позиционирует себя как набор серверов для корпоративного использования, где стандартом де-факто является доменная организация с Active Directory, где велосипед давно изобретен и контекст уникальности логинов (идентификаторов) четко обозначен (кстати, как раз в АД неуникальность нам как раз НЕ полезна, так как только создаст проблем при авторизации в АД)
ac пишет: Это вы про ту проблему, которую мы недавно с вами исправляли?
в том числе.
Кстати, ту проблему мы не исправили, а только нашли workaround, так как считать гостя АД всегда неавторизованным, возможно, в некоторых конфигурациях будет неправильно (например если нужно выпускать "гостей" только на заданные сайты, а получается, что роли такому "гостю" задать нельзя) — т.е. предложенное Вами решение мне подходит, но восторгов (эстетических) не вызывает
ac пишет: Как обычно, торможу по пятницам. Есть ведь более простой способ запросить перелогиниться — просто поставить флажок "X" в этом ACL. Помню, что где-то писал об этом в документации, но сейчас сам не нашел Напишу на более видном месте.
Кстати, предложенный Вами вариант имеет существенное ограничение: если указать в настройках прокси NTLM / Basic, то в предложенный варианте авторизация по basic вообще не проходит — т.е. даже не появляется запроса на авторизацию
причем, на машине НЕ в домене (с ОС linux) нормально, а вот под Windows с машины в домене с IE появляется окно авторизации в домене (т.е. NTLM не срабатывает), но никакие авторизационные данные не подходят и в логе для этой машине что-то странное, то Гость, то пользователь...
другой теме
! которых с "списке в средней панели нет". Еще раз перефразирую ворос так:
описание файла 1
Вот на что отвечал:
