when using secure channel on port 636 for the LDAP servers the encryption is verified by a Fingerprint against the AD servers certificate. When this certificate is updated in AD you must 'Fetch' a new fingerprint or this connection will not continue to work.
This could be a complicated task to know about and remember.
Solution:
CP solutions is to simply delete the fingerprint and leave that field blank, now you would never have this problem. The downside is you have an increased risk for man-in-the-middle attack.
Another solution would be to have 1 AD server with higher priority and keep that on standard port 389 not encrypted. Then monitor the log for traffic for that host, then you know you have problem with a encrypted AD server. This is also a security risk since all user password will be sent in clear text. So in my mind the first solution is a better choice.
This could be a complicated task to know about and remember.
Solution:
CP solutions is to simply delete the fingerprint and leave that field blank, now you would never have this problem. The downside is you have an increased risk for man-in-the-middle attack.
Another solution would be to have 1 AD server with higher priority and keep that on standard port 389 not encrypted. Then monitor the log for traffic for that host, then you know you have problem with a encrypted AD server. This is also a security risk since all user password will be sent in clear text. So in my mind the first solution is a better choice.
No comments:
Post a Comment