Segmentation fault when trying to start kadmind

[Joshua Schaeffer]

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