Kerberos

Edit /etc/krb5.conf to configure your domain:

/etc/krb5.conf

[libdefaults]
    default_realm = EXAMPLE.COM

[realms]
    EXAMPLE.COM = {
        admin_server = $ADDRESS
        # use "kdc = ..." if the kerberos SRV records aren't in DNS (see Advanced section)
        kdc = $ADDRESS
        # This breaks krb4 compatibility but increases security
        default_principal_flags = +preauth
    }

[domain_realm]
    example.com  = EXAMPLE.COM
    .example.com = EXAMPLE.COM

[logging]
    kdc          = SYSLOG:NOTICE
    admin_server = SYSLOG:NOTICE
    default      = SYSLOG:NOTICE

Where $ADDRESS is IP address or domain name, where kerberos lives, like 10.0.0.120 or kerberos.example.com.

This file's format is described in the MIT Kerberos documentation

Create the database:

Finally, start/enable and .

Start the Kerberos administration tool, using local authentication

Add a user principal to the Kerberos database:

kadmin.local: addprinc myuser@EXAMPLE.COM

WARNING: no policy specified for myuser@EXAMPLE.COM; defaulting to no policy
Enter password for principal "myuser@EXAMPLE.COM": ***
Re-enter password for principal "myuser@EXAMPLE.COM": ***
Principal "myuser@EXAMPLE.COM" created.

Add the KDC principal to the Kerberos database:

Finally, Add the KDC principal to the server's keytab:

kadmin.local: ktadd host/kerberos.example.com

Entry for principal host/kerberos.example.com with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kerberos.example.com with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.

Quit the Kerberos administration tool:

kadmin.local: quit

You should now be able to get a Kerberos ticket:

Add ALLOW rules to your firewall for any applicable ports/protocols:

• 88, TCP and UDP for Kerberos v5
• 749, TCP and UDP for kadmin if you plan to configure it
• 750, TCP and UDP for Kerberos v4 if you need backwards compatibility

This is not necessary if you specify the kerberos and kadmin server in each machine's krb5.conf Do not forget reverse DNS.

You should now be able to get a Kerberos ticket on the client:

Create a principal for administration:

Add the user to the kadmin ACL file: This file's format is described in the MIT Kerberos documentation

Configure kdc.conf: This file's format is described in the MIT Kerberos documentation

Restart and .

You can now use kadmin as your own user, authenticating with kerberos:

$ kadmin

Authenticating as principal myuser/admin@EXAMPLE.COM with password.
Password for myuser/admin@EXAMPLE.COM: ***
kadmin:

This is the easier method, but requires you to have configured kadmin.

Open kadmin as root (so we can write the keytab) on the client, authenticating with your admin principal:

Add a principal for any services you will be using, eg. "host" for SSH authentication or "nfs" for NFS:

Save each key to the local keytab:

Start kadmin on the Kerberos server, using either unix or kerberos authentication:

Add a principal for any services you will be using, eg. "host" for SSH authentication or "nfs" for NFS:

kadmin.local: addprinc -randkey host/kbclient.example.com

WARNING: no policy specified for host/kbclient.example.com@EXAMPLE.COM; defaulting to no policy
Principal "host/kbclient.example.com@EXAMPLE.COM" created.

Save each key to a new keytab to be transferred to the client:

Finally, copy from the server to the client using SCP or similar, then put it in place with correct permissions:

Finally, delete kbclient.keytab from the server and client.

To allow a different kerberos principal to authenticate to a user account, add the principal name to the target account's file. For example, to allow to SSH to alice's account:

Add a Kerberos export option. If necessary, multiple options can be specified using a colon as a delimiter with the preferred setting first, e.g. sec=krb5p:krb5i.

• sec=krb5p uses kerberos for authentication, integrity, and encryption.
• uses kerberos for authentication and integrity checking, but still transmits data unencrypted.
• uses kerberos for authentication only, and transmits the data unauthenticated and unencrypted.
• is the default and does not provide any cryptographic security.

And reload the exports:

# exportfs -arv

Mount the exported directory:

# mount nfsserver:/srv/export /mnt/

You can add for verbose information, and may need and or your chosen security option.

Check that it worked with the command:

mount | grep nfs

nfsserver:/srv/export on /mnt type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=192.168.100.139,local_lock=none,addr=192.168.100.136)

Chromium needs to be run with a command line parameter that specifies a list of sites where Kerberos authentication is allowed. The easiest way is to add persistent flag to the configuration file:

To configure Firefox with trusted sites visit about:config and set property to FOO.COM (Note: for Firefox there is no "*."; for Chrome, there is).

Cannot set GSSAPI authentication names, aborting

Your realm is missing either the or principal.

For clients, invalid arguments/options may happen on first setup if rpc-gssd is not loaded. Loading it is usually acomplished by enabling and starting , but after first setup this target will need a restart.

If any of the following errors are encountered:

$ ssh -v -o GSSAPIDelegateCredentials=yes -o GSSAPIAuthentication=yes <user>@<IP address>
Unable to negotiate with <IP address> port 22: no matching key exchange method found. Their offer: gss-group14-sha1-...

$ ssh -v -o GSSAPIDelegateCredentials=yes -o GSSAPIKeyExchange=yes -o GSSAPIAuthentication=yes <user>@<IP address>
command-line: line 0: Bad configuration option: gssapikeyexchange

it means that package is not configured with GSSAPI patch for OpenSSH. You can install or follow this method.