Форум OlegON > Компьютеры и Программное обеспечение > Сеть

Кросс доменная Kerberos авторизация : Сеть

29.03.2024 12:02


12.12.2014 11:51
Micle
 
Есть эксперты? Существует задача сделать прозрачную авторизацию на Apache причём по внешнему доменному имени.

Детали заключаются в следующем:
- есть внутренний домен называется он к примеру MKS.local
- в домене есть KDC, который раздаёт ключи
- Apache прописан по внутреннему адресу
Код:
http://www.MKS.local
и при этом прекрасно авторизует пользователей при обращении к себе через внутреннее доменное имя.
- так же тот же самый апач принимает запросы из вне. Наружный домен является официально зарегистрированным доменным именем например firma.ru, апач охотна раздаёт страницу по адресу
Код:
http://www.firma.ru
Нужно прикрутить прозрачную авторизацию пользователей домена MKS.local через керберос на
Код:
http://www.firma.ru
. Как правильно приготовить всё?
12.12.2014 12:48
OlegON
 
Не силен я в апаче, забыл уже все, поскольку брезгую...
Но в чем принципиальное требование к отличию конфигураций этих хостов? Они синонимами в конфиге апача идут? Точнее, что мешает их сделать ими?
12.12.2014 12:55
Micle
 
Цитата:
OlegON Не силен я в апаче, забыл уже все, поскольку брезгую...
Но в чем принципиальное требование к отличию конфигураций этих хостов? Они синонимами в конфиге апача идут? Точнее, что мешает их сделать ими?
Основная загвоздка именно в протоколе Kerberos. Браузер не отправляет должным образом оформленный "Kerberos ticket" в сторону сайта с доменным именем (firma.ru) вне родного домена (MKS.local). Вместо этого он шлёт NTLM, который в свою очередь не поддерживается апачем (точнее модулем авторизации mod_auth_kerb2). Как их подружить между собой что-то я плохо понимаю...
12.12.2014 15:25
Micle
 
Углубился до tcpdump. Обнаружил что "браузер" комп с которого пытаюсь открыть страницу через внешнее доменное имя (firma.ru) даже не пытается получать Kerberos ticket у KDC. Оно и понятно, мало ли кто у нас запрашивает керберос авторизацию. Так и должно быть. Из чтения манов по протоколу уяснил, что такое принципиально возможно, но:
1. между доменами должно быть установлено доверие
2. клиентская машина должна о нём знать
Но, поскольку в домене firma.ru нет KDC до и доверительные отношения строить не с кем... Поднимать ещё один KDC и дружить виндовый KDC с новоиспеченным как то рука не подымается, потому как нет никакого опыта в этом.

Несколько кривоватый, но тем не менее способ нашол. Нужно всем внешним пользователям прописать в hosts файле резолв внутреннего адреса веб сервера (MKS.local) на внешний IP откуда сайт принимает внешние соединения. И вот уже для таково адреса tiсket спокойно получается, при условии доступности внутреннего KDC.. (вот это и есть основная кривость этого способа). Но при его наличии тогда приходим к тому, что весь этот заворот кишок вообще нафик не нужен, ибо при наличии впн можно напрямик идти по внутреннему IP за страницей...

ХЗ мне кажется я потерял ту мысль, которая меня заставила искать решение в это направлении.... надо думать.
12.12.2014 15:57
Micle
 
А мысль по поводу внешнего доменного имени была следующая: Пользователи находящиеся в данный момент вне сети, но получившие уведомление по почте из системы работающей на внутреннем сайте, должны иметь возможность перейдя по ссылке, попасть в систему. Т.к. система генерит ссылки исходя из жостко заданного имени размещения сайта, то получается что всё, что необходимо сделать чтобы пользователь таки попал на сайт - это обеспечить ему разрешение внутреннего имени сайта на внешний адрес. И уже на сервере разруливать авторизацию пользователей пришедших с внешки и изнутри. Внутренним предлагать керберос, внешним - Basic. Ну и конечно завернуть всё это дело в SSL для надёжности раз дело имеем с Basic авторизацией.

Всем спасибо, сеанс само-терапии можно считать законченным )) Если у кого возникнут мысли готов обсудить.
12.12.2014 18:55
OlegON
 
У меня мысль одна, что все внешние пользователи не должны иметь доступа к внутренним сервисам в принципе. Из соображений безопасности, разумеется. Поэтому VPN и авторизация из внутренней, но отдельной подсети, а никак не снаружи с отделением всего лишь этой авторизацией от сонма ботов и прочих хищников.
12.12.2014 19:26
Micle
 
У меня полно разъездных сотрудников, директор начал понимать толк в том что я строю и развиваю при этом он часто работает с личного ноутбука. Устанавливать всем и вся vpn как то не очень.

В защиту идеи приоткрыть доступ к части сервисов имею следующее:
- пароли в домене меняются достаточно часто так что даже если где то залипнет сохранённый пасс от внутреннего сервиса - это мало вероятно станет проблемой.
- перехватывать SSL то ещё удовольствие.
- пользователи в принципе не имеют лишних полномочий.
- даже я как администратор домена, не работаю под все-правной учёткой постоянно, т.к. она не имеет доступа к довольно большому количеству внутренних сервисов в режиме пользователя.
- не принадлежащая домену железка не может проходить доменную авторизацию, т.е. придётся пасс вколачивать через Basic авторизацию, даже из сети предприятия

Самое главное преимущество - доступ к важным сервисам даже с мобильного (нужно адаптировать способ предоставления контента. Но даже и без адаптации сама возможность получить своевременно важные данные находясь где угодно - весьма ценна.
12.12.2014 19:35
OlegON
 
Тогда, полагаю, должен быть уже список тех, кто должен иметь доступ, список железок и места, откуда они должны получить доступ, список сервисов, к которым надо получить доступ и список сервисов, которые доступны через те, что открываются? Схемка такая... Я, если честно, под вечер пятницы туго думаю, но идея открывать сетку через браузер мне не нравится. Очень. А автоматизации всяческой подъема VPN через браузер достаточно много.
12.12.2014 19:42
Micle
 
Не не. Сетку открывать - не в коем случае... Всё, что будет выставляться наружу - это короткий перечень сервисов которые реализованы через www браузер, и в силу этого сильно ограничены и по правам доступа и по функционалу. Кроме того список пользователей к этим сервисам ограничен.

С ограничением набора устройств - конечно сложнее дело обстоит. Всё затевается как раз чтобы этот набор расширить.
Часовой пояс GMT +3, время: 12:02.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.