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 an Authentication Key Binding.
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:
openssl s_client -connect <IP of Domain Controller>:636-showcertsThe output should display the certificate intended for the LDAPS connection, including the DNS name of the host as a Subject Alternative Name.
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
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.