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

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

Детали заключаются в следующем:
- есть внутренний домен называется он к примеру MKS.local
- в домене есть KDC, который раздаёт ключи
- Apache прописан по внутреннему адресу
и при этом прекрасно авторизует пользователей при обращении к себе через внутреннее доменное имя.
- так же тот же самый апач принимает запросы из вне. Наружный домен является официально зарегистрированным доменным именем например firma.ru, апач охотна раздаёт страницу по адресу Нужно прикрутить прозрачную авторизацию пользователей домена MKS.local через керберос на . Как правильно приготовить всё?

Не силен я в апаче, забыл уже все, поскольку брезгую...
Но в чем принципиальное требование к отличию конфигураций этих хостов? Они синонимами в конфиге апача идут? Точнее, что мешает их сделать ими?

Основная загвоздка именно в протоколе Kerberos. Браузер не отправляет должным образом оформленный "Kerberos ticket" в сторону сайта с доменным именем (firma.ru) вне родного домена (MKS.local). Вместо этого он шлёт NTLM, который в свою очередь не поддерживается апачем (точнее модулем авторизации mod_auth_kerb2). Как их подружить между собой что-то я плохо понимаю...

Углубился до tcpdump. Обнаружил что "браузер" комп с которого пытаюсь открыть страницу через внешнее доменное имя (firma.ru) даже не пытается получать Kerberos ticket у KDC. Оно и понятно, мало ли кто у нас запрашивает керберос авторизацию. Так и должно быть. Из чтения манов по протоколу уяснил, что такое принципиально возможно, но:
1. между доменами должно быть установлено доверие
2. клиентская машина должна о нём знать
Но, поскольку в домене firma.ru нет KDC до и доверительные отношения строить не с кем... Поднимать ещё один KDC и дружить виндовый KDC с новоиспеченным как то рука не подымается, потому как нет никакого опыта в этом.

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

ХЗ мне кажется я потерял ту мысль, которая меня заставила искать решение в это направлении.... надо думать.

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

Всем спасибо, сеанс само-терапии можно считать законченным )) Если у кого возникнут мысли готов обсудить.

У меня мысль одна, что все внешние пользователи не должны иметь доступа к внутренним сервисам в принципе. Из соображений безопасности, разумеется. Поэтому VPN и авторизация из внутренней, но отдельной подсети, а никак не снаружи с отделением всего лишь этой авторизацией от сонма ботов и прочих хищников.

У меня полно разъездных сотрудников, директор начал понимать толк в том что я строю и развиваю при этом он часто работает с личного ноутбука. Устанавливать всем и вся vpn как то не очень.

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

Самое главное преимущество - доступ к важным сервисам даже с мобильного (нужно адаптировать способ предоставления контента. Но даже и без адаптации сама возможность получить своевременно важные данные находясь где угодно - весьма ценна.

Тогда, полагаю, должен быть уже список тех, кто должен иметь доступ, список железок и места, откуда они должны получить доступ, список сервисов, к которым надо получить доступ и список сервисов, которые доступны через те, что открываются? Схемка такая... Я, если честно, под вечер пятницы туго думаю, но идея открывать сетку через браузер мне не нравится. Очень. А автоматизации всяческой подъема VPN через браузер достаточно много.

Не не. Сетку открывать - не в коем случае... Всё, что будет выставляться наружу - это короткий перечень сервисов которые реализованы через www браузер, и в силу этого сильно ограничены и по правам доступа и по функционалу. Кроме того список пользователей к этим сервисам ограничен.

С ограничением набора устройств - конечно сложнее дело обстоит. Всё затевается как раз чтобы этот набор расширить.