ADFS: signing in by mail address, and the manager from the directory

Applies to: SimpleTwo 0.9.x · Checked: 20.09.2026

ADFS connects as an ordinary OIDC provider — see Sign-in with a corporate account. This article covers the two cases that come up in almost every deployment and are solved on the ADFS side, not in SimpleTwo.

1. Signing in with a mail address (Alternate Login ID)

Symptom. The client found the right installation, the password is right, and sign-in answers "invalid credentials". The coordinator's journal shows sso.password_reject.

Cause. SimpleTwo sends ADFS exactly the string the person typed, and ADFS checks it against userPrincipalName by default. An employee whose UPN is ivan@corp.local and whose mail is ivan@example.com will not be found.

Fix. Alternate Login ID (ALI) makes ADFS resolve the typed value against a directory attribute instead of the UPN. Nothing changes in SimpleTwo.

ALI applies to the whole forest, not to one application

It changes how identifiers resolve for every sign-in through this ADFS. Do it in an agreed window, and audit the directory first.

Step 1. Find duplicates. If one value belongs to two accounts, ADFS cannot choose — and both people stop signing in:

Get-ADUser -Filter * -Properties mail |
  Where-Object { $_.mail } |
  Group-Object mail | Where-Object Count -gt 1 |
  Select-Object Name, Count

For the multi-valued proxyAddresses the check is mandatory separately: it is where leftovers from old migrations usually live.

Step 2. Choose the attribute.

Attribute	When	Caveat
mail	people type their primary address	single-valued, simplest
proxyAddresses	people have several addresses and may type any of them	multi-valued; values are stored with a prefix (smtp:ivan@example.com) while the person types the address without it

An employee with an empty attribute keeps signing in by UPN after ALI is enabled — that path continues to work.

Step 3. Enable it. On the ADFS server:

Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" `
  -AlternateLoginID mail `
  -LookupForests corp.local

Roll back with empty values:

Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID "" -LookupForests ""

Step 4 — the one people skip. Test the endpoint SimpleTwo actually uses: the app signs in through the password grant, not the browser form, and ALI has historically applied unevenly across ADFS endpoints.

curl -s -X POST "https://adfs.example.com/adfs/oauth2/token" \
  -d grant_type=password \
  -d client_id="<Client ID from Settings → SSO>" \
  -d username="ivan@example.com" \
  -d password="<password>" \
  -d scope="openid" | head -c 400

Response	What it means
an access_token / id_token	ALI works on the endpoint that matters; nothing to change in SimpleTwo
"error":"invalid_grant" with a code like MSIS9659	the identifier was not resolved: check the attribute value on that account and the forest list
works with the UPN, not with the mail address	ALI is not in effect for this endpoint

Run it twice: with the mail address and with the UPN. Colleagues on the primary domain keep typing their UPN, and it has to keep working.

Step 5. Add the domain to Settings → SSO → organisation domains. That list is what turns "invalid credentials" into a comprehensible "this domain is not served here", and it is what lets the client find your coordinator from that address at all.

The password grant bypasses MFA and conditional access

That is a property of ROPC itself, not of ALI. If multi-factor authentication is mandatory for you, know that sign-in from the app does not see it. Moving the client to the authorization code flow, where the person types their identifier on the ADFS page (and ALI stops mattering), is planned.

2. The manager: two claims instead of a transformation in ADFS

In Active Directory the manager attribute holds a DN (CN=Peter Smirnov,OU=Users,DC=corp,DC=example,DC=com), not an address. ADFS used to be asked to look the directory up a second time and turn that DN into a mail address; that is no longer needed and no longer supported: an address in this field matches nobody and is written to the audit log.

SimpleTwo joins people itself: the manager's DN in one account matches the employee's own DN in another. So all ADFS has to send is two ordinary LDAP attributes.

Step 1. Register the claim descriptions. Without a short name the claim is computed and never reaches the OIDC token — which looks exactly like a rule that did not fire:

Add-AdfsClaimDescription -Name "UserDN" `
  -ClaimType "http://schemas.xmlsoap.org/claims/UserDistinguishedName" `
  -ShortName "user_dn" -IsAccepted $true -IsOffered $true -IsRequired $false

Add-AdfsClaimDescription -Name "ManagerDN" `
  -ClaimType "http://schemas.xmlsoap.org/claims/ManagerDistinguishedName" `
  -ShortName "manager_dn" -IsAccepted $true -IsOffered $true -IsRequired $false

Step 2. Add one rule from the Send LDAP Attributes as Claims template (attribute store: Active Directory) in SimpleTwo's issuance rules:

LDAP Attribute	Outgoing Claim Type
distinguishedName	UserDN
manager	ManagerDN

Both columns are editable combo boxes: distinguishedName is not in the offered list and has to be typed. No custom rules are needed and rule order does not matter.

Step 3. Tell SimpleTwo what to read. Console → Settings → directory fields:

• Directory DN (internal) → from the user_dn claim;
• Manager → from the manager_dn claim.

The first field is internal and shown nowhere: a DN on a colleague's card is noise.

Step 4. Verify. The manager appears on the card once both the employee and the manager have signed in at least once: until one of the accounts exists here there is nothing to join. Confirmation is silence in the audit log — directory.manager_unresolved entries stop appearing.

3. When it does not work

What you see	Cause
No user_dn / manager_dn in the token	the claim descriptions are not registered (step 1), or the short names are taken
manager_dn empty for some people	their manager attribute is empty in AD — a directory question
Both claims present, no manager on the card	Directory DN (internal) is not mapped in SimpleTwo
directory.manager_unresolved with a DN in the audit log	that manager has never signed in to SimpleTwo
One person's manager "fell off"	they were moved to another OU and the DN changed; it recovers at the manager's next sign-in

Why so much detail about emptiness

Almost every ADFS failure here is silent: a rule with a typo in an attribute name does not fail, it returns an empty set and succeeds. "Not found" and "did not run" are told apart only by where exactly the emptiness is.