The registry value LDAP_ALTERNATE_LOGINID_ATTRIBUTE is a gem. It is found under the HKLM\SOFTWARE hive in the key \Microsoft\AzureMfa. It plays a critical part to get the NPS extension for Azure MFA to work in real-life scenarios.
For the NPS extension for Azure MFA to work we need to have a match between the User Principal Name (UPN) in the on-premises Active Directory and in Azure Active Directory (AzureAD). The mapping between those two values is not always one on one. You can have Azure AD Connect use different a attribute to populate the Azure Active Directory UPN than the on-premises UPN.
There are many reasons you can need to do so and it happens a lot in real-world environments. Changing a UPN is possible but not always in the manner one wants. Sometimes these reasons are technical, political, or process-driven. In the end, you don’t want to break other processes, confuse your users or upset the powers that be. No matter what the reason, what can you don when you cannot change the UPN to make them match up?
LDAP_ALTERNATE_LOGINID_ATTRIBUTE is a gem
When you have installed the NPS extension for Azure MFA you will find part of its configuration in the registry. In there you can add values or leverage existing ones. One of those is LDAP_ALTERNATE_LOGINID_ATTRIBUTE. It allows using the NPS extension for Azure MFA despite the fact the UPN for users does not match between on-premises Active Directory and the UPN in Azure Active Directory.
What it does is instead of sending the on-premises UPN to Azure AD it uses an alternate value. The trick is the select the attribute that was used to populate the Azure AD UPN in scenarios where these do not match. In our example that is the mail attribute.
AD connect uses the mail attribute to populate the Azure AD UPN for our users. So we have [email protected] there.
In our example here we assume that we cannot add an alternate UPN suffix to our Active Directory and change the users to that. Even if we could, the dots in the user name would require a change there. That could get messy, confuse people, break stuff etc. So that remains at [email protected].
When we have the NPS extension for Azure MFA set up correctly and functioning we can set the LDAP_ALTERNATE_LOGINID_ATTRIBUTE to “mail” and it will use that to validate the user in Azure and send an MFA challenge.
Need help configuring the NPS extension for Azure MFA ?
By the way, if your need help configuring the NPS extension for Azure MFA you can read these two articles for inspiration.
- Transition an RD Gateway to Use the NPS Extension for Azure MFA | StarWind Blog (starwindsoftware.com)
- Install and Configure the NPS Extension for Azure MFA | StarWind Blog (starwindsoftware.com)
There are a lot of moving parts to get an RD Gateway deployment with NPS extension for Azure MFA to work. It would be a pity to come to the conclusion it takes a potentially disruptive change to a UPN, whether on-premises and/or in Azure is required for it to work. Luckily there is some flexibility in how you configure the NPS extension for Azure MFA via its registry keys. In that respect, LDAP_ALTERNATE_LOGINID_ATTRIBUTE is a gem!
Great job! This is truely usefull!
Thanks for this tip!
I noted that upgrading from NPS Extension for Azure MFA v126.96.36.199 to NPS Extension for Azure MFA v188.8.131.52 you have to re enter the mail entry in the registry!
My upgrade path was -> no uninstall but ‘overwrite’ the current installation.
Arian van der Pijl!
Thx for the heads up on this.It’s best to watch those entries like a hawk and document them well. The impact is high and the blast radius large when it fails.
we have configured the setting, but the MFA request arrives on the smartphone with a big delay.
Do any of you know this problem?
Some days we notice some delays, not always constantly during the day but nothing very bad or always. We have that with or without this setting. But most of the time the delay is OK/reasonable. It is not an end user concern or service desk issue that needs addressing in terms of usability.
Okay, thank you. Our delay is very high when an alternate loginid is configured – over 20 minutes most of the time.
No, that is not good. Do you have this for all accounts/users? Or is it just a test user where you sent a lot of tests and some of those are showing up late for a certain time or is that continuously at 20 minutes or more for everyone?