Azure AD

Blocking Legacy Authentication – Conditional Access vs Authentication Policies

Posted on August 13, 2019October 20, 2020 by Adam Fowler

I’ve already written a post on why Legacy Authentication (Basic) is bad, and Modern Authentication is good. At the time of writing, Authentication Policies were the way to go to block Legacy Authentication methods. Of course, things change and there’s now a better* option to look at – Conditional Access.

I’ve also covered Conditional Access before, and it’s really hard to fault the solution. There are now Baseline policies deployed by default (still in preview though) to Azure AD tenants with recommended best practices:

One of these is for blocking legacy authentication – but I’m not going to recommend you turn this on (at least for starters, it’s good at the end when you know you have full modern authentication support), as it’s a tenant wide setting that has no exceptions if you need to allow legacy authentication for an account (unlike Require MFA for admins, which does allow exceptions).

Instead, you can create your own policy that does the same. This means you can gradually roll it out, and put exceptions in place until you either work around them, or live with them. If you have a requirement for an account that requires legacy auth, then you need to consider how else you’ll protect that account – can you use other Conditional Access policies to restrict it to a certain region/locations, certain apps, platforms etc – lock it down as much as you can, and make sure the account has a long unique password.

The single important setting to block legacy auth via a Conditional Access Policy is blocking access to ‘Other clients’ via Client apps:

Microsoft have a full guide on how to set this up on docs.microsoft.com.

So, why is this better than using Authentication Policies? Two main reasons:

If an account has their access or signin blocked due to an Authentication Policy, it’s not logged. You can look at the user in Azure AD and check the sign-ins, but you won’t see anything. However, if it blocked via Conditional Access, you’ll have a nice log entry showing you it was blocked:

Side note: Although in this example I was logging in from Australia, I was trying to connect to Exchange Online via PowerShell. That seems to often be detected as being in the US, so be careful with region blocking.

The other reason is that Authentication Policies can take up to 4 (!) hours to apply, although it’s often more like an hour. That is a long time to wait, and you just have to keep waiting and trying until it works – except if you did it wrong, you won’t know and you’ll keep waiting. Or, if you need to unblock access while rolling out, it’s a long time to roll back.

Authentication Policies do have their place though, they give more granular control over what you want to block or not – say you know you want to block POP3 access company wide, but not IMAP – that’s possible in there, but not via Conditional Access.

Unless you have a good reason to use Authentication Policies, just use Conditional Access (and assuming you have Azure AD Premium P1 or P2 licensing to actually let you use Conditional Access, and if you are using Azure AD you should be on that licensing anyway). It’ll make your life easier!

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

Posted on November 27, 2018November 27, 2018 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.

Users Managing Email Groups and Exchange Online

Posted on October 5, 2018October 5, 2018 by Adam Fowler

For a very long time, users have been able to manage email group members via the Outlook client. Going into the Address Book, finding the group in the Global Address list, going into Properties and choosing ‘Modify Members’:

From there, someone can add or remove members as long as they’d been added to the “Managed By” field against the object in Active Directory, as well as ticking the box “Manager can update membership list” below it.

Easy! Except, that no longer works if the user is in Exchange Online, and the Email Group is from on-premises AD rather than Azure AD/Office 365. It’s not supported. This problem has been around for a while, back in 2015 Perficent wrote about this same topic. The options given for managing these groups are:

Exchange Admin Center
Exchange Management Console
Exchange Management Shell

None of those are what you want your standard users touching in my opinion – although you can give someone access to the Exchange Admin Center and only see the distribution groups they own – but for me, I’m still on Exchange 2010 so this isn’t an option. This leaves you with a few options:

1. Change all your email groups to Cloud based groups. If this makes sense for you, doing this will let the manager of a cloud based group add/remove members via the Outlook Address Book.
You can also look at changing distribution groups over to Office 365 Groups (which are also cloud based), which give a whole bunch of different features beyond a what a distribution group can do, while giving the same standard DG experience.

2. Make all requests come through to IT so you can make the changes yourself. Not great for anyone involved, as it’s double/triple handling something where the user could quickly do it themselves.

3. Create Dynamic Distribution Groups and let automation do it’s thing – which will work for some, but exceptions to rules and the inability to see who’s in a group can make this frustrating for some.

4. Provide another way for staff to change group members themselves.

I’ve gone with option 4 – as I’m a big fan of Adaxes which I’ve written about a few times on my blog before, and they have a nice way of giving users a web interface that only lets staff manage the groups they’re the owner of.

There’s other ways to do this as well of course and other 3rd party solutions that can expose ways of adding/removing members of a on-premises distribution group – but remember there could be up to a half hour delay in syncing the change from AD to AAD via Azure AD Connect. If possible, look at adding a trigger at the end of a group change to do a delta sync:

Start-ADSyncSyncCycle -PolicyType Delta

That’ll be the quickest way to get the change up quickly, as staff may be used to the change working immediately.

There’s a lot to consider on how you’ll manage this, so make sure it’s sorted before you migrate – or expect a lot more tickets going through your helpdesk.

Conditional Access Stuck on “Loading…”

Posted on May 22, 2018 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!

Share this:

Share this:

Share this:

Share this:

Share this: