Skip to content

2022

World Password Day

Forget passwords. Passwords are garbage. To celebrate World Password Day, I’m curating blog articles that can help organizations on their passwordless journey.

While much of the Microsoft documentation on passwordless is quite good, it can tend to be overwhelming at times; the hope is to give you some great leads on some clear, step-by-step instructions on how to get you from a password-filled to a passwordless world in Active Directory and Azure AD.

With each link, I’ve provided a rough time estimate for how long the process should take, given a dedicated effort. There may always be the fringe case or two where passwordless is more complex – if your existing environment has things such as AD FS and using smartcards, or has DC’s older than 2016, you have a bunch of Macs in your environment, as examples. It always helps to review the documentation, which I also link to.

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.