Announcing two new Researcher Learning Paths

by Contributed | Jun 30, 2021 | Technology

This article is contributed. See the original author and article here.

We are pleased to announce two new Learning Paths available right now focused on Researchers. We have curated over 7 hours of content that will get you up and ready on Azure.

We want to hear from you. Make sure that you fill a quick survey so that we can ensure that the future learning paths we build are tailored for you.

Whether you need to get started from scratch or are only interested in more advanced topics, we’ve got everything you need to ensure you are productive as soon as possible. If you need to start from scratch let me introduce you to the first learning path.

The Introduction to Cloud Computing for Researchers will get you introduced to the fundamentals of Azure and cloud computing. This learning path will go through how resources are grouped, storing data in Azure, and how to allocate computing resources to run workloads on.

Then, if security and cost are more important to you, Cloud Security and Cost Management for Researchers is your next stop. You will learn how to secure your resources and your data as well as ensure that you are not exhausting all your Azure credits within the same day.

Don’t forget to fill this quick survey. Your feedback matters and future learning paths will be built based on that feedback. We want to hear from you. What can we do to empower you as a researcher?

Let us know!

The case of Azure AD Quota exhaustion

by Contributed | Jun 29, 2021 | Technology

This article is contributed. See the original author and article here.

Hello everyone, my name is Zoheb Shaikh and I’m a Solution Engineer working with Microsoft Mission Critical team (SfMC). Today I’ll share with you about an interesting issue related to Azure AD Quota limitation we came across recently. 

I had a customer who exhausted there AAD quota which put them at a significant health risk.

Before I share more details on this let’s try to understand what your organization AAD Quota could be and why does it even matter.

In simple words Azure AD has a defined quota of number of Directory objects/Resources that can be created and stored in AAD.

A maximum of 50,000 Azure AD resources can be created in a single tenant by users of the Free edition of Azure Active Directory by default. If you have at least one verified domain, the default Azure AD service quota for your organization is extended to 300,000 Azure AD resources. Azure AD service quota for organizations created by self-service sign-up remains 50,000 Azure AD resources even after you performed an internal admin takeover and the organization is converted to a managed tenant with at least one verified domain. This service limit is unrelated to the pricing tier limit of 500,000 resources on the Azure AD pricing page. To go beyond the default quota, you must contact Microsoft Support.

For information about AAD Quotas, see Service limits and restrictions – Azure Active Directory .

How to check your AAD Quota limit

Test this in Graph Explorer: https://developer.microsoft.com/en-us/graph/graph-explorer

Sign into Graph Explorer with your account that has access to the directory.

Run beta query (GET) https://graph.microsoft.com/beta/organization

Now since you understand what AAD Quota is and how to view details let’s get back to the customer scenario and try to understand how AAD Quota affected them and what is in this for you to learn.

The customer was approximately a 100k Users organization using multiple Microsoft cloud related services like Teams, EXO, Azure IaaS, PaaS etc.

As a part of cloud modernization journey, they were doing a massive Rollout of Intune across the Organization post doing all the testing and PoC.

Our proactive monitoring and CXP teams did inform the customer that there Azure AD objects are increasing at an unusual speed, but the customer never estimated this could go beyond their AAD Quota.

One fine morning I got up with a call from our SfMC Critsit manager that my customer’s AAD Quota has exhausted and their AAD Connect is unable to Synchronize any new objects. As a part of Reactive arm of SfMC we got in a meeting with customer along with our Azure Rapid Response team to find what is the cause of the problem.

We decided on below approaches for the issue:

1. Confirm AAD Quota exhaustion and what objects are consuming AAD Resources


2. Remove stale objects from AAD.


3. Reach out to Product Group asking for a Quota increase for this specific customer. 

How to check what objects are consuming AAD Quota limit

While I was engaged in this case, we did it the hard way (by exporting all registered objects in Excel and then using Pivot Tables to analyze) but now there is an easy way to do as described below:

1. Login to Azure AD Admin Center (https://aad.portal.azure.com)


2. In Azure AD Click on preview features (Presently)
   
   

    

   
   


3. This will give you a nice overview of your Object Status of AAD
   

We created the below table to help us find what exactly is going on in the environment, in this we measured how many Objects are in total and how many were created in last few days.

Not sharing numbers here but highlighting that we saw Devices consuming about 50 % of the AAD Object quota and increased in the last 24 hours to few thousands.

This output made us understand that thousands of devices are getting registered every day which has resulted in AAD Quota exhaustion.

Based on our analysis to come out of this situation we recommended the customer to delete stale devices that have not been used for more than 1 year. This itself enabled us to delete approximately 50k objects.

This 50k object deletion ensured that they are out of the critical situation giving them some breathing space to think and avoid this problem from reoccurring at least for the next couple of weeks till we figure out what exactly is going wrong.

Being part of the Microsoft Solution for Mission Critical team, we always go above and beyond to support our customers. The first step is always to quickly resolve the reactive issue, subsequently identify the Root Cause, and finally through our Proactive Delivery Methodology making sure this does not happen again.

We followed below approach to identify the root cause and ensure it will not happen again, below the steps:

1. Configuring Alerts for validation and Quota exhaustion
   
   
   
   1. Daily alerts for Azure AD Object count
   
   
   2. Alerts in case AAD Object Quota limit is exhausted.
   
   
   
   

2. More detailed review on the Root Cause of the issue.
   
   


3. Creating a baseline for AAD Objects needed in the organization.
   
   
   
   1. Baseline to be created based on number of Objects in Organization (Users, computers etc.)
   
   
   2. What is the expected count?
      
      
   
   
   
   


4. Increasing the Object Quota based on the baseline created if needed.

In the next sections we will go through each of the above actions for more explanation

1. Configuring Alerts for validation and Quota exhaustion

Option#1 using Azure Automation.

We wanted to add alerts to ensure the customer is notified if they are nearing the limit. We achieved this by using Azure Automation as below with the help of my colleague Eddy Ng from Malaysia.

Below is the step-by-step process on how you can help achieve alerts post creating an Azure Automation account:

• Create the credential in Credential vault. Click on the + sign, add a credential and input the information name. The credential must have the sufficient rights to connect to Azure AD and not have MFA prompt. The name used is important. It will be referenced from the script.

• Next Install Microsoft Graph Intune under the Modules Resources. Click on Browse Gallery, search for Microsoft.Graph.Intune. Click on the result and Import.

We are recommending MS Graph PowerShell SDK going forward.

• Go to Runbooks.

Create a new Runbook. Give it a name.

Runbook type : Powershell

Paste the below code:

#get from credential vault the admin ID. Change “admin” accordingly to the credential vault name

$credObject = Get-AutomationPSCredential -Name admin

#initiate connection to Microsoft Graph

$connection = Connect-MSGraph -PSCredential $credObject

#setting up Graph API URL

$graphApiVersion = “beta”

$Resource = ‘organization?$select=directorysizequota’

$uri = “https://graph.microsoft.com/$graphApiVersion/$($Resource)”

#initiate query via Graph API

$data = Invoke-MSGraphRequest -url $uri

#get data and validate

#change the number 50000 accordingly

$maxsize = 50000

if ([int]($data.value.directorysizequota.used) -gt $maxsize)

{

    write-output “Directory Size : $($data.value.directorysizequota.used) is greater than $maxsize limit”

    Write-Error “Directory Size : $($data.value.directorysizequota.used) is greater than $maxsize limit”

    Write-Error ” ” -ErrorAction Stop   

}

else

{

    Write-Output “Directory Size : $($data.value.directorysizequota.used)”

}

• Click Save and Publish


• Click Link to Schedule

• Populate the schedule accordingly. For example, run daily at 12pm UTC.


• Results from each run job can be found under Jobs.

• If above quota, the status will be failed as a result of the script -erroraction Stop.

• Setup Alerts to take advantage of this by creating New Alert Rule

• Click select condition. Signal name “Total Job”. Follow the below. Amend “MyRunbook” accordingly. When finished, click done

• Select Action Group. Create Action Group.


• Populate info accordingly for Basics.


• Populate info similar to below for Notifications.

• Click Review + Create


• Once done, scroll below under Alert Rule Details, such as Name, Description and Severity.

• Create Alert Rule

Results: When the Directory Quota Size breached the limit, you will get an alert via email to the admins.

You can then proceed to click on the Runbook and select Jobs. Click on All Logs to see the error output for each individual job run.

If you wish to monitor the previous results in bulk, go to Logs and run this Kusto Query below. Scroll to the right for ResultDescription. Assumption is that the schedule is set to run daily. A limit of 50 will then be for the past 50 days.

AzureDiagnostics

| where StreamType_s == “Output”

| limit 50

Option#2 Alternative way Configuring Alerts for validation and Quota exhaustion

While I was writing this blog, my colleague Alin Stanciu from Romania advised with probably better way to configure Alerts for Quota Exhaustion.

Replace the script in the Azure Automation account as below!

#get from credential vault the admin ID. Change “admin” accordingly to the credential vault name

$credObject = Get-AutomationPSCredential -Name ‘azalerts’

#initiate connection to Microsoft Graph

$connection = Connect-MSGraph -PSCredential $credObject

#setting up Graph API URL

$graphApiVersion = “beta”

$Resource = ‘organization?$select=directorysizequota’

$uri = “https://graph.microsoft.com/$graphApiVersion/$($Resource)”

#initiate query via Graph API

$data = Invoke-MSGraphRequest -url $uri

#get data and validate

$usedpercentage=(($data.value.directorysizequota.used/$data.value.directorysizequota.total)*100)

#if ($usedpercentage -gt $maxsize)

#{write-output “Directory Size : $($data.value.directorysizequota.used) is greater than 90 percent”}

#else

#{

Write-Output “Directory Size : $($data.value.directorysizequota.used) and percentage used is $($usedpercentage)”

#}

And you could use Azure Log Analytics to help Alert on Monitor as below

AzureDiagnostics

| where Category == “JobStreams”

| where ResourceId == “” // replace with resourceID of the Automation Account

| where StreamType_s == “Output”

| project TimeGenerated, ResultDescription, JobId_g

| parse ResultDescription with “Directory Size : ” [“Actual Size”] ” ” * “percentage used is ” [“Percentage used”]

| extend [‘Percentage used’] = toreal([‘Percentage used’])

| top 1 by TimeGenerated desc

| where [‘Percentage used’] > (0.1)

This can help you get an overview of percentage used

Alert configuration using Log Analytics can be done as shown in below screenshots:

You could define the threshold when to be alerted

2. More detailed review on the Root Cause of the issue

In this step we need to identify why so many devices are being registered every day.

We exported the list of all registered devices in AAD in excel and tried to filter based on what type of registrations they have had.

Thanks to Claudiu Dinisoara & Turgay Sahtiyan for helping create a nice dashboard in POWERBI based on these logs which helped us understand the Root Cause much better.

This dashboard helped us understand the type of Device registrations and the overall count across the years, we found that there has been a Significant increase in AAD Device registrations due to Intune Rollout across the organization.

We checked with customer’s Intune support team, and they confirmed that this increase was expected.

3. Creating a baseline on number of AAD objects we can have:

The trickiest part on this issue was coming up with a baseline number for AAD Objects.

So, the customer had approximately 100k users and we came up with the below table for the baseline.

Please note that this number was unique to customer scenarios and discussions and it may differ for your organization.

We compared the expected baseline with their Quota limit was 5,00,000 and came up with the strategy for cleanups and strategy to maintain the object counts as per baseline.

4. Increasing the Object Quota based on the baseline created if needed.

Their AAD Quota limit was 500,000 objects however our baseline indicated that they need to be around 400,000 objects.

Hope this helps,

Zoheb

Enabling automation with Microsoft 365 Apps for enterprise

by Contributed | Jun 29, 2021 | Technology

This article is contributed. See the original author and article here.

Robotic Process Automation (RPA), also known as unattended use, allows an organization to license certain account types that are designed to be used in process automation. 

There are two types of RPA: 

1. Attended RPA – The collaboration between the user and the bot, which is also known as the Virtual Assistant. 


2. Unattended RPA – The execution of tasks and interactions independent of the user. With unattended RPA, the bot can run automation on its own. 

Over the years organizations have used automation within Office apps, but the process always had to be done with volume license versions of Office due to licensing limitations and feasibility of an organization licensing RPA accounts. Microsoft 365 E3: Unattended License now enables IT admins to automate and use the same version/build of Office that their end users are running. Keep in mind that Office was developed with the end user in mind and not automation. Although this new license allows for amazing automation, we suggest you follow the considerations for RPA outlined here: https://aka.ms/unattendedofficeconsiderations. 

Requirements for using unattended RPA 

The following are the requirements for using unattended RPA with Microsoft 365 Apps for enterprise:

• Microsoft 365 E3: Unattended License – Required on any account running an RPA unattended task. The account can be a user account, a system/service account, or a robot account.


• Microsoft 365 Apps for enterprise, version 2009 or later.


• RPA is currently only available for Office apps for Windows.

Enabling RPA scenarios 

 
If you want to enable RPA in Microsoft 365 Apps for enterprise, click here for step-by-step instructions. 

What does it look like? 

To validate if the Microsoft 365 E3: Unattended License is active from a Microsoft 365 App, navigate to File > Account. Here’s an example in the screen shot below: 

Another way to validate if the license is active is under, “%LocalAppData%MicrosoftOfficeLicenses5Unattended.”

If user is signed in, but there is no RPA entitlement (Unattended License) assigned or activated on the account, users may see the following message within their Microsoft 365 Apps: 

Assigning licenses to devices in Microsoft 365 admin center 

To deploy an Unattended License, you simply purchase the required number of Microsoft 365 licenses and assign the license to a user in the Microsoft 365 admin center. To enable this functionality on a device, use the group policy for currently installed devices and/or the command line.

For more information on unattended RPA with Microsoft 365 Apps for enterprise, check out this Microsoft Docs article.

Continue the conversation by joining us in the Microsoft 365 Tech Community! Whether you have product questions or just want to stay informed with the latest updates on new releases, tools, and blogs, Microsoft 365 Tech Community is your go-to resource to stay connected!

What’s new in Windows 11 for Universal Print

by Contributed | Jun 29, 2021 | Technology

This article is contributed. See the original author and article here.

Following the announcement of Windows 11 on June 24, we wanted to update you on what is coming to Universal Print with Windows 11. If you want to get a head start on these new Universal Print capabilities, head over to the Windows Insider blog to read how you can access the first Windows 11 Insider Preview build. Subscribe to the Windows Insider blog if you want to be updated on our progress to general availability of Windows 11 later this year.

Universal Print is a modern print solution that organizations can use to manage their print infrastructure through serverless cloud services from Microsoft. Since the release of Windows 10, version 1903, we have supported this cloud service with a Universal Print driver. The advantage of that driver is you no longer have to maintain printer drivers on your desktops. There is one driver to rule them all.

Using Universal Print with Universal Print ready printers, which we blogged about a few weeks ago, gives admin and employees the best experience. Those printers are easy to manage in the cloud and expose their functionality to the user.

With Windows 11, we are upgrading the user experience with printers in several ways. First is the general print experience to go along with the updated user experience with Windows 11.

Adding a printer in the Windows 11 Settings app

In addition, we are adding some eco-friendly functionality to the updated Universal Print driver that many users will appreciate, the ability to add a PIN to a print job, so the job will not be printed until the user enters the same PIN on the printer. This is one more reason to upgrade your existing printer to a Universal Print ready firmware, if available.

Entering a PIN to release a print job in Windows 11

Some will see this as increased security, but we mostly think of this as functionality that will reduce paper and toner waste and offer users some privacy when printing. Print jobs will not go to waste on the printer. This capability will also come to Windows 10, version 21H2, which will be released later this year.

With Windows 11, we release support for Print Support Application (PSA) in Windows. Windows ships an inbox printer class driver based on the standards based Mopria printing protocol. This enables a simple and seamless printing experience and eliminates the need for users to install additional software or custom drivers to connect and print to their Mopria-certified printers. The Universal Print driver on Windows 11 can be extended by printer manufacturers and/or Managed Print Software (MPS) solutions with additional custom features and workflows by publishing a PSA to Microsoft Store. These UWP apps are not drivers and run in the user’s context. When installed on the user’s Windows 11 device, the PSA may run in the background to process print jobs for the corresponding printer or can offer an advanced print user interface to address scenarios such as:

• Printer specific custom advanced finishing options.


• Add accounting information and workflows.


• Add a watermark (optional or enforced)

Admins can install the default PSA or another vendor’s PSA if required for a Universal Print ready printer on the user’s Windows 11 devices using Microsoft Endpoint Manager. This capability will also come to Windows 10, version 21H2, which will be released later this year.

PSA will also be available outside the commercial Universal Print service configuration on a consumer Windows 11 device. Apps will install automatically from the store when the home user connects a printer to the home network. The advanced settings in the traditional print UI on Windows 11 will no longer show, and the PSA takes over that UI to offer the user the most appropriate functionality for the printer model they have. The significant advantage is that no printer driver is installed, but an app that interacts with the driver to offer the user more functionality, increasing the stability and security of the user’s device.

In addition, we are bringing some enhanced support for the Internet Printing Protocol (IPP) to the Windows ecosystem. IPP has been implemented in Windows 10 for network printers since 2018. With Windows 11, we are adding IPP over USB to widen hardware support using IPP. To support IPP and PSA in an enterprise environment, Windows also supports directed discovery of IPP printers. This also enables IPP and PSA for Windows Server 2022 for Point and Print customers who want to continue using Windows Server for print enablement. This helps customers use PSA independent of the solution they use: Universal Print or Windows Server or a combination. This capability will also come to Windows 10, version 21H2, which will be released later this year.

Learn more: Universal Print and Windows 11

Intune – Enrollment Options for End-Entity Certificates

by Contributed | Jun 29, 2021 | Technology

This article is contributed. See the original author and article here.

Working as a PKI engineer, I am frequently asked about “the best” method to enroll certificates to mobile devices via Intune. What exactly is the best method from a PKI engineer’s perspective? The most secure one, of course. The following article tries to explain the different methods in terms of security.

Overview

Intune supports three different methods to provision certificates to devices or users, that can be easily confused: Simple Certificate Enrollment Protocol (SCEP), Public Key Cryptography Standards (PKCS), and imported PKCS#12 certificates.

While SCEP and PKCS provision each device with a unique certificate, with Imported PKCS#12 certificates you can deploy the same certificate (and private key) that you’ve exported from a source, like Certification Authority database, to multiple recipients. This shared certificate might be useful in scenarios when you need to decrypt data on different devices using exactly the same key pair, e.g. with S/MIME e-mail encryption.

The following article tries to explain the differences – mainly, but not only – from the security perspective. As understanding a technology’s security impact without understanding the technology itself is impossible, we start each section with a brief overview of the certificate enrollment process.

Foreword: Tiered Administration & your PKI

Microsoft’s AD Tier model has enhanced to the “Enterprise Privileged Access Model ”. What remains the same is the fact that a PKI which is fully trustworthy for Active Directory, must be assigned to Tier 0 and secured and treated accordingly. This is not only true for computers hosting Certification Authorities, but also for computers acting as Registration Authorities (like NDES) or computers which have enroll permissions for user certificates allowing for custom subjects (like Microsoft Intune Certificate Connector”).

SCEP (Simple Certificate Enrollment Protocol)

The headline already says that this is about a specific protocol: Simple Certificate Enrollment Protocol. Network Device Enrollment Server (NDES) – a Windows Server Role Service – implements this protocol, thereby providing certificate enrollment services for devices (and users). To interconnect Intune with the on-prem NDES, you need to download and install the following piece of software: Microsoft Intune Connector (aka “Microsoft Intune Certificate Connector” aka “NDES Certificate Connector” or simply “NDESConnectorSetup.exe”). Please be aware that installing Intune NDES Connector significantly changes the default behavior of NDES.

Certificate Enrollment Process

Prerequisite: To use a SCEP certificate profile, devices must trust your Root Certification Authority (CA). Create a Intune Trusted Certificate profile in Intune to provision the Trusted Root CA certificate to users and devices.

The following steps provide an overview of certificate enrollment using SCEP in Intune:

Source: Troubleshoot use of Simple Certificate Enrollment Protocol (SCEP) certificate profiles to provision certificates with Microsoft Intune – Intune | Microsoft Docs

1. Deploy a SCEP certificate profile. Intune generates a challenge string, which includes the specific user (subject), certificate purpose, and certificate type.


2. Device to NDES server communication. The device uses the URI for NDES from the profile to contact the NDES server so it can present a challenge. We recommend publishing the NDES service through a reverse proxy, such as the Azure AD application proxy, Web Access Proxy, or a third-party proxy.


3. NDES to policy module communication. NDES forwards the challenge to the Intune Certificate Connector policy module on the server, which validates the request.


4. NDES to Certification Authority. NDES passes valid requests to issue a certificate to the Certification Authority (CA).


5. Certificate delivery to NDES.


6. Certificate delivery to the device.

Various Aspects of Security

• The key pair is created by the device (or its TPM) and the private key never leaves the device (or the TPM).


• Security of the enrollment process depends on the security of the server hosting the Connector and the NDES Role Service.
  
  
  
  • Intune Connector is installed on the same server that hosts NDES. This server should be properly hardened, with a minimum number of local Admins.
  
  
  • Verification of certificate subject is performed through Intune together with a NDES Policy Module installed in C:Program FilesMicrosoft IntuneNDESPolicyModule.
  
  
  • NDES works as a Registration Authority, meaning that it uses its NDES Enrollment Agent certificate to countersign each certificate request after verification, before forwarding it to the CA. Consequently, the NDES Enrollment Agent certificate is extremely sensitive and should be enrolled and stored in an HSM: An adversary getting hold of the NDES Enrollment Agent certificate (and private key) could counter-sign a certificate request of his choice with arbitrary subjects, thereby enrolling valid user authentication certificates (think of the CEO or the Enterprise Administrator). Keep in mind that members of the Local Admins group have access to keys stored in the Local Computer certificate store!
  
  
  • NDES can run either in the context of Network Service or of a domain service account. Group Managed Service accounts (gMSA) are not supported with the Intune Connector installed. Hardening the NDES service account is essential, not only for your certificate enrollment process, but also for your Active Directory security (weak service accounts make your AD vulnerable to “Kerberoasting” attacks).
  
  
  
  


• NDES requires Enterprise Admin group membership for installation.


• The Intune Connector/NDES server must be accessible from the Internet and protected by a reverse proxy, like WAP or Azure Application Proxy with Azure Conditional Access. Find more details at: Support for NDES on the Internet.


• Although this is not a feature of SCEP, the Intune NDES Connector provides a feature to revoke certificates at the Certification Authority.


• Non-security related side note: When several profiles (e.g. SCEP and VPN or Wi-Fi) are applied to iOS devices at the same time, a separate certificate is enrolled for each profile. 

PKCS (Public Key Cryptography Standard)

The term “PKCS” may be confusing here, because Wikipedia explains PKCS as follows: “PKCS are a group of public-key cryptography standards devised and published by RSA Security LLC, starting in the early 1990s. The company published the standards to promote the use of the cryptography techniques to which they had patents, such as the RSA algorithm, the Schnorr signature algorithm and several others. Though not industry standards (because the company retained control over them), some of the standards in recent years have begun to move into the “standards-track” processes of relevant standards organizations such as the IETF and the PKIX working-group[1].”

However, in this context “PKCS” simply means that two different PKCS standards are used to request a certificate (PKCS#10) and/or push the certificate including the private key (PKCS#12) to the device.

Some key facts about PKCS#12:

• 
  
  
  
  • PKCS#12 is the successor to Microsoft’s “PFX”, however, the terms “PKCS #12 file” and “PFX file” are sometimes used interchangeably. Find more details at Wikipedia explaining PKCS#12 .
  
  
  • PKCS#12 defines an archive file format for storing many crypto objects within a single file (e.g. private key + certificate + CA certificates).
  
  
  • PKCS#12 is protected by a password because it contains sensitive data (the private key). This password is named “PFX password” further on.
  
  
  
  

   

  
  

a) PKCS

In this scenario you install the same peace of software as for SCEP enrollment (“Microsoft Intune Certificate Connector” aka “NDES Certificate Connector” or simply NDESConnectorSetup.exe”), you just select different configuration options. More details are provided here: Configure and use PKCS certificates with Intune.

Certificate Enrollment Process

A detailed description of the enrollment process is provided in the article Troubleshoot use of PKCS certificate profiles to provision certificates with Microsoft Intune.

Prerequisite: To use a SCEP certificate profile, devices must trust your Root Certification Authority (CA). Create a Intune Trusted Certificate profile in Intune to provision the Trusted Root CA certificate to users and devices.

The following steps provide an overview of using PKCS for certificate enrollment in Intune:

1. In Intune, an administrator creates a PKCS certificate profile, and then targets the profile to users or devices.


2. The Intune service requests that the on-premises Intune Certificate Connector creates a new certificate for the user.


3. The Intune Certificate Connector creates a key pair and a Base64 encoded PKCS#10 certificate request.


4. The certificate request is sent to an Active Directory Certification Authority.


5. The CA verifies the certificate request.


6. If positive, the CA issues the certificate, and returns it to the Intune Connector.


7. The Connector re-unites the certificate with the private key by creating a PKCS#12 envelope and encrypts it with a randomly generated password (PFX Password).


8. The PFX Password is then encrypted with the Intune KeyRecoveryAgent certificate before it is uploaded to Intune together with the PKCS#12 certificate.


9. Intune decrypts the PKCS#12 certificate and re-encrypts it for the device using the Device Management certificate. Intune then sends the PKCS#12 to the device.


10. The device decrypts the PKCS#12 and imports it.

Various Aspects of Security

• Security of the enrollment process depends on the security of the server hosting the Connector (this is even more true in case the Local System account is used to connect to the CA). This server should be properly hardened, with a minimum number of local Admins.
  
  
  
  • The Connector submits certificate requests in the context of the computer account hosting the Connector.
  
  
  • This computer account can request certificates with a subject of its choice (including the CEO’s or Enterprise Admin’s username).
  
  
  • Intune derives the subject from the authentication token, there is no additional verification of the subject.
  
  
  
  


• The server hosting the Intune Connector does not need to be published to the Internet.


• The certificate private key is generated on the server where the Connector is installed and not on the user’s device. It is required that the certificate template allows the private key to be exported, so that the certificate connector can export the PFX certificate and send it to the device. However, please note that the certificates are installed on the device itself with the private key marked as not exportable.

Scalability

In contrast to the SCEP Connector, with PKCS Connector the issuing CA as well as the certificate template are configured in the Intune profile. This means that one PKCS Connector can be used to enroll different certificate templates or even enroll certificates from different CAs.

b) Imported PKCS

Microsoft Intune supports use of imported public key pair (PKCS) certificates, commonly used for S/MIME encryption with email profiles. S/MIME decryption is challenging because an email is encrypted with a public key:

• You must have the private key of the certificate that encrypted the email on the device where you’re reading the email so it can be decrypted.


• Before a certificate on a device expires, you should import a new certificate so devices can continue to decrypt new email. Renewal of these certificates isn’t supported.


• Encryption certificates are renewed regularly, which means that you might want to keep past certificate on your devices, to ensure that older email can continue to be decrypted.

Because the same certificate needs to be used across devices, it’s not possible to use SCEP or PKCS certificate profiles for this purpose as those certificate delivery mechanisms deliver unique certificates per device. Here is the main drawback of S/MIME: It is impossible to securely and at the same time efficiently synchronize keys across devices and that’s why Microsoft recommends using Azure Information Protection instead (which was designed with having today’s security and usability challenges in mind).

However, if you still want to go for this scenario you need to install the “PFX Certificate Connector for Microsoft Intune” or simply “PfxCertificateConnectorBootstrapper.msi”. The article Use imported PFX certificates in Microsoft Intune provides details about the configuration.

Certificate Deployment Process

This method neither covers creation of key pairs nor enrollment of certificates. It simply assumes that key pairs and certificates already exist. The focus of this Intune Connector is to offer a temporary solution while migrating from S/MIME to a more up to date solution like Office 365 Message Encryption. S/MIME was originally standardized in 1995 when users didn’t have multiple mobile devices and key compromise was something you didn’t have to worry about.

The following steps provide an overview of the PKCS#12 certificate deployment process in Intune:

1. The PFX Certificate Connector holds a PFX Certificate Connector certificate and uses the private key to encrypt the PFX password.


2. The encrypted PFX password is uploaded to Intune.


3. The user’s S/MIME certificate (in PKCS#12 format) is protected with the PFX password and uploaded to Intune, too.


4. In Intune, an administrator creates a PKCS#12 certificate profile, and then targets the profile to users or devices.


5. The user’s device requests the PKCS#12 certificate.


6. Intune sends the encrypted PFX password, the PKCS#12 certificate and the device’s public key to the PFX Certificate Connector.


7. The PFX Certificate Connector decrypts the PFX password.


8. The PFX Certificate Connector re-encrypts the PFX password with the device’s key.


9. The re-encrypted PFX password and the PKCS#12 certificate are sent to Intune.


10. The re-encrypted PFX password and the PKCS#12 certificate are forwarded to the user’s device, which then decrypts the PFX password, decrypts the PKCS#12 certificate and imports it into the device.

Various Aspects of Security

• Security of the deployment process is dependent on the security of the server hosting the Connector. This server should be properly hardened, with a minimum number of local Admins.
  
  
  
  • The PFX Connector certificate’s private key should be protected using an HSM.
  
  
  
  


• As already mentioned, S/MIME was originally standardized in 1995 when users didn’t have multiple mobile devices and key compromise was something you didn’t have to worry about. Today, we see distributing and using the same private key across various devices with a different level of security as a contradiction in itself.


• The PFX Connector only covers the distribution of certificates and private keys to the user’s devices. It does not cover:
  
  
  
  • Creation of key pairs, requesting and enrolling certificates
  
  
  • Secure on-prem storage of private keys
  
  
  • Certificate revocation in case a device is lost or stolen
  
  
  • Renewal of expiring certificates
  
  
  
  

I hope you enjoyed this article and it helps to bring some light into the various options of enrolling certificates via Intune.