Microsoft

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

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.

Outlook Search Results Won’t Delete

I ran into this issue when migrating users to Exchange Online, while running Outlook 2016 MSI 32 bit.

Once a user is on Exchange Online, Outlook starts leveraging the power of FAST search. This search occurs on the Exchange Online end, rather than the device end, and is designed to give quicker results while being more reliable than Windows Desktop Search. There’s a great write-up on this on Microsoft’s TechCommunity that goes into much more detail.

It does depend what sort of search you do as to whether it’ll use FAST or Windows Desktop Search too, but the most basic of searches will use FAST. There’s also timeouts and speed checks that can force it to fail back to Windows Desktop Search.

However, there are some catches with this search from my testing. If you do an email search and decide to delete one of the emails in the results, it appears that nothing has happened. You can delete and delete, right click, press the delete key, click the X to delete and it all appears to do the same – nothing. In the background though, it has actually deleted your email, it just doesn’t display this in any way. It’s like the search results are a static result and won’t update on an action like this.

This behavior can be confusing for a user, especially when they’re used to seeing emails disappear and react when something’s done to them.

There’s another catch that depending on your environment, might be more of a deal breaker. If you use the category field, flag, or extra fields, for example when filing a document into a DMS system, those aren’t displayed or updated in a FAST search. If your users need this to effectively manage their emails, then it’s worth looking at just disabling FAST search via Outlook altogether.

As mentioned in the above post and this Technet article, there’s a single registry setting that can disable FAST search:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Search

Value name: DisableServerAssistedSearch

Value type: REG_DWORD

Value: 1

A restart of Outlook is needed after this change, and users won’t be alerted of anything different. Search will just start using Windows Desktop Search (which was always running anyway) and not know any better.

OneDrive for Business Rollout Considerations

If you’re managing OneDrive for Business in your organisation, there’s a lot to consider – more than what you’d think until you start looking into it. I’ve just gone through this, so thought it was a good time to document and share what I found with my recommendations.

There’s two major areas to review settings in:

admin.onedrive.com

You may not know this even exists as it’s still in preview, as OneDrive for Business fully functions without ever having to go here. The OneDrive admin center at https://admin.onedrive.com/ has some nice settings worth checking out. Some of the settings were already available in other areas, but this gives a central point to manage them.

Sharing: Under the Sharing section, there’s a few settings I’d recommend changing. The defaults are much more open – allowing users to create shareable links that don’t require a sign-in (which is really a bad idea when you’re sharing work information!), as well as the default link type being ‘Shareable: Anyone with the link’.

I’d recommend having the default ‘Direct: Specific people’ when sharing a link, and restricting the ability to have anonymous shareable links at all. This way ensures that data only gets shared to the people the end user chooses, and nobody else.

Sync: ‘Allow syncing only on PCs joined to specific domains’ is off by default, and you’ll need to look up your domain’s GUID to enter it in. This is good for data leakage, do you really want someone’s home PC automatically downloading all work data? This won’t block them from accessing OneDrive information at all as it’s available via web and Android/iOS apps, but none of those solutions automatically sync content. You can also block Mac OS if you don’t manage any in your company.

There’s also the option of blocking syncing of specific file types – I can’t think of a particular reason for this though. OneDrive already has AV built into it, as does your PC with Windows Defender, AND you should have Applocker in place to block running unwanted executables… but it’s still worth noting the option.

Storage: The default ‘Days to retain files in OneDrive once a user account has marked for deletion’ might be missing a word, but it’s default value is 30. You can go all the way up to 3650, which is 10 years minus a few days for leap years. I don’t have to worry about this data or pay extra for it, so I’d rather have it retained just in case.

There’s also another option where on departure, the manager based on the AD/AAD field of the departing user will be granted access to their OneDrive, which is a nice automated way of having someone check the contents in case anything needs to be saved out. That setting lives in the SharePoint Admin center, fully described in the above link.

Device Access: Worth noting that you can restrict access from certain IP addresses, but in the real world I don’t see many companies doing this unless you really want to keep your OneDrive data internal.

If you’re in a position to disable this other option though, removing the ‘Allow access from apps that don’t use modern authentication’ is good security wise, and ties into my other post Protect Your Office 365 Accounts By Disabling Basic Authentication.

There are other options in the OneDrive for Business Admin Center, but nothing I personally considered changing.

Group Policy

This is probably where you’ve already started. Make sure you’ve deployed the latest ADMX files, and review all the settings. Here’s the key ones I’d recommend looking at, some are computer based and some user:

Enable OneDrive Files On-Demand: This makes just the stubs of files download to the OneDrive client, then download the full file when requested. There might be some pushback on not having instant access to a file when wanted, but when you tie this into Known Folder Redirection (below) and have users that move around a lot, this should save bandwidth and disk space across your fleet. I have this one enabled.

Prevent users from using the remote file fetch feature to access files on the computer: I’d definitely have this one off as it lets users access the entire contents of any PC they’re signed into (where their account also has access to the local files of course), remotely. It could easily lead to data leakage when you’re opening up such a big door.

Delay updating OneDrive.exe until the second release wave: If OneDrive becomes important to your users (which it should, yet again with Known Folder Redirection), then you probably want to avoid getting a new release that has a bug. Sit back and wait for the second release wave to make sure you’re getting a more stable update each time. Enabled with maybe a few users having this Disabled for piloting/testing.

Prevent users from synchronizing personal OneDrive accounts: I enabled this one, as with the above settings I’ve already allowed a method that users can get and work on the files they want from anywhere. I can also monitor this and produce logs if required. Someone’s personal OneDrive I have no visiblity or control over, and there’s really no need to allow this.

Silently move Windows known folders to OneDrive: Once you’re ready and fully deployed with OneDrive, this is the next great feature to check out. It deserves it’s own blog post later, but you can silently configure the user’s Desktop, Documents and Pictures folders to live in OneDrive, rather than the local PC. This lets users access the same data wherever they log into, with the extra benefit of doing it in the background after the user logs in – no login delays. It’s like having an important part of roaming profiles, without the headaches. More info here: https://docs.microsoft.com/en-us/onedrive/redirect-known-folders

If you’d originally disabled OneDrive via GPO through the policy Prevent the usage of OneDrive for file storage then just disabling that policy should be enough, as long as you still have OneDriveSetup.exe running at login via the Run registry hive against the user. If you removed that, you may have to add it back in.

I found this method to be useful – to create the value HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Run – Reg_SZ value type OneDriveSetup with value data C:\Windows\SysWOW64\OneDriveSetup.exe /thfirstsetup – but only applying this if the OneDrive registry value didn’t exist. OneDriveSetup should remove itself if successfully run, and will also create OneDrive meaning the setup key won’t get put back again.

If you see what a new user gets the first time they log in assuming no OneDrive cleanup has happened, is the exact same OneDriveSetup key as above. In my testing, having other switches against OneDriveSetup caused issues.

Access An Exchange Online Mailbox Without a License

This is just a quick one. Most Office 365 admins will hopefully have a separate admin account to perform higher level tasks, compared to their normal user account.

Because of this, the admin accounts shouldn’t need any licensing, because they’re not being used like a normal user. One person shouldn’t need to have two sets of licenses – but there are some problems that can come up because of this.

For example, if you want to use your admin account to access someone’s mailbox, that can be difficult when you don’t have a mailbox yourself to log onto, to then open another user’s mailbox. Outlook can be used to work around this, where you set up a profile for the email address of the user you want to access, but enter your admin credentials when prompted:

Your Name is just a display name field, email address needs to be the user’s email. Don’t enter a password here and click ‘Next’
This login page will start by showing the user’s email address, use the option ‘Sign in with another account’ and use your admin account.

The above works OK, but is a little time consuming if you’re accessing a mailbox for a quick check.

If you try to go to Outlook Online, you’ll get a message saying your admin account doesn’t have a license or a mailbox. To get around this, you’ll need to use a URL like:

https://outlook.office.com/owa/user@mydomain.com/?offline=disabled

so it jumps straight to that user’s mailbox, assuming you have access rights to it, and have waited a few minutes for the rights to apply.

Using the URL method is really quick way of accessing another user’s mailbox without needing a license yourself.