ldap with simple:tls auth against AD (W2K8R2)

[Gabriele Paggi]

Hi,

I'm struggling getting ldap working with TLS in my test environment.
Apologizes for the long post but I'll try to provide as many details
as possible about the tests I've done.

I'm running:
SunOS server-tst-01 5.11 snv_151a i86pc i386 i86pc Solaris
With the default ldap/client.

Users authentication via ldap works smoothly with simple
authentication but something goes wrong as soon as I enable TLS.

I initialize my ldap client configuration via ldapclient this way:
ldapclient -v manual \
-a credentialLevel=proxy \
-a authenticationMethod=tls:simple \
-a certificatePath=/var/ldap/ \
-a proxyDN=cn=HOST-server-tst-01,ou=office1,ou=company,dc=vapp-
mexrk,dc=vcd \
-a proxyPassword=XXX \
-a defaultSearchBase=dc=vapp-mexrk,dc=vcd \
-a domainName=vapp-mexrk.vcd \
-a defaultServerList="ad-0.vapp-mexrk.vcd" \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=vapp-mexrk,dc=vcd?sub \
-a serviceSearchDescriptor=group:dc=vapp-mexrk,dc=vcd?sub

I fix nsswitch.conf afterward to have ldap listed only for groups and
passwd (like I did without TLS).
With this configuration any attempt to run id / getent results in the
following errors:
***@server-tst-01:/var/ldap# id gpaggi
Jun 23 16:28:59 server-tst-01 id[12569]: [ID 293258 user.warning]
libsldap: Status: 81 Mesg: openConnection: simple bind failed - Can't
contact LDAP server
Jun 23 16:28:59 server-tst-01 id[12569]: [ID 545954 user.error]
libsldap: makeConnection: failed to open connection to
ForestDnsZones.vapp-mexrk.vcd

DNS configuration should be fine, given that it works without TLS.
Increasing logging level on the AD didn't show anything interesting.

Strangely enough ldapsearch works fine:
***@server-tst-01:/var/ldap# ldapsearch -v -h ad-0.vapp-mexrk.vcd -p
636 -ZZ -P /var/ldap/cert8.db -D 'cn=HOST-server-
tst-01,ou=office1,ou=company,dc=vapp-mexrk,dc=vcd' -w XXX -b 'dc=vapp-
mexrk,dc=vcd' -a always 'sAMAccountName=gpaggi'
ldapsearch: started Thu Jun 23 16:23:59 2011

ldap_init( ad-0.vapp-mexrk.vcd, 636 )
filter pattern: sAMAccountName=gpaggi
[...]
1 matches


The following tests for the SSL part return the expected results:
1) certutil -L -d /var/ldap/ -n ca-cert
shows the right CA cert, which I used to sign the AD certificate.
2) ***@server-tst-01:/var/adm# openssl s_client -connect ad-0.vapp-
mexrk.vcd:636 -CAfile /home/gpaggi/MyCA.cert -showcerts
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES128-SHA
[...]
Verify return code: 0 (ok)

I'm kind of lost at this point and I would *really* appreciate any
kind of help :)

Thank you!
Regards,
Gabriele

[Chris Ridd]

Post by Gabriele Paggi
I fix nsswitch.conf afterward to have ldap listed only for groups and
passwd (like I did without TLS).

Not much of an idea I'm afraid, but what have you got for the hosts
line in nsswitch.conf? You'll probably want 'files dns' instead of
'files ldap'.

[Gabriele Paggi]

Hello Chris,

Post by Chris Ridd
Not much of an idea I'm afraid, but what have you got for the hosts
line in nsswitch.conf? You'll probably want 'files dns' instead of
'files ldap'.

As said the ldapclient has the bad habit to copy nsswitch.conf.ldap
over nsswith.conf.
Every time I run it, I take care of fixing the file as follows:

# the following two lines obviate the "+" entry in /etc/passwd and /
etc/group.
passwd: files ldap
group: files ldap

# consult /etc "files" only if ldap is down.
hosts: files dns

# Note that IPv4 addresses are searched for in all of the ipnodes
databases
# before searching the hosts databases.
ipnodes: files dns

networks: files
protocols: files
rpc: files
ethers: files
netmasks: files
bootparams: files
publickey: files

#netgroup: ldap

automount: files
aliases: files

# for efficient getservbyname() avoid ldap
services: files

printers: user files

auth_attr: files
prof_attr: files

project: files

tnrhtp: files
tnrhdb: files

Thank you anyway!

Gabriele

[Chris Ridd]

Post by Gabriele Paggi
Hello Chris,

Post by Chris Ridd
Not much of an idea I'm afraid, but what have you got for the hosts
line in nsswitch.conf? You'll probably want 'files dns' instead of
'files ldap'.

As said the ldapclient has the bad habit to copy nsswitch.conf.ldap
over nsswith.conf.

Yes, that's pretty annoying. I just hack nsswitch.conf.ldap before
running ldapclient.

Post by Gabriele Paggi
# the following two lines obviate the "+" entry in /etc/passwd and /
etc/group.
passwd: files ldap
group: files ldap
# consult /etc "files" only if ldap is down.
hosts: files dns

Looks OK to me. Can you snoop the network to see what libsldap is
actually trying to connect to?

[Gabriele Paggi]

Hello Chris,

Post by Chris Ridd
Looks OK to me. Can you snoop the network to see what libsldap is
actually trying to connect to?

I lack a bit of networking knowledge to troubleshoot this using
snoop / tcpdump.
It's contacting the right server (as I see also in the AD logs) but
something goes wrong with the SSL certificate, I suspect.

The CN of the certificate is the same of the FQDN of the AD and the
CA, which I used to sign the certificate, is imported on both the AD
and the Solaris server.
I don't get what's wrong given the following test succeeds:
===
***@server-tst-01:/var/adm# openssl s_client -connect ad-0.vapp-
mexrk.vcd:636 -CAfile /home/gpaggi/MyCA.cert -showcerts
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES128-SHA
[...]
Verify return code: 0 (ok)
===

I might end up asking the Oracle support if they can help on this :(

Gabriele

[Pepe]

Post by Gabriele Paggi
Hello Chris,

Post by Chris Ridd
Looks OK to me. Can you snoop the network to see what libsldap is
actually trying to connect to?

I lack a bit of networking knowledge to troubleshoot this using
snoop / tcpdump.
It's contacting the right server (as I see also in the AD logs) but
something goes wrong with the SSL certificate, I suspect.
The CN of the certificate is the same of the FQDN of the AD and the
CA, which I used to sign the certificate, is imported on both the AD
and the Solaris server.
===
mexrk.vcd:636 -CAfile /home/gpaggi/MyCA.cert -showcerts
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
Protocol : TLSv1
Cipher : AES128-SHA
[...]
Verify return code: 0 (ok)
===
I might end up asking the Oracle support if they can help on this :(
Gabriele

Do you know whether your ldap client has access to the "CA root
certificate" to validate the "SSL certificate" which you are using?