Форум проекта Pro-LDAP.ru
Общие вопросы по LDAP => Общий раздел => Тема начата: regul8or от 11 Январь 2016, 15:45:35
-
Здравствуйте. Пытаюсь настроить Kerberos с OpenLDAP под Ubuntu - в соответствии с 9 главой замечательного руководства.
Есть сервер LDAP с загруженной схемой. В каталоге создан контейнер для принципалов Kerberos и настроен ACL.
На сервере с Kerberos установлены krb5-kdc-ldap и krb5-admin-server. Отредактированы krb5.conf, kadm5.acl, kdc.conf.
kdb5_ldap_util stashsrvpw пароль извлекает, kdb5_ldap_util create -subtrees создаёт записи принципалов в контейнере в каталоге. Контейнер правильный, область - правильная. А вот дальше этого не пройти.
$ kadmin.local
Authenticating as principal [i]userid[/i]/admin@[i]REALM[/i] with password.
kadmin.local: Error reading password from stash: Cannot open LDAP password file '/etc/krb5kdc/service.keyfile': Permission denied while initializing kadmin.local interface
$ sudo kadmin.local
Authenticating as principal root/admin@[i]REALM[/i] with password.
$
В первом случае всё логично, у userid нет доступа к файлу-тайнику. А во втором случае в /var/log/syslog есть сообщение о segfault в libkdb5.so.7.0. Всё что я нашёл в интернетах по этому поводу - это то что это такая реакция на отсутствие krbPrincipalKey. Однако, в созданных в каталоге записях этот атрибут есть у всех принципалов.
Куда копать? Учитывая, что в Kerberos я понимаю довольно слабо, уже хочется плюнуть на эту затею и оставить локальную БД, тем более что с ней всё нормально.
-
regul8or, покажите, пожалуйста, Ваши ACL:
# ldapsearch -ZZQLLLb cn=config olcAccess
-
$ sudo ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b cn=config olcAccess
dn: cn=config
dn: cn=module{0},cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: cn={4}dhcp,cn=schema,cn=config
dn: cn={5}kerberos,cn=schema,cn=config
dn: olcBackend={0}hdb,cn=config
dn: olcDatabase={-1}frontend,cn=config
olcAccess: {0}to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
by * break
olcAccess: {1}to dn.exact=""
by * read
olcAccess: {2}to dn.base="cn=Subschema"
by * read
dn: olcDatabase={0}config,cn=config
olcAccess: {0}to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
by * break
dn: olcDatabase={1}hdb,cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange,krbPrincipalKey,userPKCS12
by dn="cn=admin,dc=regul8or,dc=home" write
by anonymous auth
by self write
by * none
olcAccess: {1}to dn.subtree="cn=kerberos,ou=services,dc=regul8or,dc=home"
by dn="uid=krbadm,ou=users,dc=regul8or,dc=home" manage
by dn="cn=admin,dc=regul8or,dc=home" write
by * none
olcAccess: {2}to dn.subtree="ou=dhcp,ou=services,dc=regul8or,dc=home"
by dn="cn=dhcpadm,ou=users,dc=regul8or,dc=home" write
by dn="cn=admin,dc=regul8or,dc=home" write
by * none
olcAccess: {3}to dn.base=""
by * read
olcAccess: {4}to *
by dn="cn=admin,dc=regul8or,dc=home" write
by * read
-
Похоже, что Вы не загрузили ACL 9.1-kerberos.acl.ldif (Раздел 9.1 руководства).
Чтобы kadmin.local имел права доступа к принципалам Kerberos, его надо запускать от суперпользователя, это верно. Но и самому суперпользователю должно быть разрешено читать принципалов из базы.
Поэтому ACL для Вашей БД должен начинаться так:
dn: olcDatabase={1}hdb,cn=config
olcAccess: {0}to *
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * break
olcAccess: {1}to attrs=userPassword...
Попробуйте загрузить ACL 9.1-kerberos.acl.ldif, проверьте, корректно ли он загрузился и ещё раз запустите kadmin.local от суперпользователя.
-
А это не то?
olcAccess: {1}to dn.subtree="cn=kerberos,ou=services,dc=regul8or,dc=home"
by dn="uid=krbadm,ou=users,dc=regul8or,dc=home" manage
by dn="cn=admin,dc=regul8or,dc=home" write
by * none
-
Понял, что Вы имеете в виду
Попробую.
-
Всё-таки нет. Да, я добавил предложенное правило и результат остался тем же - segfault/
kerberos и slapd у меня на разных серверах.
/etc/krb5.conf
[dbdefaults]
ldap_kerberos_container_dn = cn=kerberos,ou=services,dc=regul8or,dc=home
[dbmodules]
openldap_ldapconf = {
db_library = kldap
# ldap_kerberos_container_dn = cn=kerberos,ou=services,dc=regul8or,dc=home
ldap_kdc_dn = uid=krbadm,ou=users,dc=regul8or,dc=home
ldap_kadmind_dn = uid=krbadm,ou=users,dc=regul8or,dc=home
ldap_servers = ldap://ldap.regul8or.home
ldap_conns_per_server = 5
ldap_service_password_file = /etc/krb5kdc/service.keyfile
}
etc/krb5kdc/kdc.conf:
[kdcdefaults]
kdc_ports = 750,88
[realms]
REGUL8OR.HOME = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:no
rmal des:v4 des:norealm des:onlyrealm des:afs3
default_principal_flags = +preauth
}
-
Откровенно говоря, разносить сервисы KDC и LDAP на разные серверы я не пробовал.
Но возможно я знаю, в чём проблема. Попробуйте сначала получить тикет от KDC:
$ kinit -p krbadm/admin@REGUL8OR.HOMEИли
$ kinit -p krbadm@REGUL8OR.HOMEИ проверьте, получили ли вы тикет с помощью
$ klist
А затем попробуйте запустить kadmin.local.
-
Оба заклинания не работают. Результат один:
kinit: Cannot contact any KDC for realm 'REGUL8OR.HOME' while getting initial credentials
И это наверное потому что KDC запуститься не смог из-за того же segfault-а
-
Погодите! Так сервис KDC не работает и не запускается?
# service krb5-kdc start
-
* Starting Kerberos KDC krb5kdc
Segmentation fault (core dumped) [fail]
-
regul8or, к сожалению, мой диагноз не утешительный.
Скорее всего служба KDC не стартует потому, что некорректно созданы записи для принципалов. А это, в свою очередь, произошло потому, что на этапе создания контейнера для принципалов и позже нужно вручную синхронизировать ключи из keytabs серверов KDC и LDAP.
Увы, в ближайшее время я не смогу воссоздать конфигурацию с раздельными серверами и найти источник проблемы. Слишком много работы. Могу лишь порекомендовать поднять всё на одном сервере.