How to import third-party certification authority (CA) certificates into the Enterprise NTAuth store

There are two methods you can use to import the certificates of third-party CAs into the Enterprise NTAuth store. This process is required if you’re using a third-party CA to issue smart card logon or domain controller certificates. By publishing the CA certificate to the Enterprise NTAuth store, the Administrator indicates that the CA is trusted to issue certificates of these types. Windows CAs automatically publish their CA certificates to this store.

Original product version: В Windows Server 2016, Windows Server 2012 R2
Original KB number: В 295663

More information

The NTAuth store is an Active Directory directory service object that is located in the Configuration container of the forest. The Lightweight Directory Access Protocol (LDAP) distinguished name is similar to the following example:

CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=MyDomain,DC=com

Certificates that are published to the NTAuth store are written to the cACertificate multiple-valued attribute. There are two supported methods to append a certificate to this attribute.

Method 1 — Import a certificate by using the PKI Health Tool

PKI Health Tool (PKIView) is an MMC snap-in component. It displays the status of one or more Microsoft Windows CAs that comprise a PKI. It’s available as part of the Windows Server 2003 Resource Kit Tools.

PKIView gathers information about the CA certificates and certificate revocation lists (CRLs) from each CA in the enterprise. Then it validates the certificates and CRLs to ensure that they’re working correctly. If they aren’t working correctly, or they’re about to fail, PKIView provides a detailed warning or some error information.

PKIView displays the status of Windows Server 2003 CAs that are installed in an Active Directory forest. You can use PKIView to discover all PKI components, including subordinate and root CAs that are associated with an enterprise CA. The tool can also manage important PKI containers, such as root CA trust and NTAuth stores, that are also contained in the configuration partition of an Active Directory forest. This article discusses this latter functionality. For more information about PKIView, see the Microsoft Windows Server 2003 Resource Kit Tools documentation.

You can use PKIView to manage both Windows 2000 CAs and Windows Server 2003 CAs. To install the Windows Server 2003 Resource Kit Tools, your computer must be running Windows XP or later.

To import a CA certificate into the Enterprise NTAuth store, follow these steps:

Export the certificate of the CA to a .cer file. The following file formats are supported:

• DER encoded binary X.509 (.cer)
• Base-64 encoded X.509 (.cer)

Install the Windows Server 2003 Resource Kit Tools. The tools package requires Windows XP or later.

Start Microsoft Management Console (Mmc.exe), and then add the PKI Health snap-in:

1. On the Console menu, select Add/Remove Snap-in.
2. Select the Standalone tab, and then select the Add button.
3. In the list of snap-ins, select Enterprise PKI.
4. Select Add, and then select Close.
5. Select OK.

Right-click Enterprise PKI, and then select Manage AD Containers.

Select the NTAuthCertificates tab, and then select Add.

On the File menu, select Open.

Locate and then select the CA certificate, and then select OK to complete the import.

Method 2 — Import a certificate by using Certutil.exe

Certutil.exe is a command-line utility for managing a Windows CA. In Windows Server 2003, you can use Certutil.exe to publish certificates to Active Directory. Certutil.exe is installed with Windows Server 2003. It is also available as part of the Microsoft Windows Server 2003 Administration Tools Pack.

To import a CA certificate into the Enterprise NTAuth store, follow these steps:

Export the certificate of the CA to a .cer file. The following file formats are supported:

• DER encoded binary X.509 (.cer)
• Base-64 encoded X.509 (.cer)

At a command prompt, type the following command, and then press ENTER:

The contents of the NTAuth store are cached in the following registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates

This registry key should be automatically updated to reflect the certificates that are published to the NTAuth store in the Active Directory configuration container. This behavior occurs when Group Policy settings are updated and when the client-side extension that’s responsible for autoenrollment executes. In certain scenarios, such as Active Directory replication latency or when the Do not enroll certificates automatically policy setting is enabled, the registry isn’t updated. In such scenarios, run the following command manually to insert the certificate into the registry location:

Microsoft recommended driver block rules

Applies to:

• WindowsВ 10
• WindowsВ Server 2016 and above

Microsoft has strict requirements for code running in kernel. Consequently, malicious actors are turning to exploit vulnerabilities in legitimate and signed kernel drivers to run malware in kernel. One of the many strengths of the Windows platform is our strong collaboration with independent hardware vendors (IHVs) and OEMs. Microsoft works closely with our IHVs and security community to ensure the highest level of driver security for our customers and when vulnerabilities in drivers do arise, that they are patched and rolled out to the ecosystem in an expedited manner. Microsoft then adds the vulnerable versions of the drivers to our ecosystem block policy which is applied to the following sets of devices:

• Hypervisor-protected code integrity (HVCI) enabled devices
• Windows 10 in S mode (S mode) devices

Microsoft recommends enabling HVCI or S mode to protect your devices against security threats. If this is not possible, Microsoft recommends blocking the following list of drivers by merging this policy with your existing Windows Defender Application Control policy. Blocking kernel drivers without sufficient testing can result in devices or software to malfunction, and in rare cases, blue screen. It is recommended to first validate this policy in audit mode and review the audit block events.

This application list will be updated with the latest vendor information as application vulnerabilities are resolved and new issues are discovered. It is recommended that this policy be first validated in audit mode before rolling the rules into enforcement mode.

Add partner certification authority in Intune using SCEP

Use third-party certification authorities (CA) with Intune. Third-party CAs can provision mobile devices with new or renewed certificates by using the Simple Certificate Enrollment Protocol (SCEP), and can support Windows, iOS/iPadOS, Android, and macOS devices.

There are two parts to using this feature: open-source API, and the Intune administrator tasks.

Part 1 — Use an open-source API
Microsoft created an API to integrate with Intune. Though the API you can validate certificates, send success or failure notifications, and use SSL, specifically SSL socket factory, to communicate with Intune.

The API is available on the Intune SCEP API public GitHub repository for you to download, and use in your solutions. Use this API with third-party SCEP servers to run custom challenge validation against Intune before SCEP provisions a certificate to a device.

Integrate with Intune SCEP management solution provides more details on using the API, its methods, and testing the solution you build.

Part 2 — Create the application and profile
Using an Azure Active Directory (Azure AD) application, you can delegate rights to Intune to handle SCEP requests coming from devices. The Azure AD application includes application ID and authentication key values that are used within the API solution the developer creates. Administrators then create and deploy SCEP certificates profiles using Intune and can view reports on the deployment status on the devices.

This article provides an overview of this feature from an Administrator-perspective, including creating the Azure AD application.

Overview

The following steps provide an overview of using SCEP for certificates in Intune:

1. In Intune, an administrator creates a SCEP certificate profile, and then targets the profile to users or devices.
2. The device checks in to Intune.
3. Intune creates a unique SCEP challenge. It also adds additional integrity-check information, such as what the expected subject and SAN should be.
4. Intune encrypts and signs both the challenge and integrity-check information, and then sends this information to the device with the SCEP request.
5. The device generates a certificate signing request (CSR) and public/private key pair on the device based on the SCEP certificate profile that’s pushed from Intune.
6. The CSR and encrypted/signed challenge are sent to the third-party SCEP server endpoint.
7. The SCEP server sends the CSR and the challenge to Intune. Intune then validates the signature, decrypts the payload, and compares the CSR to the integrity-check information.
8. Intune sends back a response to the SCEP server, and states whether the challenge validation is successful or not.
9. If the challenge is successfully verified, then the SCEP server issues the certificate to the device.

The following diagram shows a detailed flow of third-party SCEP integration with Intune:

Set up third-party CA integration

Validate third-party certification authority

Before integrating third-party certification authorities with Intune, confirm that the CA you’re using supports Intune. Third-party CA partners (in this article) includes a list. You can also check your certification authority’s guidance for more information. The CA may include setup instructions specific to their implementation.

To support Android Enterprise Device Owner devices, the CA must support use of an HTTPS URL when you configure the HTTP Server URL for the SCEP certificate profile.

Authorize communication between CA and Intune

To allow a third-party SCEP server to run custom challenge validation with Intune, create an app in Azure AD. This app gives delegated rights to Intune to validate SCEP requests.

Be sure you have the required permissions to register an Azure AD app. See Required permissions, in the Azure AD documentation.

Create an application in Azure Active Directory

In the Azure portal, go to Azure Active Directory > App Registrations, and then select New registration.

On the Register an application page, specify the following details:

• In the Name section, enter a meaningful application name.
• For the Supported account types section, select Accounts in any organizational directory.
• For Redirect URI, leave the default of Web, and then specify the sign-on URL for the third-party SCEP server.

Select Register to create the application and to open the Overview page for the new app.

On the app Overview page, copy the Application (client) ID value and record it for later use. You’ll need this value later.

In the navigation pane for the app, go to Certificates & secrets under Manage. Select the New client secret button. Enter a value in Description, select any option for Expires, and then and choose Add to generate a value for the client secret.

Before you leave this page, copy the value for the client secret and record it for later use with your third-party CA implementation. This value is not shown again. Be sure to review the guidance for your third-party CA on how they want the Application ID, Authentication Key, and Tenant ID configured.

Record your Tenant ID. The Tenant ID is the domain text after the @ sign in your account. For example, if your account is admin@name.onmicrosoft.com, then your tenant ID is name.onmicrosoft.com.

In the navigation pane for the app, go to API permissions under Manage, and then select Add a permission.

On the Request API permissions page, select Intune, and then select Application permissions. Select the checkbox for scep_challenge_provider (SCEP challenge validation).

Select Add permissions to save this configuration.

Remain on the API permissions page, and select Grant admin consent for Microsoft, and then select Yes.

The app registration process in Azure AD is complete.

Configure and deploy a SCEP certificate profile

As the administrator, create a SCEP certificate profile to target to users or devices. Then, assign the profile.

Removing certificates

When you unenroll or wipe the device, the certificates are removed. The certificates aren’t revoked.

Third-party certification authority partners

The following third-party certification authorities support Intune:

If you’re a third-party CA interested in integrating your product with Intune, review the API guidance:

Microsoft windows third party component ca 2014

A Simple PE File Signature information Extracting Tool.

This program is used to get signature information from PE files which signed by a/some embedded code signature certificate(s) on Windows. Supporting multi-signed file info and certificates chain. Runned on Windows Vista, Windows 7, or later OS platform.

This code uses CryptoAPIs to parse the signature and certificate data from specified file, supporting many file types, such as .exe, .cat(catalog file), .dll, .sys, etc.

这个程序用来从由1个或多个嵌入式代码签名证书所签名的PE文件中获取签名信息。支持多签名文件信息和证书链的提取。运行在Windows Vista，Windows 7，及更新的操作系统平台。

这份代码使用 CryptoAPIs 来解析指定文件中的签名和证书数据，支持多种文件类型，包括exe，cat（catalog文件），dll，sys等格式。

Developer can compile this program with Microsoft Visual Studio 2008 or later version Visual Studio. The target binary file will be built at Debug or Release folder, depending on which compiling method developers select.

开发者可以通过Microsoft Visual Studio 2008或更新版本的Visual Studio来编译这个程序。目标二进制文件会在Debug或Release目录生成，这取决于开发者选择何种编译方式。

This code does not use WinVerifyTrust to verify and retrieve signature and certificate information, but CryptoAPIs instead.

It might also be noted that this program supports analyzing multi-signed PE files, even though on the OS platforms which does not support multi-signature detecting, such as Windows 7, Windows Vista, etc. Multi-signed PE file means that this file has been signed by more than one embedded code signature certificate.

If you transfer the path to a multi-signatured file into PESignAnalyzer process, it will show the target information as below. Every [The X Sign Info] means a chunk of completed information of a signature block.

这份代码没有使用 WinVerifyTrust 来验证和获取签名证书信息，而是用 CryptoAPIs 代替。

需要注意的是，这个程序支持解析多签名的PE文件，即使是在诸如Windows 7，Windows Vista这种不支持多签名检测的操作系统平台上。多签名的PE文件意味着这个文件已经被多个嵌入式代码签名证书所签名了。

如果你将一个多签名文件的路径作为参数传递给PESignAnalyzer的二进制文件，它会展示如下所示的信息。 每一个 [The X Sign Info] 意味着一个签名的完整信息。

If you have any questions or problems, you can contact with me: leeqwind123@outlook.com

About

This program can retrieve signature information from PE files which signed by one or more certificates on Windows. Supporting multi-signed (nested) infomation and certificate-chain.