When in that location was a name alter in Active Directory (AD), we used to update the Universal Main Name (UPN) in AD, then separately run the Fix-MsolUserPrincipalName command to update Azure AD to the aforementioned UPN. Except, it no longer worked – I was at present getting an 'Access Denied' message.

When trying to update the UPN via the Microsoft 365 admin eye, it would correctly advise that the object was homed in Advert, so changes needed to be made there. Except, they were, and Azure AD Connect was even reporting that it had seen the update and sent it off to Azure Advertisement, no errors.

After some investigation, I institute that at that place is now an pick to allow 'Synchronize userPrincipalName updates' which is off in older tenants. To check and update this:

In PowerShell, first install and connect to MSOLService. Then to cheque the condition if UPN updates will sync and update:

              Get-MsolDirSyncFeatures -Feature SynchronizeUpnForManagedUsers

If it'south $truthful, yous're already set. If it'due south $false, update the value to $true with this command:

              Set-MsolDirSyncFeature -Feature SynchronizeUpnForManagedUsers -Enable $truthful

In my testing, running some other Azure AD Sync (both delta and total) did not resolve whatsoever already updated UPNs. I had to change the UPNs to a temporary value, sync, so change them back to the original value I wanted, and sync over again. The update was instant in Azure AD in one case the sync had run each time.

Was stumpted on this i and had to become advice from Microsoft Support.

A unmarried user couldn't log in via Multi-Cistron Authentication. SMS code would say it was sent, wouldn't come through. Phone telephone call also wouldn't come through. Trying to set up some other MFA method aka.ms/mfasetup would receive i of these errors:

You are blocked from performing this performance. Please contact your administrator for assist.

Nosotros're sorry, nosotros ran into a problem. Please select "Next to try again.

In that location were zilch search results for that first error word for discussion, which is never a proficient sign.

There's several areas you tin 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 whatsoever of those.

After logging a case, Microsoft Support advised to cheque hither:

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 cake future sign in attempts, as you'd hope. This too triggered an email alert to admins, and that link is where the user'south block is listed until released.

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

I've as well covered Provisional Admission before, and it'southward really hard to mistake the solution. There are at present Baseline policies deployed by default (nonetheless in preview though) to Azure Advertising tenants with recommended best practices:

Provisional Access Baseline Policies

One of these is for blocking legacy authentication – but I'g non going to recommend you lot turn this on (at least for starters, it's good at the end when you lot know you have total mod authentication back up), as information technology'southward a tenant broad setting that has no exceptions if you lot need to allow legacy hallmark for an account (unlike Require MFA for admins, which does allow exceptions).

Instead, you tin create your own policy that does the same. This means you tin gradually ringlet it out, and put exceptions in identify until you lot either work around them, or live with them. If you lot have a requirement for an account that requires legacy auth, and then you demand to consider how else y'all'll protect that account – can you lot use other Conditional Admission policies to restrict it to a certain region/locations, sure apps, platforms etc – lock information technology down as much as you can, and brand sure the account has a long unique countersign.

The single of import setting to block legacy auth via a Conditional Access Policy is blocking admission to 'Other clients' via Client apps:

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

And then, why is this amend than using Authentication Policies? 2 main reasons:

If an business relationship has their access or signin blocked due to an Authentication Policy, it'southward non logged. You can look at the user in Azure Advertizing and check the sign-ins, just you won't see annihilation. However, if it blocked via Conditional Access, you'll have a nice log entry showing you it was blocked:

Side annotation: 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 equally being in the US, so be careful with region blocking.

The other reason is that Authentication Policies can accept up to 4 (!) hours to apply, although it's oftentimes more like an 60 minutes. That is a long time to wait, and you but have to keep waiting and trying until information technology works – except if you did it wrong, you lot won't know and you'll keep waiting. Or, if you need to unblock access while rolling out, it'southward a long time to curlicue dorsum.

Authentication Policies do have their place though, they requite more than granular control over what you lot desire to block or non – say you know y'all want to block POP3 access visitor broad, but not IMAP – that'due south possible in at that place, but non via Conditional Access.

Unless yous have a skilful reason to utilize Authentication Policies, merely use Conditional Access (and bold y'all have Azure AD Premium P1 or P2 licensing to actually allow you apply Conditional Admission, and if yous are using Azure AD you should be on that licensing anyway). It'll make your life easier!

Office 365 Groups aren't that new, simply they all the same audio more attracting than a plain Distribution List or Shared Mailbox. They aren't the solution that applies to all situations however, and yous'll demand to counterbalance up each scenario as to what fits best.

(for Office 365 Group fundamental considerations, please read Michael Mardahl'southward blogpost "Getting off to a proficient start with Microsoft Office 365 Groups")

Here'southward some things around Office 365 Groups and using them as an electronic mail distribution listing (DL) that caught me out, or are differences worth pointing out. If you lot're thinking of migrating a DL or a shared mailbox to an O365 Group, these are worth because:

  • If a member of an Office 365 Grouping sends an email to the group, they won't go that email. It makes sense that you probably don't want an email that yous sent, but it is a change of behavior from traditional DLs. This may change in the time to come, at least as a toggle-able option.
  • If you have Commutation 2010, Office 365 Groups won't appear in the Outlook customer, unless their primary email address is @tenant.onmicrosoft.com – which probably isn't what y'all have as the default domain. Upgrading your Exchange to 2013 or newer should resolve this requirement. I blogged this one separately a while agone.
  • If you're in Exchange Hybrid mode and routing your emails to Commutation On-Premises first, Function 365 Groups won't be able to receive external emails UNLESS you enable group writeback in Azure Ad Connect. This feature requires Substitution 2013 or newer, and so isn't possible in Exchange 2010. If you are using dynamic O365 Groups, the group membership displayed on-bounds will be incorrect or blank.
  • An Office 365 Group mailbox can't take folders created in it. If staff take access to a shared mailbox and use that to manage their emails under different folders, that's a no-go for an Office 365 Group. There's a bunch of other ways you can manage this, simply if they specifically want that option, so an Office 365 Group won't assistance them.
  • By default, users will see a 'Groups' selection in Outlook (either client or web) which they can drop downwardly, see the groups they're in, and see the inbox. That's the only binder that's visible though, and information technology tin be like shooting fish in a barrel to assume that's the but folder. There are however, several folders available. Yous can't open an Office 365 Group equally another mailbox, equally you'll be told via Outlook Web that yous don't accept access to the mailbox, and Outlook client won't recognise the proper noun of the mailbox.
    You tin withal, utilize the 'Open Shared Mailbox' option in Outlook Web by right clicking on your mailbox in the binder view, or right clicking on 'Folders' (depending on if you're using the 'one-time' or 'new' Outlook) and add the Office 365 Group that way. This will requite you visibility of all folders and their contents:
  • Automating Office 365 Group membership is harder. You either automate membership with a dynamic group, or allow the owner(s) do it themselves. Neither are bad options, simply dynamic group membership exceptions to rules are harder to practice. How do you accept a group that's all Finance, plus these 4 people that aren't finance? You could take an expression like this, just that is something that could get rather messy to maintain:

(user.department -eq "Finance") -or (user.postal service -eq "[e-mail protected]") -or (user.mail -eq "[email protected]") -or (user.mail -eq "[email protected]") -or (user.mail -eq "[email protected]")

  • Meeting responses work differently to a DL. Say yous ship a meeting appointment, and have the respones go to a DL – all members of the DL see the response. This tin exist useful in sure scenarios, just probably not that mutual. An Office 365 Grouping works differently, where the 'Meeting Message Processing Agent' in Exchange Online volition see the meeting response, and send it direct to the Deleted Items folder. This action skips members receiving a copy of the response which might be proficient generally, but again it's another unlike style that Role 365 Groups piece of work when you're expecting the same every bit a DL.

That's what I've found so far – if you lot accept whatever yourself please share and I'll test/add to the listing, and will update with any other tricky scenarios that I come up across.

If you've gone downward the path of Azure Active Directory (Azure Advert), then I dare say you lot're not at the end. Information technology'due south a long but rewarding path, with new features constantly being added to enhance a critical service in the Microsoft offerings.

Information technology's also probable you lot didn't start with Mutli-Gene Authentication (MFA) in identify and set to go. Perhaps you did and well done! For the rest of us though, we slowly movement into these systems while turning more than options on.

Just enabling MFA with Conditional Admission is cracking, only getting all users to actually annals for MFA https://aka.ms/mfasetup tin can exist a challenge. If you're fortunate enough to have Azure Advertising Premium P2 licensing, you can apply a MFA registration policy to do a nicely managed rollout and forcefulness people on. Those without P2 however, have an selection that's a bit hidden, not as well known and slightly scary:

Require users to register when signing in?


Nether the question mark: Designates whether unregistered users are prompted to annals their own authentication information when they sign in for the starting time time. If set to "No," administrators must manually specify the necessary password reset hallmark 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 chip misleading, it actually ways that they'll be prompted the NEXT time they log in, rather than the first time.

This option is plant nether Azure Active Directory > Countersign reset > Registration, and is off past default.

Turning this option on is a company wide setting and from my testing, worked pretty much immediately. Every bit presently equally someone who hadn't signed upwards for MFA logged onto function.com, they were prompted to go through the MFA registration procedure. There'due south no fashion to point this at certain users or test it, you just have that i little switch to turn it on for every single business relationship 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 earlier this option is toggled, just at least it tin easily be turned off once more if yous run into whatever bug.

Update 2d May:

After publishing this, Sean Flahie on Twitter mentioned his experience if Azure Cocky-Service Countersign Reset (SSPR) wasn't enabled for users, and enabling the combined feel – both of which I have in place already. If y'all're having any issues then delight look into both of these.