A common web server setup with an uncommon SSO hiccup
Last week an SSO stat! customer called me needing some help. They had the Apache Web server on IBM i configured to use Kerberos authentication, and it had been working fine. They then introduced a load balancer… and they couldn’t get SSO to work with it!
Surprisingly, although it is a pretty common setup, this was the first time that I have run into this problem with SSO.
What is a Load Balancer?
Let’s take a quick step back for perspective.
Just what does a load balancer do? Well, it is a separate server that sits between one or more Web servers on the backend, and browser users on the front end.
Once a load balancer is introduced, users still use the URI portion (the path after the system name) of a URL, but they are directed to that content on the hostname or IP address of the load balancer instead.
The load balancer receives requests, determines the Web server to which it will send the request, and passes the request through without changing anything other than hostname or IP address in the URL. This includes the Service Principal Negotiation (SPNEGO) token included with the request.
And therein lies the problem.
Using Load Balancing with SSO
Let’s set up an example to understand the problem that can occur when you introduce load balancing to your existing SSO environment:
Instead of the browser pointing to each one of the Web servers directly using http://websvr1.com/… and so on, after the introduction of the load balancer, the browser now points only to http://mylb.com/…. The load balancer then chooses (according to configuration and an algorithm) which Web server it will send the request through. The request is passed through, unchanged, except for the name of server.
When you add load balancing AFTER configuring SSO, watch for two errors.
Error #1: No service principal found
Now, according to the Kerberos protocol, when the browser points to the load balancer, it will automatically get a Kerberos ticket for mylb.com (i.e., http://mylb.com/…). The Kerberos protocol will not let you get a ticket for a service on any system other than the one you are attempting to directly connect to. That is problem number 1.
Kerberos service principals exist for each of the Web servers (e.g., HTTP/websvrN.com@COM), but nothing has been done to define HTTP/mylb.com@COM. So the browser request to connect with the load balancer will fail with a “no service principal found” error.
The Fix for Error #1
The fix for this is to add another Active Directory (AD) user account for the load balancer and run KTPASS to associate the HTTP/mylb.com@COM service principal with it.
Great! Let’s try that.
Error #2: Invalid service ticket
Ooops. Now we get another error! This time the Web server to which the load balancer sends the request returns an error “invalid service ticket.” This is because the service ticket is for the HTTP service on mylb.com, not on the system name of the Web server selected by the load balancer.
The Fix for Error #2
The good news is that this is also an easy fix. Since HTTP/mylb.com@COM is already defined in AD, just add HTTP/mylb.com@COM to the keytab file on each of the Web servers that are front-ended by the load balancer.
The Take-Away
When you implement load balancing in your SSO environment, be sure that you create a Kerberos service principal account for it in Active Directory, and that the Web servers are also configured to accept service principals with the load balancer’s TCP/IP hostname and/or IP address.
When in Doubt, Call Me!
Still confusing? If you’re one of my SSO stat! customers, just call me and I’ll fix it for you. It takes just a couple of minutes to make the required changes…when you know what needs to be done.
Better yet, call me before you have problems — when you’re planning a system change — and I’ll let you know up front if you’re likely to run into any issues. You’re not bothering me! This is the beauty of being an SSO stat! customer, and the kind of trouble-shooting I love to provide.
Contact me here: http://www.botzandassociates.com/contact-us