> Does Active Directory still lack support for StartTLS?
Yes Active Directory supports TLS. You can check for the OID in
supportedExtension of the RootDSE to validate that the specific server you are
querying supports it. It is available anonymously assuming you can get to port
389. Look for 1.3.6.1.4.1.1466.20037 (LDAP_SERVER_START_TLS_OID). This goes
back to at least Windows Server 2003 TMK.
> AFAIR, Microsoft Active Directory supports using "{loginname}@{dnsdomain}" as
> "bind DN". Something like "phawk...@gvmedia.com.au" where "phawkins" would be
> your "{loginname}" and "gvmedia.com.au" your Windows "{dnsdomain}".
The user principal name default is indeed loginname@dnsdomain... However, that
can be overridden, I would verify with the admins that the userPrincipalName
attribute hasn’t been set to something else. Some companies change that for
security purposes as they want something that can’t be derived from the OS base
info. Some companies do it just to shorten the UPNs or to be arbitrary. So
instead of phawk...@gvmedia.com.au it could be phawk...@media.com or something.
I have also seen companies that have horrible provisioning processes that are
entirely manual and people typo the UPN and no one catches it for some time as
most Windows users don’t use UPNs when logging in from Windows machines. You
should also be able to use the full DN if you know that or domain\userid as
well.
> ldap_bind: Invalid credentials (49)
additional info: 8009030C: LdapErr: DSID-0C0903A9, comment:
AcceptSecurityContext error, data 2030, v1db1
> ldap_bind: Other (e.g., implementation specific) error (80)
additional info: 80090304: LdapErr: DSID-0C0903A9, comment:
AcceptSecurityContext error, data 20ee, v1db1
If you have a Windows machine, you can download err.exe from MSFT (free
download in the Exchange tools somewhere) and it will decode some of this for
you. Specifically the first error code after additional info: and the error
code after data. The DSID code is info to a directory, file, and line number in
the source code but that won’t help you unless you are part of the MSFT shared
source program.
G:\_SORT\Dev\CPP\Auth>err 8009030C
# for hex 0x8009030c / decimal -2146893044 :
SEC_E_LOGON_DENIED winerror.h
# The logon attempt failed
# 1 matches found for "8009030C"
G:\_SORT\Dev\CPP\Auth>err 2030
# for decimal 2030 / hex 0x7ee :
ecRejected ec.h
# for hex 0x2030 / decimal 8240 :
ERROR_DS_NO_SUCH_OBJECT winerror.h
# There is no such object on the server.
# 2 matches found for "2030"
G:\_SORT\Dev\CPP\Auth>err 80090304
# for hex 0x80090304 / decimal -2146893052 :
SEC_E_INTERNAL_ERROR winerror.h
# The Local Security Authority cannot be contacted
# 1 matches found for "80090304"
G:\_SORT\Dev\CPP\Auth>err 20ee
# for hex 0x20ee / decimal 8430 :
SQL_8430_severity_16 sql_err
# The message body does not match the message body encoding
# format.
ERROR_DS_INTERNAL_FAILURE winerror.h
# The directory service encountered an internal failure.
# 2 matches found for "20ee"
I am uncertain of what you are working with, but if you have the ability to
ignore the server cert you can see if doing that gets you your connection, if
that works, it is likely due to the cert chain on your machine.
joe
--
O'Reilly Active Directory Fourth Edition - http://www.joeware.net/win/ad4e.htm
Blog: http://blog.joeware.net
From: bounce-ldap-5210...@listserver.itd.umich.edu
[mailto:bounce-ldap-5210...@listserver.itd.umich.edu] On Behalf Of Linus van
Geuns
Sent: Sunday, March 04, 2012 10:04 AM
To: Peter Hawkins
Cc: ldap@umich.edu
Subject: [ldap] Re: *****SPAM***** LDAPS Connection difficulties
Argh, damn small keyboards! :o)
On Sun, Mar 4, 2012 at 3:33 PM, Linus van Geuns <li...@vangeuns.name> wrote:
Hey Peter,
On Sun, Mar 4, 2012 at 4:07 AM, Peter Hawkins <phawk...@gvmedia.com.au> 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 "phawk...@gvmedia.com.au" 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
