Overcoming Security Risk in Active Directory SSO

Active Directory SSO solutions eliminate the need for users to remember a unique, complex password for each application and platform they access, replacing it with a single logon facilitating access to multiple systems and applications.

For organizations, Single Sign-On is largely a productivity play.

Working in IT is a constant battle to find the perfect balance of security and productivity. This is no better personified than in the need for Active Directory (AD) users to access multiple systems through the use of Single Sign-On (SSO) platforms.

Offering faster access times to applications, with reduced password requirements (usually, one), it’s a no-brainer technology that reduces administrative overhead and support costs, while being a non-disruptive technology with a high adoption rate. It also does come with some security benefits: Since SSO only utilizes a single credential it often equates to requiring a very complex single password. Additionally, the act of disabling access enterprise-wide becomes as simple as disabling the initial account. But, as with any technology designed to improve productivity, there are often losses on the security side. And in the case of SSO, there are some implied security risks.

WHAT ARE THE SECURITY RISKS IN Active Directory SSO?

In general, Active Directory SSO is more concerned with providing access than restricting it. And, at a time when malware-based attacks are rampant, it’s not the perfect time to be giving it all away. Despite the benefits previously mentioned, there are quite a few risks that come along with utilizing SSO:

a) Instant Access to More Than Just the Endpoint – Logon credentials are a major focus for external attackers (81% of data breaches involve credential misuse1). With Active Directory SSO in place, once a malicious user has initial access to an authenticated Single Sign-On account, they automatically have access to all linked applications, systems, data sets, and environments the authenticated user is provisioned for. Most SSO environments leverage a portal of some kind that facilitates access without requiring additional passwords. While great for users, it’s terrible for security!

External attacks using malware to gain control over an endpoint would have post-logon access to everything connected via SSO immediately after infection, increasing an attacker’s footprint within the organization.

b) Less-Than-Perfect Control over Access Once Granted – Let’s say a user has successfully logged on via Active Directory 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.

c) Over-reliance on Two-Factor Authentication – Two-Factor Authentication (2FA) leverages an external authentication mechanism (in addition to a password) to prove the user is who they say they are. However, 2FA solutions are not widely adopted and most likely because they impede end-users with additional security steps that prove costly, complex, and time-consuming for the IT department to set up and manage. The strongest Active Directory SSO environments rely on – expensive – biometrics (which are the toughest to fake), but many still rely on either a convenient external factor everyone has: SMS and their mobile phone – or just the AD logon password as a single layer of protection.

The problem is SMS has been at the center of a lot of two-factor hacks. It has led to the National Institute of Standards and Technology withdrawing support for SMS-based two-factor. And for those organizations who rely solely on the AD logon password – then all it takes is one instance of bad user behavior to lead to a severe breach, for example, an employee sharing a password, leaving a workstation unlocked or a malicious user stealing a colleague’s credentials.

d) 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, and usually involves requiring separate credentials for elevated access. Because SSO is all about giving you 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.

Even with risks, organizations like the benefit of the improvement in productivity and reduction in support costs. So how can you facilitate the simplified access of SSO while still maintaining a solid security posture?

REDUCING THE RISK IN ACTIVE DIRECTORY Single Sign-On

Surprisingly, the answer doesn’t lie in getting rid of SSO. On the contrary, it’s about filling in the security gaps by taking a few additional steps in a way that as non-disruptive as possible.

Step 1: Securing the Logon to Active Directory with Logon Management

Most SSO solutions leverage Active Directory as the initial logon. So, it’s the most applicable point in which to put security controls – after all, if you can’t log on to AD, you have zero access to anything via SSO. A Logon Management solution puts a few security controls around the initial Windows logon:

It restricts when and from which endpoint(s) or IP addresses a particular user account can logon
It restricts logon frequency and concurrency
It restricts based on session type (local, RDP, etc.)
It monitors logons for unusual activity such as attempting logon on after hours or from an unusual endpoint
It can require approvals from another user – normally a manager, or IT
It can force a full logoff from a Windows session based on permitted hours or in response to IT directive

It’s that last part (underpinned by all the other Logon Management capabilities) that fills in one of the gaps of Active Directory SSO – killing access via SSO is only effective if you also kill access to all of the external applications. With an ability to kill the entire Windows session, you know every accessible data set, system, and application is equally secure.

Usually, run as an integrated part of the logon process, Logon Management is a non-disruptive technology that aligns with the productivity-focused mindset of those implementing SSO.

Step 2: Improving a Least Privilege Posture with Privilege Session Management

SSO desires to give users access to additional applications without requiring a logon. But good least privilege practice dictates elevated access requires additional authentication. A happy medium might be the use of Privileged Session Management (PSM). PSM is a proxy of sorts between the user and the system or application with elevated access. Low-level users can request access (by means of a portal) with access granted without providing the password to the user. Now, this sounds like it’s no different than SSO, and in some ways, that’s true.

What PSM would add to the mix is its policy-driven controls under the hood that put a few additional controls in place:

It can define which users can access which systems, when, from where, etc.
It can require approvals of a peer or a manager before allowing access
It can notify IT of access granted
It can record the session to create an audit trail of activity

The addition of PSM creates a similar end-result to SSO, with a comparable level of “non-disruptiveness” but with the addition of having several layers of security controls in place.

Step 3: Use Security Policy-Driven Single Sign-On

SSO has a place in any organization and, in the case of organizations with many cloud-based apps, you can successfully leverage AD as the system of record for all external access. By having solid AD controls in place (such as Logon Management and PSM), you create a secure foundation for Active Directory SSO. But you can’t stop there. Below are some suggested Active Directory SSO security controls to have in place:

Ensure SSO least privilege – think about the access Active Directory SSO should provide using the lens of Least Privilege. Define roles for each type of user in the organization, identifying the specific applications they need to do their job, limiting access to only those IT deems absolutely necessary.

Require Multi-Factor Authentication – asking for more than just one additional factor significantly improves security.

Use Modern Authentication Protocols – Make sure your Active Directory SSO solution is leveraging OpenId Connect or OAuth 2.0.

Limit Device Access – Put restrictions on which devices with which a user can leverage Active Directory SSO.

Enforce Frequent Password Changes – for accounts with elevated access, consider requiring new passwords more often.

ACHIEVE BOTH ELEVATED SECURITY & PRODUCTIVITY WITH AD LOGON & Active Directory SSO

To a user, Active Directory SSO is a god-send; being able to access everything without additional logons? Sign me up! But, with the added gains in productivity comes an equal increase in security concerns. Once past the SSO, the floodgates of access are wide open, making the logon a critical inflection point for organizational security.

By leveraging solutions that address the security gaps introduced by SSO, organizations reduce the risk associated with SSO. Implementing Active Directory SSO with a security policy in mind can improve SSO’s own security stance. PSM addresses concerns about providing access to privileged accounts. And, Logon Management puts proper security around the very foundation of SSO – the AD logon.

The risk in Single Sign-On exists only if you see Active Directory SSO as a means to gain access. But by recognizing the inherent security gaps that exist, and compensating by implementing additional controls in the form of Logon Management and Privilege Session Management, you effectively reduce SSO risk, making it a source of elevated productivity and security.

For more information visit https://www.isdecisions.com/products/userlock/