Configuring Kerberos Network Identity

Design is being done to use centrally managed network connected logins like kerberos.

In order to use kerberos logins, the machine needs to be setup to use the kerberos realm that these logins are stored in. This setup can be done during "firstboot" during install, or at a later time from the control center.

Participants

Stef Walter, ...

Status

• Needs design

  Design in progress

  Needs implementation

  Implementation in progress

  Stable

Objectives

• 1) To configure the machine so that kerberos tickets can be retrieved after logging into a local account. 2) To configure the machine so that kerberos tickets used to log into the local machine, without a local account.
• Configuring kerberos should be as simple or simpler than on Windows.
• Should work with Windows Active Directory, "out of the box", without modifications to the Active Directory domain.
• Almost kerberos options and settings should be automatically detected or have usable defaults.
  • The only information we need is the realm domain name, and administrator credentials.
  • We may want to prompt for user credentials to test them up front during configuration.
• We'll usually be able to automatically determine if a realm is an Active Directory realm or IPA, or other.

• Non goal: We don't need this user interface to configure every possible option. Obviously admins of large networks can script or otherwise automate joining machines to domains. This here is targetted at users and small administrators.

Use case: Logging in using network identity

• Fry is a user on an Active Directory corporate network.
• Fry sets up GNOME on his new laptop, and wants to use his corporate user name and password to log into it.
• In firstboot, he chooses the option to use network accounts, and types his corporate domain name.
• If his corporate account has permission to join a new machine to the domain, then Fry types his user name and password. If not, then he asks his system administrator to come over and type admin credentials.
• After completing setup, he sees instructions or UI elements that allow him to log in using his network identity.
• At a later date, when not connected to the corporate network, Fry can still use his network identity to log onto his account on the local machine.

Use case: Using a network identity with a local account

• Leela has already setup her GNOME laptop, and wants to access file shares and intranet websites on an Active Directory corporate network.
• Leela goes to the GNOME control center, and chooses the option to setup a new network identity.
• She types the corporate domain name.
• She is prompted for her corporate user name and password.
• Leela is then able to access corporate services, like file sharing without again being prompted for a password.

Integration points

• gnome-control-center, probably through a dialog invoked by a button on the user identities page.
• Integrated into firstboot setup in ananconda.

Design Limitations

• In order to use kerberos to log in as a user onto the local machine (without a local account), we must have "joined" the machine to the realm. Not doing this leads to a security hole. This is due to limitations in kerberos.
  • Joining the machine to the domain, creates host credentials on the machine, which can be used to verify that the tickets are coming from the actual KDC. If not done, then a rogue KDC can answer authentication requests, allowing access to the local machine to an attacker on the local network.
  • If only getting kerberos ticket once already logged in as a local user, machine credentials are not necesary, and therefore joining the machine to the domain is not strictly necessary.
• "Joining" the machine to the realm often requires Administrator credentials for the realm in question, or credentials of some other kerberos account that has permission to add a new machine to the domain.
• Currently setting up a FreeIPA kerberos client always requires administrative credentials for the realm in question.
• NTP needs to be setup to use the Active Directory controller as an NTP server in order to guarantee painless operation. The NTP user interface should reflect this.

Relevant Art and current experiences

Windows XP

Joining a domain is not super discoverable, usually done during setup.

http://windows.microsoft.com/en-US/windows7/Connect-your-computer-to-a-domain

Mac OSX

OpenSUSE

• Doesn't seem to actually request ticket automatically, after joining domain (but couldn't log in as that user, so questionable).
• In installer click hidden in plain sight 'Change...' button on 'Create New User' page, choose 'Windows Domain'

• After installer, in first time configuration, type domain, create homedir, offline etc.

• Click NTP, and use your intimate knowledge of NTP terminology to configure domain server as your NTP server.
• DNS not setup automatically.

• Install packages when prompted, flicker, downloading, wait

• Enter Administrator password when prompted with collapsed dialog.

• Yay it worked!

• Don't use GNOME mode for login, as the setup does strange things with the window sizes and some dialogs are collapsed in the display manager.

Fedora 16

• During setup there's a button "Use Network Login", with a "Join Domain" button in resulting dialog.
• Prompts for all sorts of information (Winbind Domain, Security Model, Winbind ADS Realm, Winbind Domian Controllers, Template Shell, allow offline login).
• Cannot use any of this during fedora setup, because of the fact that samba-winbind is not installed.

• After installation: system-config-authentication
• Tells you to install 'samba-winbind'

• Fill in all the info (5 fields), click 'Join domain', click 'Save', type admin password.
• Hard to know what goes in all these fields, should be discovered automatically.
• Failure without any message. Windows actually doesn't display anything useful either, just generic failed message. So here we're approaching feature parity.
• Details visible in terminal if system-config-authentication started.
• SELinux caused failure. Filed bug #790111
• sudo setenforce 0

• Try again. This time message about "Server not found in Kerberos database" visible in terminal (no error displayed in UI).
• Clear the Windows Domain Controllers field.
• Try again. This time "clock skew too great" failure visible from terminal (no error displayed in UI).
• sudo yum install ntpdate
• wait for yum to download the internet, coffee
• sudo ntpdate windows-dc.thewalter.lan
• Try again. This time it worked, again without status message or indication that we're joined to domain.
• The krb5.conf file created was invalid for requesting a ticket on the domain, in particular servers were missing and dns_lookup_realm = false, dns_lookup_kdc = false, and domain_realm
• DNS server not setup automatically.

Debian Kerberos

• Debian prompts during install of Kerberos for info using their deb package GUI stuff.

SADMS

• SADMS is a tool that is a strange combination of filling in fields and then clicking toolbar buttons to make stuff happen, in order to join a domain.

Centrify

• Centrify is a set of command line packages and scripts that enable an alternative implementation of an AD client on the machine, with support for advanced features like group policy. There doesn't seem to a be a GUI, at least not in the packages I downloaded for RHEL.

Common configuration problems

• Packages not installed (samba-winbind). Should integrate with package kit, or have the package installed by default.
• Time not synced with domain controller. When joined to a directory or domain, we probably should lock the NTP source to the domain controller. Need to present this correctly to user in the control center.
• DNS not setup correctly, should be using a DNS server aware of the domain.

Implementation Notes

• A system DBus service started on demand, which exposes a standard XDG DBus interface, for configuring kerberos on the local machine, and enrolling the machine in kerberos.
  • The DBus interface would be consumed by firstboot and gnome-control-center.
  • Multiple implementations of this dbus service. eg: one for AD and another for IPA.
• We shouldn't prompt for all info about the domain, just ask for the domain, and leave the other options for command line or possibly administrative tools like authconfig.

• SSSD is developing support for Windows SID to Unix UID mapping, which would allow it to be a client for AD "out of the box": https://fedorahosted.org/sssd/ticket/996

  • The aim is to get have this ready around the time frame of GNOME 3.6, so we could use it.
  • If not ready, then we'd have to fall back on winbind as the AD client.
• Need to test logging in with network identity heavily, and see which other settings or factors can prevent login.
  • For example, with OpenSUSE I renamed the machine, and then could no longer log in.

Discussion

• None of this should preclude deploying kerberos to clients via scripting or other advanced tools. Option junkies, and networks with special requirements should do it this way.
• Machine enrollment is also needed to provide services to the realm. If (later) setting up file sharing, we should check if the machine has been enrolled, and if not enroll it. Could use the same DBus interface, and perhaps the some parts of the same UI design (ie: dialogs).
• If joining a machine to the domain fails (perhaps due to missing credentials), this means we cannot enable logging into the local machine with kerberos identity. But we may want to fallback to allowing the user to configure kerberos so that they can get a ticket after logging in with a local account.