enabling secure ldap samba4

[Michael Wood]

Hi Matthieu

On 22 August 2010 11:46, Matthieu Patou <mat at samba.org> wrote:
>  Hi Michael,
>
>> Could it be something to do with not having pkg-config installed?
>>>
>>> In config.h I have:
>>>
>>> #define HAVE_LIBGNUTLS 1
>>> #define HAVE_GNUTLS_GNUTLS_H 1
>>> #define HAVE_GNUTLS_GLOBAL_INIT 1
>>> #define HAVE_GNUTLS_X509_H 1
>>> #define HAVE_GNUTLS_X509_CRT_SET_VERSION 1
>>> #define HAVE_GNUTLS_X509_CRT_SET_SUBJECT_KEY_ID 1
>>> #define HAVE_GNUTLS_DATUM 1
>>> #define HAVE_GNUTLS_DATUM_T 1
>>> #define HAVE_LIBGCRYPT 1
>>>
>>> but no ENABLE_GNUTLS.
>>>
>>> After looking in source4/lib/tls/wscript the lack of pkg-config does
>>> indeed seem to be the cause.
>
> We had this pb in the old build system, maybe with waf now it's possible to
> correctly detect the presence of pkg-config and to print an clear message
> when it's not here and also to fail if there is no pkg-config and the user
> asked --enable-gnutls.

That sounds like a good idea.

>> [...]
>>
>> I've re-run the configure and now have ENABLE_GNUTLS defined in
>> config.h and after compiling samba loads the cert, key and CA cert :)
>>
>> stat64("/usr/local/samba/private/tls/ca.pem", {st_mode=S_IFREG|0644,
>> st_size=2650, ...}) = 0
>> open("/usr/local/samba/private/tls/ca.pem", O_RDONLY) = 45
>> open("/usr/local/samba/private/tls/key.pem", O_RDONLY) = 45
>> open("/usr/local/samba/private/tls/cert.pem", O_RDONLY) = 45
>>
>> I reprovisioned, but the certs were not generated, so I used my own.
>
> In fact at startup the samba daemon checks for the certs (if compiled with
> ENABLE_GNUTLS):

Oh, OK.  I've just tried that and they are generated.  I assumed that
the provision would create them.

>> Unfortunately I'm still having trouble connecting:
>>
>> Traceback (most recent call last):
>>   File "./ldap-tls-test", line 12, in<module>
>>     conn.start_tls_s()
>>   File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line
>> 540, in start_tls_s
>>     return self._ldap_call(self._l.start_tls_s)
>>   File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96,
>> in _ldap_call
>>     result = func(*args,**kwargs)
>> ldap.CONNECT_ERROR: {'info': '(unknown error code)', 'desc': 'Connect
>> error'}
>>
>> and:
>>
>> $ ldapsearch -ZZx -h localhost
>> ldap_start_tls: Connect error (-11)
>>        additional info: (unknown error code)
>>
> Well I'm puzzled, can you try something like this:
>
> ldbsearch -H ldap://localhost -b ""  -s base
>
> And you should get something like:
[...]
> highestCommittedUSN: 8954
> domainFunctionality: 3
> forestFunctionality: 3
> domainControllerFunctionality: 3
[...]

I compared your output to what I get and other than the names and the
currentTime, the only differences are as follows:

highestCommittedUSN: 3456
domainFunctionality: 2
forestFunctionality: 2
domainControllerFunctionality: 4

I can paste the whole output if you like, but that is really the only
difference.

I doubt that is relevant, right?  Not sure why the functionality
levels are different.

> And also try this patch, it's for trying to debug the starttls thing. If

It seems you forgot to attach the patch.

> everything is ok you should see something like :
>
> Start TLS called on LDAP
> Start TLS: init_server ok
>
> But I guess you'll only see "Start TLS called on LDAP" or even nothing !

Well, I'm having trouble debugging this.  Maybe because of
optimisation, but when ldapsrv_StartTLS() is called it gets past the
if (!ctx->tls_socket) check OK.  This is where it was failing before.
So it returns NT_STATUS_OK at the end of the function.  But after that
I'm not entirely sure what happens.

Thanks.

-- 
Michael Wood <esiotrot at gmail.com>