Argh, damn small keyboards! :o) On Sun, Mar 4, 2012 at 3:33 PM, Linus van Geuns <[email protected]> wrote:
> Hey Peter, > > On Sun, Mar 4, 2012 at 4:07 AM, Peter Hawkins <[email protected]>wrote: > >> Hi all >> >> I'm a bit of a newbie with LDAPS but I have been asked to perform an LDAPS >> authentication from a unix server to a windows server, but I cannot get >> it to bind. >> > > Does Active Directory still lack support for StartTLS? > If Microsoft implemented StartTLS, you should prefer that over LDAP over > SSL (LDAPS). > Once you've solved your certificate issues, you can try StartTLS using > e.g. ldapsearch -ZZ ... > > >> >> >> The windows admin supplied a username, a password, an IP address and a >> certificate >> (eLearningPublic.cer) but they don't know their Bind-DN. >> > > AFAIR, Microsoft Active Directory supports using "{loginname}@{dnsdomain}" > as "bind DN". Something like "[email protected]" where "phawkins" > would be your "{loginname}" and "gvmedia.com.au" your Windows > "{dnsdomain}". > > >> >> I used #strings to look in the certificate to see what the hostname seemed >> to be and the following string is in the certificate: >> >> mldshomdsp01.ce.xyz.com.au >> >> This does not seem to resolve publically but I assume that's the hostname >> used to create the certificate. I put an entry into /etc/hosts to have >> this resolve to the IP they gave me. >> > > Here are some commands that might held with analyzing your certificate: > > openssl x509 -noout -subject -issuer -startdate -enddate > -in eLearningPublic.cer > openssl x509 -noout -text -in eLearningPublic.cer > certtool -i --infile eLearningPublic.cer > > >> >> >> I installed the certificate in a /usr/local/etc/openldap/certs and placed >> the following in my ldap.conf: >> >> TLS_REQCERT never >> TLS_CACERT /usr/local/etc/openldap/certs/eLearningPublic.cer >> >> I then looked at the certificate to try and find the bind-DN >> >> # openssl s_client -connect mldshomdsp01.ce.xyz.com.au:636 -CAfile >> /usr/local/etc/openldap/certs/eLearningPublic.cer >> >> CONNECTED(00000003) >> depth=0 /CN=mldshomdsp01.ce.xyz.com.au >> verify error:num=20:unable to get local issuer certificate >> verify return:1 >> depth=0 /CN=mldshomdsp01.ce.xyz.com.au >> verify error:num=21:unable to verify the first certificate >> verify return:1 >> --- >> Certificate chain >> 0 s:/CN=mldshomdsp01.ce.xyz.com.au >> i:/CN=mldshomdsp01.ce.xyz.com.au >> --- >> Server certificate >> -----BEGIN CERTIFICATE----- >> >> < SNIP...> >> >> -----END CERTIFICATE----- >> subject=/CN=mldshomdsp01.ce.xyz.com.au >> issuer=/CN=mldshomdsp01.ce.xyz.com.au >> --- >> Acceptable client certificate CA names >> /DC=au/DC=com/DC=xyz/DC=ce/CN=Internal Company Root CA >> /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority >> /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE >> CyberTrust Global Root >> /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft >> Corporation/CN=Microsoft Root Authority >> /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority >> /CN=NT AUTHORITY >> --- >> SSL handshake has read 1291 bytes and written 346 bytes >> --- >> New, TLSv1/SSLv3, Cipher is AES128-SHA >> Server public key is 1024 bit >> Compression: NONE >> Expansion: NONE >> SSL-Session: >> Protocol : TLSv1 >> Cipher : AES128-SHA >> Session-ID: >> CA3E0000FDAB34D348334DACE16E940397A02812E3F20B60EB631B9784BAA87B >> Session-ID-ctx: >> Master-Key: >> >> E63D5D64939F6A9AD3A232B046D0AADF4303756335D7FD3B112EACD822BA1B3692BE06FCCBADBACCA14A648A67C018E7 >> Key-Arg : None >> Start Time: 1330655479 >> Timeout : 300 (sec) >> Verify return code: 21 (unable to verify the first certificate) >> --- >> >> At this point I was a bit out of my depth but I made a guess: >> >> >> #ldapwhoami -x -D "cn=theUserName,dc=au,dc=com,dc=xyz,dc=ce" -H >> "ldaps://mldshomdsp01.ce.xyz.com.au" -w #testPassword -d1 >> ldap_url_parse_ext(ldaps://mldshomdsp01.ce.xyz.com.au) >> ldap_create >> ldap_url_parse_ext(ldaps://mldshomdsp01.ce.xyz.com.au:636/??base) >> ldap_sasl_bind >> ldap_send_initial_request >> ldap_new_connection 1 1 0 >> ldap_int_open_connection >> ldap_connect_to_host: TCP mldshomdsp01.ce.xyz.com.au:636 >> ldap_new_socket: 3 >> ldap_prepare_socket: 3 >> ldap_connect_to_host: Trying 192.168.143.2:636 >> ldap_pvt_connect: fd: 3 tm: -1 async: 0 >> TLS: could not load verify locations >> (file:`/usr/local/etc/openldap/certs/eLearningPublic.cer',dir:`'). >> > > This might be your clue that there is something wrong with the certificate > you provided. > > >> >> ldap_err2string >> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >> > > This just means: "Failed to setup encrpypted session." > > >> >> >> >> I know the server's reachable (for one thing I can telnet to it on port 636 >> and get a connection). >> >> I can see it says it cannopt load the certificate, but it seemed to parse >> it with s_client and it has suitable permissions (not to mention I'm >> logged in as root): >> >> # ls -l /usr/local/etc/openldap/certs/eLearningPublic.cer >> -rw-r--r-- 1 peter peter 526 Feb 29 19:20 >> /usr/local/etc/openldap/certs/eLearningPublic.cer >> >> >> Can anyone shed any light on this? >> > > It has been a while since I last dealt with self-signed certificates, but > some clues that might help to identify your issue(s): > - If your eLearningPublic.cer is in DER format, convert it to PEM: > openssl x509 -inform DER -in eLearningPublic.cer -outform PEM > -out eLearningPublic.pem > - That certificate may not be self-signed and you might need the signing > authorities certificate [chain] to validate it: > openssl x509 -in eLearningPublic.cer -noout -text | less > (The fields "Issuer" and "Subject", "X509v3 Subject Key Identifier" and > "X509v3 Authority Key Identifier" need to have the same value, > recpectively.) > - Your certificate might be rejected for using insecure stuff like MD5 signatures, try verifying it with openssl and gnutls: openssl verify -check_ss_sig -purpose sslserver -verbose eLearningPublic.cer certtool -e --infile eLearningPublic.cer (You might need to create a PEM encoded certificate chain file for gnutls verification, once you've retrieved the singning certificate authority: cat certificate.pem > chain.pem; cat cacert.pem >> chain.pem; ) certtool is shipped with package gnutls-bin on Debian/Ubuntu. Hope this helps and sorry for the email increments. ;-) PS: Using "TLS_REQCERT never" for anything but test environments invalidates the whole concept of using X.509 PKIs to establish trusted, encrypted connections. As long as you have a self-managed CA or self-signed certificates, you may actually be able to trust your PKI as long as you validate certificates. Regards, Linus
