Password fatigue is a common issue, even if you don’t often see it directly. It has become common practice to save passwords within browsers, but the annoyance and frustration of clicking through each individual login screen is still there – and steadily increasing. Password fatigue and related issues can pockmark productivity and bring individual progress to a grinding halt.

For the 14th Century Englishman or Englishwoman, there was no escaping the frustration of having multiple shared secrets. A well-known seal could prove who you were, but not if you belonged, and so a wide variety of passphrases and shared secrets were necessary. Authentication may have been relatively simple – but it was still incredibly verbose at times.

With Active Directory Single Sign-on, the modern age has the capability to eliminate this issue in a simple and secure manner using various industry standards – a critical necessity for both usability and compliance. For more information, see the Compliance section below.

Named after the mythological three-headed guardian of Hades, the Greek underworld, Kerberos is an authentication protocol that relies on mutual authentication and a trusted third-party. Kerberos was built and designed at the Massachusetts Institute of Technology as an additionalmethod of securing network services provided byProject Athena.

As the referential name would imply – Kerberos implements a three-part authentication process that builds on symmetric key cryptography. The three ‘heads’ of Kerberos Authentication refer to the Key Distribution Center (KDC), the client machine and the service provider. The KDC can be installed as part of the Active Directory Domain Controller (DC) – introducing the trusted third party into the mix.

The basic process of Kerberos proceeds as follows:

1. Client Machine Creates Ticket Granting Ticket (TGT) for User†

2. User attempts to access a Service Provider

3. Client Machine receives a Session Ticket from Domain Controller and submits it to the Service Provider††

4. Service Provider validates the Session Ticket and returns a new Session Ticket to the Client Machine

5. The Client Machine submits new Session Ticket to Domain Controller for validation

6. User is Granted Access to the Service

This entire process - from start to finish – happens rapidly behind the scenes. If Active Directory and the service in question are appropriately configured for Kerberos Authentication, the user need only make the initial request and the service will be provided without any interruption.

SAML is an open-standard authentication protocol, which enables user authentication between an Identity Provider (IdP) and a Service Provider (SP). A SAML Token containing user-specific attributes is created by the IdP and automatically sent to the SP in order to validate a user without having to repeatedly login via traditional methods.

By using an IdP such as PortalGuard in conjunction with ActiveDirectory and SAML, Single Sign-on can be achieved without any downside to the individual user. No confidential information is shared – the login credentials are not transmitted directly to any of the target websites – and the Service Provider is able to validate the authenticity of the SAML Token directly, in order to provide secure authentication.

Most Identity Providers can easily utilize Active Directory to provide out-of-the-box SAML SSO to literally thousands of on-premises and cloud-based websites.

Shawn Bayern at the Yale University of Technology and Planning developed the Central Authentication Service (CAS) primarily for Single Sign-on, but it later introduced multi-tier proxy authentication. Since its inception, and throughout its various versions that exist today, much the same process for SSO authentication has occurred. CAS uses a three-party approach similar to Kerberos for authentication – with a specific requirement of a dedicated CAS server.

For more environments that require more direct authentication management than is provided through standards such as SAML, the CAS protocol can be configured for many web applications. While the structure of CAS may be reminiscent of Kerberos, the process itself is more akin to that of SAML SSO. Much like using SAML, CAS enables Single Sign-on to a preconfigured list of web apps by providing two-part authentication. When the web app in question requests validation, it communicates with the CAS server and not the user, at which point the CAS server provides a service identifier and a security ticket to be verified by the application.

As with other SSO methods, this process happens behind the scenes and will not require the user to provide additional credentials unless the application has not been configured for Single Sign-on. Additionally, no security credentials are put at risk because they are not transmitted to the web application directly. Given its wide-ranging support for various web applications, the CAS protocol is often used heavily in the education vertical.vii

Most business or educational institutions already employ Active Directory for Windows login – opening the door to the possibility of reduced or single-sign on to an expanded assortment of web applications through any of the above protocols.

Using Active Directory as a user repository for identity management, as well as an anchor for Single Sign-on will reduce the threat of an intruder gaining access due to an improperly crafted or stored user password. When the end-user is only required to remember a single secret code, they are much more likely to accept that reality and reduce the likelihood of compromising security.