Aria Operations for Logs Active Directory Integration Fails on Port 636 Due to SSL Certificate Issue

Products

• VMware Aria Suite

Issue/Introduction

• Users may encounter issues configuring Active Directory (AD) integration in Aria Operations for Logs when attempting to use port 636 (LDAPS) for secure communication.

• While port 389 (LDAP) connections are successful, connections on port 636 fail with an "AD authentication failed" error.

  • Port 389 Connection Test (uses "Standard" Connection Type)

• • Port 636 Connection Test (uses "Standard" Connection Type and "Require SSL" box should be checked)

• Error messages observed in /storage/core/loginsight/var/runtime.log shows No subject alternative names matching IP address ##.##.##.## found.] error 
  
    ["application-akka.actor.default-dispatcher-6569"/ WARN] [com.vmware.loginsight.aaa.ad.ActiveDirectoryValidator] [Unable to validate Active Directory credentials. Please check your Active Directory DNS name, port, and SSL settings as well as your username and password.;
CertificateException: No subject alternative names matching IP address ##.##.##.## found]
["application-akka.actor.default-dispatcher-6569"/ INFO] [com.vmware.loginsight.api.providers.ad.ADProvider] [Failed validation of AD Domain.] com.vmware.loginsight.commons.exceptions.AuthenticationException: Unable to validate Active Directory credentials. Please check your Active Directory DNS name, port, and SSL settings as well as your username and password.
Caused by: com.vmware.loginsight.commons.exceptions.AuthenticationException: Invalid or untrusted domain '<Your Domain name >'.
Caused by: javax.naming.CommunicationException: simple bind failed: ##.##.##.##:636
Caused by: javax.net.ssl.SSLHandshakeException: No subject alternative names matching IP address ##.##.##.## found
[2025-02-26 06:57:24.266+0000] ["application-akka.actor.default-dispatcher-6569"/WARN] [globals.GlobalErrorHandler] [API Provider raised handled error when processing POST /api/v2/ad/test: {"errorMessage":"AD authentication failed.","errorCode":"TEST_ERROR","errorDetails":{"errorCode":"com.vmware.loginsight.api.errors.wrong_credentials"}}]    

• or This error may also appear in the logs located at /storage/core/loginsight/var/runtime.log
  
  

  ["application-akka.actor.default-dispatcher-262"/10.40.2.42 INFO] [com.vmware.loginsight.api.providers.ad.ADProvider] [Failed
validation of AD Domain.]
com.vmware.loginsight.commons.exceptions.AuthenticationException: Unable to validate Active Directory credentials. Please check your Active Directory DNS nam
e, port, and SSL settings as well as your username and password.
        at com.vmware.loginsight.aaa.ad.ActiveDirectoryValidator.validateActiveDirectoryConnection(ActiveDirectoryValidator.java:109) ~[auth-lib.jar:?]
        at com.vmware.loginsight.api.providers.ad.ADProvider.validateConnection(ADProvider.java:215) ~[webservice-providers-lib.jar:?]
        at com.vmware.loginsight.api.providers.ad.ADProvider.testADAuthenticationConfig(ADProvider.java:142) ~[webservice-providers-lib.jar:?]
        at controllers.ADConfigurationController.testAD(ADConfigurationController.java:52) ~[api-play-service_2.13-1.0.jar:2.9.1]
        at router.Routes$$anonfun$routes$1.$anonfun$applyOrElse$794(Routes.scala:15975) ~[api-play-service_2.13-1.0.jar:1.0]
        at play.core.routing.HandlerInvokerFactory$$anon$8.resultCall(HandlerInvoker.scala:160) ~[play_2.13-2.9.1.jar:2.9.1]
        at play.core.routing.HandlerInvokerFactory$JavaActionInvokerFactory$$anon$3$$anon$4$$anon$5.invocation(HandlerInvoker.scala:125) ~[play_2.13-2.9.1.ja
r:2.9.1]

          at java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source) [?:?]
Caused by: com.vmware.loginsight.commons.exceptions.AuthenticationException: Invalid or untrusted domain '<Your Domain name >'.
        at com.vmware.loginsight.aaa.krb5.ActiveDirectoryQueryHelper.getActiveDirectoryConfigurationAttributes(ActiveDirectoryQueryHelper.java:972) ~[auth-lib.jar:?]
        at com.vmware.loginsight.aaa.ad.ActiveDirectoryValidator.validateActiveDirectoryConnection(ActiveDirectoryValidator.java:102) ~[auth-lib.jar:?]
        ... 44 more
Caused by: javax.naming.CommunicationException: simple bind failed: <Your Domain name >:636
        at com.sun.jndi.ldap.LdapClient.authenticate(Unknown Source) ~[?:?]
        at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source) ~[?:?]
        at com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source) ~[?:?]
        at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxFromUrl(Unknown Source) ~[?:?]
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(Unknown Source) ~[?:?]
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(Unknown Source) ~[?:?]
        at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(Unknown Source) ~[?:?]
        at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(Unknown Source) ~[?:?]
        at javax.naming.spi.NamingManager.getInitialContext(Unknown Source) ~[?:?]
        at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source) ~[?:?]
        at javax.naming.InitialContext.init(Unknown Source) ~[?:?]

• A name resolution check using the nslookup command to the Active Directory domain controller and DNS server failed, resulting in a communication error.
  
                      <Login UserName>@<Hostname> [ ~ ]# nslookup < Your Domain Name >
             ;; communications error to ##.##.##.#53: timed out
             ;; communications error to ##.##.##.#53: timed out
             <Login UserName>@<Hostname> [ ~ ]# nslookup <DNS Server IP or FQDN >
             ;; communications error to ##.##.##.#53:: timed out
             ;; communications error to ##.##.##.#53:: timed out
  
  
• curl -v telnet://AD-FQDNorIP:636 failed with "Could not resolve host." &  curl -v telnet://AD-FQDNorIP:636 failed with "curl: (56) Recv failure: Connection reset by peer"
      
      <Login UserName>@<Hostname> [ ~ ]# curl -v telnet://< Your Domain Name >:636
   * Could not resolve host: < Your Domain Name >
   * Closing connection
    curl: (6) Could not resolve host: < Your Domain Name >
    
    <Login UserName>@<Hostname>[ ~ ]# curl -v telnet://< Your Domain Name >:636
    * Host < Your Domain Name >:636 was resolved.
    * IPv6: (none)
    * IPv4: ##.##.##.##
    *   Trying ##.##.##.##:636...
    * Connected to < Your Domain Name > (##.##.##.##) port 636
    * Recv failure: Connection reset by peer
    * Closing connection
     curl: (56) Recv failure: Connection reset by peer
  
  
• A ping test to domain controller failed with the error "temporary name resolution failed"
  
  
• Certificate check failed with no peer certificate available message for the affected Domain Controller
  
  <Login UserName>@<Hostname> [ ~ ]# openssl s_client -connect <Domain Controller Name>:636 -tls1_2
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 320 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
  
  

Environment

• Aria Operations for Logs 8.18.3
• Aria Operations for Logs 8.x

Cause

• "Temporary name resolution failed", "Could not resolve host", or "communications error to ##.##.##.##.#53: timed out" typically occur when the DNS or IP address configuration is incorrect in the Aria Operations for Logs setup.

• curl: (56) Recv failure: Connection reset by peer or "no peer certificate available" messages indicate either that the domain controller lacks an SSL certificate or that firewall port 636 is blocked.

• "CertificateException: No subject alternative names matching IP address ##.##.##.## found": 

  It points to a problem with the SSL certificate used by the AD server. The certificate does not contain the IP address in its Subject Alternative Name (SAN) field. This is a common requirement for secure LDAP (LDAPS) connections.

  Specifically, the certificate lacks the necessary Subject Alternative Name (SAN) entry for the IP address used by Aria Operations for Logs to connect. This prevents successful SSL handshake and LDAPS connection establishment.

• "javax.naming.CommunicationException: simple bind failed: ##.##.##.## :636": 

  This indicates that the Aria Logs instance is unable to establish a connection to the AD server on port 636 (LDAPS). This is directly caused by the SSL certificate issue.

Resolution

 Verify Network Configuration:

• Ensure that the Aria Operations for Logs appliance has the correct IP address and DNS configurations.

• Verify that DNS is correctly resolving the FQDN of the active directory server.

 Firewall Settings:

• Confirm that port 636 is open at the firewall level to allow secure communication.

Check SSL Certificate on the Domain Controller:

• Ensure that a valid SSL certificate is installed.
• Verify that the certificate includes the following SAN (Subject Alternative Name) fields:
• The Fully Qualified Domain Name (FQDN) of the domain controller.
• The IP address of the domain controller.
• If the IP address is missing, generate a new certificate that includes both required SAN entries.

Update Aria Logs Configuration:

• Navigate to: Configuration > Authentication > Active Directory
• Replace the IP address with the FQDN of the domain controller.
• Ensure "Require SSL" is selected.
• Set the Connection Type to Standard.

Retry Authentication:

• Re-test the connection by going to: Configuration > Authentication > Active Directory
• If authentication is successful, save the configuration.
  
  

 

 

Additional Information

• While using the FQDN provides a workaround, it is strongly recommended that the Active Directory server administrator regenerate the SSL certificate to include the IP address in the Subject Alternative Name (SAN) field. This ensures long-term security and compliance.