[SSSD] sssd-ad uses wrong key to verify tgt at login time

Sumit Bose sbose at redhat.com
Tue Jun 17 14:19:15 UTC 2014


On Tue, Jun 17, 2014 at 01:16:15PM +0200, Jurjen Bokma wrote:
> On 06/11/2014 11:06 AM, Sumit Bose wrote:
> >On Sat, Jun 07, 2014 at 01:20:24PM +0200, Jurjen Bokma wrote:
> >>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.
> >yes, that's why I reopened the ticket.
> >
> >Nevertheless about 'more applications use the system keytab by default'.
> >IMO this is bad practice and if you have a chance please complain at
> >vendors doing this. The reason is that other than e.g the global storage
> >for public SSL/TLS certificates the keytab entries should be compared
> >with passwords. If multiple applications share the keytab they allow the
> >other applications to access and use their passwords.
> I'd say that is true: not just any application should be allowed to use the
> system keytab. And indeed, msktutil has an option that allows the systems
> administrator to do just that. It can also run as a non-privileged user.
> Still, running msktutil as root is common practice, and I see nothing wrong
> with root processes being able to see passwords/keys (unless your security
> demands are strict). If they do, they have to be prepared to encounter each
> other's keys though, at which point sssd fails. Moreover, I don't see see
> why, if sssd is allowed to use the system keytab, msktutil shouldn't be
> allowed to do the same. Msktutil joins the machine to the domain and enables
> sssd in the first place.
> By your reckoning, the right solution is for sssd to support a different
> keytab than the system keytab. That is workable, but I wouldn't pick it as
> the best solution, because there are situations (which I've encountered)
> where sssd actually could (and IMHO should) use the msktutil's key from the
> system keytab. But if that key doesn't fit the lock, sssd shouldn't just
> break.

I agree, SSSD should not break that's why we have to fix
https://fedorahosted.org/sssd/ticket/1871. Btw, SSSD has the krb5_keytab
option which can tell SSSD to use a different keytab that
/etc/krb5.keytab.

bye,
Sumit

> 
> 'gards
> Jurjen
> 
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list