Thanks for the response Linus
> 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.
> 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
I also tried [email protected] and
[email protected]
and even just "username"
all give the same result.
>
however whenever I try any DN which does NOT have an '@' in it I get
ldap_bind: Other (e.g., implementation specific) error (80)
additional info: 80090304: LdapErr: DSID-0C0903A9, comment:
AcceptSecurityContext error, data 20ee, v1db1
So it looks like think you're right about the format.
> 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
Excellent! Thanks - it gave an error so I jumped to your command below
to convert it to pem and sure enough that loaded it and created
somethign that the command above COULD read.... in other words it was in
DER format.
# 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
> 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",
Yes they do... both have CN=mldshomdsp01.ce.xyz.com.au
> "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)
>
>
> - 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?
> 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.
> (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; )
Since the command above ran, I'm assuming I don't need this, right?
> 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.
When I remove it I get the original error (rather than invalid
credentials):
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> 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
