Passwords

Force Multi-Factor Authentication Registration in Azure Active Directory

If you’ve gone down the path of Azure Active Directory (Azure AD), then I dare say you’re not at the end. It’s a long but rewarding path, with new features constantly being added to enhance a critical service in the Microsoft offerings.

It’s also likely you didn’t start with Mutli-Factor Authentication (MFA) in place and ready to go. Maybe you did and well done! For the rest of us though, we slowly move into these systems while turning more options on.

Just enabling MFA with Conditional Access is great, but getting all users to actually register for MFA https://aka.ms/mfasetup can be a challenge. If you’re fortunate enough to have Azure AD Premium P2 licensing, you can use a MFA registration policy to do a nicely managed rollout and force people on. Those without P2 however, have an option that’s a bit hidden, not as well known and slightly scary:

Require users to register when signing in?


Under the question mark: Designates whether unregistered users are prompted to register their own authentication information when they sign in for the first time. If set to “No,” administrators must manually specify the necessary password reset authentication information in the properties for each user in this directory, or instruct users to go to the registration portal URL directly.

The description for this option is a bit misleading, it actually means that they’ll be prompted the NEXT time they log in, rather than the first time.

This option is found under Azure Active Directory > Password reset > Registration, and is off by default.

Turning this option on is a company wide setting and from my testing, worked pretty much immediately. As soon as someone who hadn’t signed up for MFA logged onto office.com, they were prompted to go through the MFA registration process. There’s no way to point this at certain users or test it, you just have that one little switch to turn it on for every single account in your tenant.

For someone who had signed up for MFA, they were asked to confirm the details entered previously.

I’d recommend letting your staff know before this option is toggled, but at least it can easily be turned off again if you run into any issues.

Update 2nd May:

After publishing this, Sean Flahie on Twitter mentioned his experience if Azure Self-Service Password Reset (SSPR) wasn’t enabled for users, and enabling the combined experience – both of which I have in place already. If you’re having any issues then please look into both of these.

Microsoft DOESN’T admit expiring-password rules are useless

CNET has an article titled “Microsoft admits expiring-password rules are useless” which I strongly disagree with, and thought it was worth explaining why.

Beyond the actual blog post from Aaron Margosis at Microsoft not actually containing the word ‘useless’, it’s an inaccurate summary of what is a well written and clear write-up from where I sit.

This all came out of publishing the draft of the Security Baseline recommendations for Windows 10 1903, which details out what settings Microsoft recommend and why. If you’re managing a Windows environment, these are a must read, and should be reviewed with each version of Windows 10 you plan to move to.

The general take of the CNET article was that password changes have been useless for years, suggests Microsoft should completely ‘yank’ the ability to force passwords to expire, and if your IT staff don’t remove password expiry immediately, they’re living in a ‘security Stone Age’. It’s rather insulting and coming from someone in my opinion, who doesn’t know what they’re talking about. They might say the same about me, of course :)

On the other hand, Microsoft’s blog post tells a different story. Yes, passwords are problematic and forcing them to change frequently causes other issues where people just change the number on the end by ‘1’, but they aren’t saying password changes are useless.

Microsoft used to recommend 90 day expiries, then to 60 days. The idea there was that if a credential is leaked somehow, the smaller window that the password is known by third parties, the better. But, if your password M0nkey34! is now M0nkey35!, that’s probably going to be the first thing a targeted attacker tries if the password they had for you didn’t work.

Although all this is true, it works on the assumption that someone is actively targeting you. It happens, but it’s much more common for attackers to just do spray attacks based on millions of credentials they have. Why are they going to pick your account and try a bunch of combinations of passwords, when they could just go through stupid amounts of records with no effort and find weaknesses there?

Say you are a target for some reason; it’s likely that the password leaked from somewhere isn’t new – it’s probably months or years old. If you’d never changed your password because your company never forced it to change, then the attacker now has a valid password for you.

It’s also much more likely your password was stolen from a 3rd party service, nothing to do with your corporate systems. You might have signed up with your work email address, but the password ‘should’ be unique to the service signed up for. We all know users don’t work that way, and use the same password all over the place. Having a password they know will change frequently, may mean that they use something at least unique, even if it does increment.

All of this is moot of course, if you have multi-factor authentication (MFA) in place, because the requirement of something else (a phone, bio-metrics etc) means a username and password by themselves are actually useless. However, most companies do have systems in place that have no options around MFA, so what do they do?

To re-iterate, I agree with everything said in Microsoft’s blog post. This is where one paragraph in the blog post sums it up nicely:

Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don’t believe it’s worthwhile for our baseline to enforce any specific value. By removing it from our baseline rather than recommending a particular value or no expiration, organizations can choose whatever best suits their perceived needs without contradicting our guidance. At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines.

Work out your risks, your userbase, what systems might be impacted, what extra protection you have in place and make an informed decision around what frequency works for you.

The focus shouldn’t be on password changes, but should be on implementing those other protections in all scenarios – but before that happens (which for many companies can easily take several years), you’ll need to work out what policy you do. There is no single best-fit recommendation on what that is when using pure passwords, because they’re inherently bad however you look at them.

Look at Conditional Access, Password Protection and Azure AD Identity Protection for starters on adding in these extra protections!

The answer isn’t a pure ‘password changes are useless’, and it’s irresponsible to say so.

Protect Your Office 365 Accounts By Disabling Basic Authentication

This had been on my to-do list for a little while since I heard about it (mostly from Daniel Streefkerk who quite rightly has been drawing attention to this via Twitter, thanks!)– and it should be on yours too.

By default, Basic Authentication is allowed as an authentication method in Exchange Online. This is because that’s the ‘standard’ way things have worked for a very long time – you want to get your emails, you provide a username and password and you’re done.

In our modern world, that doesn’t work too well anymore. It’s too risky in that many ways, and things like 2FA and Conditional Access add an extra layer of security when logging in. That’s great, but many systems weren’t built or haven’t been updated to support this – they’ll just fail when logging in.

What this leaves us with, is an internet exposed authentication system that accepts username and password logins without any other layers of authentication, even if you have 2FA and conditional access turned on.

As per Microsoft’s documentation around disabling basic authentication covers, this lets attackers use brute force or spray attacks to try different credentials to get into your tenant. With the amount of leaks we see these days (register on Troy Hunt’s https://haveibeenpwned.com/ if you haven’t already), it’s likely attackers are hitting Microsoft servers with correct accounts of your staff members. If they manage to get the right password – which is very possible if people end up using an old password they used years ago, or password changes were disabled because you thought you were covered with 2FA – they now have valid credentials to get in and pretend to be that staff member, often to then send emails to all their contacts with a malicious link or some other scam.

If you want to see what’s going on for your tenant, go to the Azure portal and into Azure Active Directory > Monitoring – Sign-ins. Set the Status to ‘failure’ and apply, and see what’s there.

Here’s an example, where you can see the client app is ‘Other clients, IMAP’. This account is disabled, and if you look in the device info there’s no data.

Once you have a look here, you might start to get worried – so it’s time to see if you can disable basic auth!

Only certain email clients will work without basic auth, so your first step is to work out what people are using, and get approval to force the usage of only these:

  • Outlook 2013 or later (Outlook 2013 requires a registry key change)
  • Outlook 2016 for Mac or later
  • Outlook for iOS and Android
  • Mail for iOS 11.3.1 or later

That can be a tough ask, and you’ll need to weigh up the risk of leaving basic authentication in place (to me this is an easy choice, but can still be difficult to get approved and implement).

Again, the Microsoft documentation explains how to do this quite easily – create a new Authentication Profile which has Basic Auth disabled by default, and apply it to test users:

New-AuthenticationPolicy -Name “Block Basic Auth”

Set-User -Identity testuser@yourdomain.com -AuthenticationPolicy “Block Basic Auth”

Set-User -Identity testuser@yourdomain.com -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

That’s all you need to do to test. The third command forces an immediate refresh on the test user.

I would recommend leaving this in place for a while, and get as many test users on as possible as you might find certain systems using basic authentication that you weren’t aware of.

If you need to drop the policy off of a user, use this command:

Set-User -Identity testuser@yourdomain.com -AuthenticationPolicy $null

If you’re then ready to apply this policy to all accounts company wide, these three commands will do it:

$users = Get-User -ResultSize unlimited
$usersid = $users.MicrosoftOnlineServicesID
$usersid | foreach {Set-User -Identity $_ -AuthenticationPolicy “Block Basic Auth”}

You’ll also want any new accounts to get your new policy by default, which can be done with this command:

Set-OrganizationConfig -DefaultAuthenticationPolicy “Block Basic Auth”

And with that, you’ll have all existing and future accounts protected from the risks of leaving Basic Auth enabled. Of course if you have a special requirement where a few accounts do need Basic Auth, create another policy, enable basic auth on it, and apply it to those accounts. Your attack surface will still be greatly decreased, and hopefully you’ll eventually be able to disable basic auth on those too.

Note: There’s also an option for OneDrive for Business around this same setting, more details here: https://www.adamfowlerit.com/2019/03/onedrive-for-business-rollout-considerations/

Update 26th April 2019:

There’s also now a Conditional Access option that supports ‘other clients’ –
“This includes older office clients, other mail protocols(POP, IMAP, SMTP, etc), and ACS”. This might help you if you either want to block those older clients, or allow them through in certain circumstances:

Why Haven’t You Deployed LAPS Yet?

LAPS – Local Administrator Password Solution is an official Microsoft solution for doing exactly what it’s called – managing local administrator passwords on the computers you manage (both desktops and servers).

The solution is fairly simple – have a tiny client rolled out on each PC, that gets told by Group Policy to generate a random password. The local admin account gets set to that password, and Active Directory also gets told what that password is. That changes on a 30 day cycle

The end result is that anyone who obtains local admin access through that account, can’t access anything beyond that single computer – and, that’s only for 30 days maximum before it gets changed. Even if the computer is taken off the domain, your Active Directory will have a record against the computer of what the last set password was.

There’s a great overview, demo, and install files available from TechNet with Jessica Payne going into great detail on how it all works and showing you exactly what to do which I highly recommend after watching it personally.

As she says, it only takes 10 minutes or so to set up, and it’s that much more secure than using Group Policy to set everyone’s local administrator account to the same password (which by the way, doesn’t securely save the password in the Group Policy anyway) and running into issues when someone needs the local administrator password for one reason or another.

Oh, there is a tiny AD schema update, but it’s a single command and nothing to worry about :)

Once you’ve got LAPS set up, you use the LAPS UI program to view passwords:

Chris Brown has also written up a nice ‘how-to’ guide on setting up LAPS from end to end which is worth following too.

LAPS is easy to deploy, easy to manage and provides several security benefits… and it’s free. If you’re not using LAPS yet, it’s time to do it! Grab it from Microsoft here.

My Solution to Online Password Management

Hello,
Today’s blogpost is about password management. I have (what I think) is a good solution that means you’ll only need to remember a few small details for all your online passwords.

An entirely unexciting topic for most – including myself. You’ve all heard and possibly uttered phrases such as ‘the longer the password the better’ and ‘use complicated passwords’ which are of course true. Here’s a blurb taken from Intel’s Supplier Password rules via https://supplier.intel.com/Auth/PasswordRules.asp :

In order to protect your security, Intel has certain rules for choosing passwords. Please read the following rules so that you will know how to choose a good password.
The following rules apply to all passwords:

  • The password must be at least 8 characters long.
  • The password must contain at least:
    • one alpha character [a-zA-Z];
    • one numeric character [0-9];
    • one special character from this set:
      ` ! @ $ % ^ & * ( ) – _ = + [ ] ; : ‘ ” , < . > / ?
  • The password must not:
    • contain spaces;
    • begin with an exclamation [!] or a question mark [?];
    • contain your login ID.
  • The first 3 characters cannot be the same.
  • The sequence of the first 3 characters cannot be in your login ID.
  • The first 8 characters cannot be the same as in your previous password.
  • Passwords are treated as case sensitive.

*yawn* Please don’t give up on this post yet, I do have a point to make! Now, the next commonly quoted rule is ‘never usethe same password on multiple sites’. So, how do you remember the wacky combination? XKCD has half the answer:

Via http://xkcd.com/936/

Great for a single password, but again how do we manage 100’s? Many people use databases such as KeePass, or notepad files inside encrypted zip files with another password on top. Cumbersome in my opinion, you don’t want to have to go checking for passwords each time you log in somewhere. There’s also other solutions that save the websites, usernames and passwords in a centralised location – a big risk in itself I say. So, here’s my two layer solution:

1) Have your own email domain, and use a different email address for every single site you sign up to. On top of that, make the email address something that always identifies with the site.

For example, I could buy the domain passwordssuck.com, set up Google Apps with it, and have a catch all. This means I can tell people I like an email address like “adam.fowler@passwordssuck.com” but also if I were to sign up for Blogger, I could use “blogger@passwordssuck.com”.

Why do this? The first reason is spam. If you sign up to a site that gets compromised, or sells off email addresses, the most likely impact to you is getting a bunch of spam. If you no longer use the site, you can blacklist the email address you signed up with (in this example, blogger@passwordssuck.com) and you’ll never see spam on that address again. If you still use the site, you’ll have to either live with the spam that gets by any spamfilters, or change your email address. I don’t like the idea of changing it, because for this overall formula (coming up!) to work, you just want to look at a site and immediately know what the login is.

The second reason – again if the site gets compromised, is that your email address and password combination are now useless anywhere else. Even if you used the same password anywhere, the email address to log in is a one off.

2) The password part. You need a formula. Once you remember the formula, you don’t need to remember anything else.

You can adjust this how you like, but I’ll give an idea of a decent formula (and no, this isn’t exactly what I use!). First, come up with two words. Let’s go with ‘keyboard’ and ‘mouse’. Now, let’s use some special characters. Now we have ‘K3yboard’ and ‘mou5e’ – these will never change.

Between our two words, let’s go back to the site we’re on. Blogger.com. What I’ll do is take the first and last letter of the domain. B and R. We’re going to put this in between our two chosen words. ‘K3yboardBRmou5e’ – but let’s get even trickier! Instead of B and R, we’ll go up two letters in the alphabet. B goes to D, and R goes to T.

Now we have ‘K3yboardRTmou5e’ as our final password. This means, when I go to blogger.com and think ‘hmm what’s my username/password’ it’s going to be “blogger@passwordssuck.com” and password “‘K3yboardRTmou5e'”.

Youtube.com? That’d be “youtube@passwordssuck.com” and “‘K3yboardAGmou5e'”

If someone obtained your credentials for Youtube, there’s no way these details will work anywhere else. If someone targets you specifically for some reason, they’re still going to need to know your formula. They have no idea which parts of your password are static, and which change, and even if they thought the AG was the bit that changed, they then need to work out what that means.

In summary, once you remember your formula, that’s the last thing you’ll need to remember. You don’t have to go down the full path of having a different email address for each site, but I’d put a bit more work into varying your password formula.

If you have any feedback on the above, or think it’s a terrible idea for any reason please let me know!