Single Sign On

To authenticate users, the server that Cockpit is running on must be joined to a domain. This can usually be accomplished using the realm join example.com command.

The domain must be resolvable by DNS. For instance, the SRV records of the kerberos server should be resolvable:

The server running Cockpit should have a fully qualified name that ends with the domain name.

There must be a valid Kerberos host key for the server in the /etc/krb5.keytab file. Alternatively, if you would like to use a different keytab, you can do so by placing it in /etc/cockpit/krb5.keytab, or below $XDG_CONFIG_DIRS if set (see cockpit.conf). It may be necessary to create a kerberos service principal and update the keytab if it is not present. Depending on your domain type different service names are required:

When joining an IPA domain with Cockpit and the ipa command line tool is available, both the service principal name and a /etc/cockpit/krb5.keytab get created automatically, so that Kerberos based single sign on into Cockpit works out of the box. If you want/need to do this by hand or in a script, first create or modify the HTTP/ service principal:

Then generate a key for that principal:

The following command can be used to list the /etc/cockpit/krb5.keytab:

Lastly accounts from the domain must be resolvable to unix accounts on the server running Cockpit. For example:

If you wish to delegate your kerberos credentials to Cockpit, and allow Cockpit to then connect to other machines using those credentials, you should enable delegation for the hosts running Cockpit, and in some cases the HTTP service as well. When joining an IPA domain, this is enabled by default.

Domain admins (usually the admins@example.com group) should normally also be able to administer any joined machine. Enable sudo access for that group with the following command on the IPA server, for version 4.7.1 and later:

On earlier FreeIPA versions, run these commands instead, as a domain admin on any joined machine:

Note that this does not change security properties; domain admins can give this privilege to themselves, so it is safe to enable by default.

The client side, where your web browser is running, should have a valid kerberos ticket in the current user session. A command like this will get one:

In addition your browser must be usually be configured to allow kerberos authentication for the domain.

Use a fully qualified server name (with the domain name at the end) to access Cockpit in your web browser.

If you wish to connect from one server to another in Cockpit using kerberos SSO, then you have to explicitly enable all sorts of things. For starters, make sure that delegated credentials are allowed by your domain (see above). Next when requesting your kerberos ticket make sure that forwardable tickets are requested:

Make sure that the forwardable flag F is present in your ticket:

Lastly configure your browser to allow delegated, forwardable kerberos credentials to be sent to Cockpit: