As organizations discovered years ago, password credentials scale badly. With one credential, life is easy. But as soon as this rises beyond two, things quickly deteriorate. Apart from being hard to remember, entering multiple passwords is time-consuming and inherently insecure. Now, when employees authenticate to multiple applications and services every day, this is a non-starter.

The password problem first popped up in the 1990s and quickly led to the development of single sign-on (SSO). The principle was simple: employees would authenticate to multiple applications through a single SSO interface doing the hard authentication work for them behind the scenes.

At a stroke, SSO based on common protocols such as SAML 2.0 makes life simpler as well as reducing the other downsides of multiple passwords such as re-use and management overhead. Organizations want the convenience of SSO, but also worry about the risk that comes with offering access to multiple applications, including core ones such as Microsoft 365, through a single credential.

Today, using SSO comes with a caveat: As a single credential, SSO is only secure in combination with multi-factor authentication. This is now a must.

Adopting SSO should be a no-brainer, right? It’s so convenient. Unfortunately, the implementation part of SSO almost always ends up complicated. This is because any chance at simplicity doesn’t make it past step one. Why?

Well, the first decision you make is to decide where the SSO platform and the identity system used by it should be located. Most IT leaders have two choices:

• First, you can follow the increasingly popular option to use a cloud SSO service incorporating a dedicated identity platform. This can be implemented through a wide choice of commercial providers as well as Microsoft’s own Azure platform.

• Or, you can implement SSO using an existing identity system. In almost all cases, this means Microsoft’s Active Directory (AD), hosted by an organization on-premise.

In principle, a cloud-based SSO platform is simpler in terms of infrastructure because the service provider hosts both the SSO layer as well as the identity system against which users are authenticated.

This supports multiple cloud applications and services with ease through SAML 2.0 and other protocols. Organizations no longer need to maintain on-premise infrastructure, freeing up IT departments to do other things.

• Relying on a service provider creates a single point of failure, can be expensive to maintain on an ongoing basis, and risks vendor lock-in.

• Using cloud SSO forces organizations to trust a service provider with their data and security. As the 2023 cyberattack on the identity management system of SSO service provider Okta has underlined, the security of these platforms should no longer be taken for granted.

• Cloud SSO might not always support an organization’s legacy and on premise applications.

Perhaps the biggest advantage is simply that organizations can build on the AD infrastructure they’ve already invested in over many years. By using AD as the identity store, they also retain full control over their SSO infrastructure. This is critical for organizations in sectors that must demonstrate this to remain compliant.

When choosing between these two approaches, organizations must still be mindful of the reality that all organizations today use a mixture of in-house and cloud applications. The only real question is how to best integrate them.

It’s tempting to assume that this tips the balance towards a cloud SSO but, as already noted, many organizations still value control. The challenge for organizations with this requirement is to enable on- premises SSO without the downside of additional complexity.

In every SSO project, something that’s taken as a given is the need to support Microsoft 365 and Azure applications efficiently. The case for doing this using existing on-premise AD infrastructures should be compelling, yet many organizations are put off by the practical challenges.

In theory, organizations could use a native tool such as Microsoft’s on-premise SSO platform, AD Federation Services (AD FS). But it's a complex platform comprising several components each requiring its own server infrastructure. This complexity is a clue to the weaknesses and gaps of this platform. Inevitably, complexity adds to implementation challenges and costs as well as the cost of ongoing management.

Remember: The whole point of SSO is to get away from the inconvenience and productivity drain of users accessing applications individually.

Realistically, AD FS increases this overhead, the last thing organizations want at a time when skills are difficult to find and labor overheads are high.

Nor does it help that AD FS lacks support for important features normally taken for granted in an AD environment. These include file sharing, printing via a print server, and using most forms of remote desktop. Perhaps the biggest killer of all, AD FS does not support a wide range of MFA options. This often raises concerns.

After all, the bottom line of SSO is that users are accessing an application infrastructure at the heart of which is the AD directory service. This is a huge target for attackers. So while protecting it is demanding, it’s important work.

Organizations must balance combining SSO with different MFA methods without compromising usability or ease of access. To do this, admins must be able to configure MFA with sufficient granularity as well as have full visibility on how this access is being used.

To overcome the implementation challenges of on-premise SSO in a single system, we designed UserLock SSO to support SAML-based enterprise applications (Salesforce, Slack, Zendesk, Dropbox, etc.) as well as Microsoft 365.

For Microsoft 365, UserLock allows you to embrace SSO alongside lightweight security layers like advanced session management, MFA security and contextual access controls. And since UserLock integrates seamlessly with your existing AD database, you don’t need to maintain a second cloud identity system for SaaS access.

The pay-off for this integrated approach? Easier provisioning of on-premise SSO, for one. But also, and most importantly, better security. Admins can offer SSO to their users with full Microsoft 365 and SaaS integration without losing visibility or control over the accounts accessing AD. Perhaps most importantly, your attack surface also remains limited to your on-premise infrastructure.

The user, of course, is unaware of any of this. From their point of view, they can login to internal, SaaS and Microsoft applications using only their AD credentials, even when connecting remotely across a VPN. And while they may have to complete MFA to do this, granular, straightforward MFA means that this extra security step doesn't become intrusive or impact productivity.

Setting up Microsoft 365 SSO with UserLock involves a three-stage console workflow. It includes adding Microsoft 365 as a provider, configuring SSO settings using IS Decisions’ Microsoft 365 tool, and installing and connecting the on-premise AD domains with Azure using either the IS Decisions wizard tool or Microsoft’s own Azure AD (now EntraID) Connect.

UserLock and Microsoft 365 environments integrate with one another using the dedicated UserLock app:

1. Launch the Microsoft 365 configuration app.

2. Select the UserLock SSO server domain to be connected to Microsoft 365.This also initiates installation of the MSOnline Powershell module and requires signing into the Azure Ad admin account.

3. Choose the organization’s AD domain to be federated with Microsoft 365.

4. Synchronize AD users between these using either the UserLock SSO Wizard (for small numbers of users) or the Azure AD connect (slower but more automated for larger numbers of users).

For a detailed breakdown of this process, read about how to configure Microsoft 365 for UserLock single sign-on.

Many organizations make the transition to hybrid, taking security as a given. But as recent cyber attacks show, the cloud-based identity providers that store your organization's credentials are not immune from attack. At best, you need to accept living with a larger attack surface (with risks that you don't/can't control).

UserLock SSO is an attractive option for organizations across sectors that want or need to keep identity management on-premise.

For example, one of our clients, a French manufacturing company, needed MFA flexibility. Two big requirements for this customer were enabling VPN access with full oversight while protecting Microsoft 365 access from the possibility of credential compromise. This had to be done without relying on unreliable SMS-based MFA. UserLock was able to meet these requirements, integrating SSO, MFA and oversight of account access into a single platform.

For a Canadian energy company, the goal was to secure their OT network. The bottom line for this customer was compliance. As an energy company, MFA was deemed an essential control between the DMZ separating its OT and IT networks. Conventional solutions were expensive, complex, and lacked integration between SSO and MFA. UserLock now provides these features while making use of the company’s existing AD.