20 year old SAML is great, and it’s essential for web apps where you can’t establish a direct trust between the identity service and downstream system, but truth be told, I still prefer it’s 31 year old cousin: LDAP.
In an enterprise environment, in my mind, there’s three realistic options for a primary / centralized identity store: Active Directory, an open source LDAP implementation (like openldap), or a cloud based directory (eg: Microsoft Entra ID / AzureAD, Okta, Google Workspace).
While I bias towards open source, for LDAP I’m actually a fan of Active Directory as the primary user identity store given its multi write-replica architecture. Windows and tooling has come a long way to enable deploying lightweight Windows Servers and manage them through code. As most organizations end up with a few Windows Servers, having everything centralized in one place, has a lot of appeal to me. If you’re already running a large fleet of servers, don’t have a single Windows Server, and use AWS, then a realistic option could be AWS Managed Microsoft AD. The downside of Active Directory is the LDAP interface was “extended” in a way that doesn’t play nice with the standard LDAP schema.
For organizations that have a large number of Linux servers, regardless if AD is in use, I prefer running openldap with read replicas adjacent to critical servers (eg: across co-lo sites, or in each AWS region) to ensure folks aren’t locked out of prod while someone deployed a Windows update, and I prefer to not have multiple dedicated AD servers floating around in every network segment.
… but “run AD” and “have openldap for Linux” seems contradictory to having a single centralized directory for all users. While there’s some management overhead involved, in a previous role I found there’s a way to have your cake and eat it too, but there’s three problems to overcome:
- Determining what’s the actual source of truth directory
- Ensuring the directories are always in sync
- Password management
Once settled on a source of truth (primary) directory, this can be used to regularly forcibly replicate user/group/OU objects over the other. As Active Directory has a worst case replication time of 15 minutes, I like to run directory-directory sync operations every 10 minutes. For example if openldap is your primary directory, every 10 minutes force changes from openldap over the top of any existing user and group objects in Active Directory. To achieve this, rather than going on a vendor discovery tour, I recommend you take a look at lsc.
Finally, one thing to keep in mind is we never want passwords stored using reversible encryption, so we need a way to manage passwords. While it won’t win any design awards, I like PWM as it’s easy to have it simultaneously change LDAP and Active Directory passwords, and optionally extend it to handle other / legacy systems at the same time. For those worried this will break your AD forced password rotations and CTRL-ALT-DEL password resets, you’re right, but given NIST 800-63B now recommends against arbitrary password rotation intervals, pointing users to a dedicated password reset tool which can be optionally protected with MFA seems like a reasonable tradeoff to me. If you’re using Duo for MFA, I assume you’re already familiar with the Duo Authentication Proxy.
If you’ve already taken the blue pill and use a cloud based directory service as your source of truth, the major ones have now implemented LDAP endpoints which you can use for user authentication, however they each have their own limitations. If you’ve not already explored these, you can find more info at: Microsoft, Amazon, Google, Okta, Ping. Personally, I wouldn’t want to rely on them for production server authentication during outages, but your availability risk appetite might be greater than mine. Alternatively you may be able to setup LDAP read-replicas from your cloud directory, however I’ve never tried this myself.