Форум проекта Pro-LDAP.ru
Обсуждение материалов проекта Pro-LDAP.ru => Книги проекта Pro-LDAP.ru => Тема начата: egor от 07 Май 2015, 13:09:36
-
В этой теме Вы можете оставлять свои замечания, предложения и комментарии о книге "OpenLDAP и Ubuntu на практике" (http://pro-ldap.ru/books/openldap-ubuntu-in-practice/).
-
Доброе время суток.
глава 9. Застрял на SASL. OC правда не бубунта, а centos 6.1.
KDC и иже с ними настроены. ЛДАП-серверу принципиал и набор ключей сделан. Но вот после загрузки 9.2.2-sasl.ldif
# ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i sasl
выдаёт не
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
additional info: SASL(-4): no mechanism available: security flags do not match required
а
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
olcSaslHost: mail.bla.bla
olcSaslRealm: BLA.BLA
olcSaslSecProps: noanonymous,noplain
т.е. сразу всё ок.
но...
root@mail openldap# ldapwhoami
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Cannot determine realm for numeric host address)
Не понимаю :( Помогите, кто может.
-
Здравствуйте!
При таком подключении
# ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i sasl
у Вас используется механизм EXTERNAL, о чём и говорит этот вывод:
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
olcSaslHost: mail.bla.bla
olcSaslRealm: BLA.BLA
olcSaslSecProps: noanonymous,noplain
То есть Вы подключились от системной записи root (uid=0 и gid=0).
Если Вы хотите хотите посмотреть, за кого Вас считает slapd при этом подключении, нужно указать это при вызове ldapwhoami:
# ldapwhoami -Y EXTERNAL -H ldapi:///
Поскольку Вы не указали механизм явно, SASL берёт мехаизм по умолчанию, в данном случае GSSAPI, который и выдаёт ошибку.
Что касается самой ошибки, то
An invalid name was supplied (Cannot determine realm for numeric host address)
очень похоже на проблемы с разрешением имени хоста, нужно подправить что-то в DNS.
Егор
-
Спасибо за ответ, но я и хотел GSSAPI пощупать :( С SASL/EXTERNAL всё жужжит (я просто упомянул первый вывод, т.к. по брошюрке у вас sasl/external ругается, а у меня на centos сразу завелось). День вчера потратил, DNS обнюхал (тоже по ошибке на него грешу), но ничего не увидел. Даже SRV-записи там прикрутил, думаю, мож kerberosy разрешить DNS смотреть нужно?
-
Прежде чем выполнять вот это:
root@mail openldap# ldapwhoami
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Cannot determine realm for numeric host address)
... Надо выполнить два действия:
1. Связать OpenLDAP и Kerberos через параметр export KRB5_KTNAME=/etc/ldap/krb5.keytab в файле /etc/default/slapd.
(для CentOS это будет параметр KRB5_KTNAME=/etc/openldap/krb5.keytab и файл /etc/sysconfig/ldap соответственно)
2. Успешно получить билет для администратора от KDC с помощью kinit. И проверить его наличие с помощью klist.
Только после этого можно надеяться на успех.
-
естественно keytab был запихнут в /etc/sysconfig/ldap. Выполнен service slapd restart был получен билет для pupkin/admin.
но...
root@mail openldap# ldapwhoami
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Cannot determine realm for numeric host address)
Блин. Одно неловкое движение и ты отец с этим ЛДАП/Церберос. До этого на другое ругалось, убивал домен керберос и заново создавал, всё зажужало. Кроме SASL/GSSAPI! А по ssh ходит, но пароль принимает LDAP (это если без тикетов).
Я так понимаю дальше будет проблема синхронизации паролей LDAP и Kerberos?
Короч надо в сторону 389DS смотреть, и думать что умные дяди за меня уже всё сделали.
-
ssn, а каким DNS-сервером пользуетесь?
-
bind. 9.8.2.
-
2 вопроса:
1. Корректно ли настроена обратная зона?
2. Пробовали ли выполнить kinit и ldapwhoami от имени обычного пользователя, а не root?
-
Да. проблема решена. Естественно DNS.
Стенд - учебный, обратную зону наколядовал в полглаза, никому не мешала. Начал 389-й привинчивать, вот он-то на неё и забурчал.
Посмотрел и почесал в затылке - я для dns зону оттяпал 192.168.0.0/16 (ну для посмотреть когда-то давно) и для in-addr.arpa записи вёл типа
105.1 PTR mail.bla.bla
105.2 PTR adm.bla.bla
вот только, идиот, попутал изначально. Писал
1.105 PTR mail.bla.bla и т.д.
Конечно обратная запись и не находилась!
Поправил, тут и ваш вопрос подоспел. Проверил - усё работает! Ура!
Как всегда невнимательность... Но всё больше уважаю Микрософт, сделали весчь-таки! (я АД имею ввиду). Кубики - ЛДАП-Керберос-SSO - таки собирать тяжко.
Всем спасибо, пошёл думать над samba и SSO и как все эти логины/пароли синхронизировать.
-
ssn, весьма советую глянуть, что такое sssd. Я тут на днях попробовал - мне очень понравилось. Значительно упрощает наше руководство. Когда созрею - сделаю в нём новый раздел про sssd.
-
я на него постоянно глазом кошусь, но увы. ОС на базе РХЕЛ 6.1, обновлять нельзя, а шапка допилила сссд только с 6.4. Я и самбу буду теребить 3.5 ;D
А сеть имеет и линукс-машины, и виндоус, никак с этой иглы не соскочим!
-
Уважаемые гуру. Вопрос возник ввиду малограмотности и скудоумия.
Обязательно было поддерево для Кербероса новое заводить в ЛДАП или как описывается в http://help.ubuntu.ru/wiki/руководство_по_ubuntu_server/авторизация_по_сети/kerberos_and_ldap можно слепить вместе пользователей и принципиалов, простым добавлением полей (ну никак от РСУБД не отойду... атрибутов) и не ломать голову над синхронизацией?
-
ssn, честно, не пробовал ;D
Но я искренне верю, что проблем возникнуть не должно.
Уж простите за такой ответ.
-
ну мне кажется тут с безопасностью и идеологией кербероса проблемы...
эх... Нет пока опыта эксплуатации... Ну даст бог, через пару лет свои экзерцисы отпишу :)
-
Добрый день, уважаемые,
Застрял на Главе 6 "Настройка OpenLDAP в качестве хранилища правил sudo" с такой проблемой:
В группу sysadmin добавил тестового пользователя. С клиента можно посмотреть пользователя и группу
sysadmin:*:5000:10000,20000
test.user:x:20000:20000:Test User:/home/test.user:/bin/zsh
Но при этом при sudo пользователю не разрешен:
Пользователю test.user не разрешается запускать sudo в hostname.
При этом на ldap-сервер уходит запрос '(|(sudoUser=test.user)(sudoUser=%test.user)(sudoUser=%#20000)(sudoUser=ALL))', т.е. поиск в группе по memberUID не происходит, соответсвенно, пользователю test.user в sudo отказано.
Так же нет вывода supplementary групп при запуске id %username%:
uid=20000(test.user) gid=20000(test.user) группы=20000(test.user)
# /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
-
Приветствую, unmyke!
Покажите, пожалуйста, записи из DIT для группы sysadmin и пользователя test.user.
А так же ACL для Вашего DIT.
-
Приветствую, unmyke!
Покажите, пожалуйста, записи из DIT для группы sysadmin и пользователя test.user.
А так же ACL для Вашего DIT.
Добрый день, Sdoba.
Получилось добиться желаемого результата, но с указанием другого значения в memberUID
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=
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'у), там увидел запрос
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?
-
Оно так и должно быть или можно/нужно/правильнее в 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
Скорее всего из-за этого и проблемы.
-
Вставлю свои 5 копеек.
Отключил nscd, включил дебаг nslcd (спасибо за подсказку egor'у), там увидел запрос
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 (http://pro-ldap.ru/tr/rfc/rfc2307.html#section-3) по поводу атрибута memberUid не сказано конкретно, что там должно быть (синтаксис IA5String -- чересчур общий). Но чаще всего я встречал там именно имена учётных записей пользователя, причём по одному в значении атрибута, то есть:
memberUid: unmyke
memberUid: Sdoba
memberUid: egor
Это общепринятая практика, и nslcd ожидает именно такого заполнения каталога.
Егор
-
Да, так же в 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.
Еще раз спасибо, Егор, без подсказки в лс не разобрался бы в сути!
-
Оживлю темку :)
У меня внезапно в сети нарисовался АД и все проблемы тут же улетучились, к моему глубокому сожалению :(
Но! Возникла другая сеть, и тут пока злого МС нет, поэтому спустя больше года начал опять палочкой тыкать с помощью этой переведённой книжки-костыля в LDAP+Kerberos+Samba. И наткнулся на ужасную вещь. Когда дохожу до инициализации БД (2.6), то значение olcRootPW у меня добавляется вида "№%№;ПИАСУКЕНУ;Ы"№№"КЫ;№ВЕ%;Е%;С№ № , нифига не тот посоленный хэш, что я в ldif прописываю, да ещё и olcAccess{0} (там где для рута права прописываются) такая же ахинея пишется. Но! ldpasearch от этого root работает. Что за напасть???
Да ещё и Apache стал подключаться в режиме read only... бррр...
-
Здравствуйте!
то значение olcRootPW у меня добавляется вида "№%№;ПИАСУКЕНУ;Ы"№№"КЫ;№ВЕ%;Е%;С№ № , нифига не тот посоленный хэш, что я в ldif прописываю, да ещё и olcAccess{0} (там где для рута права прописываются) такая же ахинея пишется. Но! ldpasearch от этого root работает. Что за напасть???
Скорее всего это base64-кодировка Вашего исходного значения. Но чтобы сказать наверняка, нужно посмотреть значения этих атрибутов. Если Вас действительно это волнует, пришлите вывод ldapsearch с этими атрибутами сюда или в личку, я посмотрю.
Да ещё и Apache стал подключаться в режиме read only... бррр...
Не очень понял, что Вы имеете ввиду.
Егор
-
Извиняюсь за идиотский предыдущий пост:) исправляюсь
ситуация - модификация установленного в 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 в какой-то момент времени стал на попытки поменять значения атрибутов утверждать, что он подключён в режиме только чтение.
-
Это base64, как я и предполагал. В значениях атрибутов были символы, которые не понравились slapd, и он преобразовал их в base64, как это положенно по стандарту LDIF. О таком преобразовании говорит двойное двоеточие после имён соответствующих атрибутов. Вы можете проверить, что base64-значения соответствуют исходным, например, на сайте http://base64.ru/ (http://base64.ru/) . Значение olcAccess было разбито на две строки тоже согласно стандарту LDIF (RFC2849 (https://pro-ldap.ru/tr/rfc/rfc2849.html)).
Что касается режима "только чтение", то тут трудно сказать что-то определённое. От имени какого пользователя Вы подключаетесь? Вы поменяли DN пользователя olcRootDN и он, судя по приведённым фрагментам, больше не попадает в контекст именования БД (cn=admin,dc=bla,dc=bla.ru не входит в dc=bla,dc=bla.ru2), возможно дело в этом. Или же ограничения связаны с ACL. Чтобы сказать наверняка, нужно смотреть в логи LDAP-сервера.
Егор
-
Спасибо, но теперь я не понимаю как olcAccess менять!
replace: olcAccess
olcAccess: {0}to * и т.д. теперь оставляет всё на месте. К RFC даже боюсь прикасаться. ЛДАП и так придумали какие-то укурки :)
Про только чтение, как всегда анекдот от ssn. Наверно в какой-то момент рука дрогнула и мышка ткнула на свойствах соединения галочку read only :)
P.s. Фух, поспешил, таки меняет.
-
Опять прошу помощи.
Как узнать, собран мой ЛДАП-сервер с поддержкой модулей да оверлеев али нет?
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 это рисовать?
-
Здравствуйте! Нужно указать правильный объектный класс. Пример из README (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=contrib/slapd-modules/smbk5pwd/README;h=5d0cca12e7e67133399a4cd05a7e481fbcb8dbd9;hb=HEAD):
# {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
Будьте внимательнее. Егор
-
Да уж... Откуда я там аудит выкопал? Торопился утром и фигню напостил.
Ох. Повторю свой пост уже правильно. Конечно я взял из редми 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 тоже не хочет подключаться...
Уж помогите убогому, что может быть :(
-
Это действительно содержимое Вашего 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? Мне кажется, так быть не должно.
Егор
-
Егор, дико извиняюсь. Чёрт бы побрал этот ЛДАП! И мою невнимательность тоже. Не увидел во что превратился в итоге мой пост. Охо-хох-ох, грехии мои тяжкие... Естественно ldif такой:
dn: olcOverlay={0}smbk5pwd,olcDatabase={2}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSmbK5PwdConfig
olcOverlay: {0}smbk5pwd
olcSmbK5PwdEnable: krb5
olcSmbK5PwdEnable: samba
olcSmbK5PwdMustChange: 2592000
Насчёт admin... а я даже и не понимаю как по другому-то? Руководства для ракетчиков я пока читаю по диагонали, а вот в этой конкретной книге-переводе блога конфигурация меняется именно так. Я так и делаю.
-
Специально собрал схему на Ubuntu 16.04, OpenLDAP-2.4.42, slapd-smbk5pwd-2.4.42.
К коробочной конфигурации с olcDatabase={1}mdb,cn=config и olcModulePath: /usr/lib/ldap добавил набор схемы samba.ldif (https://pro-ldap.ru/sources/schema/samba.ldif), затем применяю такой LDIF:
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: smbk5pwd.la
dn: olcOverlay={0}smbk5pwd,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSmbK5PwdConfig
olcOverlay: {0}smbk5pwd
olcSmbK5PwdEnable: samba
olcSmbK5PwdMustChange: 2592000
# ldapmodify -Y EXTERNAL -H ldapi:// -f ./smbk5pwd-init.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=module{0},cn=config"
adding new entry "olcOverlay={0}smbk5pwd,olcDatabase={1}mdb,cn=config"
Всё применяется штатно:
# ldapsearch -LLL -Y EXTERNAL -H ldapi:// -b 'olcOverlay={0}smbk5pwd,olcDatabase={1}mdb,cn=config'
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: olcOverlay={0}smbk5pwd,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSmbK5PwdConfig
olcOverlay: {0}smbk5pwd
olcSmbK5PwdEnable: samba
olcSmbK5PwdMustChange: 2592000
Пароли, кстати, тоже меняются, я проверил (и LDAP, и samba):
ldappasswd -H ldapi:// -x -D cn=admin,dc=nodomain -w test -s newpass uid=ivanov,dc=nodomain
Проверьте, есть ли у вас вообще модуль smbk5pwd.la, в Ubuntu он лежит в /usr/lib/ldap/.
-
Всё есть. И .la и .so. В Centos 6.6 они лежат в /usr/lib64/openldap:
rpm -ql openldap-servers | grep smb
/usr/lib64/openldap/smbk5pwd-2.4.so.2
/usr/lib64/openldap/smbk5pwd-2.4.so.2.10.2
/usr/lib64/openldap/smbk5pwd.la
/usr/lib64/openldap/README.smbk5pwd
схемы брал из входящих в состав дистрибутива Centos samba и Kerberos. Пробовал и схему самбы с вашего сайта, результат тот же. попробую развернуть на убунте ради интереса и попробовать там.
Я ненавижу ЛДАП и всё с ним связанное :)
Кстати, в редми модуля редхат чётко написала:
We do not provide Heimdal Kerberos but MIT. Therefore the module is compiled only with Samba features in Fedora and RHEL
Тобишь как я понимаю модуль скомпилили с самбой RHEL. Т.о. и в Centos должно работать же.
-
У меня всё вышло с первого раза без проблем. Чтобы не перечислять всё конфиги, я сжал ту рабочую директорию, в которой проводил эксперименты (см. вложение). Может быть это поможет.
-
Спасибо, сейчас попробую прикрутить её на centos. Ubuntu позже попинаю.
-
Извиняюсь за отнимаемое время...
Решил посмотреть как из коробки будет, мало ли я по пути книжки чего напутал.
Установил, добавил схему самбы из дистрибутива, запустил ваш лдиф с добавлением модуля и наложения.
ошибка (34) - плохой dn.
снёс, установил, вашу схему самбы уже добавил (ред хат схему самбы автоматом не ставит), тоже самое...
Надо наверно искать форум сентоводов-красношляпников, мож они чего подскажут :(
Ну а щас попробую убрать модуль из вашей конфигурации и опять добавить.
-
Короч, не знаю шо я там сделал, но таки запустил это наложение! Работает или нет не успел проверить, да и сил ужо не осталось. Не понимаю, чего не так делал, буду разбираться, т.к. 4 дня убито впустую. Просто не понимаю!
-
Может будет кому-то интересно...
В итоге оказалось, что на моей конфигурации не отрабатывалась olcSmbK5PwdEnable: krb5.
А ldif брал из /usr/share/doc/openldap-servers-2.4.-39/README.smbk5pwd
:(
olcSmbK5PwdEnable: samba
так работает.
включаю оба:
olcSmbK5PwdEnable: krb5
olcSmbK5PwdEnable: samba
забастовка.
охо-хо.
-
Добрый день!
У меня вопрос по главе книги "10.2.1 Полная потеря сервера"
Там написано
Где работаем: ldap-srv
Если сервер который крутит OpenLDAP сломается, то первым делом нам нужно будет найти другой или починить этот. Затем потребуется установить на него Ubuntu 14.04. Потом скопируйте на него файлы из резервной копии и выполните следующие команды:
# apt-get install -y slapd ldap-utils krb5-kdc-ldap krb5-pkinit krb5-admin-server libnss-ldapd libpam-ldapd wamerican sudo-ldap
# mv /etc/ldap /etc/ldap.install
# cd / && tar zxvf /tmp/slapd.directory.20141215.tar.gz
# update-rc.d slapd defaults
# service slapd start
Это поможет Вам начать работать. Конечно, затем нужно будет перенастроить rsyslog. Смотрите раздел 2.3.
Мне кажется или там действительно не хватает пункта восстановления самой базы из бекапа?
такогоже как в главе "10.2.3 Повреждение данных (или человеческий фактор)"
zcat /root/backup/slapd/slapd.data.20141212.ldif.gz > /tmp/slapd.data.ldif
# slapadd -v < /tmp/slapd.data.ldif
-
Здравствуйте, sfmc!
Вы правы, там действительно не хватает этапа восстановления данных каталога. Перевод англоязычного ресурса предоставил Павел Булка (в оригинале, кстати, тоже нет этого этапа), а я не удосужился прогнать на макете все примеры. Приношу свои извинения.
Поправил текст. Спасибо за внимательность и неравнодушие!
С уважением, Егор.