Skip to content

Home

  • in MFA
  • 6 min read

Azure AD: You Should Disable This Legacy MFA Setting

When talking with organizations about securing their Azure AD tenants, there is always a focus on the latest and greatest, and all the ways it brings everyone forward on the Zero Trust journey. Advancements in Conditional Access, Windows Hello for Business, FIDO2 – the focus is on what’s new and where to go. Occasionally there is the reminder to block legacy authentication (speaking of – have you?), but the focus tends to be on what’s new, and not reviewing what’s old.

There is one setting, however, that tends to lurk deep within Azure AD tenants, especially for organizations that have had their tenant for a long while, that goes unnoticed, and when left enabled, allows users to potentially interfere with what we believe to be their authentication pattern.

What's the setting?

If we dig into the legacy multi-factor authentication service settings portal, which can be found by browsing to Azure AD -> Security -> MFA, and then on the right, under Configure, select Additional cloud-based MFA settings. It will bring you to the following:

Figure 1

The setting we are focused on is at the bottom. Under remember multi-factor authentication on trusted device, Allow users to remember multi-factor authentication on devices they trust.

Azure AD: Cross-tenant Access Settings Clarity

With the release of Azure AD cross-tenant access settings, I’ve noted some confusion among folks as to what it is, and as importantly, what it isn’t.

I’ll also be covering B2B Direct Connect, because even though it’s a separate feature, with release coinciding at the same time as cross-tenant access settings, I see it all being lumped “into the same” set of preview features.

The Microsoft Docs article on this is an excellent source of information, which can be found here, Cross-tenant access overview – Azure AD | Microsoft Docs. Along with that, we’ll dive into the background and use cases for this new suite of knobs and dials for our external identities.

Azure AD: The Arrival of Dynamic Administrative Units

Administrative units. The Azure AD sort-of equivalent of organizational units (OU’s). For those less familiar, administrative units (AU’s) allow for granular assignment of RBAC roles in Azure AD.

Organizations initially struggled with the limited ability to delegate granular RBAC roles in Azure AD, with the directories flat structure; especially for all of us coming from an Active Directory background. When administrative units were introduced, they started to open up the door for organizations that needed to delegate access to a subset of users in an Azure AD tenant.

The one catch with AU’s that was a non-starter for many organizations – they weren’t dynamic. And while OU’s are not dynamic in Active Directory, it’s a different take when the tenant is usually secondary to AD being authoritative. Move a user in AD, one would hope that the location in Azure AD would follow. While there are some PowerShell scripts out there that feel very akin to those used for AD shadow groups, overall maintenance of AU’s could prove cumbersome in dynamic organizations.

The struggle, however, is no more – administrative units now support dynamic user and device membership!

Windows Hello for Business: Hybrid Cloud Trust

When we talk about Windows Hello for Business (WHfB) rollout scenarios, the one that has consistently been the preferred path is Hybrid Key Trust. It is the lowest weight scenario for deployment requirements, and if you already had Active Directory Certificate Services (AD CS), it was only a matter of a few hours to configure your directory to be ready to start a rollout.

While there are some smaller niche limitations, the most common limitation that every organization will encounter with Hybrid Key Trust, is that initial Windows of needing to wait for Azure AD Connect to synchronize the msDS-KeyCredentialLink attribute from Azure AD to the user object in Active Directory.

This process is what informs Active Directory of the public side of the users WHfB key pair, and is what enables the user for certificate-based authentication, through WHfB, to AD. Historically this leaves many organizations needing to communicate to users that it will “take some time” between when they enroll and when they can first start using WHfB – not the greatest way to introduce users into a passwordless experience.

  • in MFA
  • 8 min read

Azure AD: Increasing Security Within The MFA Experience

MFA push notifications – one of the more polarizing MFA options available within Azure AD. From a usability perspective, the perception is that it’s less interruptive and less complex for end users. From a security perspective, it’s a low barrier of entry for a malicious actor; especially when targeting a user who may approve push notifications for MFA without much thought.

We have seen Microsoft implement various methods of interaction into push notifications to try and combat users just hitting Approve without a second thought. The Authenticator App for passwordless, sometimes referred to as phone sign-in, already has number matching implemented. But this never made it into our more common corporate MFA scenarios – until recently when additional options for the Authenticator App showed up in Public Preview.

After reviewing the details within enabling of number matching and additional context, the effort is a handful of minutes of work – organizations can categorize this one under the ‘low effort/high return’ security bucket.

Figure 1 Figure 2

Before and after