How to integrate OAM with windows natively (Part 2)

Two weeks ago one of my co-workers asked me if it was possible to integrate Active Directory  with Oracle Access Manager. So here is my two part mini-series on working with Oracle Access and Active Directory.  Today I will talk about Kerberos authentication, or in other words, how you can leverage windows native authentication to provide SSO to domain connected users.

Part 2, Kerberos authentication

The objective

The objective of this specific integration is to allow users to login to their work stations and be immediately signed in to various connected web applications. This is a step up from last week’s integration because a user does not need to enter any more credentials to be logged in. This is a great way of having users use internal resources without having to login again. There is only one catch, Kerberos authentication only works if the user is able to communicate with port 88 on the domain controller. If this is possible the user is able to ‘login’ to the domain and not the cached credentials store within windows itself. This integration will use a way to check if you are already authenticated to the domain controller, so if you cannot reach the domain controller, you cannot do Kerberos authentication.  In that case the user will still be presented with a login screen by default.

The concept

Kerberos (version 5) is not as most people think a proprietary protocol, it started life back in 1993 at MIT. In the beginning people were unsure of how to use it or even classify it. The first seven years the US armed forces even named it “Auxiliary Military Equipment”  on the US Munitions List. Its inner workings are more complicated than basic LDAP traffic because Kerberos uses a complicated system of “Kerberos tickets”. You can check how Microsoft implements this by going through the public documentation. For now, the most important thing to know is that whenever you logon to a windows machine using an Active Directory you receive a Kerberos ticket. In order to facilitate the login process we want the client to pass us his Kerberos ticket so we can check if the user is logged in.

Components used

Active Directory Domain Services: (alternatively an Active Directory Lightweight Domain Services can be used). For more information, see: This wikipedia article and The microsoft documentation.

Oracle Access Manager 11G: This is the basic authentication manager provided by Oracle. For this setup no additional components are used. For more information on the OAM, please see the oracle documentation.

The integration process

This integration process requires you to have already configured the basic AD configuration. Specifically, the AD should be configured as a user identity store.

The first thing you need to do is allow a service on a remote computer to interact with the Active Directory on a Kerberos level. This is done by generating a keytab file and setting  an SPN. The SPN is used internally by the directory server to allow a service account to interact as a service on a Kerberos level. This is usually accomplished by using the setSPN windows command line program.  Only in this guide, the setSPN command is invoked on the background. We will check the results to ensure that the command has processed correctly. So let’s get started on the windows commandline!

Step 1: Create a new service account in AD, if you are unsure of how to perform this task, please see my previous post in which I explain the process.

Step 2: Generate the keytab file:

The keytab file holds necessary information for the OAM server in order to communicate with the AD server using Kerberos. The command which is used to create the keytab file says it all I think. So let’s look at it.

The command to create the keytab file is:

ktpass -princ HTTP/ WIN-0TSLLVQ4E2Q@BRAMTEST.AMIS -pass TH1$1$Mypassw0rd! -mapuser oamberb -ptype KRB5_NT_PRINCIPAL -crypto ALL -out C:\keytab.new

So now what did we configure? Well take a look at the table below:

So basically we encrypt a series of keys, usernames, passwords and a principal name. This is all the information OAM needs to connect to the AD and sent request to check if a user has been logged in.

Step 3: Check the keytab file and the SPN

To check if the keytab file is any good we are going to test it on the domain controller. For this step you need to setup a Kerberos ini file. The ini file has to be created at: c:\windows\krb5.ini. It is very important to get this step right or else the keytab file will need to be created again.  My Kerberos ini file looks like this:

[libdefaults]
 default_realm = BRAMTEST.AMIS             #Name of my AD realm
 ticket_lifetime = 600
 forwardable = yes
 udp_preference_limit=1                             #To counteract  size restrictions which can sometimes occur

[realms]
 BRAMTEST.AMIS = {
  kdc = WIN-0TSLLVQ4E2Q.bramtest.amis #Pingable name of my active directory domain controller
  admin_server = bramtest.amis
  default_domain = BRAMTEST.AMIS
 }

[domain_realm]
 .bramtest.amis = BRAMTEST.AMIS
bramtest.amis = BRAMTEST.AMIS 

Please note that the use of capital letters is mandatory in the indicated places! After configuring the krb5.ini file, the keytab file can be tested. The tool I will use for this is the kinit tool, which is part of the java runtime. You can test the keytab file by executing the following command:

 kinit oamberb@BRAMTEST.AMIS 

If that command throws an error, your krb5 file is wrong.  If it does work,  you can now try your newly generated keytab file using kinit:

 kinit oamberb@BRAMTEST.AMIS  -k -t <keytab.new

If this does not work, the keytab file was not generated correctly and it will have to be recreated.

Step 4: Transfer the keytab file to the OAM machine

You have to send the keytab file to the OAM machine so we can use it later in the process. When transitioning to a UNIX environment please take into account that the file rights might be altered. Do not forget to check the file rights.

Step 5: Check the keytab file again

After transferring the keytab file to the new server, check the keytab file again. This is to check if the keytab file works on the target server. The tool I will use for this is the kinit tool, which is part of the java runtime.  Just execute the following script:

kinit -V HTTP/ WIN-0TSLLVQ4E2Q@BRAMTEST.AMIS -k -t C:\ keytab.new

Step 6: Create the Kerberos authentication Module

The last step is to create an Kerberos authentication module in OAM. There is a preset Kerberos module which you can use, it basically needs 4 parameters:

Result

You can now use the Kerberos authentication module to authenticate users.  Just check my pervious post om how to integrate the authentication modules.  I hope you have enjoyed these blog posts, if there is anything you missed in these blogs, please let me know!