What credentials can I use for the Active Directory Application Mode (ADAM) or Active Directory Lightweight Directory Services (AD LDS) Management Agent (MA) in Forefront Identity Manager (FIM) 2010 or R2?
Bit basic this post but I had to install FIM Synchronization Service and an AD LDS instance during a meeting to get this answer so figured I might as well post the information here for posterity.
Binding to ADAM/AD LDS
For the rest of this post I’m going to use the term ADAM however everything I say applies to AD LDS (in fact my testing was using AD LDS on Windows Server 2008 R2). And when I say bind I mean logon.
OK, with that out of the way. You can bind to ADAM using an ADAM principal (some user-defined object type in the ADAM instance that “implements” the msDS-BindableObject class, i.e. an ADAM user); a Windows principal (a local user object on the Windows computer running ADAM, i.e. a user in the Local Security Authority or LSA, or in Active Directory Domain Services or AD DS, e.g. a user or inetOrgPerson object); a user proxy (a special type of user object in the ADAM instance that is linked, via objectSid, to an AD DS user); and lastly anonymous binds.
ADAM only authenticates “ADAM principals”. “Windows Principals” and user proxy objects are authenticated by Windows, i.e. the local LSA or AD DS.
ADAM supports the following credential formats:
- Windows principals:
- User Principal Name (UPN). Domain-based Windows Principals only, e.g. firstname.lastname@example.org.
- Account Name (sAMAccountName). The account name, e.g. computer\paulw or domain\paulw, e.g. msresource\paulw.
- Distinguished Name (DN). Domain-based Windows Principals only, e.g. CN=Paul Williams,OU=People,DC=msresource,DC=net.
- ADAM principals:
- Display Name.
- Distinguished Name.
There’s some obvious caveats for ADAM principals. UPN or displayName must be unique across all objects (irrespective of type, so if you have OU=paulw,O=msresource,c=GB you cannot logon with a displayName or UPN of paulw).
I heard you can logon with canonical name too, but limited testing did not prove that theory.
Specifying credentials for the ADAM MA
With enough background on the subject of binding to ADAM let’s look at what we can do with the ADAM MA.
By default, the MA is configured to support a Windows Principal, i.e. a Simple Authentication and Security Layer (SASL) authentication – this means SPNEGO a.k.a. Integrated Windows Authentication (IWA).
This means, by default, you are limited to NETBIOS_DOMAIN_NAME\username (or COMPUTER_NAME\username) and email@example.com. Although when I say DOMAIN\username you don’t actually write it like that – there’s an input box for username, password and domain. When you introduce an @ into the username the domain box is no longer required although not greyed out.
Now, stick a DN in and you’ll get an error:
That picture says:
The user name cannot contain any of the following characters,
‘<’, ‘>’, ‘&’, ‘”’, ‘/’, ‘\’, ‘[‘, ‘]’, ‘:’, ‘;’, ‘|’, ‘=’, ‘,’, ‘+’, ‘*’, ‘?’
Try a basic username and password (no domain, e.g. displayname and password) and you’ll get a validation error:
That picture says:
Please complete the credentials.
The reason for this is because we’re in SPNEGO mode. We need to change to SIMPLE BIND to unlock the ability to specify a DN or a username and password (could be UPN or displayName) with no DOMAIN/COMPUTER requirement. That’s done via the options button (adjacent to “Configure Connection Security”):
So the default is to not only bind using SASL but use SASL to sign and seal (encrypt) all communications thereafter. When you “Enable Simple Bind” you can choose to use SSL with or without Certificate Revocation List (CRL) Checking or (dev lab only please people) no SSL, i.e. clear text credentials.
After turning on simple bind you can use a DN to bind (as many LDAP folk expect):
Hopefully someone will find this helpful.