pam_ldap + samba account: запрос пароля
Хороший здесь форум... :)
Посему продолжу злостный оффтопик :))) Но буду его старательно маскировать.
Итак, есть некая Unix-система (FreeBSD 6.2, но не думаю, что от перехода к Gentoo что-нибудь изменится) в которой системный механизм авторизации переделан с классического на LDAP.
Используется OpenLDAP сервер версии 2.3.41 на том же хосте.
В тестовых целях на начальнмо этапе ограничения по доступу - только на запись.
Сцена первая.
posixAccount
Авторизация в Apache (если кому интересно - сецию конфига цитирую, захотите использовать в приведённом виде - не забудьте задать значение атрибута userPassword для пользователя 'www'):
AuthName "My secret part" AuthType Basic AuthBasicProvider ldap AuthLDAPURL "ldap://localhost:389/ou=People,dc=mydomain,dc=ru" AuthzLDAPAuthoritative off AuthLDAPBindDN uid=www,ou=People,dc=mydomain,dc=ru AuthLDAPBindPassword some_cleartext_password Require valid-user Satisfy Any
пароль сверяется по хэшу из атрибута 'userPassword'.
На тот же пользовательский аккаунт накладывается objectClass sambaSamAccount (с соответствующим набором атрибутов).
Повторная попытка авторизации с стандартным паролем обламывается. Но если при авторизации указать пароль Samba, авторизация проходит успешно.
Что за глюк?
Ну и вторая сцена
Есть некоторая машинка с Samba-сервером. Системная авторизация классическая, samba авторизуется через OpenLDAP (2.3.40).
Есть тестовая машинка с Win2003.
При обращении к вышеописанному серверу - всё ОК (выводится окно запроса имени пользователя/пароля).
В чём собственно проблема:
При попытке обращения с той же тестовой машинки к тестовому серверу (системная авторизация через OpenLDAP, Samba аналогично через тот же OpenLDAP-сервер) вместо окна запроса имени пользователя/пароля выводится сообщение о том, что правов обращения к ресурсу нэма.
Конфиги Самбы (за исключением имён серверов и регистрационных данных администратора LDAP-сервера) идентичны.
Доменов нигде нет.
В логах Самбы независимо от уровня логирования - ничего.
В логах OpenLDAP - только RESULT tag=97 err=49 text=
(что, по моим наблюдениям означет либо ввод неверного пароля, либо попытку обращения к атрибутам, доступ к которым запрещён; в моей конфигурации на данном этапе доступ на чтение разрешён всем и ко всему).
Вопрос: чем объясняется столь странное поведение и куда рыть для решения проблемы?
- Для комментирования войдите или зарегистрируйтесь