Есть 2 типа учётных записей рабочих станций в LDAP:1) dn: cn=HOST$,ou=Computers,o=MyORG,c=ru
objectClass: top
objectClass: dhcpHost
objectClass: posixAccount
objectClass: sambaSamAccount
cn: HOST$
uid: HOST$
...
...
и
2) Отличается от 1 лишь тем, что
dn: uid=HOST$,ou=Computers,o=MyORG,c=ru
т.е. в итоге запись имеет вид:
dn: uid=HOST$,ou=Computers,o=MyORG,c=ru
objectClass: top
objectClass: dhcpHost
objectClass: posixAccount
objectClass: sambaSamAccount
cn: HOST$
uid: HOST$
...
...Вопрос: ПОЧЕМУ Samba "видит" 2-й тип записи и в упор не видит 1-й???
P.S. В исходниках Samb'ы используется фильтр вида (&(uid=%s)(objectClass=sambaSamAccount)), который одинаково замечательно подходит как к первому типу записи, так и ко второму.
>P.S. В исходниках Samb'ы используется фильтр вида (&(uid=%s)(objectClass=sambaSamAccount)), который одинаково замечательно подходит
>как к первому типу записи, так и ко второму.
возможно в результате первый найденый, пробу
>>P.S. В исходниках Samb'ы используется фильтр вида (&(uid=%s)(objectClass=sambaSamAccount)), который одинаково замечательно подходит
>>как к первому типу записи, так и ко второму.
>
>
>возможно в результате первый найденый, пробупробуй удалить один.
>>>P.S. В исходниках Samb'ы используется фильтр вида (&(uid=%s)(objectClass=sambaSamAccount)), который одинаково замечательно подходит
>>>как к первому типу записи, так и ко второму.
>>
>>
>>возможно в результате первый найденый, пробу
>
>пробуй удалить один.Так если бы! Я же не копирую записи, а заменяю dn: uid=HOST$,... на dn: cn=HOST$,... и после этого с компьютера HOST в домен уже войти невозможно :( Это просто уродство какое-то, честное слово! В записи ничего не меняется, кроме dn:, атрибуты cn и uid имеют одинаковое значение, так что по сути эти два dn'а абсолютно равнозначны, так что мне абсолютно непонятно, как Samba умудряется разницу между ними видеть???? Кстати, Samba получает доступ к LDAP с правами root'а (того, который в slapd.conf прописывается), так что проблемы с правами доступа к записям LDAP'а в данном случае просто исключены...
>Так если бы! Я же не копирую записи, а заменяю dn: uid=HOST$,...
>на dn: cn=HOST$,... и после этого с компьютера HOST в домен
>уже войти невозможно :( Это просто уродство какое-то, честное слово! В
>записи ничего не меняется, кроме dn:, атрибуты cn и uid имеют
>одинаковое значение, так что по сути эти два dn'а абсолютно равнозначны,
>так что мне абсолютно непонятно, как Samba умудряется разницу между ними
>видеть???? Кстати, Samba получает доступ к LDAP с правами root'а (того,
>который в slapd.conf прописывается), так что проблемы с правами доступа
>к записям LDAP'а в данном случае просто исключены...
Хотя нет, нагло вру, компьютер с запись вида dn: cn= заходит в домен! Там проблема возникает только при вводе в домен, т.е. при регистрации, когда модифицированные скрипты smbldap-tools (smbldap-tools.pm и smbldap-useradd) создают учётку dn: cn=, а Samba её почему-то в упор не замечает и в ответ вместо "Добро пожаловать в домен N" я получаю "Неправильное имы пользователя или пароль" (или что-то в этом духе) :(
>>Так если бы! Я же не копирую записи, а заменяю dn: uid=HOST$,...
>>на dn: cn=HOST$,... и после этого с компьютера HOST в домен
>>уже войти невозможно :( Это просто уродство какое-то, честное слово! В
>>записи ничего не меняется, кроме dn:, атрибуты cn и uid имеют
>>одинаковое значение, так что по сути эти два dn'а абсолютно равнозначны,
>>так что мне абсолютно непонятно, как Samba умудряется разницу между ними
>>видеть???? Кстати, Samba получает доступ к LDAP с правами root'а (того,
>>который в slapd.conf прописывается), так что проблемы с правами доступа
>>к записям LDAP'а в данном случае просто исключены...
>Хотя нет, нагло вру, компьютер с запись вида dn: cn= заходит в
>домен! Там проблема возникает только при вводе в домен, т.е. при
>регистрации, когда модифицированные скрипты smbldap-tools (smbldap-tools.pm и smbldap-useradd) создают учётку dn:
>cn=, а Samba её почему-то в упор не замечает и в
>ответ вместо "Добро пожаловать в домен N" я получаю "Неправильное имы
>пользователя или пароль" (или что-то в этом духе) :(
тогда проще с дебаггом на клиенте с linux ввести в домен net -d 5 join к примеру
простите пожалуйста, а для чего вы заменили uid на cn?
что нам даёт команда:
[user@localhost]$grep uid /etc/ldap.conf
pam_login_attribute uidследовательно юникс не должен видеть ваши компы ибо они ищутся именно по атрибуту uid
а когда самба не видит юникосвые аккаунты для компов(а они их и не увидит), она как бы это сказать, чуток нервничает...
>простите пожалуйста, а для чего вы заменили uid на cn?
>что нам даёт команда:
>[user@localhost]$grep uid /etc/ldap.conf
>pam_login_attribute uid
>
>следовательно юникс не должен видеть ваши компы ибо они ищутся именно
>по атрибуту uidесли dn:cn=,dc=
это не означает что нет аттрибута uid
>Вопрос: ПОЧЕМУ Samba "видит" 2-й тип записи и в упор не видит
>1-й???
>
Ответ а данном случае может быть прост, это баг,
по наденному entry не делается возврат полного dn,
а он dn скорей всего составляется как uid=,dc=.
Это не баг и не глюк
Самбе требуется, чтобы каждой ее учетке соответствовала юниксовая учетка
При вводе машины в домен последовательность примерно следующая:
1 Выполняется add machine script (од должен добавит ЮНИКСОВЫЙ аккаунт)
2 Самба ищет только что созданный аккаунт, но не в LDAP!
(поскольку предполагается, что системные и самбовые аккаунты
в общем случае могут быть в разных базах)
она ищет, используя libnss, т.е. в случае, когда системные аккаунты лежат в LDAP,
ищет все-таки в LDAP, но не там, где у нее в конфиге прописано, а по /etc/ldap.conf!
3 Если находит, уже в СВОЕЙ ветке LDAP создает запись (или модифицирует уже существующие),
добавляя свои атрибуты (sambaSamAccount и т.д.)В общем, читайте Samba3-HOWTO!
Посмотрите еще man smb.conf на предмет опции ldapsam:trusted
Я, правда, ее не использовал, так что не знаю, какой эффект будет.
>Это не баг и не глюк
>Самбе требуется, чтобы каждой ее учетке соответствовала юниксовая учетка
>При вводе машины в домен последовательность примерно следующая:
> ...
Спасибо, похоже, Вы прямо мысли мои читаете и благодаря этому абсолютно точно поняли, что какой в контексте этой проблемы с нераспознаваемыми 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).
Похороните меня под плинтусом, пожалуйста. Я НЕ ПОНИМАЮ, почему, но после того, как я вернул smbldap-useradd в исходное состояние и оставил при этом исправленную строку dn: cn=...в smbldap_tools::add_posix_machine, машины стали добавляться с dn: cn= без проблем. При этом Samba действительно сама добавляет sambaSamAccount. Пребываю в состоянии тихого шока. Почему раньше ничего не работало, почему сейчас заработало, почему мой собственный скрипт добавления компов не работает, хотя он делает то же самое, что и этот smbldap-useradd????? М-да... ОС Windows нужно было назвать Enigma.