I figured this out last Friday....

  - The port # was a typo/mistake in my command line, I meant 636 not 363.
    I checked my ldap.conf and it was correct there.  Correcting that didn't change the outcome.

  - I had used s_client to make a connection, and prove I had the correct root cert to trust
    the server public cert, so I knew that part worked too.

  - I finally found out about the DEBUG directive in ldap.conf.   I added a DEBUG 7 to the file
    and tried again.  I got a ton of trace data ending with a meaningful error from the certificate logic.
    The IP address I was using didn't "literally" match the host name in the cert. and it was rejected it for  
    that reason.   I replaced the address with the host name in the command line and it succeeded.

    The output trace still prints a line about SASL bind, but it doesn't seem to actually do it.
   
Thanks,
Dave.

On 7/13/2011 11:30 PM, Jose Ildefonso Camargo Tolosa wrote:
Hi.

On Fri, Jul 8, 2011 at 9:54 AM, David Mitton <david@mitton.com> wrote:
Thanks for the reply, sorry about the poor quoting, I'm cut and
pasting from the web archive.

 ------
From: Jose Ildefonso Camargo Tolosa < ildefonso.camargo@gmail.com>
Date: Fri, 8 Jul 2011 08:58:16 -0430


Greetings,

On Thu, Jul 7, 2011 at 4:08 PM, David Mitton <david@mitton.com>
wrote:

I am trying to use OpenLDAP from an embedded Linux system to
authenticate  (PAM LDAP) against a Windows AD server.  I must use
TLS to secure this, but I would rather not use SASL or Kerberos if
possible.

pam_ldap = http://www.padl.com/pam_ldap.html[1] OR
http://arthurdejong.org/nss-pam-ldapd/[2] .... you are not dealing
here with OpenLDAP....

DJM> Good point, I will look at exactly which module(s) I'm using and
come back to that later.  I beleive for the moment I'm using whatever is in
Centos.  I have Arthur Jong's modules as well, but I don't think I've installed them yet.


Uh... I really wouldn't recommend centos (or any rh-derivative), try Debian or Ubuntu (these could prove to be better suited for this kind of job).
 


I have been able to mock this up on a Centos system without TLS, and
the PAM worked fine.  When I turn on TLS, the Windows server
handshakes the TLS but then has a problem with the first message.  I
am also working that side.



Most likely, cert trust, you need to CA that signed the windows server certificate, and make OpenLDAP client trust it.
 

I have walked through the handshake with s_client, and the connection
is happy.
I am now working with ldapsearch and trying things....
The first thing I notice is that it seems to try an SASL bind.  Can
I stop this?
I'm not sure I have SASL actually installed on this system, and I'm
not sure I want it in my target.

ldapsearch -x   <--- does simple auth instead of sasl.

Is this possible? from both the OpenLDAP client and/or Windows AD?
Ideas on the correct alphabet soup to try this with ldapsearch would
be appreciated.
Thanks.

Well, I have seen this done through samba, but you *should* be able
to use AD's LDAP to authenticate your Linux workstation, I guess.

Sincerely,
Ildefonso Camargo
-------

 I tried the following command and here are the results... note that
after the simple_bind, a SASL_bind line appears.   I'd like to dig
into this deeper....  What will give me more info?

 Thanks,  Dave.

ldapsearch -d 1 -v -x -H ldaps://172.16.9.3:363 -b "dc=foobar,dc=local" -D 'FOOBAR\mgr' -w 'Strongpw@09' '(sAMAccountName=mgr)'


Port 363???? afaik, AD uses standard 389 port, try this better: ldap://172.16.9.3:389 , and, maybe, add -Z parameter to ldapsearch (to attempt TLS).
 
ldap_initialize( ldaps://172.16.9.3:363 )
ldap_create
ldap_url_parse_ext(ldaps:// 172.16.9.3:363)
ldap_bind
ldap_simple_bind
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 172.16.9.3:363
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 172.16.9.3:363
ldap_connect_timeout: fd: 3 tm: -1 async: 0
ldap_close_socket: 3
ldap_perror
ldap_bind: Can't contact LDAP server (-1)


Not unexpected (because of the port).