PeopleSoft Desktop Single Sign-on via Kerberos – Part 1

With the release of PeopleTools 8.51 Desktop Single Signon via Kerberos is now a supported reality.  Though this can’t really be considered a delivered solution, I’d call it a reference solution, for those that want to build their own it is at least available and documented.  So here is a walk through of setting up the  “reference” desktop single sign-on solution. (I’m doing this on 8.52 but 8.51 should be very similar).  I’ll also be doing this on Oracle Enterprise Linux servers (Oracle Linux Server release 5.8 to be precise) while Oracle’s documentation is geared towards an all Windows environment.

First lets go over the basic plan of attack:

1. Need an Active Directory server (instructions not included)
2. Need our Linux servers to be able to authenticate against said AD
3. Create required accounts/SPN and keytab file
4. Need to enable servlet filter on Weblogic to handle Kerberos Token
5. Need to enable app server to handle Kerberos Token
6. Need to enable public user and single signon kerberos peoplecode
7. Need to test and troubleshoot if needed

I’m not going to rehash everything explained in the PeopleBooks article, if you want their explanation of how this actually works you can read it for yourself, it’s a decent writeup.

If you don’t have an Active Directory server already available that’s beyond the scope of this article.

Let’s setup our servers to talk to our Domain Controller via Kerberos.  With Windows, if your servers are in your Domain this is already taken care of but for us Linux users we need to make it happen.  Here’s how I did it and there isn’t a lot to it.

First, lets edit /etc/krb5.conf. It should look something like this.
[libdefaults]
ticket_lifetime = 24000
default_realm = TESTDOMAIN.LOCAL
dns_lookup_realm = yes
dns_lookup_kdc = yes
For this exercise I commented out the realms and domain_realms section. The above settings rely on DNS to look up the kdc, so if for some reason your not using DNS from your kdc you might want to use a config similar to below where you specify an IP or name for your kdc.
[libdefaults]
default_realm = TESTDOMAIN.LOCAL
ticket_lifetime = 24h
forwardable = yes
[realms]
TESTDOMAIN.LOCAL = {
kdc = 192.168.1.30
}
[domain_realm]
.testdomain.local = TESTDOMAIN.LOCAL
testdomain.local = TESTDOMAIN.LOCAL
There are many other options available in this configuration file, see the man page for more details. What I provide here is the basics to get things moving. Once krb5.conf is setup try running kinit to test the ability to acquire a ticket. For this we need to know a user and password in AD.

[root@appsrv ~]# kinit USER@TESTDOMAIN.LOCAL
Password for USER@TESTDOMAIN.LOCAL:
[root@appsrv ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: USER@TESTDOMAIN.LOCAL

Valid starting Expires Service principal
07/12/12 21:32:50 07/13/12 07:34:04 krbtgt/TESTDOMAIN.LOCAL@TESTDOMAIN.LOCAL
renew until 07/13/12 21:32:50

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

[root@appsrv ~]# kdestroy

Ok, That works, we got a ticket, listed it, and got rid of it. From the man pages:
kinit - obtain and cache Kerberos ticket-granting ticket
klist - list cached Kerberos tickets
kdestroy - destroy Kerberos tickets
Do this for both the web and app server.

Now let’s create our service account, HTTP service principal, and a keytab file. A side note here, I took a short cut by creating a single account to use for both servers. In a real world environment you might want to consider using Computer Accounts and actually adding the Linux servers as members in the Domain.

1. Create USERs in AD: add user krbauth/p@ssw0rd
2. run command prompt as admin
3. Setspn.exe -S HTTP/websrv.testdomain.com krbauth

webserv.testdomain.com needs to match your server and DNS domain name although my AD Domain is testdomain.local I have testdomain.com as a working DNS entry on this network.
C:\Windows\system32>setspn -S HTTP/websrv.testdomain.com krbauth
Checking domain DC=testdomain,DC=local

Registering ServicePrincipalNames for CN=krbauth,OU=Users,DC=testdomain,DC=local
HTTP/websrv.testdomain.com
Updated object

C:\Windows\system32>
Once we have the account and SPN setup we can create a keytab file for our Linux hosts. On the Windows server run the following command: this command is CASE sensitive as are most Kerberos items including the krb5.conf file.
C:\Windows\system32>ktpass /princ HTTP/websrv.testdomain.com@TESTDOMAIN.LOCAL /mapuser krbauth /pass p@ssw0rd /crypto ALL /ptype KRB5_NT_PRINCIPAL/out c:\users\user\desktop\krb5.keytab
Targeting domain controller: DC1.testdomain.local
Successfully mapped HTTP/websrv.testdomain.com to krbauth.
Password succesfully set!
Key created.
Output keytab to c:\users\user\desktop\krb5.keytab:
Keytab version: 0x502
keysize 98 HTTP/websrv.testdomain.com@testdomain.local ptype 1 (KRB5_NT_PRIN
CIPAL) vno 4 etype 0x12 (AES256-SHA1) keylength 32 (0xc29e40406bb1e6aac2428f7f41
a514c8f832940ca2f0ba2742900503a57c9f15)

Once the keytab file is created copy this file via binary means to the Linux host, I use winscp for these types of things. We can test the keytab file by using the following
kinit -k -t /home/psoft/krb5.keytab HTTP/websrv.testdomain.com@TESTDOMAIN.LOCAL
again, use klist and kdestroy to verify and clean up after yourself.

In Part 2 I’ll continue with setting up the web and app server.