Kerberos Single Sign On

Introduction

This tutorial will guide you through the configuration of Kerberos for Single Sign On.

Please first configure LDAP and test it. When you configured LDAP correctly, you can move on with the following instructions to setup Kerberos SingleSign On.

Kerberos is a method that let you identify to other services with your windows logon. Having configured LDAP and Kerberos you can achieve Single Sign On which means, that custo diagnostic will automatically use the user that is logged on to Windows for authentication and the user does not need to enter any passwords.

Kerberos lets you automatically login to the custo manager with you windows user if your user has a valid LDAP mapping. To do this you need to configure LDAP first.

It involves configuring Tomcat (the application server that hosts the custo diagnostic server), so we use Tomcat as a synonym for custo diagnostic server at this place. Most of this manual is copied from https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html

Steps to configure the Kerberos System:

1. Create a normal domain user (used by Apache Tomcat to identify for Kerberos methos), "custoKerberos" .
2. Create a keytab-File - this file contains combines the use of Apache Tomcat ("Service Principal Name") to the user created above.
3. Configure Apache Tomcat to use the kerberos configuration
4. Enable Kerberos Identification in custo service center.

The first two steps has to be performed by an domain administrator.

Its worth to write down all information before you start.

E.g. In our Example we used the following names:

General Information

Kerberos (the basis for integrated Windows authentication) requires careful configuration. If the steps in this guide are followed exactly, then a working configuration will result. It is important that the steps below are followed exactly. There is very little scope for flexibility in the configuration. From the testing to date it is known that:

• The host name used to access the Tomcat server must match the host name in the SPN exactly else authentication will fail. A checksum error may be reported in the debug logs in this case.
• The SPN must be HTTP/<hostname> and it must be exactly the same in all the places it is used.
• The port number must not be included in the SPN.
• No more than one SPN may be mapped to a domain user.

Create Domain User for Apache Tomcat

This step has to be done by the domain administrator.

Create a normal domain user. This user does not have to have specific access rights - but it must be able to authenticate/login with this user to the Windows Domain.

In our example we name the user  "custoKerberos", password "secretPW!"  (← don't take it in real life). the only membership is "Domain User". Please make sure, that the password does not have to be changed, and will not expire.

Create keytab-File

This step has to be done by the domain administrator.

Watch out:  Some entries are CASE SENSITIVE! 

Please use the following command to create the keytab-file.

ktpass -princ HTTP/tst2srv01-2016.xy-hospital.xy@XY-HOSPITAL.XY 
-mapuser custoKerberos@xy-hospital.xy 
-crypto rc4-hmac-nt -ptype KRB5_NT_PRINCIPAL 
-pass custo -out "C:\Program Files\custo diagnostic server\conf\tomcat.keytab"

This command:

• links the service principal name "HTTP/tst2srv01-2016.xy-hospital.xy@XY-HOSPITAL.XY"   to your custoKerberos-User (and defines the authentication/crypto way)
• stores the private key in tomcat.keytab file

This file contains the Tomcat private key for the service provider. To generate the file, run the following command as a domain administrator (all on a single line). You can do this step on the server where tomcat runs on.

Configure Apache Tomcat

Watch out:  Some entries are CASE SENSITIVE!  Some Path-Names need forward-slashes!

We attached the file to download it for you. Please do not use copy/paste from the code below - use the files attached to this website.

Replace / Edit krb5.ini and jaas.conf file, located in your ...\custo diagnostic server\conf Directory

krb5.ini

[libdefaults]
  debug = true
  default_realm = XY-HOSPITAL.XY
  dns_lookup_kdc = false
  default_keytab_name = FILE:C:\Program Files\custo diagnostic server\conf\tomcat.keytab
  krb4_config = /etc/krb.conf
  krb4_realms = /etc/krb.realms
  kdc_timesync = 1
  ccache_type = 4
  forwardable = true
  proxiable = true
 

[realms]
  XY-HOSPITAL.XY = {
    #
    # Specify your Domain Controller here
    kdc = tst2dc01.xy-hospital.xy
    admin_server = tst2dc01.xy-hospital.xy
    default_domain = xy-hospital.xy
} 



[domain_realm]
.xy-hospital.xy = XY-HOSPITAL.XY

 

[login]
krb4_convert = true
krb4_get_tickets = false

jaas.conf

We attached the file to download it for you. Please do not use copy/paste from the code below - use the files attached to this website.

# Attention!
# principal Name must be IDENTICAL (case sensitive) to the principal Name used with ktpass
# Be aware of forward slahes in file Name
# 2020-02-04, FHo

com.sun.security.jgss.krb5.initiate {
    com.sun.security.auth.module.Krb5LoginModule required
    doNotPrompt=true
    principal="HTTP/tst2srv01-2016.xy-hospital.xy@XY-HOSPITAL.XY"
    useKeyTab=true
    keyTab="C:/Program Files/custo diagnostic server/conf/tomcat.keytab"
    storeKey=true;
};

 

com.sun.security.jgss.krb5.accept {
    com.sun.security.auth.module.Krb5LoginModule required
    doNotPrompt=true
    principal="HTTP/tst2srv01-2016.xy-hospital.xy@XY-HOSPITAL.XY"
    useKeyTab=true
    keyTab="C:/Program Files/custo diagnostic server/conf/tomcat.keytab"
    storeKey=true;
};

Please copy the editied files and the keytab file to a save location. 

Now you can change Login Method to Remote User:

As the last step, please restart the custo diagnostic server now.

For testing Kerberos authentication without using the custo manager, you can use the curl utility that is installed in the same folder as the custo diagnostic client:

If everything works and the logged in windows user is allowed to use custo diagnostic then this command should return "true".