Secure email with Intune Cloud PKI in less than 15 minutes

This is incredible. I have experience with deploying PKI solutions in the past and it can be time-consuming and complex. My customer has a requirement to encrypt email but they have no internal PKI. I wanted to see how this could be achieved with the new Intune Cloud PKI. I was amazed, I was able to configure the entire solution in my lab in less than 15 minutes and now I can concentrate on the rest of my day.

Licensing first, Cloud PKI is part of the Intune Suite so I ensured that my test users had this license. Then on with the configuration. It's so easy. We'll have a look at how to create and deploy a Microsoft Cloud PKI root CA and issuing CA in Microsoft Intune. We will then create certificate profiles so that the issuing CA can issue certificates to devices.

The account you use to sign into the Microsoft Intune admin center must have permission to create CAs. The roles with built-in permissions include Microsoft Entra Global administrator and Intune service administrator account. 

Alternatively, you can assign Cloud PKI CA permissions to an admin user.

Root CA

In the Microsoft Intune admin center, navigate to Tenant administration > Cloud PKI, and then select Create.

Enter a name and optional description for your CA. Click Next.

Now we have the configuration settings. For CA type you have to choose Root CA, as this is the first one. For validity period, select 5, 10, 15, 20, or 25 years. For Extended Key Usages, select how you intend to use the CA. To prevent potential security risks, CAs are limited to select use. I need Email protection for now, but I may need Client authentication at a later stage. 

Enter a common name for the root CA and optionally enter other attributes.

Enter the required Key size and algorithm. The options are:

• RSA-2048 and SHA-256
• RSA-3096 and SHA-384
• RSA-4096 and SHA-512

Click Next to continue. Configure a scope tag if required and click Next.

Review the configuration. You won't be able to edit these properties after you create the CA. If you need to change something later must create a new CA. If you are happy select Create.

After a short time you will see your root CA.

Have a look at the properties. Download the certificate, you will need it later.

Here is the certificate in .cer format.

Issuing CA

Next we will configure the Issuing CA. An issuing CA is required to issue certificates for Intune-managed devices. Cloud PKI automatically provides a SCEP service that acts as a certificate registration authority. It requests certificates from the issuing CA on behalf of Intune-managed devices using a SCEP profile.

In the Microsoft Intune admin center, navigate to Tenant administration > Cloud PKI, and then select Create.

Enter a name and optional description for your CA. Click Next.

This time we have more options (as we already have one Root CA). Choose Issuing CA as the CA type and Intune as the Root CA Source. Select your Root CA to link with the Issuing CA.

What is the function of the issuing CA? You will only see the options made available through the Root CA. 

I've selected email protection and client authentication again.

Common name is the only required field here.

You cannot configure the key size and algorithm as they are inherited from the root CA.

Review the summary and create the issuing CA.

Root CA and Issuing CA have now been created and are available in the Intune admin center. Note that, at the moment, it is not possible to delete these CAs without a support ticket.

Download the certificate and copy the SCEP URI. You will need them later.

Here we have our Root and Intermediate certificates.

Certificate Profiles

Now we need to create three certificate profiles.

• Trusted certificate profile for the Cloud PKI root CA
• Trusted certificate profile for the Cloud PKI issuing CA
• SCEP certificate profile for the Cloud PKI issuing CA

Let's do the Root CA first.

Create a configuration profile using the Trusted certificate template.

Browse to the .CER file download earlier from the Root CA.

Assign the profile to a group.

Create a second profile using the Trusted Certificate template. Browse to the CA file downloaded from the Issuing CA.

Next we need a configuration profile based on the SCEP certificate template.

Default settings will work here. Note that key storage provider, key usage, key size and hash algorithm are not pre-configured but are required.

Select your Root CA and extended key usage. I've chosen secure email and client authentication again. Enter the SCEP URI that you copied earlier.

Create and assign the SCEP profile.

On the test device

So, what do we see on the test device?

The root and intermediate certificates can be seen in the Trusted Root Certificate Authority store.

The SCEP certificate for the logged in user can be seen in the Personal store.

In the Intune admin center, browse to Tenant Admin > Cloud PKI > Issuing CA > View all certificates to see a list of all the SCEP certificates issued to users.  

Drill into a certificate to see the details.

Now, in the Outlook client, select File from the main menu, then click Options. Select Trust Center at the bottom of the menu on the left side of the Outlook Options. Click the Trust Center Settings button. Select Email Security from the left-hand menu of the Trust Center window and you will see the email encryption settings.

Click Settings to see the certificate details.

The user now has the option to encrypt emails using S/MIME.

I hope this help, until next time........

macOS management with Intune - activation lock

Back to main macOS page

You can set up Find My on your Mac so you can locate it and protect it if it’s ever lost or stolen. You can also share your location with others. When you add your Mac to Find My, Activation Lock is automatically turned on. After it's enabled, the user's Apple ID and password must be entered before anyone can:

• Turn off Find My Mac
• Erase the device
• Reactivate the device

While Activation Lock helps secure Apple devices and improves the chances of recovering a lost or stolen device, this capability can present you, as an IT admin, with many challenges. For example:

• A user sets up Activation Lock on a device. The user then leaves the company and returns the device. Without the user's Apple ID and password, there's no way to reactivate the device.
• You want to reassign some devices to a different department during a device refresh in your organization. You can only reassign devices that don't have Activation Lock enabled.

To help solve these problems, Apple introduced the ability to disable Activation Lock for supervised devices (macOS 10.15 or later), without the user's Apple ID and password. Supervised devices generate a device-specific Activation Lock bypass code, which is stored on Apple's activation server. Intune supports this feature.

First I want to check the current Activation Lock status on my test Mac. For that we need System Information. Click on Alt (or Options) at the same time as the Apple logo to expose System Information on the menu. Then look in the hardware section. I've highlighted where the Activation Lock status should be, but it's not there. Why is that? It's because my Mac doesn't support the feature. Activation Lock is available on all Apple silicon Macs. But on devices that use Intel chips the feature is restricted to models with an Apple T2 Security Chip, running macOS Catalina or later. So as an example, a non-T2 Intel Mac—such as the MacBook Air (2017)—will not support Activation Lock. You can see from the screenshot that my device has a Dual-Core Intel Core i5.

We can still see how this is supposed to work. On the test device I've turned on Location Services (System Preferences > Security & Privacy > Enable Location Services). This is a requirement for Find My Mac.

Find My Mac can be found in the Applications list.

Find My Mac will want to use location services. It will be turned on but cannot enable activation lock on my test device.

Have a look at the hardware properties of the device in Intune. Under Conditional Access we can see that the device is supervised. We can also see that the Activation lock bypass code field is not populated. 

There are two methods to disabling Activation Lock on devices:

• Manually entering the Activation Lock bypass code on the device
• Using the Disable Activation Lock device action

Let's use the device action and click Disable action lock.

We have to accept the warning about disabling action lock. Click Yes.

That would then disable action lock on the device. As expected it has failed on my test Mac device.

I hope this helps. Until next time......

macOS management with Intune - Gatekeeper

Back to main macOS page

Next up we'll talk about Gatekeeper. By default, Gatekeeper helps to ensure that all macOS installed software has been signed by the App Store or signed by a registered developer and notarized by Apple. It verifies that the software is free of known malicious content and hasn’t been altered.

We'll start with a macOS configuration profile. Navigate to Devices > macOS > Configuration Profiles and select Create new policy.

Choose Templates as the Profile type and select Endpoint Protection.

Enter a name for the policy and click Next.

We'll see two settings to configure. You are given the following options for "Allow apps downloaded from these locations"

• Not configured (default)
• Mac App Store
• Mac App Store and identified developers
• Anywhere

This is to limit the apps a device can launch, depending on where the apps were downloaded from. The intent is to protect devices from malware, and allow apps from only the sources you trust.

I've chosen Mac App Store for now. There is a second setting to configure "Do not allow user to override Gatekeeper". This prevents users from overriding the Gatekeeper setting, and prevents users from Control-clicking to install an app. When enabled, users can't Control-click any app to install it. I want this so I've selected Yes.

I'm assigning this policy to my group of Mac devices.

Select Create. The policy will then be assigned.

In Intune, I can see that the policy has been successfully deployed to my test device.

I can see that each of the two settings was successfully applied to the device.

On the device you can navigate to System Preferences > Profiles. There are two new profiles. The first one disallows apps by identified developers.

The second one disallows the opening of untrusted apps i.e. not downloaded from the Mac App Store. 

Navigate to System Preferences > Security and Privacy and we can see the configuration. Only allow apps downloaded from the App Store. The setting is greyed out and cannot be changed, even by an administrator on the device.

See what happens when launching an app that was downloaded from the Internet. It can't be opened because it was not downloaded from the App Store. That's what we want.

I hope this helps. Until next time.....