LINUX.ORG.RU
ФорумAdmin

LDAP+Kerberos - замкнутая схема!


0

1

Кто-нибудь знает, как реализуется такая схема?

Она хоть и необычная, но по-моему вполне логичная:
1) Единственным сервисом, который делает LDAP BIND напрямую, без SASL, является Kerberos. Это аксиома. Никаких хранений паролей доступа к LDAP в тысяче различных мест быть не должно.
2) При аутентификации пользователя Kerberos ищет по фильтру со скопом, либо тупо мапит по данным REALM'а и доп.настройкам (типа: uid=%s,ou=staff,dc=dcREALMn+1,dc=dcREALMn...) его в каталоге. Если находит - пытается сделать BIND с переданным паролем. Если BIND проходит удачно - выдаёт тикет
3) Сам OpenLDAP, как и всё остальное, вместе взятое, также авторизует юзеров по Kerberos'у. То есть:
3.0 В OpenLDAP нагло лезут без пароля и говорят: смотри тикет
3.1 OpenLDAP запрашивает SASL GSSAPI
3.2 SASL запрашивает Kerberos
3.3 Kerberos аутентифицирует, проверяя, есть ли у товарища правильный тикет, если нет - то отправляет обратно fail
3.4 Проходим всю цепочку задом наперёд - OpenLDAP авторизует товарища... либо не делает этого

«Необычность» схемы состоит в том, что не только OpenLDAP обращается в Kerberos (через SASL), но и наоборот - Kerberos аутентифицирует исключительно по данным каталога.


Аутентификацию с использованием sasldb2, уж простите, считаю маразмом: каталог на то и нужен, чтобы данные пользователя консолидированно хранить, иначе мы опять приходим к размазыванию данных по кучке баз и базёнок. Тот же Active Directory, заметьте, никаких чудо-файликов дополнительных не использует!

P.S. Сам пытался как-то долбаться с Kerberos'ом, читающим LDAP через сокет, но это был просто кошмарный геморрой, и в итоге что-нибудь, да работало не так. При этом Kerberos не имеет вменяемых средств отладки, что конечно доставляло не по детски. Обратная схема, когда есть sasldb2 очень проста, сто раз делал, тут нет вопросов.

★★★★★

Сам пытался как-то долбаться с Kerberos'ом, читающим LDAP через сокет, но это был просто кошмарный геморрой, и в итоге что-нибудь, да работало не так.

Вот бы и поделились, что сделали и что не получилось.

Подозреваю, ответов на ваш пост не будет.

zgen ★★★★★ ()
Ответ на: комментарий от zgen

Главная трабла была в том, что Kerberos не мог получить доступ в LDAP нормально, он туда пытался анонимно подключаться. Но там и задача была другая: простое хранение базы Kerberos'а в LDAP'е. А мне нужно не чтобы он там свою krb5* абракадабру хранил (это как раз он лучше складывает в файлы свои, чтобы не замусоривать учётки пользователей), а чтобы он проверял пароль через LDAP! В принципе, я даже согласен на локальный сокет, но... в офдоках я даже возможности такой не нашёл! Они там предлагают пароли утилитой kadmin заводить, а то что у меня, например, уже есть куча юзеров с паролями - это никого не волнует. Главное, ведб сделали же это в Active Directory не через задницу: там-то пароль хранится в каталоге!

DRVTiny ★★★★★ ()

>При аутентификации пользователя Kerberos ... пытается сделать BIND с переданным паролем.

Одна проблема - kerberos-KDCу пароль никто не передаёт. Он его должен уже знать.

DonkeyHot ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.