Disabling Active Directory integration (for this domain)


Article ID: 38306


Updated On:


CA Release Automation - Release Operations Center (Nolio) CA Release Automation - DataManagement Server (Nolio)



After following the steps to configure Release Automation with LDAPS I am still not able to login with an ldap user. 

Steps available here: https://docops.ca.com/ca-release-automation/5-5-2/en/administration/enable-ldap-integration



Release Automation 5.5.2

Active Directory via SSL/LDAP/LDAPS



First, it should be made clear that there are two ways to integrate with LDAP/LDAPS:

  1. Using the Administration -> User Import (which does not require any distributed.properties file updates); and
  2. Using the Administration -> Group Import (which does require distributed.properties file updates)


With that said, the problem described above and the discussion below assumes you are using Group Imports with updates to the distributed.properties file. But, Cause & Solution #2 can apply to problems while trying to import users (while using LDAPS). 

  1. If any of the fields in the distributed.properties file (related to the LDAP integration) are misconfigured then it can cause this problem. And if any of the fields are not configured properly then the connection to LDAP will not work - usually with a message in the nolio_dm_all.log file indicating as much:

    2016-02-17 15:43:49,601 [localhost-startStop-1] ERROR (com.nolio.platform.server.dataservices.services.auth.providers.NolioActiveDirectoryAuthenticationProvider:57) - Found a NON working system user [U: <yourLdapUser>@<domainName>, DC: <domainName>]. Disabling Active Directory integration (for this domain)

  2. If all of the configuration entries are correct and you are using LDAPS then the problem may be related Release Automation not trusting the certificate. In this case you will typically see a message similar to the following in the nolio_dm_all.log:

    [Root exception is javax.net.ssl.SSLException: PKIX path building failed:
    sun.security.proivder.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]



The resolution depends on the cause. Ideas to help confirm the various settings that could be problematic are available in the "Additional Information" section below. Once the cause (1 or 2) has been determined then use the the product documentation "Enable LDAP Integration"  as a guideline in identifying the appropriate files to update.

Based on the guideline, and depending on the cause, the solution generally follows this principle:

  1. Update the appropriate configuration files (like the distributed.properties file) if you determine it is a configuration issue.
  2. Update the appropriate key/truststore file used by RA if you determine it is a certificate trust problem. Take care here. The "Enable LDAP Integration" page makes some recommendations based on an assumption that the steps from the "Secure Communications" page have been taken. If you have not followed the steps in the "Secure Communications" page then it is not a problem. Import the LDAPS certificate into the jre/lib/security/cacerts truststore instead of importing the LDAPS certificate into conf/custom-truststore.jks.


Additional Information:

Ideas to help validate configuration settings:

  1. Use the log messages above to understand if you are receiving either of those messages. If not then Release Automation may have been successful in its attempt to bind with your LDAP server and the problem is related to something other than cause 1 or 2. 

  2. If you are getting the message mentioned for cause #1 then the bind to LDAP is failing. It might be easier to verify the connection settings by logging into ASAP (as superuser), go to Administration -> User Management. Then, under either Users or Groups choose the option to Import from LDAP. The point of this exercise is to fill out all of the relevant fields using the same values provided to the distributed.properties file and validate. Make sure to use the Active Directory and Use SSL checkboxes if applicable. Then click Load and make sure it is able to see users/groups. If not then:
    • If LDAPS is being used then check the nolio_dm_all.log file for the message given for "cause #2" above. 
    • If LDAPS is NOT used or the Certificate is being properly trusted then the nolio_dm_all.log file should indicate the failure. If not then there is debug logging that can be enabled for these specific modules. Enable it (outlined below), stop/start services, and then reproduce to get the ldap error message.
      • Edit the file: <NACInstallDir>/webapps/datamagement/WEB-INF/log4j.properties
        #log4j.logger.org.springframework.security=DEBUG, Spring

  3. If LDAPS is desired then make sure:
    • the ldaps certificate has been imported into the appropriate truststore.
    • the distributed.properties use.active.directory.url is set to "ldaps://" and the appropriate port (default 636). ex: ldaps://myServerName:636


Component: RACORE