Wednesday, March 14, 2018

The LDAP ‘authentication’ anti-pattern

You could walk into just about any organization today, and you’re bound to find an LDAP directory populated with its users. Look a bit further, and you’ll likely find one or more applications using that directory for ‘authentication’. I say 'authentication' with quotes, because LDAP authentication is something of a misnomer. LDAP is a directory access protocol, designed for reading, writing, and searching a directory service. It's not an authentication protocol. LDAP authentication typically refers to the part of the protocol (binding) that is meant to establish who you are in order to determine what privileges you have to the information in the directory. 

Over time, it’s become a de facto authentication service. The wide-spread availability of LDAP services, such as Active Directory, has turned it into an easy win for software developers who are looking to build authentication into their products. LDAP client libraries are available for just about any framework, and it’s relatively easy to get an LDAP integration functioning. 

While using LDAP authentication might solve the development problem of how to authenticate users across an enterprise, it creates a host of other problems. There are inherent weakness and security issues that using LDAP introduces, that are not present in true authentication protocols. 

In order to understand what these issues are, we first need to understand how LDAP authentication actually works.

How LDAP ‘authentication’ works

Consider the following situation (it’s rather absurd but bear with me).

Let’s say I order a parcel from an online store, only to have it delivered when I wasn’t home. The driver leaves a ‘sorry we missed you’ card in my mail box asking me to visit the local parcel pick-up point to collect the package in my own time. I arrive at the collection point, and the person behinds the counter asks for my name and address, and the keys to my house so they can validate who I am. They get in their car and drive to my house. They approach the front door, insert my key, and turn it. The door opens! They have a look inside for some evidence that I actually live there like some photos on the wall, or some mail with my name on it. They drive back to the parcel centre and let me know they have been able to successfully confirm my identity and I can have my package! Great!

Logistical issues aside, there are a quite a few problems with this situation. What if the attendant wasn’t trustworthy, and they took a copy of my key? What if they were trustworthy, but left the key lying around long enough for someone else to copy it? What if they were mugged, and my keys were stolen off them? Once the keys leave my possession, I really can’t be sure who has them and what they will be used for.

Thankfully in the real world, we have documentation like driver’s licenses and passports to prove our identities. I can hand over a piece of documentation that is issued to me by a 3rd party we both trust, such as a government agency, and my identity can be proven without giving away my keys.

In the LDAP world, we still have to hand over our keys to a 3rd party to unlock the door on our behalf. We give our password to the third party and they try to get into the LDAP server with it. If the password works, then you must be the owner of that password. However, now we have the same problem that we have when we hand over our keys. We really don’t know what is going to happen to those credentials and what they could be used for. If the credentials were compromised, the attacker would not just have access to unlock the LDAP door, but any application using those same credentials.

Thankfully, in the wider world of authentication, we have passports and drivers licenses too! Authentication protocols like Kerberos, SAML and OpenID Connect all issue tokens to 3rd parties that prove you are who you say you are, without having to hand them your keys. As LDAP was never designed to be an authentication protocol, it does not have appropriate mechanisms to do this.

LDAP’s weaknesses as an authentication system

Shumon Huque wrote a fantastic article in 2007 - LDAP Weaknesses as a Central Authentication System which he highlights 3 specific problems with the approach of authenticating using LDAP.

1. The application probably isn't secure enough to be touching credentials

Shumon makes the very valid point that it is far easier to defend a small set of authentication servers against an attack, than it is to defend a large population of application servers. 

Authentication servers are generally locked down and run by people with significant expertise in security. 

On the other hand, application servers have a very different security profile, and are more likely to be compromised. They have less rigorous protection, run more complex software stacks and are more likely to have security bugs. They are also more likely to be run by people who do not have an in-depth knowledge of security. That's not a criticism of the hard-working application administrators out there – getting security right is hard, getting it wrong is too easy! 

The problem becomes that if a single application server is compromised, all the credentials that were used during the window of compromise are also compromised. Any other system that those users could log into with those same credentials, can also be considered compromised.

2. The LDAP server cannot enforce the security of the authentication mechanism used to obtain the credentials

The security of the transaction cannot be guaranteed by the LDAP server. While the LDAP server might for example be able enforce binding over TLS to ensure credentials are not transmitted in plain text, it never played a role in capturing those credentials in the first place. The application might be receiving the password over an insecure channel.

3. The user must reveal their authentication secret to a 3rd party 

A user's password, or authentication secret, should remain that, a secret. It should be known only to the authentication system, and the user themselves. When using LDAP for authentication, the user must disclose their secret to a 3rd party, for them to replay that secret against the LDAP directory.

It's probably important to call out here, that with true authentication protocols such as Kerberos, and even the older NTLM, the user secret never passes over the network. The client device and server use cryptographic operations to prove they both have the same secret, without ever exchanging the secret itself.

I'm going to add a few of my own concerns to Shumon's points. These relate to my personal experience, primarily with consumers of Active Directory;

4. Many developers don't know how LDAP works well enough to use it correctly

One of my previous blog posts details how anonymous and unauthenticated binds have tricked many developers into letting unauthorized users into their applications. Unauthenticated binds are one of the subtleties in the protocol that even the most seasoned LDAP professionals are unaware of. 

Directories are complex, and they can store an enormous amount of organizational information and provide a highly customizable way of doing that. I've seen so many cases where the developer of an application assumed a specific object class or attribute existed, and the whole thing falls over when it doesn't. To authenticate a user, you shouldn't need to have a working knowledge of the structure of the data stored in a directory. An authentication protocol should abstract away the detail of the underlying object store.

5. Application administrators often don't configure LDAP clients correctly

One of the frustrating things about managing an Active Directory in a large distributed environment, is that it's difficult to determine when services are using AD as an LDAP directory, and how the application administrators have configured their LDAP client. 

Some of the configuration horrors I’ve seen include;

  • Hardcoding DNs in applications, or using DNs in bind configuration. I've seen countless incidents caused by a rename or move of an object within in the directory, because someone has hard coded a DN somewhere. (A side note to those performing simple binds against AD - you don't need to use a DN to do this. AD also provides alternative DN formats that are more robust than using a traditional DN).
  • Using personal user accounts as a ‘bind’ account instead of a service account (guess what happens when that person leaves the organization)
  • Sending passwords in plain-text over port 389
  • I’ve seen applications with a check box to optionally ‘validate certificate’ when connection to AD using TLS (port 636). Why is this even an option? You are going to throw a password at an endpoint, and you’re not even going to check if it’s the endpoint that you think it is? 

It’s easy to get an LDAP client working, but just because it’s working, doesn’t mean the configuration is correct.

6. LDAP authentication and modern authentication are mutually exclusive

An application using LDAP for authentication will forever be limited to usernames and passwords. Trying to implement modern technologies such as multi-factor authentication and single sign on are virtually impossible (unless you are going to roll your own, which is a bad idea in its own right). The FIDO alliance aims to make passwords a thing of the past. Granted, this is a long term vision, but every application using LDAP authentication is going to stand in the way of an organization going password-less.

What are the alternatives?

Web applications today really have no need to use LDAP for authentication. There are many great web-enabled authentication protocols such as SAML, WS-Federation and OpenID Connect that do not require 3rd party applications having to touch credentials. Any number of products are available that provide these services, including Active Directory Federation Services (built into Windows Server), or hosted offerings such as Microsoft's Azure AD, Okta, Ping, and more. If you don’t have a federated identity provider available in your organization, you need to set one up as a first step.

When you are looking at new software, or going to tender, set a requirement that it must support modern authentication protocols. You may be able to use your organizations purchasing power to negotiate a better security outcome for your users. It’s ok if the vendor pushes back, or the business wants an application that only has LDAP support today. Have the conversation with the vendor anyway and tell them you want them to add support for modern authentication protocols to their product roadmap. It gets the conversation going. The more customers ask for it, the more likely they are to build it. However, if none of their customers ask for it, they’ll never do it.

A trend I’m really happy to see is a growing number of ‘thick-client’ desktop applications supporting modern authentication protocols. These apps have typically been an LDAP authentication stronghold. There are a growing number of SDKs such as the Microsoft Authentication Library (MSAL) that make it easy for developers to drop-in support for modern authentication into their mobile and desktop applications. 

Ultimately, there is a reality to accept in that not all applications today support modern authentication protocols, and perhaps they never will. Implementing a total ban on LDAP authentication is likely not possible in any organization. However, LDAP authentication should be strongly discouraged within the organization. It should only be considered when no other options are available. When going to market for new software, mandate modern authentication support as a requirement. Have vendors or application owners prove that LDAP authentication is the only option before allowing it. Don't offer it as a commodity authentication service.

Wednesday, September 20, 2017

Announcing Lithnet AutoSync for Microsoft Identity Manager

One of the things that I've always believed was missing from MIM and its predecessors was the ability to automatically 'run' the sync engine. The supported way of 'automating' the sync engine is to develop scripts that call the MIIS WMI methods. However, those scripts usually just cycle through the management agents and run profiles in a predetermined order, at a predetermined interval.

Over the years, I've often thought that there must be a better way than this! When we consider the various operations that can be performed on each management agent, the clues to how to do this start to become clear.

Delta import Performed when a change occurs in a connected system
Delta synchronization Performed when an import operation stages changes in a connector space
Export Performed when a synchronization stages outbound changes in a connector space
Confirming import Performed when an export leaves unconfirmed imports in the connector space

In all cases, except the delta import, the operations occur within the connector spaces of the sync engine itself. This means that the sync engine has the information needed to know when a sync, export and confirming import is required - It's all right there in the run history. All we really have to do, is somehow trigger the initial delta import when we know that changes have been made in the connected system.

Today, I'm releasing my solution to this problem - Lithnet AutoSync.

AutoSync is designed to run the sync engine for you. All you need to do is tell it when to run the import operations. You can do this on a schedule (eg every 15 minutes), or in response to an event if your connected system supports change detection. Built-in triggers are provided for Active Directory, LDS, and the MIM service, and you can write your own triggers using PowerShell. I've put a community PowerShell trigger gallery page up where you'll eventually be able to find and share trigger scripts for various systems.

Once the import has been triggered, AutoSync takes care of the rest. If the import results in staged changes in the connector space, a delta sync is performed. If the delta sync stages outbound changes on other management agents, then export operations are performed. After those exports, confirming imports are performed, and the cycle continues.

AutoSync is fast. By ensuring run profiles are executed only when needed, AutoSync keeps the sync engine from doing work it doesn't need to do. When combined with event-based triggers, the sync engine can respond to changes in connected systems in as close to real-time as possible. AutoSync allows for the fastest propagation of changes possible, while respecting the sync engine rules for overlapping run profiles.

AutoSync follows the Microsoft guidelines when it comes to running multiple management agents simultaneously. While import and export operations are allowed to overlap, synchronizations must be run exclusively.

AutoSync has been in development for over 18 months, and I'm very happy to be sharing this with you today. A special thanks to Piyush Khandelwal is in order, as this project wouldn't have been possible without his many, many hours of diligent testing, bug-finding and feedback. A big thank you to those who have also helped test over the life of the project including Darren Robinson, Søren Granfeldt, and the whole team back at the office who have put up with untold numbers of pre-release builds.

Head over to github to read the getting started guide, and happy auto-syncing!

Monday, March 13, 2017

Assisted password reset add-on for the FIM/MIM portal

Microsoft Identity Manager and its predecessor, Forefront Identity Manager cater for self-service password reset (SSPR) scenarios with out of the box workflows that support SMS, email, and question/answer authentication. Self-service password reset is a very important capability for any organization, and when properly deployed, can significantly reduce calls to the service desk.

However, even when SSPR is available in an organization, there will always be a percentage of password resets that the service desk performs. It could be that the user is not enrolled in SSPR, that they didn't know SSPR was available, or their registered SSPR mechanisms were no longer available (eg they have a new phone number, or no longer have access to their registered email address). In these cases, the service desk is usually called and a manual password reset is performed. This is not a scenario that is current supported by MIM directly, which typically results in the service desk dropping back to the AD admin centre or the users and computers console to perform this task.

Today, I'm announcing the release of the Lithnet Assisted Password Reset (APR) add-on for the FIM/MIM portal. This tool integrates with the user RCDC to display a "Reset password" link, allowing quick access to reset the user's password using either a generated or user-specified password.

It's simple, easy to install, and highly customizable.

It supports
  • Automatically generated random passwords of a configurable length
  • Manually specified passwords
  • Includes the option to force the user to change their password at next logon
  • Optionally forces service desk staff member to re-authenticate in order to reset a password
  • Can unlock locked accounts

Visit the GitHub site to get started.