Help, NDES is broken......

I was working with a new customer recently and they pointed out that they were having a problem with NDES. 

What is NDES? The Network Device Enrollment Service (NDES) is one of the role services of Active Directory Certificate Services (AD CS). NDES acts as a Registration Authority to enable devices running without domain credentials to get certificates from the internal Certificate Authority, based on the Simple Certificate Enrollment Protocol (SCEP).

Therefore the customer was unable to issue SCEP certificates via Intune and was unable to enforce 802.1x authentication to their network. 

An Intune managed Windows 10/11 client was a good place to start, in particular the event logs (Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin). Event IDs 307 and 32 were repeating.

Event ID 307 - SCEP: FailedLogError Message : (SCEPInstallCertificateWithScepHelper:Failed to Initialize SCEP enrollment with NDES Server https://xxxxx.msappproxy.net/certsrv/mscep/mscep.dll/pkiclient , CA Cert thumbprint 'xxxx' and server certs)

Event ID 32 - SCEP: Certificate enroll failed. Result: (Internal server error (500)).

Just for kicks I opened a browser and navigated to the NDES server URL (from event ID 307). It gave me the same Internal Server Error (500) that I could see in event ID 32.

Next I had a look on the NDES server. The IIS log files can be found in the following folder: %SystemDrive%\inetpub\logs\logfiles\w3svc1. On 10th August we could see a status code of 200: This status indicates the connection with the NDES server is successful.

On 11th August we could see a status code of 500. This Microsoft troubleshooting guide tells me that Status code of 500 could mean that the IIS_IUSRS group might lack correct permissions (Impersonate a client after authentication).

However, I opened the Local Security Policy editor (secpol.exe), expanded Local Policies, and then selected User Rights Assignment. Double-clicking Impersonate a client after authentication in the right pane, I could see that the IIS_IUSRS group had the correct permissions.

The SCEP application pool was started so no problem there.

The Application event log on the server gave me some direction. Event IDs 10 and 2 were repeating. 

Event ID 10: The Network Device Enrollment Service cannot retrieve one of its required certificates (0x80070057). The parameter is incorrect.  

Event ID 2: The Network Device Enrollment Service cannot be started (0x80070057). The parameter is incorrect. 

This prompted me to look at the computer certificates on the NDES server. Sure enough, they had expired. There were three certificates to deal with:

• Certificate based on the CEP Encryption certificate template
• Certificate based on the Exchange Enrollment Agent (Offline Request) certificate template
• Certificate based on the NDES SSL certificate template

Perfect, I just need to renew these certificates, right? Well not really.

I started with the CEP Encryption certificate, right-clicked on the certificate and selected Request Certificate with New Key.  

However the CEP Encryption template was not available so I couldn't "renew" the certificate. I needed a brand new certificate with exactly the same details.

I made a note of the Subject details for the existing certificate.

Now to create the new certificate, I right-clicked on the Personal folder and selected All Tasks > Request New Certificate.

I selected the Active Directory Enrollment Policy and clicked Next.

This time the CEP Encryption template was available. However more information was required. I clicked on the link to configure the certificate.

I added the same Subject details that I had captured earlier from the existing certificate, applied this and completed the wizard to generate the certificate.

The certificate was created with excessive permissions for the service account. I clicked Manage Private Keys.....

.... and unchecked the box for Full Control for the service account.

Next up is the NDES SSL Certificate. 

It's the same process as above except this time we use a different template. Don't forget to remove the Full Control permissions from the service account when you are finished.

Last but not least we get to the certificate based on the Exchange Enrollment Agent (Offline Request) certificate template. The process to generate this certificate is a little different than the others. Nickolaj Andersen has published the steps in a good post here. Please follow these steps to generate the third certificate. They are pretty straightforward.

I executed an IIS reset and figured that I was good to go.

The Network Device Enrollment Service policy module started successfully.

NDES looked to be functioning correctly.

Happy days, the NDES service finally started. But alas, certificates were still not being issued. There were still errors in the clients event log referring to "BadGateway: This corporate app can't be accessed". 

Opening a browser and navigating to the NDES URL gave the same information but also showed that the source of this error was the Azure AD Application Proxy. From that I figured that there was a communication error between the AAD Application proxy and the NDES server. 

I remembered that I hadn't reconfigured the Site Bindings in IIS to use the new NDES SSL certificate. Once I did that and executed another IIS Reset, the certificates started to fly and the customer was back in business with SCEP and 802.1x authentication.

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

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