Может ли Kerberos аутентифицировать по userPassword?

Не знаю, как насчет userPassword, но судя по отзывам
http://www.mail-archive.com/ldap@listserver.itd.umich.edu/msg00185.html

Хранить пароли в ldap мог вот этот:

http://www.padl.com/Research/Heimdal.html

Да, PADL молодцы, очень их уважаю. Но в итоге всё равно Kerberos запихивает в LDAP какую-то свою белиберду, на userPassword он даже не смотрит. Меня и удивляет, почему в AD «один пароль» работает, а здесь нет.

Не знаю почему Kerberos хранит собственные хеши вместо использования существующих. Кстати Samba делает точно так же для своих паролей. Если нужно, чтобы везде были одинаковые пароли - смотри в сторону оверлея smbk5pwd для OpenLDAP. При смене пароля через LDAP Password Modify ExOp он автоматически генерирует стандартный хеш (который в userPassword), а так же хеши для samba и kerberos.

P.S. Я использую smbk5pwd только для самбы, церберос пока нигде не использовал.

на userPassword он даже не смотрит

Зато на sambaNTPassword смотрит, судя по "- sambaNTPassword: used for samba and kerberos".

А это уже пол дела.

P.S. Я использую smbk5pwd только для самбы

Какая версия ldap и samba?

Какая версия ldap и samba?

slapd 2.4.21, samba 3.4.7.

>а проверять их по соотв. значению userPassword в LDAP

Ещё раз. Не может. Потому что kerberos _не_ _проверяет_ пароль.

>При смене пароля через LDAP Password Modify ExOp он автоматически генерирует стандартный хеш

Это конечно вариант, но я, например, этот ExOp не использую в большинстве случаев: проще бывает сгенерить хэш и тупо вставить его в userPassword. Хотя, может, просто сказывается привычка всё делать одним ldapmodify'ем, либо изредка - в lbe.

DonkeyHot, хорошо, а в чём проблема использовать поле userPassword как секретный ключ?

На википедии кто-то это пытался объяснить так:

Шаги входа пользователя в систему:

1. Пользователь вводит имя и пароль на клиентской машине.
2. Клиентская машина выполняет над паролем одностороннюю функцию (обычно хэш), и результат становится секретным ключом клиента/пользователя.

Шаги аутентификации клиента:

1. Клиент посылает простым текстом сообщение серверу AS, запрашивая сервисы от имени пользователя. Например так: «Пользователь АБВ хочет запросить сервисы». Обратите внимание, что ни секретный ключ, ни пароль не посылаются на AS.
2. AS проверяет, есть ли такой клиент в базе. Если есть, то назад AS отправляет следующие два сообщения:
* Сообщение A: Сессионный Ключ Client/TGS, зашифрованный секретным ключом клиента/пользователя.

---
Собственно, не проверяет, а использует для шифрования. Но суть остаётся прежней: чем userPassword в роли ключа не угодил?

>чем userPassword в роли ключа не угодил

Тем, что юзверя склонны использовать похожие пароли в разных системах. Т.о. администратор/взломщик одного KDC получает большие возможности подбора пользовательских паролей к другим. А так - не получает. Правда, можно в userPassword хранить кербовые хеши — но тогда ldap используется как тупая БД, что противоречит условию задачи.

>Тем, что юзверя склонны использовать похожие пароли в разных системах.
Аналогично: у меня на работе пароль Windows-пользователя с правами администратора домена - «1234567» (я не шучу, кстати, это правда). От таких вещей Kerberos никак не оградит. А если LDAP надёжно защищён,то какая разница, в каком формате userPassword? Да хоть открытым текстом вообще, какая разница? Если же кто-то может прийти со стороны в LDAP и посмотреть userPassword'ы или аналогичные атрибуты, тогда зачем вообще Kerberos нужен. Получается параноидальная система защиты при голом главном ФСБ-шнике... :)

Из документации OpenLDAP:
---
14.4.7. KERBEROS password storage scheme

This is not really a password storage scheme at all. It uses the value of the userPassword attribute to delegate password verification to Kerberos.

Note: This is not the same as using Kerberos authentication of the LDAP session.

This scheme could be said to defeat the advantages of Kerberos by causing the Kerberos password to be exposed to the slapd server (and possibly on the network as well).
---
Весьма оригинально, где это они видели, чтобы Kerberos использовал userPassword хоть как-то хоть где-то? И вообще чаще всего Kerberos нужен не для супер-сильной защиты, а для SSO, то есть для удобства, а не для сомнительной гипер-секьюрности, не нужной 99,9% организаций (ведь Kerberos используется в интранет преимущественно).

Это конечно вариант, но я, например, этот ExOp не использую в большинстве случаев: проще бывает сгенерить хэш и тупо вставить его в userPassword. Хотя, может, просто сказывается привычка всё делать одним ldapmodify'ем, либо изредка - в lbe.

Ну не знаю. ИМХО набрать passwd $USERNAME и ввести новый пароль всё же проще, чем использовать ldapmodify. Если принципиально хочется LDAP-way, то есть ldappasswd.

Кстати, по поводу наших изысканий: таки да, Heimdal Kerberos при любых настройках userPassword использовать не будет. Я прогрепал исходники внимательно, этот атрибут не используется.
Кстати, passwd-то может использовать Kerberos, так что тут привязки к LDAP нет прямой. При этом теряется универсальность, потому что есть куча всего недостаточно или совсем не керберизованного, но умеющего лезть в LDAP.

Да, за инфу об smbk5pwd - крепкое Вам +1, спасибо!

Кстати, passwd-то может использовать Kerberos, так что тут привязки к LDAP нет прямой. При этом теряется универсальность, потому что есть куча всего недостаточно или совсем не керберизованного, но умеющего лезть в LDAP.

Так можно же всё к LDAP'у привязать. Главное указать, что при смене пароля нужно использовать соответствующий ExOp вместо простой замены хеша в userPassword. PAM и Samba так умеют, насчёт kerberos - хз, как я уже говорил - не сталкивался пока с ним. passwd меняет пароль через exop -> smbk5pwd автоматически обновляет хеши samba и kerberos.

Да, за инфу об smbk5pwd - крепкое Вам +1, спасибо!

Да не за что!

Кстати говоря, в стабильных дебианах и убунтах пакета с smbk5pwd ещё нет, хотя в тарболле с исходникми OpenLDAP он валяется уже фиг знает сколько. В debian'овском sid'е его собрали относительно недавно...

>Да хоть открытым текстом вообще, какая разница

Ещё раз. Простая разница. Представь себе контору из более одного админа/realm-a/области ответственности. Я, имея права на _мой_ kerberos-сервер, хранящий plaintext-пароли, с большой вероятностью смогу подобрать пароли учётных записей тех же людей в _других_ системах. Т.е. при проломе одного «домена» мы получаем дыру во все соседние. Так корабли уже давно не строят, и всё равно они тонут.

>Kerberos нужен не для супер-сильной защиты, а для SSO, то есть для удобства

Защищённость обратно пропорциональна удобству. Керберос - попытка сделать достаточно защищённую аутентикацию достаточно удобной. И, похоже, реальных альтернатив нет. Можно, конечно, рассматривать PKI, но я сильно не уверен, что по критерию «Защищённость*удобство» второе может приблизиться к первому.