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).