With Microsoft touting changes to personal Microsoft (MSA) accounts, allowing customers to go completely passwordless, it has brought heightened attention again to the world of passwordless for corporate customers in the Microsoft ecosystem.
While attending an October 13th Microsoft passwordless event, highlighting the future for the corporate world, I noticed a trend – organizations asking how to deal with password management and compliance policies they must adhere to. As Microsoft calls out, the long-term goal is for organizations to forget that passwords are even a thing.
However, being that directory services will still contain a password attribute, even if we aren’t using it, how do we keep it compliant with password policies. And how do we prevent end users opting to attempt to use their password. In this series we will dive into what the answer to these questions looks like.
One thing that is important to iterate in every conversation – the world is moving passwordless, and it’s not just Microsoft who is heading in this direction. If organizations do not want to (and should not be) trailing from a security perspective, you should start investigating what passwordless looks like for you now – as with most things these days it is a journey, albeit easier than many organizations may realize.
Killing Hybrid Identity Passwords with SCRIL
SCRIL, the acronym for Smart Card is Required for Interactive Logon, is a userAccountControl property flag in Active Directory, which any organization that is heavily invested in smart cards may be familiar with. For the rest of the world, this flag goes unnoticed, beyond being a checkbox you scroll past in ADUC.
In the Microsoft documentation on their Passwordless Strategy, Passwordless Strategy – Windows security | Microsoft Docs, they do a decent job covering what removing the ability to use passwords looks like in an organization, but they don’t really cover specifics on what the behavior looks like.
This is an area you’ll want to explore in parallel with modernizing your applications – for most organizations, the biggest hurdle with cloud and passwordless are with applications that don’t support modern authentication – I’m looking at you LDAP and RADIUS. For most customers in the passwordless journey, SCRIL is something you would be working towards, and there are steps for many organizations that need to happen prior to this point – if you haven’t read the strategy linked above, you should do so.
Diving into SCRIL
SCRIL, when enabled, directs Active Directory that the user account must use a form of asymmetric key-based (certificate) authentication in Active Directory. Because Windows Hello for Business (WHfB) is also certificate-based authentication, we can leverage the same flag.
When you enable SCRIL on a user account in Active Directory, the following happens for the user account:
- The users password is set to 128 bits of random data and next logon, and per Microsoft is likely to include non-typable characters
- The user is not asked to change their password anymore within Active Directory and Windows clients, even if it is expired
- Domain Controllers do not allow passwords for that user for interactive authentication
- The user has now lost knowledge of what their password is
Enabling SCRIL and it’s Results
Before we enable SCRIL, let’s examine a user account in AD. While SCRIL is a property flag on the userAccountControl attribute, it’s exposed to us in a much more accessible manner in Active Directory; it appears as a checkbox on user accounts in ADUC and ADAC, but for this article we will be looking at the account through the AD PowerShell module.
Let’s look at the user lee.gu in AD:
Get-Aduser -Identity <username> -Properties SmartcardLogonRequired,PasswordLastSet | select UserPrincipalName,SmartcardLogonRequired,PasswordLastSet
To enable SCRIL, we toggle on SmartCardLogonRequired, which adjusts the userAccountControl attribute for us:
Set-Aduser -Identity <username> -SmartcardLogonRequired $true
SCRIL is now enabled on the user account; one thing that might seem surprising is that the password on the user is not actually changed when enabled on the account, so let’s look at how this behaves.
The User Experience and AD Password Change
Now we have Lee attempt to log into his Windows 11 device with a password:
When attempting to sign-in, we are presented with the following message:
Let’s look at the account again in AD:
And we see that the time Lee attempted logon, his password was changed in AD.
Takeaway #1
Until the user attempts authentication against Active Directory, their password will not be changed within AD.
Takeaway #2
In our demonstration we show what happens if the user attempts to use their password. But if they are already enrolled in WHfB, it’s likely that they wouldn’t be trying to use their password for authentication.
Thankfully, it does not matter what method the user leverages for authentication – if Lee authenticated for that first time with WHfB after SCRIL was enabled on the account, the password would be updated in Active Directory regardless.
Dealing with Password Policies
Up to this point we have enabled the ability to have Active Directory manage the users password, but what about password policies? Complexity and history may be inherently covered, but what about if your organization is required to rotate passwords.
If your organization does not require password rotation, or if the rotation period is an extended length of time, you should enable a password expiration policy on your SCRIL users. Why? Because a password still exists for our users, and in non-interactive scenarios, if the password becomes known through some malicious vector, it’s leaving that account exposed. When we look at computer accounts and Group Managed Service Accounts (gMSA), those passwords are rotated behind the scenes by Active Directory; we need to think of our passwordless users as similar when SCRIL is enabled.
For organizations that are at an AD Domain Functional Level of Server 2016 or higher, there is an easy button for allowing AD to manage rolling of secrets for users.
If you are not at DFL 2016, this may be a point to prioritize upgrading so that you have this feature available to your organization, or else implement a scripted process to help roll them. Choosing not to roll your NTLM secrets is leaving the door open for lateral movement.
If we launch ADAC, which is the path of least resistance for this setting, we want to right-click on the root of the domain in the left pane and select Properties. We will be presented with the following view, and want to check the box for Enable rolling of expiring NTLM secrets during sign on, for users who are required to use Microsoft Passport or smart card for interactive sign on.
Select OK, and now whenever the users password is going to expire, based on the policy applied to them, a new random 128 bit password will be assigned to the users account.
As an example, let’s look at a FGPP in AD applied to this user account, with a maximum password age of 1 day:
And the results from a few days of user authentication:
Takeaway #3
Within Active Directory, we can apply password policies to our passwordless users, and be able to maintain compliance with rotation policies, all while still having a great user experience.
The Azure AD Side of the Story
Now that we have our user operating in a truly passwordless world in Active Directory, let’s turn our eyes to the other half of the equation – Azure AD.
Even though AD is managing the password, it’s still an attribute that is synchronized to Azure AD. Recall that Azure AD synchronizes passwords in a channel that is separate from the rest of the synchronization process, so password changes show up in Azure AD shortly after changing them in AD.
Let’s look at our test user:
Shortly after updating the users password in AD, the password change has synchronized to Azure AD.
Azure AD Password Change Mechanisms
If we have password writeback enabled in Azure AD Connect, there are methods still available for our users to change their password – falling into two scenarios:
- Password change when the user knows their existing password
- Password change when the user has forgotten their password
Password Change with Existing Password
Many times, when enabling password writeback, the focus is on enablement of Azure AD SSPR. However, under the MyAccount portal, users are also able to change their password if they know their existing password. This is already solved for us, as the user won’t know their password any longer, and therefore this option is already unusable.
Password Change without Existing Password (Azure AD SSPR)
This is the one area where we need to potentially adjust our Azure AD tenant settings. While many organizations may have moved towards enabling SSPR for all users in the tenant, we now have a need to disallow SSPR for users who have SCRIL enabled.
In Azure AD, Password reset, Properties, we can adjust the toggle to specify only users in a selected group are allowed to use SSPR; we would be disallowing SSPR for SCRIL users and wanting to ensure they are out of the scope for the group selected.
Takeaway #4
With a little bit of work on the SSPR side of things, we can easily accommodate SCRIL within Azure AD, without worry that users can subvert our efforts.
Final Notes
As with all things there are some caveats to going passwordless to this level for our end users. The most prominent is that our user has no way of falling back to a password. This is where this rolls into the bigger picture – allowing users to use the Authenticator App for passwordless, and allowing for FIDO2 security keys within the organization.
TAP, or Temporary Access Pass also can fill in some instances if a user has lost all passwordless methods to bootstrap themselves back into the world, but unfortunately it cannot be used currently for enrollment in Windows Hello for Business.
Lastly, to get to this point, you may need to start your journey of application modernization. Microsoft has some great documentation to get you started on the road to authentication migration with Migrate application authentication to Azure Active Directory.
3 Responses