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.
I found that if SSPR is not enabled for ALL or if users aren't added to the scoped SSPR group, they do not get prompted for registration. This new combined experience is now in v2 of Preview called "enhanced". https://t.co/ntcVBdFxpb
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.
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?
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.
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:
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.
Worth reading the entire thread, but it turns out unknowing cleaners seem to have cause a lot of outages!
I’ll let the responses speak for themselves:
I had a WinNT cluster that held elections every Thursday night. We stayed late two weeks in a row: no elections. Skipped a week: elections. One Thursday we came back after a drink… and watched the cleaner carefully unplug the server and dust the power bar.
Early in my career I was sent to solve the mystery of a small remote site going down every weeknight about the same time. Dutifully I sat in a small office watching a comms cabinet till 6:30pm when a cleaner walked in and attempted to unplug the cabinet to power his vacuum!
The Network goes down every saturday at almost the same time and after 15 minutes it worked again. After months of troubleshooting… it turned out that the Cleaning Service used the socket of the network cabinet to plug in the vacuum cleaner…
Worked for for a communication company and offices in a region kept losing network connectivity then a couple minutes later would come back up. Found an engineer “cleaning fiber connections” in the MDF unplugging them one at a time.
I’d be hoping these incidents happened a while ago, but in reality it’s a good demonstration of how things can happen that you really didn’t plan for. It’s also a good argument for having your important gear in a secure room!
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.
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.
