First off, let me say that PrivacyIdea is an incredible project. After some initial roadbumps with install (due to my desire to use Debian instead of Ubuntu), I went ahead and switched to Ubuntu and the install and initial setup was flawless. I’ll work through the Debian install issues and put together an guide if I can at some point down the line.
I am lucky enough to have put together a couple decent servers and to have a local colocation provider that lets me keep them out of the house and in a nice datacenter. I, in turn, use them as a lab environment and VPS environment for local tech groups to use (it’s such a more rewarding demo when all the attendees can follow along live on their own VM!).
As I work to enable SSO for the various services that are available, 2FA was a part of this and PrivacyIdea fits the use case perfectly!
To help keep chaos and destruction to a minimum, for the Windows Lab environments, I provision each environment as a child Active Directory domain to the root forest. This lets me un-break what a user breaks if needed and lets me grant the user domain admin to their own sandbox while minimized risk to the infrastructure as a whole.
I would like to not have to set up a new realm in PrivacyIdea for each child domain (since the creation process is manual enough and I am but one person!).
Fortunately, Active Directory’s Global Catalog LDAP endpoint is perfect for this!
One realm for an entire forest? How? (somewhat) simple!
For example’s sake, my root forest is contoso[.]net; my child domains are ‘lab01.contoso[.]net’, ‘lab02.contoso[.]net’
Set your ldapresolver’s server URI to ldaps://dc01.contoso.net:3269 ( 3269 is LDAPS Global Catalog, 3268 is LDAP)
Set baseDN to be the base of your domain. aka: “DC=contoso,dc=net”
Your bind DN is normal, retrieve that from the distinguishedName in AD.
Search Filter required some adjustment for me. I used “(userPrincipalName=*)” since I want to only show human users (and machine accounts don’t have a UPN). Use the hidden gem ‘ldp.exe’ on your domain controllers to help tweak this. Run that on your Domain Controller, go Connection>Connect with the server of your DC (localhost?) and the port of the Global Catalog (3269); bind like normal (Connection>Bind) then Browse>Search. You will see similar options to PrivacyIdea’s ldapresolver settings; try at will. Note that the “Attributes:” section is what attributes you want back from your query, which is great to see what you can use as the Loginname attributes.
To complicate things a bit, I have my users login via the Mail Attribute (because no one is gonna remember their username of “firstname.lastname@example.org” and everyone much prefers to login as hmhackmaster@gmail[.]com). AD doesn’t like this necessarily, but it does work with the correct config in ADFS & also in PrivacyIdea.
My problem here is simple: because I have one realm querying a single Active Directory forest, duplicate sAMAccountNames can & will occur! From an Active Directory point of view, this is perfectly acceptable.
Accounts like UPN: hmhackmaster@contoso[.]net (sAMAccountName: CONTOSO\hmhackmaster) and email@example.com[.]net (sAMAccountName LAB01\hmhackmaster) can exist in the same GC / Forest. While this may not necessarily be an issue for some forests, this is a lab and most domains have an identically pattern of “firstname.lastname@example.org[.]net” account for me to use during setup and to help the end user.
PrivacyIdea doesn’t like this one bit. When logging in as the user to enroll a token, the error “ERR905: Cannot pass user_object as well as user, resolver, realm” is thrown.
When attempting to add a token to the user as an admin, the privacyidea.log file shows the following error text
[ERROR][privacyidea.app:1891] Exception on /token/init [POST] ..... Exception: Found more than one object for Loginname 'hmhackmaster-admin'
I have not found much in my research for the ERR905 or for a way to switch PrivacyIdea’s primary username to the UPN (instead of the sAMAccountName), so I figured I would start a thread here, see if anyone else has a pointers, and document my progress since I doubt this is a rare occurance (especially with MSFT really strongly transitioning away from using the legacy sAMAccountName attribute).