Имеется сервер c samba-3.0.3-alt1.1, в качестве бэкенда для хранения базы пользователей используется ldap. Системные пользователи также хранятся в ldap (настроен nss_ldap, pam_ldap). При создании машинных аккаунтов наблюдается такая ошибка: [root@fs samba]# pdbedit -d 1 -a -m testcomputer ldapsam_modify_entry: Failed to add user dn= uid=testcomputer$,ou=Computers,dc=syktsu,dc=ru with: Object class violation object class 'sambaSamAccount' requires attribute 'sambaSID' ldapsam_add_sam_account: failed to modify/add user with uid = testcomputer$ (dn = uid=testcomputer$,ou=Computers,dc=syktsu,dc=ru) Unable to add machine! (does it already exist?) Если предварительно создать в LDAP нормальный posixAccount, то попытка добавить аттрибуты sambaSamAccount с помошью pdbedit также не дают никаких результатов. Если создать системного пользователя командой: 'useradd -g machines testcomputer$', то последующая команда 'pdbedit -a -m testcomputer' вполне нормально срабатывает. Т.о. требуется обязательное наличие локального системного пользователя в /etc/passwd для машинных аккаунтов, что не совсем то, что хотелось... Я попытался разобраться в проблеме. Действительно на bugzilla.samba.org висят пара багов по подобной проблеме: https://bugzilla.samba.org/show_bug.cgi?id=623 https://bugzilla.samba.org/show_bug.cgi?id=1052 Но они до сих пор в состоянии NEW и неизвестно возьмуться ли разрабботчики решать эту проблему... Просмотрев код pdbedit.c я наткнулся на любопытный момент: pdbedit.c:508 if ((pwd = getpwnam_alloc(machineaccount))) { if (!NT_STATUS_IS_OK(pdb_init_sam_pw( &sam_pwent, pwd))) { fprintf(stderr, "Could not init sam from pw\n"); passwd_free(&pwd); return -1; } passwd_free(&pwd); } else { if (!NT_STATUS_IS_OK(pdb_init_sam (&sam_pwent))) { fprintf(stderr, "Could not init sam from pw\n"); return -1; } } Т.е. в зависимости от того, что вернула getpwnam_alloc() по разному инициализируются машинные аккаунты. Причём сюдя по отладочным сообщениям как раз на этой вилке и происходит проблема: если пользователь есть в /etc/passwd, то вариант `then`, если нет, то `else`. Если покопать код дальше, то видно, что getpwnam_alloc() просто дёргает системный вызов getpwnam(), который, судя по ману, просто роется в /etc/passwd в поиске учётной записи и не производит проверки в ldap. Это всего лишь предположение, прошу сильно не пинать, если не прав.
getpwnam() ищет по базам, указанным в /etc/nsswitch.conf в том порядке, в котором они там прописаны. Так что если записи в LDAP не находятся, то причиной может быть отсутствие записи "ldap" в /etc/nsswitch.conf. С другой стороны, другие записи, видимо, доступны по getent passwd, значит, настроено в /etc/nsswitch.conf верно. Тогда может быть проблема в двух местах: 1. Схема в LDAP не соответствует реальности Samba 3.0.3-alt1.1. Это может быть, если соответствующее хранилище создавалось до 3.0.2. 2. Ошибка в nss_ldap при работе с символом $. Судя по приведенному сообщению от pdbedit, очень похоже на (1).
Created attachment 433 [details] pdbedit output Я смотрел новую схему, у меня действительно была старая, но, к сожалению, добавление машинных аккаунтов не работало ещё на сборке alt46, поэтому установка новой схемы и рестарт ldap и samba ничего не изменило. Отличия в схеме слишком незначительные (на мой взгляд). Настройку samba+ldap я делал ещё в прошлом году и по итогам написал статью http://unix.nordcomp.ru/articles.html?id=17 , изложенная там конфигурация практически ничем отличается от того, что у меня сейчас (за исключением обновлённой версии samba). Приведу вывод pdbedit на уровне отладки 11, для двух случаев: добавление аккаунта с пользователем в /etc/passwd и без него: 1. # useradd -g machines -d /dev/null testcomp$ # pdbedit -d 11 -a -m testcomp вывод в атачменте pdbedit.1.txt 2. # pdbedit -x testcomp$ # userdel testcomp$ # pdbedit -d 11 -a -m testcomp вывод в атачменте pdbedit.2.txt Хочу обратить внимание на то, что после записи pdb backend guest has a valid init идёт расхождение в действиях pdbedit, если пользователь есть в /etc/passwd, то идёт создание sid'а (18-ый элемент) для него, а если нет, то -- нет... И это как раз различие в функциях pdb_init_sam_pw() и pdb_init_sam() element 18 -> now SET pdb_set_user_sid_from_rid: setting user sid S-1-5-21-2614677957-1106234284-1388258010-3372 from rid 3372 А как можно проверить второй вариант (Ошибка в nss_ldap при работе с символом $.)?
Знак $ является специальным символом в shell, соответственно, для того чтобы его передать приложению, его надо экранировать с использованием символа \. Таким образом, это не ошибка Самбы, а ошибка входных параметров в useradd (нужно было написать либо testcomp\$, либо 'testcomp$'
