Azure AD

5 Things To Check In Your Intune for Windows 11 Configuration

After receiving a lot of great feedback on my post 5 Things To Check In Your Microsoft 365 Tenant, I thought I’d do another post, picking my top 5 items from the Center for Internet Security’s (CIS) benchmark Microsoft Intune for Windows 11 Benchmark v3.0.1

This is a really big list to pick from, much bigger than the Microsoft 365 one – the document is over 1000 pages! Also you may look at this list and say ‘What has this got to do with Intune, I can apply these settings to any Windows 11 PC?’ – This is true, but the options CIS has laid out are ones that are natively available in Intune and therefore easily deployable. I’m also going to spend more time explaining the meaning behind the setting rather than telling you how to do it, as the CIS documentation (again freely avaialable for non-commerical use) clearly explains the setting and how to configure it.

Again these 5 things are important and I’ve tried to pick items that aren’t in the secure state by default, so I hope you find something new (or at least reassured!).

1. Ensure ‘Turn off access to the Store’ is set to ‘Enabled’

By default, any Windows 11 PC has the Microsoft Store enabled, the app installed, and a user can use it to obtain any software available in the store. I’ll avoid the whole ‘are Microsoft Store apps safe’ as I’m not privy to Microsoft’s application monitoring regime, just like Google’s Google Play or Apple’s App Store – but just like blocking users from installing software from other sources and methods, the Microsoft Store should be controlled in a corporate environment. There’s an entire history behind the Microsoft Store for Business and Microsoft Store for Education which is being replaced by packaging the apps in Intune for Microsoft Store which is still a work in progress with original retirement planned for 2023 being postponed.

All this leads to this one setting, which is just preventing the user being prompted the Windows Store as an option to find a program to open a file or protocol that currently has no association (for example, a user found a data.db file and tries to open it). They’ll see this dialog:

Either enable the confusingly named Intune setting ‘Turn off access to the Store’ (due to it only doing the below, which it describes in the details of the setting) or use this registry setting to remove the Microsoft Store option for any ‘open with’ dialog – Turn off access to the Store (admx.help)

Simple, but it ticks the box of a user complaining that they just followed what the computer told them to do when they end up with some wacky or weird solution obtained from the Microsoft Store that they start entering company data into. It also ties into a bigger piece around how you handle the Microsoft Store as a whole. I also found this blog post which goes into great detail about the Microsoft Store and how to control it, including the above setting: Restricting or blocking access to the Microsoft Store (call4cloud.nl)

2. Ensure ‘Backup Directory’ is set to ‘Backup the password to Azure AD only’

LAPS (Local Administrator Password Solution) is an incredibly important solution to prevent lateral movement between devices. At the high level, it is designed to automatically manage the local administrator password on each device, and make it unique. This means if someone was able to obtain the password on a single device, they can’t then use that same account against every other device in an organisation. More details: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview (and back in 2017 I was going on about it too https://www.adamfowlerit.com/2017/02/havent-deployed-laps-yet/)

Up until October 2023, this was only an on-premises natively supported solution; but now Intune supports it too. If you haven’t looked into LAPS or didn’t realise you could now do it in a cloud only environment, then put it at the top of your list.

Assuming you are now living with LAPS, the option Backup Directory controls where the LAPS password for each device goes. Apart from the default disabled option, this can either be ‘Backup the password to Active Directory only’ or ‘Backup the password to Azure AD only’ (yes I know it’s now Entra ID, nobody’s updated this name yet).

If you’re cloud only (Entra ID Joined) or cloud first, then this option should be ‘Backup the password to Azure AD only’ – your Entra ID should be more secure than your Active Directory, and this decision should really be a part of whatever system you’re putting first. It’s also a bit neater to view/report on events where any account is looking at the LAPS password value of a device in Entra ID, compared to on-premises Active Directory where you may have many different AD domain controllers and hopefully good monitoring/reporting of events across the entire environment – but more room for error there.

Creating a policy for this is quite a simple process from the Microsoft Intune Admin Center:

3. Ensure ‘Allow Cross Device Clipboard’ is set to ‘Block’

I am a huge fan of Clipboard in Windows and use it many times every single day. If you aren’t aware of this feature, press Winkey + V on your keyboard and it’ll pop up, asking if you want to enable it. It keeps a history of your clipboard contents – whatever you Ctrl + X or right click > copy. This is really handy when you’re copying all the time, but want to paste/recall anything beyond the absolute last thing you copied. It supports both text and pictures. Of course, this means it will copy things like passwords and other data you probably don’t want floating around. One feature of Clipboard in Windows is the ability to enable ‘Clipboard history across your devices’ which sounds somewhat handy, but drastically increases the risk of data leakage when you’re syncing that information to your account (if a work account, then should sit securely in your M365 tenant/Entra ID) or Microsoft consumer account. It’s just an unnecessary risk for little benefit – the clipboard history should stay local and be cleared on logoff/reboot. It will purely sit in memory and be lost afterwards when Clipboard sync is disabled.

Please start or keep using Clipboard in Windows but turn off Clipboard sync. It’s enabled by default.

Here’s the registry setting: Allow Clipboard synchronization across devices (admx.help)

4. Ensure ‘Notify Unsafe App’ is set to ‘Enabled’

Another setting disabled by default. Instead of explaining, I’ll just quote directly from the Group Policy setting:

This policy setting determines whether Enhanced Phishing Protection in Microsoft Defender SmartScreen warns your users if they type their work or school passwords in Notepad, Winword, or M365 Office apps like OneNote, Word, Excel, etc.

If you enable this policy setting, Enhanced Phishing Protection in Microsoft Defender SmartScreen warns your users if they store their password in text editor apps.

If you disable or don’t configure this policy setting, Enhanced Phishing Protection in Microsoft Defender SmartScreen will not warn users if they store their password in text editor apps.

This one sounds pretty reasonable right? If a user types their password into a program being monitored by Enhanced Phishing Protection, it’ll pop up and tell you:

Note that with my testing, this doesn’t apply to Microsoft Edge, nor does it apply if you paste your password, it has to be typed – but still a pretty good user reminder on something they shouldn’t be doing!

Interestingly I couldn’t find the registry value on GetADMX but the ‘Notify Unsafe App’ setting is available in Group Policy, and in Intune – create a Settings catalog policy, and use the settings listed under the category SmartScreen > Enhanced Phishing Protection: Notify Unsafe App. Further information here: https://learn.microsoft.com/en-us/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/enhanced-phishing-protection?tabs=intune

Also worth calling out checking out the other Enhanced Phishing Protection settings at the same time: Automatic Data Collection, Service Enabled, Notify Malicious. Notify Password Reuse.

5. Ensure ‘Turn off toast notifications on the lock screen (User)’ is set to ‘Enabled’

This final one is pretty obvious. When a PC is locked, you don’t want notifications popping up that may contain sensitive information and be visible by anyone that can see the screen. This is a feature that I don’t think should even exist… but it does and it’s on by default. You want to enable the setting to disable the feature (yes this is a dig at the inconsistent state of settings and enabling/disabling!).

Easily done via Turn off toast notifications on the lock screen (admx.help) or enable the Turn off toast notifications on the lock screen via Intune via a Configuration Profile. A full guide is available here: Disable Toast Notifications From Lock Screen Using Intune HTMD Blog (anoopcnair.com)


That’s it for the list – as always I hope you found it interesting and love hearing any feedback (including constructive criticism), and hope it helps people out there to always be thinking security.

Azure AD Cross-Tenant Synchronization is now in Public Preview

For a long time, the methods of having two Azure AD tenants aware of each other’s users needed to be managed in either a manual, or scripted way; accessing the data of another tenant or using their configured Apps would require each user to enrol to the other tenant and be given default guest permissions; or an admin at the destination tenant would need to set things up, send invites out, or do something else creative to make the user experience better.

I was on board Azure AD B2B in the early days; as a Microsoft MVP I had the privilege of speaking to a product manager for it that one time I went to Redmond, talking about my use case and seeing if I was ‘doing it right’. A combination of Azure AD B2B and Azure App Proxy I’d set up for guest accounts to get into an internally hosted web based application, and it worked quite well. I had my own script going through a many step process to send out an invite to the user, add the user to multiple groups and whatever other trickery I needed at the time.

Cross-tenant synchronization however, takes a lot of that pain away. You can set up a trust between two Azure AD tenants (which can be a one way sync) to allow users in Tenant A to be automatically created and managed in Tenant B as a guest user. This is great for organisations who have to frequently work with another org – and even though it’s early days for cross-tenant sync, there’s some rather good controls already. You aren’t limited to a single relationship either; I can’t see any documented limits.

Attribute Mapping allows you to configure extra rules around the attributes that get passed on, allowing you to manipulate, add or remove certain attributes (you might want to remove an employee number from employeeid, or add an extra attribute to define what tenant they were synced from; or do something that will in turn match a dynamic security group rule to automatically add your synced users to be allowed to access an application.

I’d often step through how to set this up in one of these articles, but the documentation is already detailed with step-by-step screenshots and clear instructions. It worked exactly as described when I set this up between two test tenants I have, and took about 15 minutes beginning to end, which included reading the documentation a few times to make sure I was following it correctly. It’s also possible to do via Graph API, but I did not try this method.

There’s even detailed sync logs, troubleshooting tips, and detailed reporting.

One question I’ve seen multiple people already ask is how does this relate to the Global Address List (GAL) and People Search – which the documentation claims this isn’t on by default, but easy to enable. In my testing however, the accounts showed up in the GAL with the little ‘blue person in front of world’ symbol with no extra configuration. They didn’t turn up instantly and I waited overnight, then they were there. People Search was the same. If you want to investigate this for yourself, check out the showInAddressList attribute. Other documentation also says guest objects aren’t in the GAL by default too:

and here’s the instructions on how to “Add guests to the global address list“.

As always, be aware that this is Public Preview so has less guarantees than a fully launched feature. If you have any feedback or want to see what others might be saying/asking, check out the official feedback for Azure Active Directory.

Edit 10/02/2023

Worth mentioning licensing.

As per What is a cross-tenant synchronization in Azure Active Directory? (preview) – Microsoft Entra | Microsoft Learn:

In the source tenant: Using this feature requires Azure AD Premium P1 licenses. Each user who is synchronized with cross-tenant synchronization must have a P1 license in their home/source tenant. To find the right license for your requirements, see Compare generally available features of Azure AD.

In the target tenant: Cross-tenant sync relies on the Azure AD External Identities billing model. To understand the external identities licensing model, see MAU billing model for Azure AD External Identities

The MAU billing section:

In your Azure AD tenant, guest user collaboration usage is billed based on the count of unique guest users with authentication activity within a calendar month. This model replaces the 1:5 ratio billing model, which allowed up to five guest users for each Azure AD Premium license in your tenant. When your tenant is linked to a subscription and you use External Identities features to collaborate with guest users, you’ll be automatically billed using the MAU-based billing model.

Your first 50,000 MAUs per month are free for both Premium P1 and Premium P2 features. To determine the total number of MAUs, we combine MAUs from all your tenants (both Azure AD and Azure AD B2C) that are linked to the same subscription.

The pricing tier that applies to your guest users is based on the highest pricing tier assigned to your Azure AD tenant. For more information, see Azure Active Directory External Identities Pricing.

Then from Pricing – Active Directory External Identities | Microsoft Azure:

Each synced user needs an Azure AD Premium P1 or P2 license in their home tenant.

Each tenant receiving synced users has the Azure AD External Identities billing model which used to be a 1:5 model, but is now 50k users free, the rest a small charge per active user.

Does a synced account count as an active user? Unsure, I would guess it’s a ‘probably not’ since there’s no active login for just existing as a guest in another tenant, but verify that for yourself with your licensing reseller.

Azure AD Connect v2 – Upgrade Now

Dirsync, Azure AD Sync, Azure AD Connect, and now Azure AD Connect v2. The second version of Azure AD Connect is important because it’s not an automatic upgrade, and has some different requirements.

Microsoft’s documentation Introduction to Azure AD Connect V2.0 covers this off well, and you can do an in-place upgrade, but read that link first. Microsoft are recommending you upgrade to this now, as mentioned in the article.

If you’re not sure what version of Azure AD Connect you’re on, you can log onto your server running the agent, bring up apps and features, and select Microsoft Azure AD Connect. Here I’ve got v1.6.4.0:

You can download the latest version from https://www.microsoft.com/en-us/download/details.aspx?id=47594

You may find that TLS1.2 isn’t enabled on your server – for me, it wasn’t enabled by default on Windows Server 2019. The registry keys and PowerShell script to change them is available here: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-tls-enforcement

If you try to install without doing this, you’ll have to exit, then run Azure AD Connect which will be ready to upgrade – don’t try to re-run the MSI you downloaded.

The upgrade itself is fairly unexciting, which is what we want when making changes in production that allow the entire organisation to authenticate:

You’ll need to use Azure AD Administrator credentials as a part of the install.

Once done, you can go back to Apps & features to see the new version:

Also it’s worth checking Synchronization Service Manager to make sure it’s syncing without error. All you need to do is open the program which is installed as a part of Azure AD Connect, and see the status and times. If there’s an error, it’ll tell you.

That’s it, you’ll be up and running on Azure AD Connect v2, with auto updates happening again to keep you continually updated.

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.

Windows Hello for Business – A less forceful rollout option

How to roll out Windows Hello for Business as optional

To roll out Windows Hello for Business optionally:

  1. In Group Policy, enable the ‘Use Windows Hello for Business’ policy
  2. Tick the option ‘Do not start Windows Hello provisioning after sign-in’
  3. Users will then need to click the Windows Security icon to register

Applies To : Windows 10


When I first looked at Windows Hello for Business at launch, I was impressed by it but also concerned. Turning the option on would prompt all users or devices that had the policy on, strongly encouraging them to go through the Windows Hello for Business setup with their fingerprint/face recognition and PIN.

To roll out Windows Hello for Business, follow Microsoft’s documentation which is quite detailed due to the complexities of scenarios and requirements; such as Single-Sign On, MFA of some sort and Public Key Infrastructure.

It was a bit intrusive to have this almost forced registration process as a user might not be in a position to go through the setup and be trying to do something urgent first thing in the morning, but even more of a concern was the style of the userbase I support – anyone expects to be able to log onto any computer anywhere. Windows Hello for Business doesn’t follow the user around for good reason (you’re tying the things you have to a single device), so each new device will go through the prompts.

I also had concerns around desktop users who didn’t have any other method of authentication beyond the PIN, and the perception than a PIN is less secure than a password (again the PIN is tied to a single device, while the password can be used to log onto any device).

Thankfully, a new option turned in Group Policy under the ‘Use Windows Hello for Business’ policy, located under both the Computers and Users areas Policies > Administrative Templates > Windows Components > Windows Hello for Business. The tickbox ‘Do not start Windows Hello provisioning after sign-in’. (To be fair, this has now been there for a while and I just wasn’t aware):

This will instead provide a little warning in Windows Security under Account Protection, saying Windows Hello isn’t set up. It doesn’t pop up and alert this, but instead shows a yellow exclamation mark against the shield icon in the taskbar. A user can then click through this at their leisure and set up Windows Hello for Business.

To me, this is a great way of allowing all staff the chance to set it up when they’re ready to do so, and in a staggered fashion without really having to manage it. Each business is different of course, and some will prefer or require the heavy handed approach of Windows Hello for Business on all devices – but I’m glad this more relaxed option exists.

Note that Windows Hello for Business is supported in both Azure AD connected and Hybrid Azure AD devices. For further info, read Microsoft’s documentation: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-identity-verification