LINUX.ORG.RU
решено Форум — Admin  

OpenLDAP+Kerberos. Principal add failed: Insufficient access while creating

 ,


0

1 
kadmin.local
Authenticating as principal root/admin@PROX.LOC with password.
kadmin.local:  addprinc bob
No policy specified for bob@PROX.LOC; defaulting to no policy
Enter password for principal "bob@PROX.LOC": 
Re-enter password for principal "bob@PROX.LOC": 
add_principal: Principal add failed: Insufficient access while creating "bob@PROX.LOC".

Три дня люблюсь. Сдаюсь. В чём подвох? Надо write для kdc? Или пробел лишний где-нибудь, с которым я час …. Делаю по этой …. https://wiki.debian.org/LDAP/OpenLDAPSetup#Kerberos С начала и до kadmin.local для проверки дошёл.

PS Пошёл по пути kdc и kadmin, oclAccess для них давал. root’у ничего не давал.

PPS Я всё проскочил и сразу на kerberos. Может чего пропустил, как они любят в другом месте указать то без чего не работает вообще. А там и нет ничего, а индексы я вкорячил.

★

Последнее исправление: TepakoT (всего исправлений: 3)

на доступ в базу LDAP у тебя керберос ходит под своей учеткой? ему нужны права на всю ветку сервиса. скорей всего и инициализацию ветки неделали, команда kdb5_ldap_util

anonymous2 ★★★★★
()
Последнее исправление: anonymous2 (всего исправлений: 1)
Ответ на: комментарий от anonymous2

Реалм делался, пароли сташились. Больше в статье ничего. Буду копать в сторону керберос-учётка-kdb5_ldap_util.

kdb5_ldap_util -D cn=admin,dc=prox,dc=loc create -subtrees dc=prox,dc=loc -r PROX.LOC -s -H ldapi:///

kdb5_ldap_util -D cn=admin,dc=prox,dc=loc stashsrvpw -f /etc/krb5kdc/service.keyfile uid=kdc,ou=kerberos,ou=services,dc=prox,dc=loc

kdb5_ldap_util -D cn=admin,dc=prox,dc=loc stashsrvpw -f /etc/krb5kdc/service.keyfile uid=kadmin,ou=kerberos,ou=services,dc=prox,dc=loc

Уже и root’а вкорячил и всем write дал для эксперимента.

dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}to attrs=krbPrincipalKey by anonymous auth by dn.exact="uid=kdc,
 ou=kerberos,ou=Services,dc=prox,dc=loc" write by dn.exact="uid=kadmin,ou=kerb
 eros,ou=Services,dc=prox,dc=loc" write by dn.exact="gidNumber=0+uidNumber=0,c
 n=peercred,cn=external,cn=auth" write by self write by * none
olcAccess: {1}to dn.subtree="cn=krbContainer,ou=kerberos,ou=Services,dc=prox,d
 c=loc" by dn.exact="uid=kdc,ou=kerberos,ou=Services,dc=prox,dc=loc" write by 
 dn.exact="uid=kadmin,ou=kerberos,ou=Services,dc=prox,dc=loc" write by dn.exac
 t="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write by * none
olcAccess: {2}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {3}to attrs=shadowLastChange by self write by * read
olcAccess: {4}to * by * read
TepakoT ★
() автор топика
Ответ на: комментарий от anonymous2

Включил я olcLogLevel на -1 и ах…как много информации. Буду разгребать, подкручу LogLevel, от этого «no write access to parent» мне легче не стало, пойду погуглю.

Feb  1 12:01:39 pdc slapd[191]: ==> mdb_add: krbPrincipalName=bob@PROX.LOC,cn=PROX.LOC,cn=kerberos,ou=services,dc=prox,dc=loc
Feb  1 12:01:39 pdc slapd[191]: oc_check_required entry (krbPrincipalName=bob@PROX.LOC,cn=PROX.LOC,cn=kerberos,ou=services,dc=prox,dc=loc), objectClass "krbPrincipal"
Feb  1 12:01:39 pdc slapd[191]: oc_check_required entry (krbPrincipalName=bob@PROX.LOC,cn=PROX.LOC,cn=kerberos,ou=services,dc=prox,dc=loc), objectClass "krbPrincipalAux"
Feb  1 12:01:39 pdc slapd[191]: oc_check_required entry (krbPrincipalName=bob@PROX.LOC,cn=PROX.LOC,cn=kerberos,ou=services,dc=prox,dc=loc), objectClass "krbTicketPolicyAux"
Feb  1 12:01:39 pdc slapd[191]: oc_check_allowed type "krbLoginFailedCount"
Feb  1 12:01:39 pdc slapd[191]: oc_check_allowed type "krbPrincipalName"
Feb  1 12:01:39 pdc slapd[191]: oc_check_allowed type "krbPrincipalKey"
Feb  1 12:01:39 pdc slapd[191]: oc_check_allowed type "krbLastPwdChange"
Feb  1 12:01:39 pdc slapd[191]: oc_check_allowed type "krbExtraData"
Feb  1 12:01:39 pdc slapd[191]: oc_check_allowed type "objectClass"
Feb  1 12:01:39 pdc slapd[191]: oc_check_allowed type "structuralObjectClass"
Feb  1 12:01:39 pdc slapd[191]: slap_get_csn: conn=1029 op=6 generated new csn=20230201090139.357977Z#000000#000#000000 manage=1
Feb  1 12:01:39 pdc slapd[191]: slap_queue_csn: queueing 0x7f6a8010ab40 20230201090139.357977Z#000000#000#000000
Feb  1 12:01:39 pdc slapd[191]: mdb_dn2entry("krbPrincipalName=bob@PROX.LOC,cn=prox.loc,cn=kerberos,ou=services,dc=prox,dc=loc")
Feb  1 12:01:39 pdc slapd[191]: => mdb_dn2id("krbPrincipalName=bob@PROX.LOC,cn=prox.loc,cn=kerberos,ou=services,dc=prox,dc=loc")
Feb  1 12:01:39 pdc slapd[191]: <= mdb_dn2id: get failed: MDB_NOTFOUND: No matching key/data pair found (-30798)
Feb  1 12:01:39 pdc slapd[191]: => mdb_entry_decode:
Feb  1 12:01:39 pdc slapd[191]: <= mdb_entry_decode
Feb  1 12:01:39 pdc slapd[191]: => access_allowed: add access to "cn=PROX.LOC,cn=kerberos,ou=services,dc=prox,dc=loc" "children" requested
Feb  1 12:01:39 pdc slapd[191]: => dn: [2] cn=krbcontainer,ou=kerberos,ou=services,dc=prox,dc=loc
Feb  1 12:01:39 pdc slapd[191]: => acl_get: [5] attr children
Feb  1 12:01:39 pdc slapd[191]: => acl_mask: access to entry "cn=PROX.LOC,cn=kerberos,ou=services,dc=prox,dc=loc", attr "children" requested
Feb  1 12:01:39 pdc slapd[191]: => acl_mask: to all values by "uid=kadmin,ou=kerberos,ou=services,dc=prox,dc=loc", (=0) 
Feb  1 12:01:39 pdc slapd[191]: <= check a_dn_pat: *
Feb  1 12:01:39 pdc slapd[191]: <= acl_mask: [1] applying read(=rscxd) (stop)
Feb  1 12:01:39 pdc slapd[191]: <= acl_mask: [1] mask: read(=rscxd)
Feb  1 12:01:39 pdc slapd[191]: => slap_access_allowed: add access denied by read(=rscxd)
Feb  1 12:01:39 pdc slapd[191]: => access_allowed: no more rules
Feb  1 12:01:39 pdc slapd[191]: mdb_add: no write access to parent
Feb  1 12:01:39 pdc slapd[191]: send_ldap_result: conn=1029 op=6 p=3
Feb  1 12:01:39 pdc slapd[191]: send_ldap_result: err=50 matched="" text="no write access to parent"
Feb  1 12:01:39 pdc slapd[191]: send_ldap_response: msgid=7 tag=105 err=50
Feb  1 12:01:39 pdc slapd[191]: conn=1029 op=6 RESULT tag=105 err=50 text=no write access to parent
TepakoT ★
() автор топика
Ответ на: комментарий от TepakoT

Исправил на olcAccess: {1}to dn.subtree="cn=PROX.LOC,ou=kerberos,ou=Services,dc=prox,dc=loc" ибо не вижу создания никаких krbContainer. Но не помогло. Поищу ещё такие дибильные заглушки внимательнее.

TepakoT ★
() автор топика
Последнее исправление: TepakoT (всего исправлений: 1)
Ответ на: комментарий от TepakoT

Ну вот как б так? Если контейнер для принципалов

dn: cn=PROX.LOC,cn=kerberos,ou=services,dc=prox,dc=loc

то почему в статье acl

olcAccess: {1}to dn.subtree="cn=krbContainer,ou=kerberos,ou=Services,dc=example,dc=com" ??111!

А это что??

zcat /usr/share/doc/krb5-kdc-ldap/kerberos.openldap.ldif.gz | ldapadd -Q -Y EXTERNAL -H ldapi:/// 
adding new entry "cn=kerberos,cn=schema,cn=config"

А это что??

ldap_kerberos_container_dn = cn=kerberos,ou=Services,dc=example,dc=com

Поменял на olcAccess: {1}to dn.subtree="cn=kerberos,ou=services,dc=prox,dc=loc" и всё заработало.

Похоже они хотели сделать контейнер принципалов krbContainer/EXAMPLE.COM в ветке ou=kerberos и промахнулись, в ou=services получились ou=kerberos и cn=kerberos.

TepakoT ★
() автор топика
Ответ на: комментарий от TepakoT

Похоже должно быть так

ldap_kerberos_container_dn = cn=krbContainer,ou=kerberos,ou=Services,dc=example,dc=com

а не так

ldap_kerberos_container_dn = cn=kerberos,ou=Services,dc=example,dc=com

Тогда всё остальное соответствует.

Погнали дальше, теперь DNS и DHCP.

TepakoT ★
() автор топика
Последнее исправление: TepakoT (всего исправлений: 1)
Admin