Lab - 8 - SAML and Kerberos SSO | João Paulo Barraca

Introduction

The goal of these exercises is to explore the functionalities of SAML and Kerberos using the IDP available at the University of Aveiro and a standalone Kerberos deployment

SAML

In the University of Aveiro the authentication system is based on a SAML issuing IDP, which serves as a good playground to analyse how the authentication process works. The objective of this exercise is to record the authentication process, decoding the SAML messages.

This exercise will require a a Chrome browser with the SAML DevTools Plugin, which is available on the Chrome web store. Within the browser, enable the Dev Tools with F12, and head for the SAML panel. Then:

Go to elearning.ua.pt
Login into e-learning
Provide the credentials to the IDP
Analyse the requests being made
Analyse the SAML messages payload

Questions:

Where is the user authenticated?
What is sent from the web service to the IDP?
What is sent from the IDP to the web service?
What values are protected (signed and/or encrypted)?
Make a diagram of the interactions between the client, the service and the IDP.

Kerberos

The goal of this work is to explore the functionalities of the Kerberos authentication and key distribution services. For that, we will download the Kerberos code, install it, create a Kerberos domain, use the Kerberos libraries to Kerberize applications and, finally, use those applications in the Kerberos domain.

The following steps resume the activities that are to be taken to install, configure and use Kerberos. Further details can be found in detailed online manuals.

Install Kerberos V5 in a clean Ubuntu machine. Regarding Linux packages, install the following ones:

krb5-kdc
krb5-admin-server
krb5-user

A Vagrant VM can be found here. You will need two VMs: one for the servers another for the applications. The Vagrant VMs already have this considered. The VMs should be connected by an internal network. Also, they must be configured (/etc/hosts) so that their IP address matches one of kdc.iaa.deti and srv.iaa.deti.

Creating a new Kerberos realm

A realm is defined by configuration files, used either by the Kerberos services or by Kerberized applications. These files are local to both servers and applications.

The configuration files are in fact a single one: /etc/krb5.conf, that is copied to all hosts. The base files provided by your distribution should be almost ready for use. The end result can be something like:

[libdefaults]
      default_realm = IAA

      kdc_timesync = 1
      ccache_type = 4
      forwardable = true
      proxiable = true
      fcc-mit-ticketflags = true
      dns_lookup_realm = false
      dns_lookup_kdc = false
      rdns = false

[realms]
        IAA = {
                kdc = kdc.iaa.deti
                admin_server = kdc.iaa.deti
                default_domain = iaa.deti
        }

[domain_realm]
        .iaa.deti = IAA

Special attention should be payed to DNS name resolution. Principal names involving host names are usually provided with DNS names, but internally they are canonicalized to IPv4 addresses using DNS (or any other complementary) name resolution mechanisms.

For some reason, Kerberos libraries try as well to do reverse DNS resolution from IP addresses, which in some cases is not advised (because it simply is not possible). That can be prevented by a proper configuration of the realm configuration files (rdns = false)

Create the realm database with the command krb5_newrealm.

Configuring the `kadmin` server

A kadmin server is a service that allows the local or remote management of the Kerberos services and principles. It is central to the management of a Kerberos realm and must run locally to the databases used by the realm.

This server uses configuration files and databases that must be modified or created before starting the service.

Before this service is running, the realm can be managed locally using the kadmin.local command. The kadmin command uses a local or remote kadmin server (kadmind) to manage the realm.

This step involves also the creation and configuration of Kerberos principals to administer the realm. In fact, a remote access to the remote kadmin server is only possible using the Kerberos authentication.

Thus, for enabling a remote administration of the realm one needs to add one or more principals with admistrative rights. These must have a name using admin as role (e.g. youruser/admin@IAA, for the IAA realm). Use the kadmin.local command to add a new principal with add_principal youruser/admin@IAA.

Testing Kerberos

Initial setup:

Start both machines and verify that they have connectivity using ping through their DNS.
Initiate both the KDC and the service virtual machines.
Copy the /etc/krb5.conf from the controller to the service virtual machines.
Reboot the service virtual machine

At the KDC:

Use the kadmin again to add a ordinary (i.e. non-administrator) principal. For getting administration credentials use the Kerberos principal previously created. You can do this on either machine. The name should be username@IAA, where username matches the linux username.
Change the hostname of the service VM to server
Use the kadmin and add a service principal: host/server@IAA

At the Service Virtual Machine:

Add the host/server@IAA entry to /etc/krb5.keytab using ktutil. You need to use the add_entry and the write_kt commands
Add the entry username@IAA to the file /root/.k5login
Start wireshark and capture the traffic. Analyse the kerberos messages exchanged.
Use the kinit command to perform a Kerberos login for that new principal (get a TGT).
Use a kerberized version of su name ksu to get to root.

The tool will trigger the request of tickets in order to allow username@IAA to access root@IAA on host host/server@IAA.

Lab - 8 - SAML and Kerberos SSO