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

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

Она хоть и необычная, но по-моему вполне логичная:
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 очень проста, сто раз делал, тут нет вопросов.