From Fedora Project Wiki

About this Document

Version Date Notes
Version 2 (This page) 15 February 2010, updated 17 February 2010 Now we have a single UI that integrates both SSSD and legacy functionality. One issue - only one domain visible at a time. Updated 17 Feb to better address smartcard usage.
Version 1 10 February 2010 Initial cut; had concept of a new UI and an old UI.

About this Project

What is SSSD?

SSSD (an acronym for 'System Security Services Daemon') is a Fedora Hosted free software project that aims to provide access to identity and authentication remote resource through a common framework that can provide caching and offline support to the system. It provides PAM and NSS modules, as well as D-BUS based interfaces. It provides also a better database to store local users as well as extended user data.

What is system-config-auth?

System-config-auth is a GUI utility used to set up both local and network authentication (user logins) to the system it runs on. The current legacy UI is very old. SSSD, a new system, is a much better technical solution to managing authentication than the legacy system. However, SSSD does not yet support as many authentication methods as the legacy system.

The legacy system is best classified as a set of cobbled-together technology pieces, while SSSD is more integrated.

What is the design problem?

We have a new developing technology, SSSD, to manage authentication and need to provide a UI design to help desktop users to configure authentication for their systems. There is a legacy UI in place to do this though - system-config-auth - and it is difficult-to-use. However, the old UI supports some functionality that has not been implemented in SSSD yet.

The challenges here are:

  • Design a new UI for setting SSSD configuration.
  • Enable users to still use the old UI for functionality not supported by SSSD/
  • Avoid revisiting the design of the old UI as we do not have developer resources and time to do this right now.
  • Guide users to the right UI for the job even though the criteria by which we determine the right UI for them are confusing and inconsistent.

Who is meant to use this UI?

First of all, these UIs are both accessible to users who have root-level access to the system in question. We restrict our target users to those users who administer their own system enough to have acquired root access. Users whose system is administered by someone else will have this setup already configured for them.

Secondly, while it is possible an administrator could use ssh -Y to connect to this configuration UI on remote servers with X & GTK+ installed, it is assumed that this tool will primarily be run on the system it is being used to configure. Therefore, we're assuming a desktop workstation with a monitor or a laptop, and that the user is sitting in front of the system.

Next, let's talk a little bit about system authentication. This application is targeted for users who use network-based / centrally-managed configuration. We assume the vast majority of Fedora and Linux desktop users use what is called 'local' authentication - this means the user account used to allow them to log into their system exists on the system and not in some centrally-managed database. These users will not get any use out of this UI. This is not to say these users would not interact with a remote account to say, get their corporate email. What this means, practically speaking, is that our assumption is that when most Fedora users turn on their system and get a GDM / KDM / XDM login screen in order to access a desktop environment on the system, the username and password they type on that login screen exist locally on that system, not in a centralized database.

Out of the subset of users that will use network-based, centrally-managed authentication systems, it is our assumption that 95% of these users will only need to authenticate to one domain (for example, a university network or a corporate network.) We assume that 5% or less of the set of users that will use centrally-managed authentication to log into their system will need to configure multiple domain authentication.

In summary, our design assumptions for the target of this UI are as follows:

  • Only users who use centrally-managed authentication - 95% of which will only need to worry about one domain.
  • Desktop users - either a desktop workstation or a laptop. We assume laptops will be more common.
  • Users will be physically present in front of the system they are configuring. They won't be configuring another system over the network.
  • Most Fedora users will not need to use this interface.
  • Only root-level users will have access to the interface. This means either power users / self-administered users will use it, or system administrators using the tool to generate configurations to deploy to other systems will use it.

Use-Cases

Case A: Single-Domain

This user uses a single centrally-managed account to log into their system, most likely their place of employment or maybe school (I assume most US schools don't do this though.) They may also have a local account for debugging / troubleshooting or for personal work on the same machine. This configuration will be supported by the UI.

Case B: Multi-Domain

This user may need to log into their machine using two or more accounts that are centrally-managed via two or more systems. For example, if a user is an employee for one corporation and a contractor for another, and has a login to each on the same computer. Extremely rare case. To address this case, the user will not be able to use the UI - instead, they will need to hand-configure this setup in the configuration file. If a user has multiple domains, they will almost never have more than 3 or 4, and 2 is the most common. Sometimes, the user might have domains configured that are not active. They may need a function to set them as active or inactive.

Case C: Local Only

This user only uses the built-in local authentication and account system. They do not need to access a centrally-managed database to log in. This case represents the vast majority of users.

Stories For How Users Will Encounter This UI

Story 1: Fresh Install, Local Only User

  1. User downloads a copy of Fedora from www.fedoraproject.org.
  2. User installs Fedora using the default settings.
  3. User boots machine and encounters firstboot.
  4. User encounters the 'create user' screen of firstboot. He or she is advised that if they need to set up centrally-managed logins, they'll need to click the 'use centrally-managed login' button (We'll avoid the use of the word 'network' since is more vague than 'centrally-managed' for local-only users.)
  5. The user might click on the 'use centrally-managed login' button and get the system-config-auth dialog with two tabs in it, but hopefully will quickly realize it's not meant for them to use and close the dialog, continuing on with firstboot.
  6. The user will log into the desktop without issue.
  7. Ideally, at this point, System > Administration > Authentication will not be available. If it is, the user may open this up through exploration or by accident and encounter the UI there as well.

Story 2: Fresh Install, Single-Domain User

  1. User downloads a copy of Fedora from www.fedoraproject.org.
  2. User installs Fedora using the default settings. They set up a local root account here.
  3. User boots machine and encounters firstboot.
  4. User encounters the 'create user' screen of firstboot. He or she is advised that if they need to set up centrally-managed logins, they'll need to click the 'use centrally-managed login' button (We'll avoid the use of the word 'network' since is more vague than 'centrally-managed' for local-only users.)
  5. User clicks the 'use centrally managed login' button and selects the combination of identity & auth settings they need to based on the technology on their network rather than sssd/legacy split. Depending on the choices the user makes, either sssd will be enabled or the legacy stack will be used.
    • What if the user doesn't know what technology the server uses? They'd be in a bind regardless of the design here - they need this information to be able to set any of this up. We assume it's provided by their helpdesk.
    • The user may be anxious to set up a non-root local account. Should there be a tooltip informing them they may do so later by logging in as root and using System > Administration > Users and Groups??
    • User cannot log in as root to use to System > Administration > Users and Groups to set up a local non-root account - root logins are disabled.
  6. The user finishes firstboot, and attempts to log into their system.
  7. Centrally-managed login works. Yay! All is good.
  8. Centrally-managed login fails. Darn! What went wrong?
    • Is there network access? (does GDM ask this troubleshooting question?)
    • Did the user set something up incorrectly? (does GDM suggest logging in as root and going to the auth ui to fix?)

Discussion

  • This user may be concerned at this point about setting up a local account. They have root already by this time, that's set up in the install program. We could tell the user to log in as root and set up a local account on the command-line, or we could let them create the local account right here (latter is more convenient.) However, that convenience may come at the expense of some convenience for the vast majority of Fedora users.

Story 3: Fresh Install, Multi-Domain User

  1. User downloads a copy of Fedora from www.fedoraproject.org.
  2. User installs Fedora using the default settings. They set up a local root account here.
  3. User boots machine and encounters firstboot.
  4. User encounters the 'create user' screen of firstboot. He or she is advised that if they need to set up centrally-managed logins, they'll need to click the 'use centrally-managed login' button (We'll avoid the use of the word 'network' since is more vague than 'centrally-managed' for local-only users.)
  5. User clicks the 'use centrally managed login' button and selects the combination of identity & auth settings they need to based on the technology on their network rather than sssd/legacy split. Depending on the choices the user makes, either sssd will be enabled or the legacy stack will be used.
  6. The user finishes firstboot, and attempts to log into their system.
  7. Centrally-managed login works. Yay! All is good.
  8. User manually edits configuration files to configure a second domain.

Story 4: Pre-configured Centrally-Managed Desktop

  1. User receives a company-issued desktop with Fedora or RHEL pre-installed on it.
  2. This laptop is pre-configured to log them into the corporate network. They turn it on and attempt to log into their system using credentials provided by their employer.
    • Centrally-managed login works. Yay! All is good.
    • Centrally-managed login fails. Darn! What went wrong?
  3. Let's assume it worked.
  4. User clicks on System > Administration > Authentication (for legacy) or System > Administration > Centrally-Managed Authentication (SSSD ui). Prompted for root password.
    • If they have root, they can see the settings for the first domain only populated in the UI.
    • If they don't have root, they don't open the UI.

What login/authentication methods does SSSD support? What methods are supported by the legacy system?

SSSD

For looking up user accounts on the network, SSSD supports:

  • LDAP servers (including POSIX-friendly Active Directory servers)
  • IPA servers

NIS will be supported in the future.

For actual authentication, SSSD supports:

  • Kerberos passwords
  • LDAP passwords
  • IPA passwords

Legacy System

The legacy system supports non-POSIX Active Directory servers via Winbind, Hesiod servers, NIS, smartcards, and fingerprint readers.

A Note About Offline Authentication

ervers have policies that enforce how often a user may log in while offline without connecting to the authentication server, and can set when that cache expires. Client-side, you can also enable or disable offline login and how old the cache is allowed to get before the user must connect to the server. The server settings, of course, always override what you can set on the client. If the server says your cache will only last 3 days for offline, and you set it to expire after 99 years client-side - the server setting is going to trump the client setting. The client-side enforcement is easily gotten-around by a user with root. It's really not there to prevent a user from logging in to their local machine. Truthfully, it's real purpose is to provide two things, when it's configured correctly (i.e. set up to expire at least somewhat before the server-side enforcement expires).

  1. It will notify the user when they authenticate (by way of a PAM message) that their local credentials are only valid for N more days. This provides the end-user some feedback to know how often they need to check in with the main systems.
  2. If configured as I mentioned before, with the expiration occurring a reasonable amount of time before the server-side lockout, it provides users the ability to recover their credentials without having to contact the helpdesk and have the account unlocked. They just come into the office or attach to the VPN by other means and perform an online login. This has the dual effect, then, of refreshing their local credentials as well as resetting the timeout for the server-side enforcement.

These policies are meant mainly to require users to 'phone home' frequently enough to stay in compliance with account policies - for example, so the user will hit forced password changes. To the user, though, expiration means that until the user can connect to the appropriate network, they are effectively locked out of their account on their machine.

There is a tension here between the central system administrators' need to enforce their policies and the end users' need to be able to log into their system and get work done. Since the server policies trump the client-side policies anyway, I suggest to always set the client to enable offline login, with a cache that has an indefinite lifetime. In situations where this is unacceptable, clients may be deployed with a different default configuration. Also, the server would override the setting anyway.

The way that server-side enforcement of a mandatory connection time works, is that if the system doesn't check in for X days, the server will automatically disable their network credentials. This means that even if the client does come back and try to auth after this time, they will be unable to gain access to network resources until they've called their helpdesk/IT department and had their account unlocked.

A Note About Checking For User Errors

A situation that could have an extremely negative impact on the user experience here is if the user fills out the screen in such a manner that they lock themselves out of being able to log into their computer. When the users are locked out, and sitting at GDM trying to log in, we can't really know why exactly they are unable to log in (they could honestly be mistyping their password, or they could have goofed up the url for their LDAP server.)

We want to try to minimize the chances the users end up in that locked-out scenario. I've added little icons / messages throughout these mockups here to suggest that preventing user error up front, by checking to see that entered URLs are valid at the time they are entered, before the user is locked. It is understood that in some cases the ability to check for these things is not possible, not reliably possible, or would require effort well beyond the scope of the changes being made to the dialog now. That's completely cool. I think it is good food for thought though, to consider whether or not this is a good mechanism to minimize our users' chances of getting locked out of their own machine.

One note about these little checks - if some of the resources the user inputs are on a VPN, as Stephen Gallagher pointed out, the user is unable to connect to VPN during firstboot when this dialog first appears, so a valid URL on a VPN network you're not connected to will indeed fail. To account for that case the messages could use language to reflect, 'we can't contact this resource now' or some other solution could be worked out. So please consider this aspect of the mockups a suggestion that could definitely be improved upon.

Current UI

Here is a gallery of the current system-config-authentication UI from Fedora 12, taken 09 February 2010. Note that this UI is quite old, but the 'SSSD settings' tab was added recently as part of the first phase to integrate SSSD into Fedora 12.

  • User Info Tab

    User Info Tab

  • Authentication Tab

    Authentication Tab

  • Options Tab

    Options Tab

  • SSSD Tab

    SSSD Tab

  • LDAP account settings

    LDAP account settings

  • Hesiod account Settings

    Hesiod account Settings

  • WinBind account settings

    WinBind account settings

  • Kerberos auth settings

    Kerberos auth settings

  • LDAP auth settings

    LDAP auth settings

  • WinBind auth settings

    WinBind auth settings

  • NIS settings

    NIS settings

Mockups

Things To Note About These Mockups

  • Inkscape source for all mockups is available:
  • Access Keys have not been addressed in these mockups - but they'll need to be there
  • For the smart card components to show up (as in the current implementation) the following components need to be installed:
    • coolkey
    • ccid
    • nss-tools
    • ifd-egate
    • pcsc-lite
  • For the NIS components to show up (as in the current implementation) the following components need to be installed:
    • yp-tools
    • ypbind
  • As noted above, the user-error checks are a suggestion and not a requirement.

Firstboot

Identity & Authentication Tab

Dropdown Items

User Account Storage Dropdown

  • For the User Account Configuration > User Account Storage dropdown, the following fields should appear:
    • LDAP
    • NIS (if yp-tools && ypbind installed)
    • Winbind
    • Smartcard (if coolkey, ecid, nss-tools, ifd-egate, pcsc-lite installed)

Authentication Method Dropdown

  • If LDAP is selected under User Account Storage, only the following options should be available under Authentication Configuration > Authentication Method:
    • LDAP
    • Kerberos
  • If NIS is selected under User Account Storage, only the following options should be available under Authentication Configuration > Authentication Method:
    • NIS
    • Kerberos
  • If Winbind is selected under User Account Storage, only the following options should be available under Authentication Configuration > Authentication Method:
    • Winbind

Smart cards will be handled in the 'Advanced Options' tab as they apply to both local and centrally-managed accounts.

Diagram for your convenience: 

+ LDAP
|
|-- LDAP
|
|-- Kerberos
|
+ NIS
|
|-- NIS
|
|-- Kerberos
|
+ Winbind
|
|-- Winbind

Paths Through the Tab

Path ID Number Identity Technology Authentication Technology Backend technology Mockup
1 LDAP Kerberos SSSD View Mockup
2 LDAP LDAP SSSD View Mockup
3 NIS NIS Legacy View Mockup
4 NIS Kerberos Legacy View Mockup
5 Winbind Winbind Legacy View Mockup

Mockups By Path

Path 1: LDAP/Kerberos

Can we check to make sure the server exists and is contact-able?

Back to Mockups List

Path 2: LDAP/LDAP

Back to Mockups List

Path 3: NIS/NIS

Back to Mockups List

Path 4: NIS/Kerberos

Back to Mockups List

Path 5: Winbind/Winbind

Back to Mockups List

Advanced Options Tab

Smartcards will be set up via 'advanced options.'

Retrieved from "https://fedoraproject.org/w/index.php?title=Design/SSSD&oldid=154120"