Kerberos Background
As I mentioned in my previous post, I have had the opportunity to implement Kerberos Desktop Single Signon (SSO) for PeopleSoft. When I started on this project I did not understand Kerberos very well, however to get SSO to work correctly I had to dig into the underlying technology to troubleshoot the implementation. Here I share some of the lessons that I learned.
To get a background in Kerberos, Google is your friend. Here is one good primer.
CNAMEs vs. A-Records
The environment where I implemented PeopleSoft SSO uses a lot of DNS aliases for the environment URLs. So instead of https://servername.smartpeoplesoftadmin.com:1443/psp/ps/EMPLOYEE/ERP/h/?tab=DEFAULT a typical URL looks like https://hcmdev.smartpeoplesoftadmin.com:1443/psp/ps/EMPLOYEE/ERP/h/?tab=DEFAULT. HCMDEV is an DNS alias (CNAME) pointing to the A-record (host name). There may also be multiple environments on one server. Each environment uses its own HTTPS port and alias.
However, it is important to understand that the browser requests Kerberos authentication based on the web server’s host name (A-record) and not the alias (CNAME). Neither does the browser include the port number for the Kerberos ticket request. This presents some problems when there are more than one web services hosted on the same server.
For example: serverA hosts websites https://site1.smartpeoplesoftadmin.com:1443 and https://site2.smartpeoplesoftadmin.com:2443. The A-record is serverA, and the CNAMEs are site1 and site2.
When the browser attempts authentication to either site it will request a Kerberos ticket based on the A-record (serverA). The resulting ticket will look like this: HTTP/serverA.smartpeoplesoftadmin.com@SMARTPEOPLESOFTADMIN.COM. This value is also the SPN (service principal name), which must be associated with a server or AD service account. In this case we associate the SPN with the service account that runs the PeopleSoft web and application server. In other words, the SPN is the same for all websites on the server, and can only be associated with one AD account. So for Kerberos authentication to work with multiple websites on the same server, the following must be true:
– A unique service account is needed for each server
– The SPN must be created for the service account
It is possible to make Internet Explorer request tickets based on the port number, which is done by enabling the following registry key. However, following the instructions in my blog posts does not require this modification.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209]
“iexplore.exe”=dword:00000001
Setting this key allows for separate service accounts with SPNs like this:
HTTP/serverA.smartpeoplesoftadmin.com:1443@SMARTPEOPLESOFTADMIN.COM
Kerberos Tool
During my troubleshooting I found this nifty tool that allows you to see your current tickets.
In my next post I will cover how to create the domain account and keyfile.