User Can’t Receive MFA Requests for Azure AD / Microsoft 365

Was stumpted on this one and had to get advice from Microsoft Support.

A single user couldn’t log in via Multi-Factor Authentication. SMS code would say it was sent, wouldn’t come through. Phone call also wouldn’t come through. Trying to set up another MFA method aka.ms/mfasetup would receive one of these errors:

You are blocked from performing this operation. Please contact your administrator for help.

We’re sorry, we ran into a problem. Please select “Next to try again.

There were zero search results for that first error word for word, which is never a good sign.

There’s several areas you can check for blocked users such as:

https://protection.office.com/restrictedusers

https://protection.office.com/threatincidents

https://portal.azure.com/#blade/Microsoft_AAD_IAM/SecurityMenuBlade/RiskyUsers

But I couldn’t find the user listed in any of those.

After logging a case, Microsoft Support advised to check here:

https://aad.portal.azure.com/#blade/Microsoft_AAD_IAM/MultifactorAuthenticationMenuBlade/BlockedUsers/fromProviders/

And of course, that’s where the user was listed. They’d had some suspicious activity (a MFA phone call they didn’t initiate) so chose the option to block future sign in attempts, as you’d hope. This also triggered an email alert to admins, and that link is where the user’s block is listed until released.

Azure AD Password Protection Setup Summary

Microsoft have a nice way of preventing the use of bad passwords. Yes, all passwords are bad, but some are worse than others :)

Azure Active Directory Password Protection is a service that looks at password changes and blocks passwords it deems as weak. This could be from checking it’s an easy password to break using a dictionary attack, or other easily guessable variants. It leverages Microsoft online services to do so, which requires some setup and agents installed on the on-premises environment.

Microsoft’s documentation for this is detailed and fairly easy to follow, but I thought I’d do a quick rundown.

Installing the agents:

  • There are two agents – the ‘Azure AD Password Protection DC agent’ and the ‘Azure AD Password Protection proxy service’. Both can be downloaded here.
  • The ‘Azure AD Password Protection proxy service’ needs to be installed on all Domain Controllers (DCs), but the ‘Azure AD Password Protection proxy service’ only needs to be installed somewhere once. You CAN install it on a Domain Controller, and you can install it on ALL Domain Controllers, but Microsoft highlighted this as a potential security risk allowing any DC internet access. At least two installs of this is recommended for redundancy.
  • The ‘Azure AD Password Protection proxy service’ can’t be installed alongside (on the same server) as ‘Azure AD App Proxy Service’ – which is probably the same utility server you’d think of putting this on.
  • After installing the ‘Azure AD Password Protection proxy service’ you’ll need to run a few PowerShell commands to register it with global admin rights – you don’t need to create a service account for this, it’s just a one time registration process.

    The commands are:

    Register-AzureADPasswordProtectionProxy -AccountUpn ‘yourglobaladmin@yourtenant.onmicrosoft.com’
    (run this on each install)

    Register-AzureADPasswordProtectionForest -AccountUpn ‘yourglobaladmin@yourtenant.onmicrosoft.com’
    (run this after the first install only)
  • Installing the ‘Azure AD Password Protection DC agent’ is easier again, but will need a reboot of the DC to start working.
  • Both clients automatically update themselves.

Configuring in Azure Active Directory

  • You’ll need to enable on-premises Azure Active Directory Password Protection on the Azure AD portal – that link should take you right to ‘Password Protection’ but it’s located under Azure Active Directory > Security > Authentication methods > Password protection.
  • Start with ‘Audit mode’ rather than ‘Enforced Mode’ so you can get an idea of how many users might get affected by this change, and allow you to communicate this out before forcing.
  • You can also add custom banned passwords which might include your company name and common terms in your business and industry, to ensure easily guessed passwords aren’t used.

There are other catches to this, like making sure your domain is using DFSR rather than FRSR so please go through the official documenation carfeully.

Once set up, you can either read through the logs on a DC, or run this PowerShell command on each DC to see the results.:

Get-AzureADPasswordProtectionSummaryReport

You’ll need to either wait for users to change their passwords, or do some yourself and work out which DC the changes were done against. These stats will give you an idea of how many ‘failures’ were audited, so you can decide how much of a user impact enforcing the policy will be.

You could of course ship these event viewer logs to a central repository, but the service should just do it’s thing and just block users from setting a new password that’s really bad.

Migrating from a Synology 8 bay NAS to a 6 bay NAS

I currently have a Diskstation 1813+ 8 bay NAS which is doing a great job, but since Synology gave me a 1618+ to review, and the 1813+ is 7 years old, I’m migrating over to that instead. The catch is that I have 7 drives already in the 1813+ in a single SHR setup. How do I get that across to the newer 6 bay NAS? This is actually a writeup of the planned migration, rather than the success at the end… and the goal is to reduce costs. I could just buy 6 new 10TB drives and have an easy migration!

Yes, I’ve lied in bed at night thinking about this and the best approach. I have 40TB of space, ~30TB in use in a SHR setup:

If I had somewhere to just copy 30TB of data to temporarily, it’d be easy. Copy the data off, move 6 of the drives, create a new SHR, copy the data back and done. Except, I don’t have 30TB of space anywhere.

It isn’t possible to take a disk out of the SHR setup (i.e. shrining the volume size and somehow telling it to abandon one of the disks), so I can’t get a disk that way. I can however, take one disk out and break it’s redundancy while moving data. Risky, but that could give me at least the 12TB disk to use as temporary space. That’s a start.

It’s unavoidable, I’ll need to buy some more disks for temp space. I can get two external 10TB Seagate HDD for $283AU each and use those as temporary space along with the 12TB disk. That’ll get me my 30TB to copy everything off while I juggle the rest of the disks.

That leaves me with 2x 10TB and 4x6TB in the old SHR setup. There is a limitation of SHR which is worth understanding:

For SHR: The capacity of the drive you intend to add must be equal to or larger than the largest drive in the storage pool, or equal to any of the drives in the storage pool.
Example: If an SHR storage pool is composed of three drives (2 TB, 1.5 TB, and 1 TB), we recommend that the newly-added drive should be at least 2 TB for a better capacity usage. You can consider adding 1.5 TB and 1 TB drives, but please note that some capacity of the 2 TB drive will remain unused.

https://www.synology.com/en-au/knowledgebase/DSM/help/DSM/StorageManager/storage_pool_expand_add_disk

What that means is, if I take the very slow approach of building up a SHR with just the two 10TB disks, then look to add more disks after, I can’t add a 6TB disk.

However, I can move all 6 remaining disks across and create a new SHR giving me a bit over 30TB:

Once that’s done, I can then copy all the data off the temporary 2x10TB and 1x12TB disks to the new Synology DiskStation 1618+. Great, except I want to use all four 6TB disks elsewhere and the end result would leave me with 4x10TB, 1x12TB and 1x6TB. I can’t remove the last 6TB disk without having an equal or bigger disk to replace it with, and I don’t want to but a third 10TB disk at this stage.

What I can do is set up the SHR being 1 disk short, leave out the last 6TB disk so I have 2x10TB and 3x6TB, which will give 28TB of space. Enough that I can then copy the contents of any two of the three temporary stoage disks (2x10TB and 1x12TB), and as they get cleared, add them to the SHR.

Each time I add a disk to the SHR it might take a day or two though – this process will take a while. I’ve got multiple points of failure (original SHR has no redundancy, single temporary storage disks all have no redundancy). I can only change one disk at a time.

Once I’m at 4x10TB and 1x6TB in the new SHR, I’ll have enough room to copy the 12TB of data off the spare disk, onto the SHR, then swap out the 6TB for the 12TB.

I also need to make sure for my own neatness, that the 6th bay doens’t have a drive in it at any time. Drives can’t be physically moved around in a SHR, so I don’t want to have 5 drives in a 6 bay NAS and have a ‘gap’ in the middle where there isn’t a drive. Not a dealbreaker on the move, but still :)

In summary:

  • Buy 2x10TB drives
  • Copy 20TB of the 30TB to the two drives I bought
  • Remove 1x12TB drive from SHR in the 1813+ NAS and break redundancy.
  • Copy remaining data to the 12TB drive mounted somewhere else.
  • Move 2x10TB and 3x6TB into the new 1618+NAS and create a SHR.
  • Copy the data off the 2x10TB drives to the new SHR.
  • Swap out one 6TB drive for a 10TB drive and repair the array.
  • Swap out the other 10TB drive for another 6TB drive in the array.
  • Copy the data on the 12TB disk onto the SHR.
  • Swap in the 12TB drive with the final 6TB drive.
  • All 6TB drives can go back in the 1813+ for other purposes

I think that’s my plan. I’ll update this post once I’m at the end of it (currently awaiting the arrival of the 2x10TB drives). Can you poke any holes in my plan?

Set Microsoft Edge as Default Browser One Time

The New Microsoft Edge browser is great and everyone should use it :) Especially if you’re still on Internet Explorer, you can make Edge use IE mode for the sites you have that still require IE, without having to actually use IE.

I had a scenario where I wanted Internet Explorer users to be changed to Microsoft Edge. Previously, we’d had business requirements to set IE as the default – but now that’s no longer required, I wanted to flip their default. At the same time, I didn’t want to change Google Chrome default browser users as they’d already made that choice, and didn’t want to shove a similar Chromium browser down their throats.

As per Microsoft’s doco https://docs.microsoft.com/en-us/deployedge/edge-default-browser you can use an XML file with default associations, and use Group Policy to point to that XML. It doesn’t stop users from changing the associations, but it does reset the associations each time the user logs in – so not ideal if you want to set a default, but also allow flexibility.

I worked out how to do this based on current default browser and using GPO still, so here’s what I did:

As per the doco above, create an XML file that sets Microsoft Edge as the default application for certain protocols:

<?xml version="1.0" encoding="UTF-8"?>
<DefaultAssociations> 
  <Association ApplicationName="Microsoft Edge" ProgId="MSEdgeHTM" Identifier=".html"/>
  <Association ApplicationName="Microsoft Edge" ProgId="MSEdgeHTM" Identifier=".htm"/>
  <Association ApplicationName="Microsoft Edge" ProgId="MSEdgeHTM" Identifier="http"/>
  <Association ApplicationName="Microsoft Edge" ProgId="MSEdgeHTM" Identifier="https"/>  
  <Association ApplicationName="Microsoft Edge" ProgId="MSEdgePDF" Identifier=".pdf"/>
</DefaultAssociations>

Note that .PDF is included, so if you’d rather not default .PDF files to Microsoft Edge, remove that line from the code.

The Group Policy in the doco to set this XML is called Set a default associations configuration file – and all it’s doing is populating a registry key. Instead of using the Group Policy setting, create a registry setting to apply a value to:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System
DefaultAssociationsConfiguration - REG_SZ - Path to XML e.g. \\dfs\share\defaultapplication.xml

The Group Policy registry setting will look like this:

We only want this registry setting to apply when the default browser is IE, and not apply any other time. We can use two options to do this – Remove this item when it is no longer applied, and Item-level targeting:

“Remove this item when it is no longer applied” will remove the registry setting when the item-level targeting condition is no longer true, which will stop the default browser applying again and again once the default browser isn’t IE.

“Item-level Targeting” is where we’ll check another registry value to see if IE is the default browser.

This is checking the registry key path Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice

and the Value name ProgId

and the Value Data IE.HTTP

Only when all this is true, will the XML reg key apply. Next time someone logs on, the default program associations file will be read and apply the new browser default. Then, next time Group Policy evaluates, the registry setting will be out of scope and removed, so the default program assocations file registry setting will be removed.

For reference, Chrome will be the value ChromeHTML and Edge will be MSEdgeHTM.

This method worked quite well and gave me what I was after – a one time change from Internet Explorer to Microsoft Edge, without bothering Chrome and Firefox users.

Note that this will also keep kicking in if the user changes their browser default back to Internet Explorer, which might be what you want – but if not, you’d need to add another Item-level target using a flag file or registry setting to mark that the default browser has already been applied once.