Single sign-on (SSO) security issues with Active Directory

Single sign-on (SSO) is a powerful productivity tool. With the ability to streamline access to on-premises and cloud-based applications with a single user authentication, SSO dramatically simplifies the user experience. Using a single set of credentials, employees can access their organization’s cloud resources and web applications.

But how do organizations ensure they benefit from the advantages of SSO while ensuring secure access?

Identify single sign-on (SSO) security considerations

First, it’s important to know the risks. SSO, like any other form of access, brings implied security vulnerabilities. While those risks can be minimized by implementing additional controls, like multi-factor authentication (MFA) and session management, identifying the dangers of single sign-on helps ensure that your organization implements a secure solution.

What are the security risks with SSO?

In general, SSO is more concerned with providing access than with restricting it. And, at a time when malware-based attacks are rampant, more access is not always a good thing. Despite the benefits previously mentioned, there are quite a few risks that come along with utilizing SSO:

1. Instant access to more than just the endpoint

Logon credentials are a major focus for external attackers (over 50% of data breaches involve credential data). With SSO in place, once a malicious user has initial access to an authenticated SSO account, they automatically have access to all linked applications, systems, data sets, and environments the authenticated user is provisioned for. What makes SSO so great for users is also what makes it risky!

What’s more, external attackers using malware to gain control over an endpoint also have post-logon access to everything connected via SSO immediately after infection, increasing an attacker’s footprint within the organization.

2. Less-than-perfect control over access once granted

Let’s say a user has successfully logged on via SSO and is granted access to additional external applications in the cloud. Then the user falls prey to a phishing attack, giving an attacker access to the endpoint.

If detected, the account certainly can be disabled. But, given the way Windows works, the user remains logged on and, depending on the SSO solution in place and the linked application’s security model, it’s possible for the attacker to remain logged on with access to a given application.

3. Little-to-no adherence to the principle of least privilege

The principle of least privilege dictates that users should have access to the minimum data, applications and systems necessary to do their job. It also usually involves requiring separate credentials for elevated access.

Because SSO is all about giving access with a single authentication, it runs contrary to the idea of requiring the user to authenticate each and every time they need to access something new.

Know how to reduce the risks for Active Directory SSO

While the risks are real, the benefits of SSO, like improved productivity and reduced support costs, still make the solution an attractive one. So, how do organizations benefit from SSO’s simplified access while still maintaining a solid security posture?

The answer lies in filling in the security gaps by taking a few additional steps in a way that is as non-disruptive as possible.

Step 1: Retain on-premises Active Directory for user identity management

Continue to use Active Directory to streamline all user authentication and account management. It provides the central place to create and configure an employee’s roles and services, and to remove them on their departure or when they no longer need access.

Ideally, once an employee’s AD identity is created, AD should also be used to determine which cloud applications the employee needs to access (and only those applications).

This way, an employee cannot bypass the SSO access via their AD identity, and browse directly to the application. With the ability to deny access to the entire Windows session, you know every accessible data set, system and application is equally secure, whether on-premises or in the cloud.

With UserLock, organizations can now retain on-premises AD as their identity management solution, while extending it to work with the cloud:

• No need to consolidate or integrate user identities into a new directory.

• Leverage your existing investment in AD.

• Accounts, services, roles and group policies continue to be enforced.

• Retain on-premises authentication for maximum security.

• Ability to add SSO for major cloud apps or custom apps.

• Disaster recovery for peace of mind.

Step 2: Combine SSO with MFA to secure password vulnerabilities

Combining SSO with multi-factor authentication introduces an additional security layer of security to verify the identity of users and protect AD accounts. While the rise in remote work is increasing MFA adoption, there’s still a perception that it impedes end-users with additional security steps that prove costly, complex and time-consuming to set up and manage. Unfortunately, these common 2FA myths often hold organizations back from what can be an important security tool.

In reality, MFA can:

• Stop a data breach before any damage is done.

• Protect all users, including the most privileged ones.

• Make compromised credentials useless to attackers.

• Be customized for any user, user group or organizational unit.

With UserLock, granular MFA can be easily combined with SSO to provide protection without unnecessarily impeding employees. With support for authenticator applications and one-click programmable tokens such as YubiKey and Token2, Userlock’s MFA can be customized to ensure less friction for users. Administrators can also use the context of the users’ authentication attempt to set access policies and balance the need for convenience and security.

Step 3: Context-aware technology to further secure SSO

Context-aware security analyses the situation in which an access attempt takes place to determine whether the person trying to log in is exactly who they say they are. It can reduce the size of the opportunity for would-be attackers.

For example, security controls around the initial Windows login can include:

• Restrictions on when and from which endpoint(s), geolocation or IP addresses a particular user account can logon.

• Restrictions on logon frequency and concurrency.

• Restrictions based on session type (local, RDP, etc.).

• Real time monitoring and alerts on potentially suspicious access.

• Warnings to end users themselves of the use of their own AD identities.

With UserLock, context aware security is run as an integrated part of the logon process. It acts as a non-disruptive technology that aligns perfectly with the productivity-focused mindset of those implementing SSO.