InTune

5 Things To Check In Your Microsoft Intune for Apple iOS 17 and iPadOS 17 Configuration

Welcome to another ‘5 Things To Check’ security blog post. This time we’re looking at iPhones and iPads. Do you let people BYOD their own mobile device and just let them consume email on it? Are you controlling which application(s) can connect to your tenant on unmanaged devices, and are you applying application management to prevent data going out of those controlled applications?

iOS/iPadOS hardening has a lot of similarity to SOE/Windows Client hardening these days. Although when iPhones first launched there were next to no controls or management, the platform has eventually progressed into one that can be tightly controlled and hardened. Just like Windows though, this doesn’t mean that the out of the box is the most secure, and you’ll have to review a bunch of settings. You’ll also notice the settings are a bit more ‘basic’ compared to Windows, but that doesn’t mean they’re any less important.

Unsurprisingly, there’s a large amount of configuration than can be applied to harden the mobile user’s experience in dealing with company data, as well as protecting the users themselves. Again, I’m basing my 5 picks off the Center for Internet Security’s (CIS) benchmark’s list of ‘CIS Apple iOS 17 and iPadOS 17 Intune Benchmark’ items (freely available for non-commercial use), and I’m picking 5 that I think are important and not configured by default. This doesn’t mean you should only implement these 5, but it’s a good start for awareness on how much consideration needs to go into hardening an environment and why you need to put the effort in.

The CIS benchmark is broken up into two sections: BYOD and Supervised (i.e. company owned) devices, so my picks will be items that are recommended in both scenarios.

1. Ensure “Block Siri while device is locked” is set to “Yes” (and the lock screen in general)

Some may argue that Siri should be blocked altogether, because you’re sending data that could be sensitive back to Apple, and it may occur without you knowing. In reality, many people working from home probably have an Apple, Google, or Amazon device listening to everything they’re doing on their Teams or Zoom call anyway. However, those devices should at least not be connected to corporate data – unlike their Apple phone or tablet. This is more about someone gaining access to the physical device, and potentially being able to find out information about the data the iPhone has saved on it, or has access to. There have also been past bypasses on using Siri on the lock screen to unlock the phone or access certain other areas without needing the phone properly unlocked, so it’s seen as an unnecessary risk to leave this on.

This also extends to other data that could be viewable while the phone is locked, such as ‘Ensure “Block Today view in lock screen” is set to “Yes”‘ as this can show items like meetings, and ‘Ensure “Block voice dialing while device is locked” is set to “Yes”‘ as voice dialling is a function unrelated to Siri (there’s several more settings around lock screen information too!). You don’t want someone that finds your phone being able to access these and several other areas. One thing I’d potentially disagree with on the CIS benchmark is configuring the ‘Ensure a “Lock Screen Message” has been set’ message. Their advice is to have a helpdesk phone number or email address. The problem with this is, it shows someone who finds the phone what company the phone belongs to, and might incentivise them to keep or sell the phone somehow. If someone finds a phone from either a big company, or a company they don’t like, or a competitor to their own company, that’s a risky scenario. I’d suggest it’s better to use Apple’s guide on how to deal with a lost phone https://support.apple.com/en-au/101593 and also use Intune to destroy anything company managed – it should all be synced anyway and easily replaceable.

In Intune, this configuration is called ‘Allow Assistant White Locked’

2. Ensure “Maximum minutes after screen lock before password is required” is set to “Immediately”

This one is a straight forward setting. When the device’s screen is locked, how long should it wait before letting you just unlock it without a passcode or Face Unlock. It appears that the default for this is ‘Immediately’ but this demonstrates the importance of locking down configuration using a MDM such as Intune. The maximum time configurable is 4 hours, which is a long time someone could put their device down somewhere or completely lose it, and have no protection from being unlocked. The minimum time beyond immediate is 1 minute, which doesn’t seem like much – but someone locking their phone and putting it down leaving a whole minute for someone to obtain the phone is a fair amount of time. This is one I’d like to see a 5 second option just so users who accidently lock their device have a tiny window to unlock it again without having to verify – especially for BYOD. Extra layers of protection can be put on work related apps anyway requiring another Passcode or biometrics unlock.

To look at this option on iOS, Tap ‘Settings’ > ‘Touch ID & Passcode’ or ‘Face ID & Passcode’ depending on the device > Require Passcode. This needs to be set to ‘Immediately’, but as mentioned above a user can just change this.

In Intune, iOS Configuration Settings, the Maximum Grace Period can be set to ‘0’ which means ‘immediately’.

3. Ensure “Block viewing corporate documents in unmanaged apps” is set to “Yes”

As per Microsoft Learn documentation iOS/iPadOS device settings in Microsoft Intune | Microsoft Learn , this setting prevents documents being viewed/opened/saved to non-managed apps. Although some users might find this frustrating that they can’t use their favorite personal program, it prevents data leakage. Many apps will have their own data storage solutions and it’s quite easy for a user to accidently save a document in the wrong place, potentially another cloud provider and to a different country. On top of that, the app itself may not have the same protections as the managed apps you provide. Does the company scrape the data of what the user is doing – document names, metadata, or do they even try to use their own AI solution to read and help the user edit the document, provide a summary, or other hot AI topics? All this needs to be controlled by keeping the data where you manage it as much as possible, and not letting users have an easy path of getting data out. Without something like Purview, there’s always ways of extracting data, but you need to both provide good native ways of working with the data, as well as preventing or slowing down other methods.

As noted on the documentation, this setting does block third party keyboards, but for the same reasons as above, this is a good thing. Keyboard apps may track what you’re typing in different ways and keep a dynamic suggested list of shortcut words you commonly use – maybe you want to keep that project codenamed ‘Order 66’ under wraps as much as possible.

In Intune, Device Restrictions configuration has the ‘Yes’ option for ‘Block viewing corporate documents in unmanaged apps:

4. Ensure “Block trusting new enterprise app authors” is set to “Yes”

As the little (i) next to this configuration states – “Removes the Trust Enterprise Developer button in Settings->General->Profiles & Device Management.”

This setting actually blocks users from being able to trust apps that aren’t downloaded from the app store. Maybe good for a developer trying to quickly test their own app, but for normal users this shouldn’t be necessary. You can probably imagine plenty of scenarios where a user may get tricked into installing an app through non-standard means (such as being emailed a PDF that says to unlock the PDF, please install this software) and giving an attacker an easy path of getting malicious code onto a device.

The title of this setting is a bit misleading, because it sounds like new app authors to the Apple App Store would be blocked, but that’s not the case. Apple have a stringent App approval process and arguably it may not be perfect, it’s still a much larger barrier than just a file downloaded anywhere from the internet.

The approach of ‘only install approved apps’ may work for Corporate Owned devices, but not BYOD.

This is configured in Intune under Device restrictions > General > Block trusting new enterprise app authors:

5. Ensure “Block screenshots and screen recording” is set to “Yes”

I don’t really like the user impact of blocking screenshots and screen recording, but it’s a Level 1 CIS profile item which is their lowest baseline security recommendations. To quote CIS:

Be practical and prudent.
Provide a clear security benefit.
Not inhibit the utility of the technology beyond acceptable means.

Based on this, what is the big issue with screenshots, where’s the security benefit? If you think about most users (including yourself) there’s probably a mess of screenshots somewhere. People rarely clean these up. Worse, they get treated as images/photos and will sync to potentially multiple cloud solutions – Apple’s native photo sync, OneDrive, Google, and many other apps/companies that monitor newly created images and sync them off somewhere. Although you can protect Outlook from being able to take screenshots from within Intune via application configuration, you can’t stop someone screenshotting in many other apps, and therefore can’t protect the data in that screenshot.

If someone wants to take a photo of their computer screen or phone screen you can’t stop them, but blocking screenshots makes the process more difficult and means it should only happen when really needed (or someone’s stealing data on purpose!) and you severely reduce the risk of confidential screenshots floating around many unprotected consumer cloud solutions.

I hope this list has been useful, and I’m sure iOS/iPadOS 18 and beyond will come out soon, but the above should be relevant for quite some time!

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.

Device Limit Reached – Intune Company Portal App

Device limit reached – You have added the maximum number of devices allowed by your company support. Plesae remove a device from the Azure portal or get help from your company support.

There’s a limit to the amount of devices you can register for the Intune Company Portal app.

To fix this, yes you’ll need to remove a device attached to your account. This is not done via Outlook for Web, where you can remove devices – that’s purely for Outlook. It’s also not done via https://myaccount.microsoft.com/device-list as it’s not removing it from Azure.

As per Microsoft Documentation , there’s Intune device limits, and Azure device limits. Intune / EndPoint Manager has a maximum of 15 devices, where Azure has a default of 20, but can be changed to a few different values, including ‘unlimited’.

Intune / Endpoint Manager Device Limits
Azure Device Limits

To remove devices from a user, and admin should use Azure Active Directory and go to Users > Find the user > then under Manage, choose ‘Devices’. Any old device (check by the activity date) can be selected and deleted.

After removing enough devices here, you should be able to register the new device via the Intune Company Portal app again – and in my testing, this was next to instant.

Intune – Couldn’t Enroll your Device

We started having issues with new enrolments to Intune. Nothing had changed that we were aware of, but registering a new device brought up the error “Couldn’t enroll your device. You can try again or send the error information to your IT admin in an email.” iOS or Android, didn’t matter:

screenshot_20160922-180510Intune Enrollment Error

After testing multiple accounts and multiple devices, I logged a call with Office 365 support, and eventually we worked out that for my account, I didn’t have a license applied. Intune sits under our Enterprise Mobility Suite package:

licenseIntune License is “Off”?

After checking other users, I found that everyone was in this ‘Off’ state. Weird, because we hadn’t done this, and Intune licensing was being managed by a group via Azure AD as per these instructions. That configuration was still in place too when I checked. I decided to do the logical thing and ‘turn it off and back on again’ – so I disabled the assignment on that page, then re-enabled the same group with the Intune license.

After then going back to the Office 365 User search, I found that all the users had now changed to ‘on’ again. The only recent event in the last few weeks was a renewal of our licenses, so I wonder if something happened in the back end as a part of that?

Anyway, if you see the ‘Couldn’t enroll your device’ message when using the Intune Company Portal app, make sure the user has their Intune license enabled!

Fix Wrong Domain for Users Azure Active Directory

I ran into a problem where a user couldn’t sign into Intune, which uses Azure Active Directory to authenticate users.

After checking the user in question on the Azure Active Directory portal, I noticed the domain was wrong:

aad

The user was being synced from On Premise Active Directory, so I had a look via Users and Computers to see what was going on. The user’s User Principal Name domain field was set differently to other users – instead of the proper mydomain.com, it was set to mydomain.local – another valid internal domain to Active Directory, but not one that Azure Active Directory knew about:

aad2

The unknown domain caused Azure Active Directory to disregard it, and instead use it’s default tennancy domain of wrong.onmicrosoft.com. I thought just changing the dropdown menu to mydomain.com instead of mydomain.local would fix it, but a forced Azure Active Directory Sync sync reported the change was successfully synced, but didn’t actually change the value.

I’m going to guess this is by design, as you don’t usually want logins changing. There is an easy way to change the via PowerShell instead.

Once you’ve run the standard ‘Connect-MsolLService‘ cmdlet, you can use ‘Set-MsolUserPrincipalName‘ to change the user. The full command is:

Set-MSolUserPrincipalName -userprincipalname “[email protected]” -NewUserPrincipalName “[email protected]

Pretty simple, and the change is immediate.

I then realised there may be other users with the same problem, so dediced to use the Active Directory PowerShell Module with this command:

get-aduser -filter * | where {$_.userprincipalname -like “*local*” -and $_.enabled -eq “true”} | select name

This showed all the users who had ‘local’ in their UPN. As there were only a few, I changed them all one by one with the first command above.

The same check can be run against Azure Active Directory users with this command:

get-msoluser -all | where userprincipalname -like “*local*”

Easy!