On 07/19/2017 09:45 AM, Greg Hudson wrote:
>
> This error message is likely conflating "K/M doesn't exist" with "K/M
> exists but has no key data".
>
> In the LDAP record you included, there is no krbPrincipalKey attribute,
> as one would ordinarily see in the K/M record. That key data should be
> included when the DB is created by kdb5_ldap_util; I have no theories as
> to why it's not showing up in your scenario.
Greg, thanks for pointing this out, it got me on the right track to fixing the
problem. It turned out to be an LDAP access issue. I started by deleting
everything from LDAP and then recreating the realm and when I checked LDAP
again I saw the krbPrincipalKey attribute, but then when I tried to create the
stash I got the same error. So I re-queried LDAP again and I could no longer
see the krbPrincipalKey. This got me thinking about the access lists I had
setup. I had these two:
**
olcAccess: {0}to attrs=shadowLastChange,krbPrincipalKey
by self write
by anonymous auth
by dn="cn=admin,dc=appendata,dc=net" write
by * none
olcAccess: {6}to dn.sub="cn=krbContainer,dc=appendata,dc=net"
by dn="cn=kdc-srv,dc=appendata,dc=net" read
by dn="cn=adm-srv,dc=appendata,dc=net" write
by * break
Since the ACL that gives the ldap_kdc_dn and ldap_kadmind_dn come after the ACL
that controls the krbPrincipalKey attribute, it was never getting to the second
ACL and was not able to actually see the krbPrincipalKey attribute. That's why
I was able to see the attribute at first, because I was using the admin user
from the LDAP server (its just habit for me to do that when I'm on the actual
LDAP server). Then I switched to using the adm-srv user when I was on the
Kerberos server since this is the actual user that queries LDAP for Kerberos. I
updated my ACL's and was able to get pass all my errors and issues, including
the segmentation fault.
I do have a couple more questions though:
* Do you know if ldap_kdc_dn needs read rights to the krbPrincipalKey
attribute? My understanding is that it just needs read rights to everything
under my krbContainer, which is what I have, but does it need to actually read
the keys. If not, I'd like to take this access away. Obviously I'll keep the
read and write rights for ldap_kadmind_dn.
* Would you consider the segmentation fault a bug? I know it was a
configuration problem, but it was not necessarily easy or quick to track this
down
and it was not obvious an access issue was the problem. An actual error might
be more helpful. I'm sure this problem can be duplicated by simply setting up
KRB5 to connect to LDAP and configure the ACL's like I did.
>
> The default name for the stash file is .k5.<REALM> in the KDC directory.
> (That default was chosen some decades ago and would not be my choice
> today.) So I guess search for ".k5.". The key_stash_file profile
> variable in the kdc.conf realm subsection can be used to override the
> filename.
This is good to know, thanks.
Thanks,
Joshua Schaeffer
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
