Active Directory

5 Things To Check In Your Intune for Windows 11 Configuration

Posted on by Adam Fowler

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.

Update UPN from AD to Azure AD

Posted on by Adam Fowler

When there was a name change in Active Directory (AD), we used to update the Universal Principal Name (UPN) in AD, then separately run the Set-MsolUserPrincipalName command to update Azure AD to the same UPN. Except, it no longer worked – I was now getting an ‘Access Denied’ message.

When trying to update the UPN via the Microsoft 365 admin center, it would correctly advise that the object was homed in AD, 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 AD, no errors.

After some investigation, I found that there is now an option 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 check the status if UPN updates will sync and update:

Get-MsolDirSyncFeatures -Feature SynchronizeUpnForManagedUsers

If it’s $true, you’re already set. If it’s $false, update the value to $true with this command:

Set-MsolDirSyncFeature -Feature SynchronizeUpnForManagedUsers -Enable $true

In my testing, running another Azure AD Sync (both delta and full) did not resolve any already updated UPNs. I had to change the UPNs to a temporary value, sync, then change them back to the original value I wanted, and sync again. The update was instant in Azure AD once the sync had run each time.

Azure AD Password Protection Setup Summary

Posted on by Adam Fowler

Update 27th November 2023:
The below information may be a bit dated now, so please refer to the lastest official guide here: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-password-ban-bad-on-premises-deploy

Original Post:
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 DC agent’ 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 ‘[email protected]’
    (run this on each install)

    Register-AzureADPasswordProtectionForest -AccountUpn ‘[email protected]’
    (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.

Conditional Access Baseline Policies Out, Security Defaults In for Azure Active Directory

Posted on by Adam Fowler

Something I stumbled across today – it appears that Microsoft has decided to abandon Baseline Protection Policies, and replace them with a single ‘on/off’ switch called ‘Security Defaults’

Baseline Protection policies (also called Baseline Policies, it seems both terms have been used) were in preview, and were a pre-canned set of policies based on Microsoft recommendations on standard security settings that should be in place – such as forcing any administrator account to use MFA at each sign in, and blocking legacy authentication.

Here’s what the Conditional Access page currently shows. There might be something wrong with the detection though, as I clearly have a Baseline Policy enabled:

Baseline Protection policies are a legacy experience which is being deprecated. It looks like you haven’t enabled any Baseline Protection policies, so they will be removed from your tenant. This will not impact your existing workflows. If you’re looking to enable a security policy for your organization, we recommend enabling Security defaults or configuring Conditional Access policies.

It’s not difficult to recreate the Baseline policies, so I’d suggest migrating off of them now while they’re still functional – you don’t want to be left in a state where you didn’t realise MFA for admins was now not being forced.

The replacement Security Defaults option can be found by going to Azure Active Directory > Manage – Properties > Manage Security Defaults (it’s not in the Conditional Access area):

Before flipping this switch to ‘On’, you’ll need to have a really good read of the documentation. There’s a lot this option does, and may break many environments who aren’t ready for this – such as making sure you have no Legacy Authentication requirements, and that all users will register for MFA within 14 days or be blocked from sign-in until they register.

Although I can see this option being turned on by an uninformed administrator and causing some chaos, I like the idea of this. It means a new tenant can now have a single option to start with to implement several critical aspects to protect the tenant against attacks – right now there’s a lot you need to go through to lock it down, and especially for a small business who doesn’t have the time or resources to do this as well as a larger one, a single on/off switch solves a lot of security problems.

Security Defaults is also available to all customers on all tiers – Azure AD Free tier, which means those who have basic needs can now be protected in several ways they weren’t able to do via Conditional Access before.

Security Defaults isn’t listed as being in Preview as far as I can tell, so it may be an option that’s just rolled out and a ready to go. I am guessing there’ll be a bit of kickback around this being a single option that has no other configurable options in it, so we’ll have to wait and see if the product changes, or Microsoft’s vision of a security toggle stays as their goal.

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

Posted on 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.