Category Archives: MFA

LDAP_ALTERNATE_LOGINID_ATTRIBUTE is a gem

Posted on by
7

Introduction

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.

LDAP_ALTERNATE_LOGINID_ATTRIBUTE is a gem

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.

AD DS mail attribute set to a different value than the UPN.

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].

Our AD DS UPN is set to the domain name suffix and the account name has no dots.

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.

LDAP_ALTERNATE_LOGINID_ATTRIBUTE to the rescue

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.

Conclusion

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!

MFA for a highly available RD Gateway

Posted on by
8

MFA for a highly available RD Gateway

Recently I decided to write up a couple of articles on how to set up MFA for a highly available RD Gateway. Why? Because so much information on the internet is fragmented and as such incomplete. So I wanted a reference document for myself. As I was making that document I realized I needed to explain the why and not just the how. The “why” is what helps people support and troubleshoot the solution during its life cycle.

The above, in combination with me being a verbose son of * led to 44 pages of information. So, I decided to publish it as a two-part article series.

MFA for a highly available RD Gateway
Figure 1: MFA for a highly available RD Gateway

You can find the articles here Transition a Highly Available RD Gateway to Use the NPS Extension for Azure MFA – Phase I and Transition a highly available RD Gateway to use the NPS Extension for Azure MFA – Phase II

Why and when should you read them?

If you have RD Gateway running and you have no MFA solution set up for it, I highly recommend you head over to read these two articles. That is especially true when your RD Gateways solution is a high availability (HA) deployment with an RD Gateway farm behind a load balancer. In that case, you want your MFA components to be HA as well! For some reason, so many guides on the internet ignore or brush over HA very cavalierly. That is one thing I hope these two articles remediate.

Next to that, it has many details on every aspect of the deployment to make sure you get it up and running successfully and correctly.

Finally, I present you with a collection of troubleshooting information and tools to help you figure out where the problem is so you can find a way to fix it.

That’s it. I really think it can help many of you out there. I hope it does.

The Darwin award with MFA push notifications

Posted on by
Reply

Introduction

Recently in a talk with a pen tester I was demoing an end-user security risk that is relatively new on the scene. Apps that automatically confirm MFA push notifications. This effectively bypasses conscious user interaction and approval of any login attempt secured with a push notification. Hence the Darwin award with MFA push notifications phrase was born.

The Darwin award with MFA push notifications

Just when some security people worried more about the people with push notification suffering from security fatigue as being the biggest risk we go step further. Never mind people accepting any notification like Pavlov’s dog in a semi-unconscious, conditioned action. They have even grown tired of this an turn to MFA bypass apps to handle this for them.

The Darwin award with MFA push notifications
Yes, the Darwin award is only one approval away!

More then ever it seems that disabling any kind of self-service for device registration with MFA is key. On top of that, it is a sobering reminder that a strong password and conscious user actions are still very much key to providing security via MFA. I am not bashing DUO here. This was just the one I tested and it worked shockingly well.

Conclusion

I think for some people and organizations one or more FIDO2 keys will be the better option. Unless mobile device management can prevent people from installing auto-responder apps for push notifications you might have an issue. Or, they need to find a way to block such tools. Whatever I can come up with breaks the ease of use of push notifications but there are smarter and more knowledgeable people out there than me, so who know what they come up with. Microsoft Authenticator seems to have some capabilities to prevent this. I don’t know if you can enforce it 100% and if this cannot be bypassed in code as well.

Approve sign-in box on computer
You get a number challenge …
Approve sign-in box on device
… and you need to tap the correct number.

This, however, does nothing against conditioned responses of pushing a button or scanning a fingerprint on a FIDO2 key. So, remain vigilant. The sobering fact is that the adoption of MFA is disappointingly low. And no matter how many scary MFA bypass stories your read MFA is a key aspect of securing access today. It puts you far ahead of the curve. If done well and with well thought out procedures it is a formidable barrier for but the most determined attackers. Actually MFA bypass attacks are very rare still. Most of us are not that interesting targets but it can help keep out the majority of casual or professional thieves looking for quick wins on easy targets.