Hi, I would prefer to use LDAPS, but I've failed so far in my attempts to get that setup on the AD DC...
Microsoft KB article 321051 (titled: "How to enable LDAP over SSL with a third-party certification authority") states: "...The Active Directory fully qualified domain name of the domain controller (for example, DC01.DOMAIN.COM) must appear in one of the following places: The Common Name (CN) in the Subject field OR DNS entry in the Subject Alternative Name extension..." I can't place it in the subject field as no CA will issue a certificate with a FQDN that's "private" (.local). Also, it seems overkill to have to setup ADCS just to get this working... For testing, I've tried generating a cert with an SAN extension DNS entry that corresponds to the internal FQDN of the DC. I used the certreq utility (with a SAN extension defined in the request.inf file) to generate the CSR, as per KB article 321051. That works (verified here: http://www.sslshopper.com/csr-decoder.html which shows the correct SAN extension DNS value). Sort of... The CA (cacert.org) strips out the SAN extension from the request with error message: "...the following hostnames were rejected..." Due to the fact that the FQDN of the SAN extension value is a "private" (.local) DNS suffix. I haven't tried yet with another CA yet (i.e. rapidssl.com), but I suspect it will be the same problem. Since the FQDN in the SAN extension has a DNS suffix that's "private" (i.e. .local), the CSR will get rejected by the CA. Given the requirements stated in KB article 321051, I must have the FQDN of the DC in the SAN extention fields in order for the DC to accept the cert for LDAPS use. Because of this issue, I can't enable LDAPS on the DC. I might try to generate a self-signed certificate as I'm not sure how else I can work around this issue. Any ideas? Thanks, Alan From: Clément OUDOT [mailto:[email protected]] Sent: Monday, January 13, 2014 3:05 AM To: Yann Cézard Cc: Alan Osborne; [email protected] Subject: Re: [Ltb-users] Can't change password using LTB SSP with AD LDAP 2014/1/11 Yann Cézard <[email protected]<mailto:[email protected]>> On 11/01/2014 11:03, Alan Osborne wrote: Based on the connection properties in LDAP Admin (neither the SSL or TLS checkboxes are enabled) the connection should be unencrypted... A netstat confirms that LDAP Admin is connecting to port 389 on the server. LDAP+TLS use the standard 389 port. Just check witch tcpdump/wireshark to find out if TLS is on or not ;-) See http://www.ldapadmin.org/docs/faq.html Seems ldapadmin uses windows API and not SSL lib to manage SSL. That's probably why you believe you are not using SSL or TLS to change password on AD. As far as I know, SSL/TLS is mandatory to change password on AD. Just configure it to make SSP work. Clément.
_______________________________________________ ltb-users mailing list [email protected] http://lists.ltb-project.org/listinfo/ltb-users
