Friday, June 15, 2012

Kerberos and Active Directory Logins

Ray and I and some others have been working on making it easy to use Kerberos single sign on with GNOME 3.6. The feature itself isn't super revolutionary. You sign in with your realm login (eg: your Active Directory user name and password) and then you can go on and use other services with that same kerberos sign in.

You could already do this, but setting it up was hard ... and setting it up so it couldn't be trivially hacked was even harder. If you just use pam_krb5 without 'enrolling' your machine an attacker can log in as anyone (woooooo). ... and keeping it running without breaking down on you was even harder than that, especially for mobile environments.

So I've been working a lot on making this easy to setup; auto discovering the domain/realm, its settings and as much information as possible. Last week some user visible changes landed into gnome-control-center so here are some screenies.

You'll notice the new Enterprise Login mode of the Add account dialog:


It lets you add users from an Active Directory domain or FreeIPA (soon) realm, and perhaps others in the future.  Any domains we already know about are in the drop down. If this is the first time you're using the feature, we try and automatically discover the domain from your DHCP DNS domain name. We automatically discover what kind of realm/domain we're dealing with, all the other settings, and whether it's valid or not.

Login details for the user are typed in, and then we bonk the Add button:


We try to be intelligent about validation and give good feedback:

 

 


If the domain requires administrative credentials to enroll the local machine, then we prompt for those. Active Directory on Windows 2003 and later don't require admin creds by default. FreeIPA does.


And voila, the user is added. Only the users specifically added should be able to log in; there's actually a bit of work to do on that, but that's the plan. If an admin wants to enable any domain user to log in on the machine, then they can enroll the machine using the command line or admin tools. Both are supported, just not both in gnome-control-center.

Here I added two users, Fry and Leela. Not sure why one of them showed up with their full name and the other not. Something to fix...


Under the hood a the enrollment in realms is managed by a small DBus on-demand system service called realmd. realmd can also be driven using command line tools, which expose additional options.

It was important to me to make sure that the diagnostics are clear. So many of these tools throw up cryptic error messages without anywhere to go to figure out 'Why?'. So we try hard to have user visible error messages, and then very clear diagnostic output on the console when performing these operations, that looks like:

 * Looking up our DHCP domain
 * Searching for kerberos SRV records for domain: _kerberos._udp.ad.thewalter.lan
 * Searching for sub zone on domain: _msdcs.ad.thewalter.lan
 * dc.ad.thewalter.lan:88
 * Found AD style DNS records on domain
 * Successfully discovered realm: AD.THEWALTER.LAN

Hmmm, what else ... Ray's been working on other parts of this: fixing the user accounts panel so it makes sense for non-local users. And making sure that the Kerberos tickets we get at login are correctly renewed and reauthenticated.

SSSD


These guys. Props to the SSSD guys. They've been working hard to make that daemon the perfect client for Kerberos/IPA/AD. It's a modern clean implementation, and makes stuff like using your domain login when not attached to the domain really reliable and easy.

No mo' NTP Time Syncing


I've been running around the kerberos stack trying to fix issues that cause configuration problems, fragility or just plain nastiness. For example:

For decades now kerberos implementations have pretty much required you to sync your time up with the kerberos server. It makes you roll your eyes that a security protocol relies so much on time for security, when the syncing of that time is almost always insecure. But oh well.

Anyway, for the good news. 15 years ago these guys figured out how to do kerberos without time syncing. And bit by bit their ideas have made it into kerberos implementations, but nobody new about it because the there were tons of fiddly bits that made assumptions about time syncing. I did a few last patches to sort out some issues, which have been accepted by MIT Kerberos.


Anyway, that was long enough, there's lots more, but it's starting to get boring ...

Lots of patches are being merged as we speak, but if you want to test this stuff out right now, ping me on IRC #gnome-os on gimpnet, and I'll help you get started.

Oh and see you at GUADEC.

20 comments:

  1. Awesome work! This is one important aspect for making gnome easy to use in a corporate setting. Especially for small offices!

    ReplyDelete
  2. Thank you for your attention to this critical infrastructure. I would ask that any configuration steps made possible by the GUI would also be possible in a command-line (scriptable, unattended) fashion.

    ReplyDelete
  3. Can you elaborate a bit on "If you just use pam_krb5 without 'enrolling' your machine an attacker can log in as anyone" ?

    What are you referring to? An attacker that hijacks the kerberos tickets? Somebody logging on locally with a different kerberos username than their local account? Anything else?

    ReplyDelete
    Replies
    1. Unless there is a keytab on the client machine and tickets obtained from the KDC are being validated via that keytab ... then an attacker can intercept the requests to the KDC and provide seemingly good tickets back to the client machine for any password/account combination entered at the client machine login screen.

      This is not an issue if the ticket is used with a 'real' live kerberized service, because then that service would reject these bogus tickets. However if the tickets are used as an authentication mechanism to log into the client machine (or other local resources) then they must be validated. To accomplish that, the client must generally be enrolled and have a keytab or some other trust mechanism must be set up.

      Delete
  4. This is a step forward for getting GNOME 3 desktop ready for corporate deployments. This awesome great!

    ReplyDelete
  5. You are my hero! I have been working on doing this for GNOME 3.2 and needed to update to 3.4, but this is going to land in 3.6 right? If so, time to get my Fedora up to rawhide and help test!

    ReplyDelete
    Replies
    1. I'm working on getting it into rawhide right now. In fact working on getting rawhide setup... But yes, helping out with testing would be great. Going to land in GNOME 3.6.

      Delete
  6. How does it handle enterprise logins when disconnected from the network (e.g. train, plane, woods, etc)?

    ReplyDelete
    Replies
    1. Both the SSSD and Winbind AD clients support offline logins. realmd configure's one of those as part of the enrollment process. The SSSD implementation is much better thought out though, and less prone to problems.

      Delete
  7. Stef - any work on getting evolution-ews to use realmd for authentication?

    Finally, I know in our corporate network, we have web pages that makes us use our AD login/password to authenticate. I would love to see some way to allow webkit to autoauthenticate using realmd.

    Thoughts?

    ReplyDelete
    Replies
    1. Kerberos authentication should accomplish that.

      realmd is about configuring the local machine to be part of a kerberos realm, and login against it.

      What you want is to use kerberos tickets to connect to the server. If someone logs into the machine with their AD credentials, then they'll have a valid kerberos ticket. In theory that ticket should be usable with EWS.

      If not, then we should probably figure out where things are falling down.

      Delete
  8. Hello! Will it work in KDE environment?

    ReplyDelete
    Replies
    1. The underlying components, realmd and sssd are desktop neutral. But I don't think anyone has integrated them into the KDE UI yet.

      Delete
  9. Hi Stef!
    I'm not sure if this a bug or stupidity on my part. I was expecting to be able to use the obtained Kerberos token for SSH authentication, but receive the error

    debug1: Unspecified GSS failure. Minor code may provide more information
    Credentials cache file '/run/user/1000/krb5cc_eb946c60163fbaaf81fbc2d64f38dd4f/tkt' not found


    looking in that folder I find

    primary tktCsIQBh tktKgchBW tktPHhw5G

    where the content of primary is

    > cat primary
    tkt

    Changing this to

    > cat primary
    tktCsIQBh

    makes SSH auth via the Kerberos ticket work. Should I report this somewhere or am I missing something?

    ReplyDelete
  10. Thanks for reporting it. For anyone following along: https://bugzilla.gnome.org/show_bug.cgi?id=685876

    ReplyDelete
  11. I looked at bug 681767 and the resolution in User Accounts. It looks great. But I really need the same fix for the login screen/switch user screen.

    Also, I have the same issue mentioned above. I only get the last name for my users.

    ReplyDelete
  12. I wonder is there is any way of doing this though the terminal ?

    ReplyDelete
  13. Yes, you can do 'realm join mydomain.com' in recent like Fedora, Debian or other distros.

    ReplyDelete
  14. Thanks for all the hard work. I should be able to use Fedora at work now.

    ReplyDelete