Enterprise Login

GNOME already has some enterprise login features. It is already possible to create a user account using enterprise login, through initial setup or the user accounts settings. In addition, GNOME Online Accounts allows a user to access Kerberos for persistent access to corporate resources.

This page concerns enhancements to this integration.

Contents

Enterprise Login

Goals

Reduce the amount of work required from the user in order to access corporate resources.
Present enterprise login as a single integrated feature, rather than a series of independent technologies.
Guide and assist the user where necessary. For example: graceful ticket expiry and renewal.

Non-goals

For users, authentication is a means to an end. Don't let the needs of the authentication system take precedent.
Don't distract, badger or annoy.

Technical Notes and Background

Enterprise login has two aspects:

Using a remotely administered account for log in and unlock.
Using tickets so that login is only required once for a range of network resources (primarily different websites).

This happens through Kerberos - this allows a user to obtain a "ticket granting ticket" (TGT), which allows access to a range of corporate services (websites, remote file systems, email, etc).

To date, 1 and 2 have been handled separately in GNOME: you can use enterprise login for your user account (1), but you can also have an enterprise login online account (2).

Kerberos and Tickets

To receive a TGT, a user must either input a user name and password or, if two-factor authentication is being used, a password/PIN and a generated one time password.

A TGT has a limited lifespan: typically 10 or 24 hours. After it expires, a new one must be issued. If a user name and password is being used, TGT renewal can (sometimes!) be done automatically. Two-factor authentication requires user interaction in order to obtain a new ticket.

NTLM

In a typical Active Directory setup, NTLM authentication is — unfortunately — still common. Kerberos authentication is relatively brittle and requires the server to be appropriately registered under the same name that the client is using to access it. It's easy to get this wrong, and Windows clients and servers will silently fall back to using NTLM (both within GSSAPI/SPNEGO, and explicit NTLM authentication), and there aren't even good diagnostic tools to monitor how often this happens. Corporate AD admins certainly don't tend to consider it a problem.

The practical upshot of this is that NTLM, although theoretically deprecated, is still in constant use and for a desirable user experience on Linux system in the AD environment, we have to support it too.

With Samba/winbind joining the domain, single-sign-on using the ntlm_auth helper and gss-ntlmssp works correctly and provides a viable user experience.

Any of the design here should take this situation into account, and it should be remembered that GSSAPI authentication works even when there are no Kerberos credentials, since Kerberos is only one of many mechanisms that GSSAPI can be used as a transport for.

Kerberos can typically only be accessed on a corporate network, such as a company LAN or VPN. However, with HTTPS tunnels, it is now possible to access it without the need to be on such a network. This makes it possible to gain a TGT during login/unlock: by logging in or unlocking, the user would simultaneously get access to the full range of corporate services on the network, avoiding the need to login to each one separately.

When logging in and offline, the cached version of the user name and password is used for authentication. In the case of two factor authentication, only the first factor is required.

VPN

In some cases, some (or all) resources also require being on a VPN to access.

With the OpenConnect client, it is possible to use an existing TGT to log into a VPN. In the future, it might be possible to get a TGT as a part of signing into a VPN, but it very much depends on the specifics of the VPN implementation (both client and server).

Discussion

Currently enterprise login is split between user accounts and online accounts. Should we merge them somehow, for enterprise login user accounts?

When a TGT is close to expiry (for example, in half an hour), should we show a notification? I think probably not, since we can prompt when the user wants to use a ticket next.

Tentative Design

The following is a tentative sketch for how each part of the experience could work.

Enterprise Login User Accounts

User creation occurs through initial setup or Settings (panel wireframes, add user wireframes). In both cases, it is possible to enrol the machine in a domain and create a local user using a remote enterprise account.

An enterprise login online account should be automatically set up when using an enterprise login user account. The UI should indicate that the online account is slaved to the user account.

Public Terminals

System administrators should be able to:

Enroll the machine without creating any users.
Allow blanket access to a machine through the domain.
Restrict user accounts to enterprise login only.
Hide the user accounts settings from the control center.

These options don't necessarily require UI.

Enterprise Login Online Accounts

It should be possible to use the enterprise login online account to acquire and renew TGTs, without an enterprise login user account.

The UI should:

Prior to setup, explain what an enterprise login online account is.
Recommend using an enterprise login account.
Show the domain.
Show the status of the TGT (active, expired).
Allow a TGT to be acquired/renewed.

See the latest online accounts mockups.

Ticket Acquisition

When using an enterprise login user account, TGTs should be automatically acquired or renewed when logging in/unlocking (if the machine is online):

If two-factor authentication is in use, only ask for the second factor if TGT acquisition/renewal is necessary (ie. if there isn't a TGT, or it is about to expire) - asking for the second factor every time would be a dramatic increase in the amount of work for the user, without a practical benefit.
When offline, the cached password is used. For two-factor authentication, only the first factor is required.

In either case, if an application seeks to use a resource that requires a TGT, and a ticket isn't available, it should prompt for one:

This approach ensures that authentication is only asked for when it is required: a TGT may expire, but we don't know whether the user is intending to user resources it provides access to. If a user isn't intending to use corporate resources, it is annoying to be bother by requests to renew.

Prompting at point of use also ensures that the system doesn't distract the user from the task in hand.

VPN

This part is extremely speculative. It could probably only ever work with some compatible VPN plugins.

It should be possible to link an enterprise login online account with a VPN:

When setting up an enterprise login user account, allow creating a linked VPN.
When setting up an enterprise login online account, allow creating a linked VPN.
When creating a VPN and an enterprise login online account exists, offer to link it to the enterprise login account.

When a VPN is linked with an enterprise login online account:

Logging into the enterprise login automatically joins the VPN.
Connect to VPN actions (such as in GNOME Shell and the Settings app) should be replaced with a log into enterprise account options.

Outstanding Tasks

Research and design:

Check on the status of enrollment and two-factor authentication in initial setup.
Investigate additional hints to be shown in GDM, such as prepopulating the user name field with a domain name, or adding a administrator provided string about which user name and/or password to use.

Development tasks:

Online accounts - implement updated designs for enterprise login.
User accounts settings - implement updated designs for enterprise login online accounts.
Two-factor login through system modal dialogs.
Integration of TGT acquisition/renewal into GDM.
Enterprise login sign in prompts in the browser.

Design Notes

Automatic TGT acquisition and renewal when logging in and unlocking is a key feature of the above designs. These require that the machine be online.

In some situations, the machine won't be online when the user goes to login or unlock. This prompts the question: should it be possible to get the machine online from the login/unlock screen? (This would probably be presented as a strong prompt, rather than an option.)

From a UX point of view, it would be possible to show the system dialog for connecting to a Wi-Fi network and entering a password. It would also be possible to allow connecting to mobile broadband.

However, there are a number of reasons why it might not be desirable to pursue this at this time:

Captive portal login would be difficult to present nicely - showing a regular (non-system) window outside of the session would look rather odd, and undermine the sense that you are actually outside the session.
The number of cases where the functionality would be needed is relatively low - most of the time you are either online, or offline without a network available.
Getting online can sometimes take a little while. This could lead to quite a sucky experience if you have to wait multiple seconds before being allowed to log in.
It could be a lot of work.