I've been using passwordless authentication in Microsoft 365 and Azure since it was first announced years ago (2? 3? Does time even work the same way any more?), and I've dragged a bunch of coworkers and peers along with me. Because we don't have an Active Directory domain behind our cloud accounts, I'd never had to wonder how to secure on-prem accounts against brute-force password attacks. Well it turns out there's a way, and it's part of Microsoft's published best practices for securing hybrid identity, and it's been in Active Directory for 20 years (give or take because what even is time now??). I'm talking about the SCRIL bit. Smart Card Required for Interactive Logon. Did you know it had a cool name? Have you ever called it the 'SCRIL bit'? You should: you'll sound awesome at identity & access management parties.
The SCRIL bit does something pretty cool in Active Directory: it makes a regular user account behave like a managed service account in that it allows Active Directory to roll the password on the account daily with enormous random values. This doesn't eliminate the password attribute, but since you can't just go around invalidating the AD schema for one user at a time, it renders the password attribute's value irrelevant. The user doesn't know it, and even a full SAM dump won't compromise it. The net result to using it is that the user can't manage an interactive logon without presenting a physical token. This can have some very interesting implications if the user NEEDS interactive logon and you don't provide them a token: they're not going to be very successful, but we'll come back to that.
Azure AD supports passwordless authentication options natively. The attribute continues to exist, and there may be some legacy workloads where it still gets requested, but 99% of the time I'm able to authenticate with a user account and an approval. I manage mine through the Authenticator App, but I could also use FIDO2 security keys or even text messages if that suits a business requirement (in most cases it won't).
And passwordless in Azure AD even supports temporary access passes for newly-created accounts, so the new user never even has an opportunity to set a password.
But Azure AD also supports password synchronization with AD, and this is where things get a bit tricky. We can do password hash sync (PHS), pass-through authentication (PTA), and password writeback with Azure AD Connect. We're not talking about ADFS here because that's no longer recommended by Microsoft. You probably knew that already, but you might not know that AAD Connect synchronizes passwords every 2 minutes, while PTA and writeback both use service queues in the cloud to stage requests that are retrieved and processed by on-prem components.
So what happens to a replicated account that has the SCRIL bit set on-prem, but is still using a password in the cloud? You'd think the user in the cloud would have some crazy random value imposed on their account and that password writeback would panic and the user would be forced to go home early. But fortunately somebody thought of that scenario, and while AD does perform the reset and timestamps it in the logs, AAD Connect does not detect or transmit the metadata and allows the cloud identity to keep on rollin.'
But the good news is that, since you're in the process of rolling out passwordless to your cloud users anyway, they probably won't ever need to worry about what happens to the password when you flip the SCRIL bit, and now you know a cool new term.
Would you like to find out more about Azure Active Directory? Learn how you can deploy Azure Active Directory today.
Comments