Azure Active Directory

Microsoft DOESN’T admit expiring-password rules are useless

Posted on by Adam Fowler

Update 5th August 2019: Another great blog post from Alex Weinert at Microsoft on real world data from Azure AD, common password attacks and where passwords do and don’t matter: Your Pa$$word doesn’t matter

Update 6th June 2019: The final version of the Security Baseline has been released by Microsoft, and explains the password recommendations very clearly. Here’s one paragraph quoted, bold is my emphasis, but please go and read the whole article:

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.

Original blogpost:

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.

Exchange Online Migration Clears ‘Recent’ Document Lists from Word and Excel

Posted on by Adam Fowler

I struggle to fit these issues into a short but descriptive headline sometimes :)

This issue is a little strange. If you didn’t know any better (like me), you’d expect the location of a user’s mailbox to have no impact whatsoever on the function of ‘Recent’ document history inside of Microsoft Excel and Word, but it actually does.

I found this out the hard way of course, when a couple of staff mentioned their recent lists had disappeared and it co-coincided with their Exchange on-prem to Exchange online migration.

After some digging, I came across this Reddit post: 
Users losing Recent Documents lists in Office 2016 due to upgrade to ADFS. It’s the same problem with a slightly different root cause, and goes into a much deeper technical explanation than what I’ll do here.

The short of it is that the Office applications detect what sort of login you’re using – if it’s Active Directory (AD) or Azure Active Directory (AAD). When that state changes, it uses a different registry path for a few things, including those recent documents.

Without knowing for sure but based on my testing, it must be doing some check to see if the associated account’s mailbox is in Exchange Online or not – and if not, it considers it an AD account. It doesn’t matter if you already have the users in Azure AD, Single Sign on and all that other good stuff set up – the single change of changing the mailbox location to online triggered the change for me.

For an AD account, the history paths are saved in the registry here:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Word\User MRU\AD_1234567890 (the number on the end is some sort of unique GUID).

For an Exch account, it’s in this slightly different path:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Word\User MRU\ADAL_1234567890 (again, unique GUID at the end).

In case you were wondering, MRU stands for ‘Most Recently Used’. AD is to do with on-prem Active Directory, and ADAL is (according to that reddit post) Azure Active Directory Authentication Library.

Also note the example above is for Word, there’s corresponding paths for other Office applications such as Excel.

There’s two subkeys below this key, one for File MRU and the other Place MRU.

The good news on hitting this scenario is that the values can just be exported, the path changed and re-imported. To do this, via regedit find the registry key that has the values you want (probably the AD one) and right click > export.

Find the file you exported and use notepad to do a find and replace on all the entires for AD_1234567890 and replace to the new value (which you can find from just looking in the registry).

Now, re-import the registry file and you’ll have all the recent document paths restored.

This should only be a one time problem for migrations, and only for people who had a bunch of document paths saved in there and can’t find where they are easily.

Conditional Access Makes MFA Migration Easier

Posted on by Adam Fowler

Microsoft Azure’s Conditional Access is a really great way to get a company using Multi-Factor Authentication. The old argument of not wanting MFA to get in the way of logins constantly goes away with this solution, because it lets you set the rules and scenarios where MFA will and won’t trigger.

To be more accurate, the access controls that Conditional Access can use lets you use more than just MFA to log in (username/password/token style). You can set the rules so a trusted device negates the need for MFA.

This isn’t new anymore either. Here’s a video from Microsoft back in March 2017 talking about how all this works:

What this means is that someone with a username and password on a device that is either InTune enrolled, or set up for Azure AD Hybrid is trustworthy enough. Of course this is less secure than asking for MFA every time, but do you really need to do that when someone is using their work laptop?

Another condition to choose from is ‘Locations’. You can decide that MFA won’t kick in if the login is coming from inside your corporate network. You can also target different applications with different rules that stack – so maybe the payroll system will always ask for MFA, but a less sensitive one will only ask when not on a managed device.

Security wise, there’s also a ‘Sign-in Risk‘ option where each authentication attempt is evaluated and given a risk ranking, and access can be granted or blocked based on the results. Note that this one needs Azure AD Premium P2 which isn’t part of the Microsoft 365 E3 subscription – E5 or separate licensing is required.

Because Conditional Access works like a bunch of Outlook rules, you can slowly build up and adjust what kicks in when. It’s really easy to do, and there’s really no excuse (once you have licensing!) to stop you setting it up ready to demo to staff. 

Combine Conditional Access with Azure AD App Proxy where you can externalise any internal web based app, while forcing auth on it and you’ve got an easy way of enabling workers to do their jobs remotely, while being happy about the security around it – and NOT just poking a hole in a firewall, exposing your IIS box to the world.

Conditional Access Stuck on “Loading…”

Posted on by Adam Fowler

There’s currently an issue with configuring Conditional Access via Azure Active Directory. There’s an open ticket with Microsoft Support, with no ETA at the time of writing.

The issue:  When trying to configure a new policy for Conditional Access against an Azure Active Directory application, the ‘New’ page gets stuck loading. I’ve tested this on multiple browsers, tenants, internet connections, computers, and had Microsoft support confirm.

The path to doing this is from the Azure portal – Azure Active Directory > Enterprise Applications > choose your application > Conditional Access > New policy:

The Workaround: Thankfully it’s not a showstopper, as there’s another way to get to Conditional Access and it works fine. Instead of going via a specific app first, you can just go via Azure Active Directory > Conditional Access > New policy. Also Azure Active Directory > Enterprise Applications > Conditional Access > New policy works, it’s just an extra click to the same screen.

Points to take note of – if something’s broken, try accessing the same function from a different route of click-through links and it might work another way. Also, log these issues with Microsoft Support as overall the support is pretty good and often the issue won’t be anything to do with you. Test different scenarios wherever possible too, and also asking the question on Twitter can get some extra attention!