Кто-нибудь знает, как реализуется такая схема?
Она хоть и необычная, но по-моему вполне логичная:
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 очень проста, сто раз делал, тут нет вопросов.
Ответ на:
комментарий
от zgen
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.