Хочу описать свою проблему. Может быть ее решение, которе я надеюсь здесь получить, будет интересно и другим.
Дано:
- Домен NT
- на другом сервере Eproxy 3 (без PigProxy!).
- В качестве домена авторизации — наш NT домен.
- UrlBlackList выглядит так: "*";;;"AU"
- UrlWhiteList выглядит так: "http://*mail.ru/*";"*";;"http://*tara.ru/*";"*";;"http://*yandex.ru/*";"*";;"*";"моя_личная_доменная_учетка";;
- IE при каждом запуске спрашивает авторизацию.
- Авторизация по доменным именам проходит нормально.
- На три разрешенных сайта попадает каждый авторизованный
- Я могу ходить куда угодно.
Eproxy игнорирует доменные группы. Если вместо "*";"моя_личная_доменная_учетка";; я напишу "*";"моя_доменная_группа";; то я уже никуда, кроме трех разрешенных сайтов не попаду.
Как это исправить?
Я просто завёл локальные группы на самой прокси-машине, куда кооптировал нужных пользователей домена.
USER;IN_GROUP mikkie@lanknet;Elog@lankpost pig@lanknet;Elog@lankpost merlin@lanknet;Elog@lankpost pig@lanknet;test@virtual
Видимо, это что-то записанное там по умолчанию.
Где в Вэбинтерфейсе можно его редактировать?
Как создавать такие группы?
А создать группу просто. Домен авторизации вы знаете. Следовательно, пишете:
И эту придуманную группу указываете в ACL.
Ничего не вышло
Уточните, пожалуйста, придуманную группу надо писать в придуманном домене (как в примере, который приведен по умолчанию в ExtendedGroupsList (см выше)) , или в реальном моем NT домене (как рекомендовали Вы)?
В ACL надо писать "группа@домен", или достаточно просто "группа"?
Впрочем, я по-всякому пробовала. НЕ ПОЛУЧАЕТСЯ!
Может быть придуманный домен надо записать в список доменов как NT домен?
У меня более 70 юзеров. Толково прописать доступ без ГРУПП не реально — придется писать более 1000 строк в ACL.
Придумайте что-нибудь!
Как это проверить?
Выбираете службу Eproxy, и устанавливаете вход в систему с учетной записью администратора, желательно домена
Попробуйте группа@домен
Хотя должно работать и без домена, если в ExtendedGroupsList группа отнесена к домену по умолчанию (DefaultDomain).
А вообще покажите ваши настройки. Если здесь страшно, то в http://www.eserv.ru/Support
Что в них не так? Жду помощи. Номер обращения 5547.
Local System не имеет никаких прав за пределами машины, где работает. А для получения состава группы нужны права как минимум администратора этой группы.
Я добавила .ru в вымышленные группы ExtendedGroupsList и смогла-таки сделать разграничение доступа по группам. Вроде бы все работает. Тему можно было бы закрыть, но напоследок ма-а-ленький вопросик:
Если в UrlWhiteList есть строчка:
"*";"группа с большим доступом";;
А весь UrlBlackList состоит всего из одной строчки:
"*";;;"AU"
Есть ли возможность так дополнить UrlBlackList так, чтобы некоторые нехорошие сайты стали недоступными даже для "группы с большим доступом"?
Все получилось. На нехорошие сайты теперь не пускают никого.
Все работает почти хорошо, но есть одно "но".
Всем авторизовавшимся можно заходить только на ограниченное число сайтов, описанных в UrlWhiteList. Их туда пускают, но требование авторизоваться вылезает иной раз по десять раз. Причем свой доменный пароль юзер обязан ввести только в первый раз, далее он может спокойно нажимать ESC и на сайт его в конце концов таки пустят. Но уж очень противно, когда, чуть ли не каждые 10 секунд это окно вылезает. Юзера меня повесят.
Это как-нибудь лечится?
Кстати, у группы с большим доступом такой проблемы нет. Авторизация спрашивается только один раз. И у простых юзеров такое происходит не на всех сайтах. На www.vw-autotrade.ru происходит, а на www.tara.ru — нет.
Это, действительно, левые ссылки: реклама и счетчики. Их отлов — высокое искусство.
Постепенно все приходит в норму.
А может ли Eproxy авторизовать пользователей из другого (неродного) домена?
И как тогда описывать группы?
Уточняю:
Переводим всех пользователей в другой домен. решили перетащить и сервер с Eproxy.
Как обеспечить одновременную работу из обеих доменов.
Установили прокси на машину в новом домене, скопировали содержимое каталога, настроили новый IP. Домен не трогали.
Ни IP, ни принудительная авторизация не работают.
В 200807acl.log пишет
2008-07-22 16:00:38;10.82.0.34;0;pae@stavropol.so;HostBlackList;TCP_DENIED;www.ya.ru;*;;;AU
В ExtendedGroupsList.txt:
pae@stavropol.so;ad@rdupak
В HostWhiteList.txt:
"*";"ad@rdupak";;
В Eserv3\CONF\lists\proxy\trafc\RulesList.txt:
"IsGroupMember: ad@rdupak";"ad_ 5 Priority! \EOF";
Другой домен чего? Если AD, то сложно. Подозреваю, что нужны как минимум доверительные отношения между доменами, иначе авторизации не будет.
Тут ещё главное — чётко представлять, что у Eserv свои собственные домены, а отображение их на AD или что-то ещё настраивается через источники авторизации. То есть, можно всё передвинуть так, что пользователи ничего не заметят (если, конечно, логины/пароли в старом и новом источнике совпадают).
Что в DATA\log\stat\200807auth.txt?
На поверку вышло, что пока не работает...
При авторизации пробовали использовать имя пользователя как в формате "user@doman", так и "user". результат одинаковый.
Список пользователей старого домена через Web-интерфейс доступен (читается).
Соответствующая строка из AuthSource.txt:
"stav";"auth_nt";"rdudc1.stavropol.so";
Есть одно (одно из) сомнение — в Eserv3.orig.ini тип авторизации по умолчанию —
DefaultAuthSource="Eserv"
В Eserv3.ini параметр не указан.
Да, а пользователи старого домена имеют на новом прокси право доступа по сети?
(В прежнем домене в AuthSource использовали имя домена "stavropol.so", имя контроллера добавили в исследовательских целях)
Пользователи старого и нового домена находятся в одной IP-сети, это одна организация.
Проверку работы прокси (клиентское HTTPP-подключение) делал с консоли самого сервера (где установлен Eproxy) в новом домене с использованием данных пользователя из старого домена.
Или же не отрабатывает идентификация принадлежности к группе, допущенной в HostWhiteList.txt?
Почему в конце строки в *acl.log стоит *;;;AU?
Не проходит:
Поэтому повторяю вопрос о правах пользователей — пользователям старого домена на новом прокси политиками AD сетевой доступ к машине разрешён? Видеть список пользователей — это одно, а пройти авторизацию пользователем — совсем другое.
У меня в таких случаях просветление обычно наступает после заглядывания в журнал безопасности прокси-машины. Надо только включить аудит событий входа в систему.
Если безопасности в целом, то он уже включен (т.е. в системном журнале "Безопасность" полно записей, но там не регистрируются мои обращения).
Сейчас ввел даже этого пользователя в группу локальных администраторов сервера, где установлен Eproxy
В Local Security Settings включен полный аудит в политиках:
Audit account logon events (success, failure)
Audit logon events (success, failure) отказы есть, но не относятся к моим попыткам
Столкнулись с некоторыми сложностями:
Установили Eproxy на сервер в новом домене, скопировали содержимое каталога с Eproxy (в старом домене), откорректировали списки и INI-файлы.
При обращении клиента прокси выдает: "Disabled by Admin"
Кстати, мы не имеем доступа к управлению новым доменом, нам выдали полномочия по управлению одним OU — домен у нас корпоративный, а мы филиал.
Вернулась прежняя ошибка "Unauthorized (PROXY)"
"oduyu";"auth_nt";"oduyu.so";
Выяснили, что авторизация проходит нормально.
По-крайней мере, если в HostWhiteList выставить
"*";;; то пользователя (из домена ODUYU) пускает только если ввести правильный пароль.
При неправильном пароле выдается тот же "Unauthorized (PROXY)", но в *acl.log ничего не пишет. В Log\Stat\*auth.txt пишет
Сейчас поставили в ExtendedGroupsList суффикс групп "@oduyu.so" и все заработало.
Теперь неплохо бы еще разобраться со вторым доменом (старым), чтобы с этого же сервера и его пользователей обслужить на время миграции, чтобы за двумя серверами не следить...