Hey Peter, On Mon, Mar 5, 2012 at 3:00 AM, Peter Hawkins <[email protected]>wrote:
> Thanks for the response Linus > No problem, I still remember my first contact with [Open]LDAP, StartTLS and LDAPS about 7 years ago.. ;-) > > > > > 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? > > I'm not sure... I'm on the UNIX end, but I'm assuming they have TLF > going if they are issuing certificates. > Well, StartTLS is the alternative (RFC compatibla) method of encrypting and authenticating LDAP sessions using X.509 certificates. While LDAPS establishes an TLS/SSL encrypted and authenticated "connection" and tunnels all LDAP communications through that tunnel, StartTLS establishes an (unencrypted) LDAP connection and sets up authentication and encryption of the LDAP session using LDAP extended operations. StartTLS is the RFC desifned method and should be preferred over LDAPS. To force OpenLDAP command line utilities to establish an StartTLS encrypted LDAP session before sending any other commands (like e.g. LDAP Bind), use: ldapsearch -ZZ -H ldap://you.server.name/ .... Note that the LDAP URI does use ldap:// instad of ldaps://! > > 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 > > "phawkins at gvmedia.com.au" where "phawkins" would be your > > "{loginname}" and "gvmedia.com.au" your Windows "{dnsdomain}". > > > I get a different error trying that ("Invalid Credentials") which > suggests it's talking but I have tried username@domain and every variant > of it... > > # ldapwhoami -x -D "[email protected]" -H > "ldaps://mldshomdsp01.ce.xyz.com.au" -w #passWord > > ldap_bind: Invalid credentials (49) > additional info: 8009030C: LdapErr: DSID-0C0903A9, comment: > AcceptSecurityContext error, data 2030, v1db1 > In your /etc/ldap/ldap.conf, put: -8<-------------------- REFERRALS off TLS_REQCERT demand TLS_CACERT /.../eLearningPublic.pem -8<-------------------- Try: ldapsearch -ZZ -x -D "[email protected]" -W -H "ldap:// mldshomdsp01.ce.xyz.com.au" -b '' -s base -a never You can always use "TLS_REQCERT allow" or "... never" and "TLS_CRLCHECK none" for analysing TLS problems. Please note the PEM version of your self-signed certificate. If you cannot get this to work, you should ask for validation of your windows account using e.g. a terminal server or windows workstation. Maybe the account is not allowed to log in or has the wrong password or your computer needs to be allowed to connect to Active Directory at all... Also, you should validate that the certificate provided by Active Directory actually is the one youre working with. openssl s_client and gnutls-cli (with LDAPS port) should help you identify the certificate provided by Active Directoy. > So it looks like think you're right about the format. > Well, Active Directory supports both, the principal (email-like) name and the actual DN of your account. Since you do not know the DN of your account, the principal name may be easier to figure out. > # openssl x509 -noout -subject -issuer -startdate -enddate > -in ./eLearningPublic.pem > subject= /CN=mldshomdsp01.ce.xyz.com.au > issuer= /CN=mldshomdsp01.ce.xyz.com.au > notBefore=Nov 4 02:25:47 2011 GMT > notAfter=Nov 2 02:25:47 2016 GMT [..] > > > "X509v3 Subject Key Identifier" and "X509v3 Authority Key > > Identifier" need to have the same value, recpectively.) > > These two fields do not appear (note that the unix is FreeBSD) > Only the version of your openssl and certtool ultilities should affect the output, not the UNIX distro. Try the openssl and certtool text output without restricting the fields reported. openssl x509 -noout -in eLearningPublic.pem certtool -i --infile eLearningPublic.pem > > > > > > - 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 > > This command was rejected as check_ss_sig isn't an option on my version. > Without it: > > # openssl verify -purpose sslserver -verbose ./eLearningPublic.pem > ./eLearningPublic.pem: /CN=mldshomdsp01.ce.xyx.com.au > error 20 at 0 depth lookup:unable to get local issuer certificate > > ... I think this just means it is self signed, right? > Actually, it does mean that OpenSSL was unable to find the signing authorities certificate. You may need to explicitly tell OpenSSL that this certificate is allowed to be self-signed by referencing your certificate as a valid CA: openssl verify -purpose sslserver --CAfile eLearningPublic.pem -verbose ./eLearningPublic.pem > > > certtool -e --infile eLearningPublic.cer > > # certtool -e --infile ./eLearningPublic.pem > Certificate[0]: CN=mldshomdsp01.ce.xyz.com.au > Issued by: CN=mldshomdsp01.ce.xyz.com.au > Verification output: Verified. > > Chain verification output: Verified. > This looks like a self-signed certificate, yes. [..] > Since the command above ran, I'm assuming I don't need this, right? > Right. Regards, Linus
