Книга "OpenLDAP и Ubuntu на практике"

[unmyke]

Добрый день, уважаемые,
Застрял на Главе 6 "Настройка OpenLDAP в качестве хранилища правил sudo" с такой проблемой:
В группу sysadmin добавил тестового пользователя. С клиента можно посмотреть пользователя и группу

Код: (sudo getent group sysadmin) [Выделить]

sysadmin:*:5000:10000,20000


Код: (sudo getent passwd test.user) [Выделить]

test.user:x:20000:20000:Test User:/home/test.user:/bin/zsh
Но при этом при sudo пользователю не разрешен:

Код: (sudo -l -U test.user) [Выделить]

Пользователю test.user не разрешается запускать sudo в  hostname.При этом на ldap-сервер уходит запрос '(|(sudoUser=test.user)(sudoUser=%test.user)(sudoUser=%#20000)(sudoUser=ALL))', т.е. поиск в группе по memberUID не происходит, соответсвенно, пользователю test.user в sudo отказано.

Так же нет вывода supplementary групп при запуске id %username%:

Код: (sudo id test.user) [Выделить]

uid=20000(test.user) gid=20000(test.user) группы=20000(test.user)

Код: (sudo cat /etc/nsswitch.conf) [Выделить]

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis ldap
sudoers: files ldap
Подтолкните, пожалуйста, куда надо обратить внимание.

p.s.
да, в этой же главе имеется ошибка в п.6.1.:

Для конвертации этого файла в LDIF воспользуемся скриптом /usr/share/doc/sudo-ldap/sudoers2ldif.gz из пакета sudo-ldap:

Код: [Выделить]

$  zcat /usr/share/doc/sudo-ldap/sudoers2ldif.gz > 6.1-sudoers2ldif
$  SUDOERS_BASE=ou=sudo,ou=services,dc=example,dc=com perl 6.1-sudoers2ldif 6.1-sudoers.source > sudoers.ldif

а далее по тексту импортируется файл 6.1-sudoers.ldif

[Sdoba]

Приветствую, unmyke!

Покажите, пожалуйста, записи из DIT для группы sysadmin и  пользователя test.user.
А так же ACL для Вашего DIT.

[unmyke]

Приветствую, unmyke!

Покажите, пожалуйста, записи из DIT для группы sysadmin и  пользователя test.user.
А так же ACL для Вашего DIT.

Добрый день, Sdoba.

Получилось добиться желаемого результата, но с указанием другого значения в memberUID

Код: ("test.user") [Выделить]

dn: cn=test.user,ou=users,dc=example,dc=com
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
cn: test.user
gidNumber: 20000
homeDirectory: /home/test.user
uid: test.user
uidNumber: 20000
gecos: Test User
loginShell: /bin/bash
shadowLastChange: 15140
shadowMax: 99999
shadowMin: 0
shadowWarning: 7
userPassword:: e1NFEgF9R0tkNEZPcG1hYjJ2Yls1WOGRsclIdkJO109tZTYyMlE=


Код: ("sysadmin изначально был") [Выделить]

dn: cn=sysadmin,ou=groups,dc=example,dc=com
objectClass: posixGroup
objectClass: top
cn: sysadmin
gidNumber: 5000
description: UNIX systems administrators
memberUid: 10000,20000

Отключил nscd, включил дебаг nslcd (спасибо за подсказку egor'у), там увидел запрос

Код: ("nss-pam-ldapd v. 0.8.13") [Выделить]

nslcd: [3ab105] <group/member="test.user"> DEBUG: myldap_search(base="ou=groups,dc=example,dc=com", filter="(&(objectClass=posixGroup)(|(memberUid=test.user)(member=cn=test.user,ou=users,dc=example,dc=com)))")
Изменил memberUid на 'test.user', добавил еще один атрибут memberUid: username (который 10000) — заработало.

Оно так и должно быть или можно/нужно/правильнее в nslcd (как-то) изменить запросы в ldap?

[Sdoba]

Оно так и должно быть или можно/нужно/правильнее в nslcd (как-то) изменить запросы в ldap?

У меня точно работало с числовыми идентификаторами. Правда я указывал их по-одному, например:

Код: [Выделить]

dn: cn=sysadmin,ou=groups,dc=example,dc=com
objectClass: posixGroup
objectClass: top
cn: sysadmin
gidNumber: 5000
description: UNIX systems administrators
memberUid: 10000
memberUid: 20000
Скорее всего из-за этого и проблемы.

[egor]

Вставлю свои 5 копеек.

Отключил nscd, включил дебаг nslcd (спасибо за подсказку egor'у), там увидел запрос

Код: ("nss-pam-ldapd v. 0.8.13") [Выделить]

nslcd: [3ab105] <group/member="test.user"> DEBUG: myldap_search(base="ou=groups,dc=example,dc=com", filter="(&(objectClass=posixGroup)(|(memberUid=test.user)(member=cn=test.user,ou=users,dc=example,dc=com)))")
Изменил memberUid на 'test.user', добавил еще один атрибут memberUid: username (который 10000) — заработало.

Оно так и должно быть или можно/нужно/правильнее в nslcd (как-то) изменить запросы в ldap?

В RFC2307 по поводу атрибута memberUid не сказано конкретно, что там должно быть (синтаксис IA5String -- чересчур общий). Но чаще всего я встречал там именно имена учётных записей пользователя, причём по одному в значении атрибута, то есть:

Код: [Выделить]

memberUid: unmyke
memberUid: Sdoba
memberUid: egor

Это общепринятая практика, и nslcd ожидает именно такого заполнения каталога.

Егор

[unmyke]

Да, так же в RFC2307 сказано:

To avoid confusion, the term "login name" refers to the user's login name (being the value of the uid attribute) and the term "user ID" refers to he user's integer identification number (being the value of the uidNumber attribute).

Возможно, по этой же логике memberUid должно содержать uid, а не uidNumber.

Еще раз спасибо, Егор, без подсказки в лс не разобрался бы в сути!

[ssn]

Оживлю темку
У меня внезапно в сети нарисовался АД и все проблемы тут же улетучились, к моему глубокому сожалению
Но! Возникла другая сеть, и тут пока злого МС нет, поэтому спустя больше года начал опять палочкой тыкать с помощью этой переведённой книжки-костыля в LDAP+Kerberos+Samba. И наткнулся на ужасную вещь. Когда дохожу до инициализации БД (2.6), то значение olcRootPW у меня добавляется вида "№%№;ПИАСУКЕНУ;Ы"№№"КЫ;№ВЕ%;Е%;С№ № , нифига не тот посоленный хэш, что я в ldif прописываю, да ещё и olcAccess{0} (там где для рута права прописываются) такая же ахинея пишется. Но! ldpasearch от этого root работает. Что за напасть???
Да ещё и Apache стал подключаться в режиме read only... бррр...

[egor]

Здравствуйте!

то значение olcRootPW у меня добавляется вида "№%№;ПИАСУКЕНУ;Ы"№№"КЫ;№ВЕ%;Е%;С№ № , нифига не тот посоленный хэш, что я в ldif прописываю, да ещё и olcAccess{0} (там где для рута права прописываются) такая же ахинея пишется. Но! ldpasearch от этого root работает. Что за напасть???

Скорее всего это base64-кодировка Вашего исходного значения. Но чтобы сказать наверняка, нужно посмотреть значения этих атрибутов. Если Вас действительно это волнует, пришлите вывод ldapsearch с этими атрибутами сюда или в личку, я посмотрю.

Да ещё и Apache стал подключаться в режиме read only... бррр...

Не очень понял, что Вы имеете ввиду.

Егор

[ssn]

Извиняюсь за идиотский предыдущий пост:) исправляюсь
ситуация - модификация установленного в centos 6.6 openldap.

olcDatabase={2}bdb.ldif:

Код: [Выделить]

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 9ea0d094
dn: olcDatabase={2}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap
olcDbCacheSize: 1000
olcDbCheckpoint: 1024 15
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass pres,eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: ou pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: loginShell pres,eq
olcDbIndex: memberUid pres,eq,sub
olcDbIndex: nisMapName pres,eq,sub
olcDbIndex: nisMapEntry pres,eq,sub
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 47b68d10-f989-1036-9aa6-fdf2f177b0f6
creatorsName: cn=config
createTimestamp: 20170710070102Z
olcAccess: {0}to attrs=userPassword by self write by anonymous auth
olcAccess: {1}to * by self read
olcSuffix: dc=bla,dc=bla.ru2
olcRootDN: cn=admin,dc=bla,dc=bla.ru2
olcRootPW:: {SSHA}Yxr1klb0iYiP3t2qCq3wZXidjn9/USZn
entryCSN: 20170710080200.917742Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20170710080200Z
меняю
2.6-db-mod.ldif

Код: [Выделить]

dn: olcDatabase={2}bdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=bla,dc=bla.ru

dn: olcDatabase={2}bdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=admin,dc=bla,dc=bla.ru

dn: olcDatabase={2}bdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * break
olcAccess: {1}to attrs=userPassword by self write by anonymous auth
olcAccess: {2}to * by self read

dn: olcDatabase={2}bdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}Yxr1klb0iYiP3t2qCq3wZXidjn9/USZnНе обращайте внимания, что одно и тоже, просто не стянул исходного.
Получаю:

Код: [Выделить]

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 9ea0d094
dn: olcDatabase={2}bdb
objectClass: olcDatabaseConfig
...
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 47b68d10-f989-1036-9aa6-fdf2f177b0f6
creatorsName: cn=config
createTimestamp: 20170710070102Z
[b]olcAccess:: ezB9dG8gKiBieSBkbi5iYXNlPSJnaWROdW1iZXI9MCt1aWROdW1iZXI9MCxjbj1wZW
 VyY3JlZCxjbj1leHRlcm5hbCxjbj1hdXRoIiBtYW5hZ2UgYnkgKiBicmVhayA=[/b]
olcAccess: {1}to attrs=userPassword by self write by anonymous auth
olcAccess: {2}to * by self read
olcSuffix: dc=bla,dc=bla.ru
olcRootDN: cn=admin,dc=bla,dc=bla.ru
[b]olcRootPW:: e1NTSEF9WXhyMWtsYjBpWWlQM3QycUNxM3daWGlkam45L1VTWm4=[/b]
entryCSN: 20170710080200.917742Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20170710080200Z
Что за ерунда?
А про реадонли: Apache Directory Studio в какой-то момент времени стал на попытки поменять значения атрибутов утверждать, что он подключён в режиме только чтение.

[egor]

Это base64, как я и предполагал. В значениях атрибутов были символы, которые не понравились slapd, и он преобразовал их в base64, как это положенно по стандарту LDIF. О таком преобразовании говорит двойное двоеточие после имён соответствующих атрибутов. Вы можете проверить, что base64-значения соответствуют исходным, например, на сайте http://base64.ru/ . Значение olcAccess было разбито на две строки тоже согласно стандарту LDIF (RFC2849).

Что касается режима "только чтение", то тут трудно сказать что-то определённое. От имени какого пользователя Вы подключаетесь? Вы поменяли DN  пользователя olcRootDN и он, судя по приведённым фрагментам, больше не попадает в контекст именования БД (cn=admin,dc=bla,dc=bla.ru не входит в dc=bla,dc=bla.ru2), возможно дело в этом. Или же ограничения связаны с ACL. Чтобы сказать наверняка, нужно смотреть в логи LDAP-сервера.

Егор

[ssn]

Спасибо, но теперь я не понимаю как olcAccess менять!
replace: olcAccess
olcAccess: {0}to * и т.д. теперь оставляет всё на месте. К RFC даже боюсь прикасаться. ЛДАП и так придумали какие-то укурки
Про только чтение, как всегда анекдот от ssn. Наверно в какой-то момент рука дрогнула и мышка ткнула на свойствах соединения галочку read only

P.s. Фух, поспешил, таки меняет.

[ssn]

Опять прошу помощи.
Как узнать, собран мой ЛДАП-сервер с поддержкой модулей да оверлеев али нет?
olcModuleLoad: back_mdb.la
olcModuleLoad: back_monitor.la
мне подключать не потребовалось (нет .la и .so), а вот очень нужный smbk5pwd сервак скушал:

Код: [Выделить]

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib64/openldap
#olcModuleLoad: back_bdb.la
#olcModuleLoad: back_monitor.la
olcModuleLoad: smbk5pwd.la
Дальше:

Код: [Выделить]

dn: olcOverlay=smbk5pwd,olcDatabase={2}bdb,cn=config
 changetype: add
 objectClass: olcOverlayConfig
 objectClass: olcAuditLogConfig
 olcOverlay: smbk5pwdНа это при ldapmodify ругань идёт, что мол dn неправильный
Я уже полез на оригинал книги (я тоже на Centos 6.x живу), но у мужыка на блоге все ldif лежали на dropbox и уже умерли.
Я задача синхронизации пароле стоит в полны рост Не самому же на perl это рисовать?

[egor]

Здравствуйте! Нужно указать правильный объектный класс. Пример из README:

Код: [Выделить]

# {0}smbk5pwd, {1}bdb, config
dn: olcOverlay={0}smbk5pwd,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSmbK5PwdConfig
olcOverlay: {0}smbk5pwd
olcSmbK5PwdEnable: krb5
olcSmbK5PwdEnable: samba
olcSmbK5PwdMustChange: 2592000

Будьте внимательнее. Егор

[ssn]

Да уж... Откуда я там аудит выкопал? Торопился утром и фигню напостил.
Ох. Повторю свой пост уже правильно. Конечно я взял из редми http://www.openldap.org/devel/cvsweb.cgi/~checkout~/contrib/slapd-modules/smbk5pwd/README?rev=1.4.2.3&hideattic=1&sortbydate=0
mode.ldif:

Код: [Выделить]

#{0}smbk5pwd, {2}bdb, config
dn: olcOverlay={0}smbk5pwd,olcDatabase={2}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSmbK5PwdConfig
olcOverlay: {0}smbk5pwd
olcSmbK5PwdEnable: krb5
olcSmbK5PwdEnable: samba
olcSmbK5PwdMustChange: 2592000В ответ ldapadd -xZZWD cn=admin,dc=bla,dc=bla -f mode.ldif
adding new entry "olc..."
ldap_add:invalid DN syntax (34)
 additional info: invalid DN
по книге решил 11 главу тогда сделать, но наложение к примеру accesslog тоже не хочет подключаться...
Уж помогите убогому, что может быть

[egor]

Это действительно содержимое Вашего mode.ldif? Тогда всё верно, он  не будет добавлен, т.к. нет ни одной значимой строки. Все строки, начинающиеся с пробела, считаются продолжением предыдущей, то есть в Вашем случае строки комментария -- об этом говорится в том самом RFC2849. В общем, сделайте так:

Код: [Выделить]

dn: olcOverlay={0}smbk5pwd,olcDatabase={2}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSmbK5PwdConfig
olcOverlay: {0}smbk5pwd
olcSmbK5PwdEnable: samba

И ещё. Ваши ACL позволяют модифицировать cn=config от пользователя cn=admin,dc=bla,dc=bla? Мне кажется, так быть не должно.

Егор