--- title: "How to integrate with a Microsoft CA" slug: "clm-integrate-microsoft-ca" updated: 2026-11-06T14:57:46Z published: 2026-11-06T14:57:46Z canonical: "docs.senhasegura.io/clm-integrate-microsoft-ca" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.senhasegura.io/llms.txt > Use this file to discover all available pages before exploring further. # How to integrate with a Microsoft CA This document provides information on how to integrate with a Microsoft certificate authority. For more information about the Microsoft certificate authority fields, see [Certificate authorities](/v4-2/docs/certificate-manager-reference-supported-cas). ## Requirements - The following Active Directory (AD) access groups: - **Domain Users** - **Remote Management Users** - Permission on the certificate authority (CA). See [Enable permissions on the CA](/v4-2/docs/clm-integrate-microsoft-ca#enable-permissions-on-the-ca) for more information. - Permission to provide access to WinRM resources. See [Provide access to WinRM resources](/v4-2/docs/clm-integrate-microsoft-ca#provide-access-to-winrm-resources) for more information. - Permission to provide access to the WMI namespace. See [Provide access to the WMI namespace](/v4-2/docs/clm-integrate-microsoft-ca#provide-access-to-the-wmi-namespace) for more information. Info - If you don't want to provide granular non-administrative access as per the permissions, you can grant local administrator permission on the Microsoft CA. However, this practice isn't recommended as it grants excessive privileges, increasing the attack surface and potentially compromising the security of the system. It's crucial to minimize privileges to ensure the principle of least privilege and protect sensitive information. - The following procedures were tested and validated in Windows Server 2019. ## Enable permissions on the CA 1. On the CA object, click **Properties** > **Security**. 2. Enable the **Request certificate** permission. 3. Grant permission to the service user on the certificate template that will be used by CLM to sign certificates. 1. Open the CA console. 2. Click **Certificate Templates > Manage**. 3. In the new console, find the template and click **Properties**. 4. Go to the **Security** tab and add the service user you want to grant permission by clicking on the **Enroll** checkbox. 5. Click **OK** to save the changes. ## Provide access to WinRM resources 1. Open the command prompt and run the following commands: 1. `winrm configSDDL default` 1. After running the command, select the **Execute** permission in the **Allow** column. 2. `Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI` 1. After running the command, select the **Full Control (All Operations)** permission in the **Allow** column. ## Provide access to the WMI namespace 1. Open Windows' **Run** command, type `wmimgmt.msc` and press enter. 2. In the **WmiMgmt** console, click **Properties** under **WMIControl (Local)**. 3. In the **Security** tab, select **Root** and click **Security** to configure permissions. 4. Add the **Remote Management Users** group to the groups or user names section. 5. Select the added group and click **Advanced** to access the advanced security settings. 6. Edit the permissions to apply to "**This namespace and sub namespaces**". 7. Check the following permissions: 1. **Execute Methods** 2. **Enable Account** 3. **Remote Enable** ## Integrate with a Microsoft CA 1. On Segura™, in the navigation bar, hover over the **Products menu** and select **Certificate Manager**. 2. In the side menu, select **Management** > **Authorities** > **Certificate authorities**. 3. In the top right corner, click **Add**, and select **Microsoft CA**. 4. In the **Name *** field, enter a name to identify the CA. 5. Select the button **Status** to activate or deactivate the CA. 6. In the **IP for connection with CA *** field, enter the IP address of the connection. 7. In the **CA host name *** field, enter the CA host name. 1. To obtain the CA full host name, run the `certutil` command in the Microsoft CA server and copy the value of the **Config** line. 8. In the **Plugin for connection *** field, select the plugin for connection. 9. In the **Port** field, enter the port for connection. 10. In the **Access credential *** field, select the access credential. 11. Click **Save**. ## Certificate template Segura® signs each certificate with a certificate template from the Microsoft CA: - When you sign a request in the interface, you enter the template in the **Signing template** field, on the **Signing template** tab. The default template is `webserver`. - Requests created through the API use the `webserver` template. The service user needs the **Enroll** permission on every template you use. See [Enable permissions on the CA](/v4-2/docs/clm-integrate-microsoft-ca#enable-permissions-on-the-ca) for more information. Attention Automatic renewal does not keep the template of the original certificate. The renewed certificate is signed with the `webserver` template, so its validity period and other template settings can differ from the original certificate. ## Network Connector behavior Unlike the DigiCert and Let's Encrypt CAs, the Microsoft CA does not have a **Use Network Connector?** field. The connection route comes from the device linked to the **Access credential** you select: - If the device has a Network Connector configured, the CA uses that Network Connector to issue and revoke certificates. - If the device has no Network Connector, Segura® uses the default Network Connector configured for the environment. If the default Network Connector cannot open the tunnel, Segura® connects directly to the CA. If the device's own Network Connector is unreachable, Segura® never falls back to another route: - **Signing:** the request does not fail. It waits and retries automatically until the Network Connector comes back online. - **Revocation:** the revocation status changes to error, and Segura® does not retry it.