samba - Jan 2015 - ldap start_tls to microsoft active directory

I have 20+ freebsd 10 samba 4 servers joined to our local microsoft 
active directory. At the moment things work well enough. However the 
windows administrator wants to tighten his AD security by requiring tls 
encrypted ldap.

When I add:
ldap ssl = start_tls
ldap ssl ads = yes
cldap port = 389

the net ads commands fail:
net ads testjoin
Failed to issue the StartTLS instruction: Connect error
Failed to issue the StartTLS instruction: Connect error
Join to domain is not valid: NT code 0xfffffff5

Capturing packets with wireshark shows the samba machine ending the tls 
negotiation with an unrecognized CA message.

The windows domain uses self signed certificates, and I have copies of 
the CA cert and the individual client certs in pem format. Using these I 
can connect to the domain controllers with gnutls-cli using start tls on 
port 389.

smbd -b |grep ENABLE_GNUTLS
shows that I do in fact have GNUTLS support.

I've tried multiple variations of
tls keyfile
tls certfile

and also added the certs in openldap/ldap.conf

but I've not been able to get samba to connect to AD  ldap over tls. I 
can't seem to convince it to trust the AD machines certificate.

Does anyone have ldap ssl working against a MS domain controller?

Thanks in advance
Russ Poyner

On Wed, 2015-01-28 at 10:11 -0600, Russell Poyner wrote:
> I have 20+ freebsd 10 samba 4 servers joined to our local microsoft 
> active directory. At the moment things work well enough. However the 
> windows administrator wants to tighten his AD security by requiring tls 
> encrypted ldap.
> 
> When I add:
> ldap ssl = start_tls
> ldap ssl ads = yes
> cldap port = 389
> 
> the net ads commands fail:
> net ads testjoin
> Failed to issue the StartTLS instruction: Connect error
> Failed to issue the StartTLS instruction: Connect error
> Join to domain is not valid: NT code 0xfffffff5
> 
> Capturing packets with wireshark shows the samba machine ending the tls 
> negotiation with an unrecognized CA message.
> 
> The windows domain uses self signed certificates, and I have copies of 
> the CA cert and the individual client certs in pem format. Using these I 
> can connect to the domain controllers with gnutls-cli using start tls on 
> port 389.
> 
> smbd -b |grep ENABLE_GNUTLS
> shows that I do in fact have GNUTLS support.
> 
> I've tried multiple variations of
> tls keyfile
> tls certfile
> 
> and also added the certs in openldap/ldap.conf
> 
> but I've not been able to get samba to connect to AD  ldap over tls. I 
> can't seem to convince it to trust the AD machines certificate.
> 
> Does anyone have ldap ssl working against a MS domain controller?
You have tripped up that we have two different, independent LDAP paths
in Samba.  We have one using GNUTLS, which is used by the AD DC and the
ldb tools, and another using OpenSSL, or whatever your libldap was
linked to.  You are looking for that second path, and it is configured
however (presumably) OpenLDAP's ldap client libs are configured. 

However, you may wish to just try a Samba 4.2 pre-release, where we
turned on a different form of encrypted LDAP (based on Kerberos or
NTLMSSP) by default.  If that works for you, the final 4.2 should not be
too far off, or just change the same smb.conf options mentioned in the
WHATSNEW.

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba

Andrew,

Thanks for the pointers about looking into the ldap client libs. I think 
I've found a situation where tls connections to the AD server on port 
389 have trouble.

I've added the CA cert to ldap.conf, and to the ca_root_nss file on this 
system.

First what works:
1. ldapsearch commands with -Z to force use of tls (configured in 
/usr/local/etc/ldap.conf)
2. ssl connections with s_client to port 636 and to port 443 on the 
domain controller.
3. tls version 1 connections to port 389 using s_client with the -tls1 
switch
4. gnutls-cli connections to port 636. Shows that the domain controller 
cert is trusted

What fails:
1. s_client connections to port 389 if I don't give the -tls1 switch and 
allow it to try to autonegotiate
2. gnutls-cli connections to port 389
3. net ads join still fails with a tls error.

So it looks like my client programs are configured to use the CA 
certificate, but that at least some of the client tools are failing the 
start tls negotiation with the server. A possible explanation for the 
samba failure might be that it's letting the tls library connect with 
the library's default settings and that the negotiation is failing due 
to incompatibility between the tls implementation on the MS server and 
the unix machine.

The other possibility is that samba is somehow still not finding the CA 
cert for the server. I'm not sure what else to try on that front.


Some output from s_client that might be of interest:

A failure:
openssl s_client -CApath /usr/local/openssl/certs/ -connect 
engr-dc2.ad.engr.wisc.edu:389
CONNECTED(00000003)
write:errno=54
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 321 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---



A success:
openssl s_client -tls1 -CApath /usr/local/openssl/certs/ -connect 
my.domain.controller:389
CONNECTED(00000003)
write:errno=54
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
     Protocol  : TLSv1
     Cipher    : 0000
     Session-ID:
     Session-ID-ctx:
     Master-Key:
     Key-Arg   : None
     PSK identity: None
     PSK identity hint: None
     SRP username: None
     Start Time: 1423605319
     Timeout   : 7200 (sec)
     Verify return code: 0 (ok)






On 01/29/2015 12:49 PM, Andrew Bartlett wrote:
> On Wed, 2015-01-28 at 10:11 -0600, Russell Poyner wrote:
>> I have 20+ freebsd 10 samba 4 servers joined to our local microsoft
>> active directory. At the moment things work well enough. However the
>> windows administrator wants to tighten his AD security by requiring tls
>> encrypted ldap.
>>
>> When I add:
>> ldap ssl = start_tls
>> ldap ssl ads = yes
>> cldap port = 389
>>
>> the net ads commands fail:
>> net ads testjoin
>> Failed to issue the StartTLS instruction: Connect error
>> Failed to issue the StartTLS instruction: Connect error
>> Join to domain is not valid: NT code 0xfffffff5
>>
>> Capturing packets with wireshark shows the samba machine ending the tls
>> negotiation with an unrecognized CA message.
>>
>> The windows domain uses self signed certificates, and I have copies of
>> the CA cert and the individual client certs in pem format. Using these
I
>> can connect to the domain controllers with gnutls-cli using start tls
on
>> port 389.
>>
>> smbd -b |grep ENABLE_GNUTLS
>> shows that I do in fact have GNUTLS support.
>>
>> I've tried multiple variations of
>> tls keyfile
>> tls certfile
>>
>> and also added the certs in openldap/ldap.conf
>>
>> but I've not been able to get samba to connect to AD  ldap over
tls. I
>> can't seem to convince it to trust the AD machines certificate.
>>
>> Does anyone have ldap ssl working against a MS domain controller?
> You have tripped up that we have two different, independent LDAP paths
> in Samba.  We have one using GNUTLS, which is used by the AD DC and the
> ldb tools, and another using OpenSSL, or whatever your libldap was
> linked to.  You are looking for that second path, and it is configured
> however (presumably) OpenLDAP's ldap client libs are configured.
>
> However, you may wish to just try a Samba 4.2 pre-release, where we
> turned on a different form of encrypted LDAP (based on Kerberos or
> NTLMSSP) by default.  If that works for you, the final 4.2 should not be
> too far off, or just change the same smb.conf options mentioned in the
> WHATSNEW.
>
> Andrew Bartlett
>