Entra Private Access and Exchange On-premises

Entra Private Access enables secure access over the Internet to any on-premises application, based on any port or protocol that uses TCP or UDP.

I previously published a blog post on my first look at Entra Private Access. In that post I showed how to configure enterprise applications to allow RDP and filesharing to on-premises resources. In this blog post I want to show how I configured EPA to allow Outlook to connect to Exchange 2019 (on-premises).

It should just work, right? Well, not really. 

When you create an enterprise application EPA you need to know the path and port used for communication. In this case, for Outlook communication, I needed to know about the Exchange Client Access Server. The Client Access server (CAS) role in Exchange is responsible for accepting all forms of client connections, including those from Outlook, Outlook Web App, and ActiveSync. It authenticates and redirects these requests to the appropriate Mailbox server.

Therefore the first thing I needed to know is how Outlook communicates with Exchange. For this we need to see the Outlook connection status on a working device. 

In order to view the Connection Status option, you need to both hold down your CTRL key, and right-click on the Outlook systray icon. Now you should see the Connection Status option. Click on it to check your status. You will see Outlook communicating with the CAS on ports 80 and 443. Note the URL of the CAS server and create EPA enterprise applications allowing access to the CAS server on ports 80 and 443.

That should do it, right? Well, not really.

In previous Outlook versions (Outlook 2007, 2010 & 2013) you have the option to manually setup and configure an Exchange Account. In the latest Outlook versions (2016/2019 or 365) this option is missing and the manual setup is not available. The setup relies on Autodiscover. Autodiscover greatly simplifies the process of configuring Outlook to communicate with an Exchange server by automatically determining which Exchange server the user’s Mailbox is on and configuring Outlook to communicate with that server. This makes it much easier for end users to configure Outlook, since the only things they need to know are their email address (UPN) and password.

Outlook looks in Active Directory and DNS to find the Autodisover information (autodiscover.xml). However I hadn't allowed any connection to a domain controller or DNS server via Entra Private Access, and it's unlikely any organization would allow that. I had to find a "local" solution that I could control myself. I got some inspiration from Konstantinos at wintips.org

1. Create your own Autodiscover.xml file
2. Copy the Autodiscover.xml file to a local folder
3. Edit the registry to look for Autodiscover.xml in the local folder
4. Launch Outlook

Create your own Autodiscover.xml file

Edit a standard Autodiscover xml file with details of your CAS server (underlined and in bold below). This should match the CAS that you used for the enterprise applications previously.

<?xml version="1.0" encoding="utf-8" ?>

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">

<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">

<Account>

<AccountType>email</AccountType>

<Action>redirectUrl</Action>

<RedirectUrl>https://cas.yourdomain.local/Autodiscover/Autodiscover.xml</RedirectUrl>

</Account>

</Response>

</Autodiscover>

Copy the Autodiscover.xml file to a local folder

In this case the path is now C:\Autodiscover\Autodiscover.xml

Edit the registry to look for Autodiscover.xml in the local folder

Open Registry Editor and navigate to the following location:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook

Right click on Outlook key and create a New Key with name: Autodiscover

Then select the Autodiscover key and at the right pane create the following values:

yourdomain.local (REG_SZ) with value: C:\AutoDiscover\autodiscover.xml

PreferLocalXML (DWORD) with value: 1

Replace "yourdomain.local" (underlined and in bold above) with your domain name.

Launch Outlook

Now you can launch Outlook and run through the wizard (make sure that the Global Access client is started).

Now the wizard completes successfully.

Outlook is connected to Exchange 2019 on-premises over Entra Private Access.

All that was left to do is to automate the solution using Intune. Using a Win32 app, I copied the Autodiscover.xml file to the local folder and configured the registry.

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

 

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