Enterprise desktop

• is a client enrolled to a centralized identity management system
• is a tool to solve business tasks
  • run applications under certain privileges
  • access files on the network and in the cloud
  • print documents on the network and in the cloud
• is a subject to centrally defined access controls

Identity management system

There are now several free software identity management systems with the focus on managing operating systems’ environments:

• FreeIPA
• Samba AD
• [many other LDAP+Kerberos based projects]

We are working with Samba upstream at fixing remaining MIT Kerberos compatibility issues and provide Samba AD latest in Fedora 26.

Enterprise desktop agents

• identity services:
  • POSIX attributes for users and groups via NSSWITCH
• authentication services:
  • logon using PAM services
  • Web authentication
• authorization services:
  • PAM services (centralized or local)
  • Application-specific logic (centralized or local)
• tools to simplify access and configuration of the agents

Practical case: Fedora and FreeIPA

FreeIPA client defaults to use SSSD as an agent

• nss_sss is referenced in /etc/nsswitch.conf on Fedora by default
• pam_sss use is configured at the enrollment time for system-auth PAM service which is included to most PAM configurations
• SSSD performs host-based access control to PAM services using rules stored centrally in FreeIPA
• OpenSSH is configured to look up public keys for users and hosts via SSSD

Practical case: Fedora and FreeIPA

• SUDO is configured to look up SUDO rules in FreeIPA via SSSD
• automount can be configured to use SSSD to deliver the mount maps
• SSSD provides locator and localauth plugins to MIT Kerberos to discover domain controllers and map Kerberos principals to POSIX user names
• SSSD supports:
  • offline logon
  • logon with smart cards
  • logon with Kerberos proxy

Samba AD domain member

• Fedora can be a domain member for Samba AD
  • A pure winbindd-based setup or a hybrid SSSD+winbindd configuration
• Pure winbindd:
  • nss_winbind and pam_winbind for identity and authentication
  • Limited authorization capabilities (account lock)
• Hybrid approach:
  • nss_sss and pam_sss for identity and authentication
  • winbindd is used by Samba, configured to trust SSSD-provided ID range
  • SSSD does offline logon, smart card support, kerberos proxy
  • SSSD does authorization using GPO and/or account lock

That’s all behind the scenes, what would user see?

How enterprisey are we?

Let’s score by a password

A typical workflow for every laptop reboot

0. Boot into an operating system prompt (enter a password or more)
   • optional hard drive encryption
   • optional boot password protection
1. Sign into a local system account (enter a password)
2. Jump onto virtual private network (enter a password or more)
3. Obtain initial Kerberos credentials (enter a password)
4. Use corporate applications (enter a password?)

Can we do better than this?

how far are we from

• Boot into an operating system
• Sign into a corporate environment
• Use corporate applications

?

Let’s try to login!

What was that?

• The system is configured to be a client for FreeIPA
• SSSD handles login and Kerberos keys
• Logon to the system is verified over public network using a proxy for Kerberos protocol
• Established VPN connection based on Kerberos ticket
• Credentials were entered only once
• Working with FreeIPA since Fedora 23

VPN and Kerberos

OpenConnect client supports GSSAPI negotiation

• Fedora 22+ works out of the box

OpenVPN does not support GSSAPI negotiation

• to do since 2005, ignored by upstream

Support for GSSAPI in IPSEC is coming

Two-factor authentication

Demo

What was that?

1. One time password token was programmed to Yubikey and added for the user in FreeIPA
2. SSSD handles login and notices OTP pre-authentication support in Kerberos conversation
3. Login to the system is verified over public network using a proxy for Kerberos protocol
4. Kerberos ticket is obtained, first factor is provided by SSSD to GDM for unlocking GNOME passwords and keys storage (SeaHorse)
5. Credentials were entered only once

If Kerberos credentials are available, what can we do with them?

• Authenticate with GSSAPI against almost anything
• Obtain SAML assertion for other web services (and more)
• Use to access networking file and print systems
• Display properties of the available tickets
• Renew the ticket granting ticket (TGT)
• Choose which Kerberos principal is in use

Authenticate with GSSAPI

Epiphany, the GNOME Web Browser, in GNOME 3.18:

• GSSAPI support is no more, depends on libsoup support
• libsoup has been dragging since 2009, bug #587145
• WebkitGtk is unusable for SAML/OAuth2 interactions involving Kerberos
• One cannot use Google apps with GSSAPI in Gnome Online Accounts
• No single sign-on with GSSAPI from GNOME applications using WebkitGtk to authenticate

Can we do better than this?

Rhetoric question, finally!

Single sign-on in Epiphany

What was that?

Tomáš Popela (Red Hat), David Woodhouse (Intel), and Guido Guenther (Debian) worked to fix libsoup and WebkitGtk

We logged into my FreeIPA server’s Web UI

The code is in GNOME 3.20 (March 2016) and is in Fedora 24

By default, all HTTPS sites advertising WWW-Authenticate: Negotiate authentication method will be probed with GSSAPI

Why all this work is important?

• WebkitGTK+ and libsoup are used by many applications
• Will let us mount Kerberos-authenticated Nextcloud storages in Nautilus

Why all this work is important?

• WebkitGTK+ and libsoup are used by many applications
• Multi-factor authentication moves to Web-based flows (Azure AD, Windows 10, …)
• Corporate portals are used to authenticate when accessing external resources
• Captive portals prevent Internet access before logon
• You need to be able to be on VPN before logon to your system or have Kerberos proxy working, or have multi-factor authentication working
• full circle loop now, you need a browser window before logon

Diversion: Running a browser before logon?

• Yes, effectively, a sandbox with a locked-down web engine
• But network profile (access point) needs to be selected first
• This means Network Manager has to run before logon
• This means Network Manager needs to access user-specific data before logon
• A complete re-arrangement of logon UX

Down the rabbit hole…

Ok, anything for users, not admins?

Single sign-on to Google Apps

What was that?

• Ipsilon as an Identity Provider (IdP) taking user information from FreeIPA
  • Ipsilon project: http://ipsilon-project.org/
• Google Apps as a Service Provider (SP) talking to FreeIPA via Ipsilon’s IdP
• Users from FreeIPA can logon to Google Apps if admin did pre-create accounts for them
• At no point Google has access to FreeIPA users’ credentials
• SSSD is the key component here, the same setup will work for a SSSD enrolled to Samba AD
• GNOME Online Accounts now configured to access Google Apps’ services
• Setup recipe: https://ipsilon-project.org/doc/example/google-apps.html

What does GSSAPI support open for use in GNOME Online Accounts?

• Single sign-on is the primary feature
• Automated credentials renewal
• Automated token/assertion renewal for SAML/OpenID
• No need to store passwords locally (secure kiosks?)

Visualize

GNOME Online Accounts could show Kerberos ticket properties

• Ticket time validity, flags (forward, renewal)
• Authentication indicators
• Existing service tickets in the credentials cache and allow to remove them selectively
• Allow automatic ticket renewal if KDC permits it

Visualize

Consume

Choose between different Kerberos principals

• MIT Kerberos supports kernel keyring (1.12+) and directory-based (1.11+) storage of credentials
• Multiple Kerberos principals can be stored and used at the same time
• Only a single principal can be defined as “primary” for each Kerberos realm in the collection of credentials

Kerberos ticket renewal

• SSSD supports automatic Kerberos ticket renewal for single factor cases
  • Renewing 2FA tickets requires UI interaction triggered by expiry time
  • Automatic ticket renewal requires permission from KDC, visible as a ticket flag
• GNOME Online Accounts could integrate with SSSD in prompting for credentials (multiple factors) as in 2FA case needed information could be provided via SSSD InfoPipe/AuthPipe

Better Kerberos in browsers

• Firefox Kerberos setup isn’t nice
  • needs about:config manipulation
  • DNS domains associated with Kerberos realm could be discovered via DNS SRV records, prompted for confirmation once
• FreeIPA used to provide an extension to automate Firefox setup
  • Extension was generated locally for for each FreeIPA deployment to provide configuration details
  • not anymore: Firefox removed ability to provide non-publicly available extensions since version 43
• There are about dozen bugs related to GSSAPI support in Firefox, gradually being fixed by Red Hat Firefox team together with Firefox upstream

Better Kerberos in browsers

• Chromium/Chrome
  • Have bugs for processing of WWW-Authenticate: Negotiate when Kerberos credentials are not available
  • On Linux only allows to configure Kerberos use through command line or statically system-wide, poor user experience
• A fixed libsoup/WebkitGtk allows to always use GSSAPI if server advertises WWW-Authenticate: Negotiate over HTTPS
  • no need to configure anything in Epiphany
  • could be further confined with a user confirmation similar to how passwords are managed at the first logon
• Konqueror browser in KDE allows to always use GSSAPI if server advertises WWW-Authenticate: Negotiate over HTTPS

Better Kerberos in browsers

• GSSAPI flow is synchronous, needs better UI interaction to avoid hogging down other tabs
  • still major issue for many browsers
  • Bug #890908 is finally fixed in Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=890908
  • Will be in Firefox 49, it is in Fedora’s firefox-48.0-2.fc24
• But asynchronous GSSAPI flow would do wonders too!

Any practical use of it?

Single sign-on at home

What was that?

• I set up Ipsilon to authenticate against my FreeIPA server
• I set up Owncloud instance and created a simple application to do login via Ipsilon SAML
• Successfully logged-in users get created in Owncloud if they belong to a certain group in FreeIPA
• No need to enter password if Kerberos credentials are available
• Credentials were entered only once

Better support for SAML in GNOME Online Accounts

GNOME Online Accounts in GNOME 3.20 supports single sign-on with a catch

• WebDAV protocol doesn’t really work well with mod_auth_mellon as SAML client
• Have to use separate Owncloud/Nextcloud server end-point for non-SAML logon

There is a plan to fix GNOME VFS to support SAML negotiation so that Nautilus would be able to re-negotiate when accessing WebDAV shares

How enterprisey our home could become?

Very very enterprisey

What is that?

• FreeIPA has a cross-forest trust to an Active Directory forest
• Ipsilon is configured to accept all valid users provided by FreeIPA
• Active Directory users are valid ones, with fully qualified user names to differentiate them from IPA users
• Active Directory administrator signed into Owncloud as a normal user
• Credentials were entered only once

What about disk encryption?

Secure, Automated Decryption

Nathaniel McCallum gave a talk “Secure, Automated Decryption” at 11:00 today, Wednesday, August 3rd. Watch the talk recording!

What benefits do we get by becoming enterprisey with free software?

1. Control your own infrastructure
2. Improve user experience by reducing number of password/logon interactions
3. Profit?

Questions?