[ОТВЕТИТЬ]
Опции темы
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 за страницей...

ХЗ мне кажется я потерял ту мысль, которая меня заставила искать решение в это направлении.... надо думать.
 
"Спасибо" Micle от:
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, время: 22:22.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.