>Это не баг и не глюк
>Самбе требуется, чтобы каждой ее учетке соответствовала юниксовая учетка
>При вводе машины в домен последовательность примерно следующая:
> ...
Спасибо, похоже, Вы прямо мысли мои читаете и благодаря этому абсолютно точно поняли, что какой в контексте этой проблемы с нераспознаваемыми dn'ами меня больше всего волнует :-)
К сожалению, того, о чём Вы говорили, я в официальном HOWTO не нашёл, хотя искал довольно долго. Да и про LDAP там не густо на самом деле (к тому же информация устаревшая. Где-то по состоянию на 2003-й - 2004-й годы написана)...
Перехожу к существу вопроса:
>Самбе требуется, чтобы каждой ее учетке соответствовала юниксовая учетка
Как уже было правильно замечено, юниксовая учётка не обязана выглядеть как dn: uid=..., на самом деле nss'ом записи ищутся по uid, а не по значению dn. Для учётной записи UNIX, хранящейся в LDAP, нужен objectClass=posixAccount с корректно заполненными полями (в том числе uid). dn же может быть каким угодно, потому что при поиске ldap_search'ем dn не отличается от других атрибутов, причём, насколько я знаю, ещё ни одно приложение не догадалось свои записи по значению dn искать :) Кстати, у меня по getent passwd машины с форматом записи dn: cn= прекрасно видны.
>1 Выполняется add machine script (од должен добавит ЮНИКСОВЫЙ аккаунт)
Вот, кстати, с этим я очень долго мучался. Почему-то старая Samba из состава дистрибутива ASPLinux 10 (3.0.8 ещё) добавляла свои аккаунты в LDAP-записи машин исправно, а та, которую я сам собрал из исходников (3.0.23b) по непонятным причинам делать это перестала. Но я-то не знал о том, что sambaSamAccount добавляется автоматически самой Samb'ой и грешил на кривизну smbldap-tools'ов от IDEALX'а. Я залез в скрипт smbldap-useradd и обнаружил, что действительно при добавлении машины в этом скрипте создаётся только posixAccount. Почему-то мне показалось, что это баг (хотя на Samba 3.0.8 я без проблем заводил компьютеры в домен именно с помощью add machine script = smbldap-useradd -w "%u", но сей разумный довод я почему-то предпочёл проигнорировать) и тогда я изучил состав модуля smbldap-tools.pm, нашёл там функцию add_samba_machine и подумал "Ага, вот это как раз и есть то, о чём забыли ребята из IDEALX'а при написании smbldap-useradd!". В общем, в итоге я изменил smbldap-useradd, так что там при добавлении машинной учётки стал создаваться sambaSamAccount. И, как ни странно, это помогло! Единственное, что если использовать формат dn: uid=..., то всё нормально, компы в домен прописываются "на ура", а вот если изменить формат отличительного имени на dn: cn=..., то Window'ые машины почему-то брыкаются и пишут обалденно информативные сообщения об ошибках (после этого я начинаю понимать людей, которые тихо ненавидят Microsoft со всеми его мазо-friendly solutions'ами). Собственно, после этого неприятного "открытия" я и написал сюда на форумв надежде на то, что кто-нибудь сможет объяснить мне, каким боком Samb'е может помешать "нетрадиционный" формат distinguished name'а.>3 Если находит, уже в СВОЕЙ ветке LDAP создает запись (или модифицирует уже >существующие), добавляя свои атрибуты (sambaSamAccount и т.д.)
Похоже, что проблема именно в этом... У меня Samba почему-то вообще ничего не делает сама (разве что время, оставшеся до очередной смены пароля, автоматически декрементирует при каждом входе пользователя), и после инциализации posixAccount'а машины никакого sambaSamAccount'а к нему не добавляется... Как думаете, в чём может быть загвоздка? Повторяю: все машинные учётные записи, как бы я их не добавлял, nss'у видны, так что здесь явно не с конфигурацией NSS проблема.
Интересно, что UNIX-машины при добавлении в домен через net rpc join ни на что не жалуются (если sambaSamAccount добавляется в скрипте add machine script).
|
Вариант для распечатки
Samba, вопросы интеграции Unix и Windows (Public)
(ok) on 14-Окт-06, 10:53 
