On 06/06/2014 10:24 AM, Sumit Bose wrote:
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
Thanks for
reopening! I pleaded my case in Trac.
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.
Thank you for the suggestions. Yet another workaround is to have the
application (i.c. msktutil) that put the offending key in the keytab use
another keytab entirely. That's what I did. My latest solution is even
nicer: have the join account on a puppet server, and never even use it
from the client. So I'm not even affected by the bug any more.
But more applications use the system keytab by default, reconfiguring
each to use another keytab is tedious. Moreover, when an offending key
is first in the keytab, sssd fails silently unless logging is
sufficiently verbose, and the message is rather cryptic. The admin
doesn't suspect keytab problems because the proper key *is* in the
keytab too, and will only grow suspicious when he starts sniffing the
network connection for Kerberos traffic.
IMHO, the key point is that the first key will often work, but the
assumption that it'll *always* work is just plain wrong. Please add code
to pick the right principal.
Best Regards
Jurjen