Climbing the Auth Ladder in Azure AD: Rung 0
[Editors note: I see this turning into much more than a blog post, or a blog post series, but I’m not sure what yet. Until I figure that part out, I am publishing this here on my blog as part 1 of a series.
Please consider this a beta version with a Request for Comment. Let me know what you think. I look forward to including the community input in whatever the end-state version of this turns out to be]
On a recent Friday morning my friend and colleague Joe Stocker (@ITGuySoCal) posted a picture (below) of a slide showing Office 365 identity best practices on Twitter. That tweet got me thinking about doing what turned into this blog post series, “Climbing the Auth Ladder in Azure AD”
Azure Active Directory (AAD) has a lot of options for controlling authentication into Azure and Office 365 resources. Maybe it’s to the point where AAD Auth has too many knobs and switches you can twittle around. To paraphrase Douglas Adams –
Auth is big. You just won't believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it's a long way down the road to the chemist's, but that's just peanuts to auth.
On the other hand, maybe that’s me being dramatic. We can handle this! Let’s climb the auth ladder!
In this series of blog posts I’m going to walk you through the steps up the “auth ladder” for Azure Active Directory. I am going to show you the steps you can take, adding on additional features and functionality, to get your organization up to the proper level of authentication security. Some features I cover will require additional licensing, so they may or may not be available to you in your tenant.
Rung 0: username/password
This is not even really a rung, it’s the ground. This is where you put the ladder before you can start to climb it. I would be tempted to leave this off, but the thing is your ladder must be placed on a good patch of ground or things are likely to go very wrong for you, right? Same thing here.
If you have even logged on to a computer, you have used a username and password. If you have not, how are you reading this? The reason to put this rung on the list is because I think many organizations can do username/passwords better. Rung 0 also servers as a nice starting point.
Want a super boring read? How about NIST Special Publication 800-63B Digital Identity Guidelines. If you can manage that slog, you probably still won’t really know what a good password policy looks like because man that is some boring stuff.
Password policy recommendations have changed over time, and current recommendations may not be what you would expect. There really is not a single end all definitive best practice password policy, but here is what I recommend (based on those NIST recommendations).
Longer is better – Think passphrase not password. Tell your end-users that “MyPasswordIsReallyLong,Innit?” is much more secure than “P@ssw0rd”. Also, passphrases mean you can have a unique phase for each service. Can you remember where to use “OpenO365SaysMyDogSpot” and “OpenNetflixSaysMyDogSpot”? I bet you can.
Don’t bother changing it – People are lazy! I’m lazy, you’re lazy, everyone is as lazy as we can be. Turns out your organization is going to be more secure if you allow end-users to have good long passphrases and keep them. When you force users to change passwords every 30 days, they come up with ways to use bad passwords (or write them down on a sitcky under the keyboard). If you allow them to come up with a long unique passphrase, they are less likely to end up compromised.
We can’t handle complexity – Forcing users to have really complex passwords just leads to a lot of password reset requests and easy-to-guess passwords.
Show me the password – Password fields that just show ******* are more likely to push users to use passwords that are easier to guess. Having an option to remove that visibility block will encourage users to use better passphrases.
Clues blues – “What was the name of your first pet?” or worse yet “What is your mother’s maiden name?” These knowledge base authentication clues are way to easy to beat in a world with social media and ubiquitous data collection.
Limited attempts – Account lock out after 10 failed attempts seems to be the sweet spot. 3 log in attempts is not enough for users having a bad day, but more than 10 is inviting a brute force hack.
MFA – We will talk about this more later. Rung 1 anyone?
Short version: design your password policy around long passphrases that end-users will remember and keep unique. I do think it is important to stress unique because if your end-users use the same password for all their services, then the security of your organization depends on the security of Facebook and Twitter (or any other much less secure place you users create a password).
The onus is on IT managers to make sure the organization has policies in place to properly educate end-users about password security. If your organization does not have a good end-user education policy in place, then your CIO is not doing her job.
Self-service password reset
Resetting user passwords is expensive. I can link to studies that say how expensive, but the real numbers would depend very much on the specific organization and the specific people within that organization that need their passwords reset. Instead of worrying how expense password resets are, let’s just agree they are expensive, and we want to avoid them.
Azure AD does include a Self-Service Password Reset (SSPR) functionality, and most organizations should consider enabling this feature. Before users can reset or change their Azure AD password using SSPR, they must register themselves and the authentication methods to use. I will talk more about this process when I get to setting up multi-factor authentication, as they are the same setup.
Password Hash Synchronization
Password Hash Synchronization (PHS) is a feature of Azure Active Directory Connect that will users to use their on-premises Active Directory password for authentication into Azure AD. I have covered the security of PHS in another blog post linked HERE.
What I didn’t really cover in that blog post is that PHS does improve the security of your Azure AD authentication.
Even if your organization is not using PHS because your tenant, or specific users, is/are set for authentication via AD FS, pass through authentication, or text authentication (please don’t use text authentication expect for very limited use cases), having PHS enabled means your organization can take advantage of Smart Lockout, IP Lockout, and Microsoft Leaked Credentials Service.
Smart Lockout is always on for all tenants using PHS.
Smart Lockout locks user accounts from sing-in attempts for one minute after 10 failed attempts to help prevent brute force attacks.
In short, when PHS is enabled Microsoft will search leaked credentials for you and let you know if they find specific username/password combinations. There are specific compliance sets that require organizations to investigate leaked credentials and this feature outsources that work to Microsoft for you.
Custom banned password lists
Azure AD supports tenants configuring custom banned password lists at all licensing levels. Azure AD has a built-in banned password list too that you cannot configure. That list includes the most used and easy to hack passwords, but no public list of that those globally banned passwords are in available.
In addition to that global banned password list, tenant admins can add a custom banned password list. This list should include organization specific passwords such as the following examples:
Brand names
Product names
Locations, such as company headquarters
Company-specific internal terms
Abbreviations that have specific company meaning
Admin accounts
This blog post (and the series as a whole) is about authentication, not authorization. That means I am focusing on the logging in part, not the “what you can do with that account after you have logged in”. That puts the distinction between admin and user account out of scope for this series. I am not going to talk about RBAC, least privileged accounts, or other authorization topics. That being said, I think admin accounts are important enough to warrant some mention here at Rung 0.
My view is that IT pros should have separate admin account, and not use a Global Admin account for day-to-day work. Features like Privileged Identity Management can add some grey area to my recommendation there.
In some cases, it may be appropriate for an admin to have those rights available to her primary account via PIM. Some security focused experts will argue that even if you are using PIM you should have separate admin accounts. My feeling is that decision should be based on your IT staff’s overall competence, and the sensitivity of the data that is accessible by those admin accounts.
For our purposes here, I will say be cognizant of your admin accounts and the privileges they have. By the time you are done with your climbing the auth ladder exercise, you will probably end up with some accounts higher on that ladder than others. I would expect in most organizations, admin accounts will be on the highest rung within your tenant.
Recommendations for Rung 0
Here are my recommendations for how to handle auth at the Rung 0 level of our metaphorical Azure AD auth ladder:
Usernames are set to UPN (user@domain.com)
Use long passphrases instead of complicated password
Do not force password changes
Enable SSPR
Enable PHS if users have on-premises AD accounts
Train your users!
6 simple steps, and you are ready to step onto the auth ladder with me.