On Thu, Jun 05, 2014 at 04:54:50PM +0200, Jurjen Bokma wrote:
Hi,
I believe the closing of
https://fedorahosted.org/sssd/ticket/1871#comment:2
to be wrong. Jakub Hrozek asked me to bring this up here after I brought it to his
attention through
https://bugs.launchpad.net/bugs/1274543
When it logs in to the AD server, sssd uses the first key in the keytab. In my case, that
first key is of a 'join account': a special purpose AD account that has permission
to join machines to the domain, and nothing else. In particular, it lacks the permissions
to list users. Hence it is unfit to be used by sssd for lookups. As soon as I remove the
offending key, sssd works fine, by using another key, which happens to work. When I put it
back in the keytab (as the first key), sssd stops working again. I second Jakub in the
opinion that sssd should select the 'right' principal to use: ldap_sasl_authid or
shortname$@realm.
I believe the cause of the problem to be in src/providers/krb5/krb5_child.c in the loop
immediately following the comment:
/* We look for the first entry from our realm or take the last one */
Indeed, if I make that loop skip the first key found, everything works as expected,
whether the ADJoiner key is in the keytab or not.
This is just an ad-hoc fix for my case of course.
Thank you for the report. I reopened
https://fedorahosted.org/sssd/ticket/1871 and it would be nice if you
can add your use-case to the ticket. The key point here is that your
first principal cannot be used as a service principal and hence cannot
be used for validation.
Another workaround would be to put the principal at some other place in
the keytab or to disable validation be setting 'krb5_validate = false'
in sssd.conf.
bye,
Sumit
Regards
Jurjen
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel