Microsoft Auto-enrollment Troubleshooting

This provides guidance for issues that may occur while configuring EJBCA for Microsoft Auto-enrollment.

For general EJBCA troubleshooting, see Troubleshooting Guide.

If none of the resolutions below help, enabling debug logging may provide useful information helping to resolve the issue.

Active Directory (LDAP) Connectivity

This covers issues related to connectivity between EJBCA and Active Directory.

Failing Connection Test

The following includes connection test fail messages and steps to follow to resolve the errors.

To test the Active Directory connection, click Test Connection on the Edit Autoenrollment Alias page while editing an auto-enrollment configuration alias in EJBCA.

Error Message: Active Directory connection test failed: Invalid credentials

Verify the bind account (AD User Login) name and format. Allowed formats are listed under Configure AD Connection in Microsoft Auto-enrollment Operations.
The user account in Active Directory may have expired.
New user accounts in Active Directory have User must change password on next logon set by default. If the account was created with this option, the password must be changed manually in Active Directory before it can be used.

Error Message: Active Directory connection test failed: YOURCOMPANY.COM

Ensure that the AD Domain Controller contains the FQDN of the domain controller in which the bind account exists. The valid format is hostname.domain.com.
Verify that ports 389 (LDAP) and 636 (LDAPS) are allowed through the firewall.

Error Message: Active Directory connection test failed: Certificate with serial number X and SAN Y issued by 'CN=Issuing CA' is NOT trusted... LDAPS ONLY

An Authentication Keybinding must be set up in order for EJBCA to trust the LDAPS Certificate. For instructions, see Setting up a Remote Authenticator.
If you have a Key Binding set up already, edit the Key Binding and make sure the issuing CA of the LDAPS Certificate is listed under Trusted Certificates (if not 'Any CA' is allowed).

Error Message: Active Directory connection test failed: Couldn't kickstart handshaking LDAPS ONLY

Make sure the Domain Controller has a valid LDAPS Certificate to present. On the DC machine, open run → mmc → Add/Remove snap-ins → Certificates → Computer Account → Local Computer and navigate to Certificates (Local Computer) → Personal. In this Certificate store, there must be at least one valid LDAPS Certificate available. This certificate can either be enrolled manually through EJBCA RA Web or by doing an initial enrollment on LDAP port 389.
Verify the LDAPS certificate presented by Active Directory by running the following command:
CODE
```
openssl s_client -connect <IP of Domain Controller>:636 -showcerts
```
The output should display the certificate intended for the LDAPS connection, including the DNS name of the host as a Subject Alternative Name.

Error Message: LDAP: error code 49 - 80090308: LdapErr: DSID-0C09050F, comment: AcceptSecurityContext error, data 52f, v4563^@

Make sure the service account is not a member of the Protected Users Security Group. This group does not permit LDAP Bind which EJBCA needs to connect to Active Directory.

Error Message: GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type RC4 with HMAC is not supported/enabled)^@

Make sure the service account in active directory has Kerberos AES 128 and 256 checked under the account tab for the respective service account.

Available MS Templates do not list any Certificate Templates

If the available MS Templates do not list any Certificate Templates, check the following.

Check Active Directory connection: Click Test Connection on the Edit Autoenrollment Alias page to verify that the message "Active Directory connection test was successful." is displayed on top of the page. If not, troubleshoot the connection issues in Failing Connection Test.
Ensure that the Forest Root Domain contains the name of the Forest root domain and not the domain name of the domain controller. This is because Certificate Templates are stored in the forest root, accessible to all domains in the forest.
Make sure the configuration is stored: If the AD connection was not established when the configuration page was rendered, it may be sufficient to click Save for the list to update.
ADVANCED If the issue persists, enable debug logging to provide additional information. With debug logging enabled, the assumed search path for Certificate Templates is displayed in the log when the connection is tested. For example:
```
LDAP Search Base: CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=YOURCOMPANY,DC=COM.
```
Verify the location of your Certificate Templates in Active Directory and compare it with this output.

Adding EJBCA as Policy Server

If an error occurs during the process of adding Certificate Enrollment Policy Server, it is likely caused by one of the following.

Connectivity issues between the domain controller and EJBCA

Verify connectivity between the hosts. The CEP Service in EJBCA is exposed on port 8442 by default.

Kerberos authentication failed

If there are no connectivity issues between the domain controller and EJBCA but the policy retrieval fails, there may be an issue with the Kerberos authentication.

Make sure the correct Key Tab file is uploaded to the alias in EJBCA CA UI and that it matches the specified SPN.
Verify the content of the uploaded krb5.conf file and that there is not a mismatch between the supported ciphers of the Key Tab file and the Kerberos configuration file.
An alias must be added to the CEP URL. Make sure the name of the autoenrollment configuration alias in EJBCA is added as follows https://ejbcaserver.yourcompany.com:8442/ejbca/msae/CEPService?alias
Domains should be lower case. The REALM must be upper case.

The domain controller does not have access to the Certificate Templates

Verify that the domain controller has access to at least one mapped certificate template while adding the policy URL. This is required because the client (DC in this case) expects a valid response, including templates, when clicking Validate Server (see Part 4: Configure Policy Server).

Enrollment and Auto-enrollment Issues

If the auto-enrollment configuration appears to be set up properly but users and computers fail to retrieve certificates, the following may help to narrow down the issue. The server log in EJBCA may provide useful information, especially if debug logging is enabled. However, a good starting point is to figure out whether the policy retrieval or the certificate request is failing. On any machine where enrollment fails, follow these steps logged in as Administrator:

Open Microsoft Management Console and go to Local Computer (run → mmc → Add/Remove snap-ins → Certificates → Computer Account → Local Computer).
Right-click Certificates, expand All tasks and select Request New Certificate.
Click Next, select the Certificate Enrollment Policy you wish to enroll for, and then click on Next again.
If the error message "An error occurred while obtaining certificate enrollment policy" is displayed in this step, proceed to Policy Retrieval Failed. If no error message is displayed, select your enrollment policy and click Enroll. Assuming that the enrollment failed, proceed to Certificate Enrollment Failed.

Policy Retrieval Failed

The error message "An error occurred while obtaining certificate enrollment policy" means that the client failed to retrieve enrollment policies from EJBCA. Note that this error does not necessarily mean that there's a connection issue. Clients will display this error even if a valid response is received, though not containing any enrollment policies. The following configuration should be revisited:

In EJBCA CA GUI, edit the alias you intend to use and verify that the user and computer templates are properly mapped to EJBCA profiles.
In Active Directory, verify the Access Control List of the Certificate Template(s). The requesting user/computer has to be given Read, Enroll and/or Autoenroll permissions on the template in order to retrieve the enrollment policy.

Certificate Enrollment Failed

Errors occurring during enrollment typically look like the dialog below, regardless of the actual issue.

If the policy retrieval works as expected but the client fails to enroll the certificate, the easiest way to narrow down the issue is by inspecting the CAPI2 log in the Windows Event Viewer:

Open the Event Viewer in the troubled machine and navigate to Application and Service Logs → Microsoft → Windows → CAPI2 → Operational.
Right-click the log file and select Enable Log.
Browse through the log and look for "Error" events and review the cause of the error under the Details tab.

If no critical issues are found on the client side, the EJBCA server log may reveal additional hints. The location of the EJBCA server log is /opt/wildfly/standalone/log/server.log.

Key Archival

When enrolling certificates using auto-enrollment, if the key archival option is enabled in the associated enrollment profile, you might face the following errors on the MS client side:

The error usually means that one or more CA certificates in the hierarchy of the CAs (which are considered as third party CAs) ending to the exchange certificate, are not trusted by the client side policy provider and need to be added to the list of trusted ones.

To solve this, log into the AD machine connected to EJBCA, and run the following command as Administrator from the power shell: (CaCertificate.cer is the certificate of the untrusted CA)s)):

CODE

Certutil -enterprise -addstore NTAuth CaCertificate.cer

Note that CaCertificate.cer is the certificate of the untrusted CA(s) and the command must be run for all unknown CAs.

For more information about the issue and how to resolve it, refer to the Microsoft troubleshooting article How to impo rt third-party certification authority (CA) certificates into the Enterprise NTAuth store.

The following error may also occur during the enrollment process:

TEXT

The revocation function was unable to check revocation because the revocation server was offline.

If the OCSP URL of the CAs in the hierarchy that ends with the exchange certificate is valid and accessible from the Microsoft domain side, the issue could be that the Certificate Revocation List (CRL) of one or more CAs is expired and needs to be renewed. To manage CRLs in EJBCA, navigate to the CA Structure & CRLs page, see CRL Generation.