Active Directory Connection issues

Dear All

I am actually trying to add AD application, but i am getting the below error, i am not able to figure it out where is the error.

I have imported the certificate and added in the keytool as well even after same error.

please let me know if someone faces this type of issue or how is it resolved.

[ InvalidConfigurationException ] [ Possible suggestions ] Ensure that SSL communication is in place with domain. [ Error details ] Failed to connect to - dc=cbq,dc=com,dc=qa : Failed to connect to server:ldap://: - javax.net.ssl.SSLHandshakeException: No name matching cbq.com.qa found

thanks,

Charan

hi @charankoona
This is a hostname mismatch issue, not a certificate import problem.

SSLHandshakeException: No name matching cbq.com.qa found

IIQ is connecting using cbq.com.qa, but the DC SSL certificate CN/SAN does not include that hostname (it’s usually issued to something like dc01.cbq.com.qa). Java enforces strict hostname validation, so the handshake fails even if the cert is trusted.

:white_check_mark: Fix:

  • Use the exact DC FQDN that matches the certificate in the AD application (e.g. ldaps://dc01.cbq.com.qa:636), or

  • Reissue the DC certificate and include cbq.com.qa in the SAN.

Importing the cert into the keystore alone will not resolve this.

same cert and configuration are working in my UAT server, but not in Prod Server.

what could be the issue please?

@charankoona Could you please confirm where are you trying to add your application? to your sandbox?

i am trying to add UAT ad to IIQ PROD

hi @charankoona
That explains it :+1:
You are trying to connect UAT AD from IIQ PROD, so this is expected to fail unless Prod is set up for it.

Things to check in IIQ PROD:

  1. Certificate trust

    • UAT DC SSL certificate must be imported into PROD IIQ’s JDK truststore

    • Importing it in UAT does not carry over to Prod

  2. DNS / hostname resolution

    • cbq.com.qa may resolve differently in Prod than in UAT

    • Prod may be hitting a different DC with a different cert

  3. Firewall / network access

    • PROD server must be allowed to connect to UAT DC on 636

    • This is often blocked by design

  4. Environment separation

    • Many orgs intentionally block PROD → UAT LDAP for security

    • Even if cert/config is correct, connection may not be allowed

:white_check_mark: Quick test from PROD IIQ server:

openssl s_client -connect :636

If this fails, it’s network/cert, not IIQ.

In short: working in UAT doesn’t matter — Prod must independently trust and reach UAT AD.

@charankoona In your Production server, try telnet to both IQService server and AD DC and see if it is being connected to it or not? This should be the good starting point for your troubleshooting. If connection drops, then something wrong with Port or certifications which you need to coordinate internally with your PKI or Network team.

The issue is Hostname mismatch between the LDAP URL and the SSL certificate.

Use the exact FQDN that matches the certificate (e.g., dc01.cbq.com.qa) in your LDAP URL. It should work post that.

hi @charankoona if the AD connection issue has been resolved, please consider marking the accepted solution.

Bro, have you faced this issue and resolved, I am getting this kind of information from AI tools but those will not provide me the proper solution

@naveenkumar3 thanks for the information, will it get resolved if I get new certificate and import as per the servers?

thanks @neel193 , let me work with windows and network teams

Hi @charankoona ,

To debug this further, you can use the non-SSL port 389 instead of the SSL port 636 if If the connection works, then it might be a certificate issue. You can ask the Windows team to regenerate the certificate with the required information and add cbq.com.qa in the alias name. I hope the alias name will work for this scenario.

Thanks,

PVR.

yes, it will get resolved , because the issue is Hostname mismatch between the LDAP URL and the SSL certificate.

Open the certificate and search for the dns entry in your certificate, and check it is correct.

thanks @Peddapolu , I have resolved the cert issue, bit looks like SailPoint is reading prod data instead of UAT :frowning:

@naveenkumar3 I am able to test and read the data successfully, but data is coming from production does not form the UAT DC :frowning:

Hi @charankoona Do you mean that the production and UAT environments use the same AD DC? Don’t you have different domain controllers? If it’s a different DC, make sure you’ve configured the DC at the connector level.

Thanks,

PVR.

@Peddapolu where can i configure the DC in connector level please?

is there any document available

Hi @charankoona ,

Below, in the screenshot highlighted in yellow, you can mention the domain name: prod, DC=sailpoint, DC=com. For stage, you can replace the DC like this: DC=sailpointstage, DC=com.

I hope it will help.

Thanks,

PVR.

do you get any error from UAT DC?? what is your configuration??