MiCollab IDS with Authentication connection issue 2

[Valamagules]

Hi All

Having this issue with AD LDAP connection to MiCollab IDS with Authentication.
Had done this a few times with no issues, getting this error -

[root@micollab ~]# tail -f /var/log/ids-**FQDN/current
Can't contact LDAP server ldap://**FQDN:636 [ids-ad-sync:444]
SERVER_DOWN: {'desc': "Can't contact LDAP server"}
UNAVAILABLE: {'info': '00000000: LdapErr: DSID-0C09102C, comment: Error initializing SSL/TLS, data 0, v2580', 'desc': 'Server is unavailable'}

The following is confirmed working -
- AD people has confirmed that AD is enabled for SSL/TLS connection
- Telnet to port 636 and 389 works - connects
- Mitel CA root cert has been uploaded to AD / rebooted
- MiCollab has a valid SSL (wildcard)
- Works with unsecure (no authentication) but I need authentication enabled

Any ideas?

Clever men learns what Wise men shares!

 

[techymitel]

You can use this command from the shell on MSL to check the connection to the AD server.

openssl s_client -showcerts -connect AD_SERVER:PORT

eg. openssl s_client -showcerts -connect 192.168.1.2:636

You should see lots of certificate information. If you see things like 'no peer certificate available' then the AD server certs need attention.

 

[Valamagules]

Thanks @techymitel

I get this output -

[root@micollab ~]# openssl s_client -showcerts -connect **FQDN:636
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE

But gets connected when ssl3
[root@micollab ~]# openssl s_client -showcerts -connect **FQDN:636 -ssl3

Any thoughts?



Clever men learns what Wise men shares!

 

[techymitel]

The AD server is not sending the MiCollab server the information it needs to establish a secure connection.

The AD server sends it's public key in the certificate. The MiCollab server would use the public key to encrypt data and send it to the AD server. The AD server uses it's private key to decrypt the data. Without the certificate, we can't encrypt the data, so without the certificate we can't establish a secure connection.

It's likely the AD servers own certificate has expired. Or maybe the certificate bindings for port 636 have been removed. There is nothing you can do about it on the MiCollab server. You will have to ask the AD administrator to fix this.

If you use the same command on google.com:443 you will see an example of certs being sent correctly.

 

[Valamagules]

Thanks Mate.

I asked customer to test with ldp tool on the server and they got LDAP error 81.

Have asked them to check further using this link as a base reference:

https://docs.microsoft.com/en-us/pr...nd-2008/cc725767(v=ws.10)?redirectedfrom=MSDN

I am thinking it could be read permissions (step 2)

Will update thread again shortly.



Clever men learns what Wise men shares!

 

[Valamagules]

In the end, it was the AD server not enabled for SSL.
Issue resolved once this was turned on.

Clever men learns what Wise men shares!