If your organisation is anything typical then you have multiple web sites and application that require authentication. If you’re lucky then you might have something like CA Siteminder, but your staff still complain about needing to re-authenticate every so often. The more times they need to login, the greater the chance of a mistake, causing a lockout and driving people to distraction.
So you hatch a plan; let’s do a true Single Sign On. And, hey, everyone logs into their Windows desktop and Active Directory presents as a Kerberos source, so why not use AD backed Kerberos as your SSO solution? Now users don’t need to retype passwords all the time.
Problem solved, right?
I feel this approach is misguided, and may open you to greater risk.
The problem is one of “security boundaries”.
In my view staff have at least 3 roles:
- Basic “employee” role shared by pretty much everyone; ability to enter the building, login to desktop, read email, enter timesheets… that sort of thing
- Stuff done on their own behalf. eg setting up direct deposit of wages, signing up for the company gym. Here the staff are effectively customers of the company, using HR and similar systems
- Stuff done specific to their job; developers, SAs, DBAs, bank teller, trader, sales representative, customer support…
The question, in my mind, is whether the gym web site should use the same authentication token as gaining SA shell access to a production server… especially when that access is mediated by a Windows desktop, generally a weak point in any security setup.
Now I’m of the general opinion that any type of Unix shell access on a production server should be considered “privileged access”. Similarly interactive SQL access on databases. Pretty much any access that’s not “end user”. So SAs, DBAs, Application Operate staff et al should not have “SSO” access to their infrastructure. Use something like two factor authentication, or a break-glass process, or some other mediated access solution that requires “step up” authentication. Your desktop AD Kerberos ticket should not grant you access.
This means we can reframe the question in terms access levels:
- Basic access (desktop, email, HR-like, etc)
- Application access (job specific)
- Infrastructure access (privileged)
Privileged access should definitely not be SSO. Application access is somewhere borderline between allowing your desktop credentials to be used or not. It may depend on the risk profile of the application.
The second problem is in a span of control. If everything is controlled by a single authentication source (e.g. Active Directory) then a breach in that environment can be used to pivot across your whole estate. If you have a small number of servers then this risk may be reasonable, but if you have large numbers of Windows and Unix servers then consideration should be paid towards segregating the controls environments. Now if Windows is broken into your Unix environment isn’t directly at risk; similarly if Unix is broken into then your Windows estate is protected.
Of course, more control points means more attackable servers, increased complexity around access admin, auditing, log analysis. You don’t get something for nothing.
It’s a balancing act; desktop, windows servers, unix servers, databases… where do you decide an environment is big enough to warrant its own AAA infrastructure, and how much risk are you willing to accept.
Summary
There has been a drive to merge all authentication systems together; allow Unix, Windows, databases, applications to share the same datasource (primarily Active Directory, via Kerberos). Tools such as Centrify and BeyondTrust Powerbroker (PBUL) allow Unix machines to participate in Active Directory a lot more closely than just using native Kerberos configuration, providing a form of central administration and control.
But you need to consider whether this surface simplicity is the right thing to do from a risk and controls perspective. SSO may not be the correct behaviour, and create a risk concentration around the AD infrastructure.
Ideally, of course, no one should have access to infrastructure and everything is automated :-)