[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: TLSVerifyClient => no login possible



Hello Sebastian,

Sebastian Reinhardt <snr@lmv-hartmannsdorf.de> writes:

> Dieter Kluenter schrieb:
>> Hello Sebastian,
>>
>> Sebastian Reinhardt <snr@lmv-hartmannsdorf.de> writes:
>>
>>   
>>> Dieter Kluenter schrieb:
>>>     
>>>> Sebastian Reinhardt <snr@lmv-hartmannsdorf.de> writes:
[...]
>>> Now I have set the loglevel to "3" and I get the following output if I
>>> try to login (still fails):
>>>     
>>
>> loglevel is != debug level, man slapd(8), run slapd -d3
>>   
>>> -------------------/var/log/messages---------------------------------------------------------------------
>>>     
>>
>> [...]
>>   
>>> Feb 25 16:41:49 lmvserver kdm: :0[11544]: nss_ldap: could not search
>>> LDAP server - Server is unavailable
>>>     
>> [...]
>>
>>   
>>> Feb 25 16:41:49 lmvserver kdm: :0[11544]: pam_ldap: ldap_starttls_s:
>>> Connect error
>>> -------------------/var/log/messages---------------------------------------------------------------------
>>>
>>> I am not sure, if this is an configuration or certificate error? Do You
>>> understand this output above?
>>>     
>>
>> The clients are nss_ldap and pam_ldap, check the clients
>> configuration for starttls parameters.
>> With debug level 3 you should see something like
[...]
> Sorry. I had not configured the pam_ldap (/etc/ldap.conf) config file
> properly. The certifikate entries were missing.
>
> Here is my /etc/ldap.conf:
> -------------------/etc/ldap.conf-------------------------------------------
> host    127.0.0.1
This Hostadress is probabely  not the certifcate DN

> base    dc=lmv,dc=lmv
> #uri ldap://127.0.0.1/
> #uri ldaps://127.0.0.1/  
> #uri ldapi://%2fvar%2frun%2fldapi_sock/
> #ldap_version 3
> #binddn cn=proxyuser,dc=example,dc=com
> #bindpw secret
> rootbinddn cn=ldaproot,dc=lmv,dc=lmv

To bind as rootdn is not a good idea.

[...]
> #ssl on
> sslpath /etc/openldap/

although it is not the base of your problem, omit sslpath

> ssl    start_tls
> ldap_version    3
> pam_filter    objectclass=posixAccount
> nss_base_passwd    ou=users,dc=lmv,dc=lmv
> nss_base_shadow    ou=users,dc=lmv,dc=lmv
> nss_base_group    ou=groups,dc=lmv,dc=lmv
> tls_checkpeer    yes
> #ssl on
> tls_cacertfile /etc/openldap/cacert.pem
> tls_cacertdir /etc/openldap/

omit tls_cacertdir

> #tls_randfile /var/run/egd-pool
> #tls_ciphers TLSv1
> tls_cert /etc/openldap/clientcert_201.pem
> tls_key /etc/openldap/clientkey_201.pem
> #sasl_secprops maxssf=0
> #krb5_ccname FILE:/etc/.ldapcache
> -------------------/etc/ldap.conf-------------------------------------------
>
> And also my /etc/openldap/ldap.conf:
> -------------------/etc/openldap/ldap.conf-----------------------------
> TLS_CACERT    /etc/openldap/cacert.pem
> TLS_CERT    /etc/openldap/clientcert_201.pem
> TLS_KEY        /etc/openldap/clientkey_201.pem
> TLS_REQCERT    demand
> host    127.0.0.1

[...]
>
> TLS: can't accept.
> connection_read(14): TLS accept failure error=-1 id=33, closing
[...]
> What is wrong? The certificate is not accepted? Is the certificae not ok?

I presume the certificate DN is not in conformance with the called URI

To test this, just do a ldapsearch with a simple bind and starttls,
that is ldapsearch -x -D some DN -w passwd -ZZ ldap://my.remote.host
-b "" -s base +

You may do a strace on this process, that is "strace -o /tmp/myfile.txt
ldapsearch ...."
As you use a host certificate, on a successful session ou may see
something like 
TLS trace: SSL_accept:SSLv3 flush data
connection_read(19): unable to get TLS client DN, error=49 id=8
But despite a error 49, the session is established.

-Dieter

-- 
Dieter KlÃnter | Systemberatung
http://www.dpunkt.de/buecher/2104.html
sip: +49.180.1555.7770535
GPG Key ID:8EF7B6C6
53Â08'09,95"N
10Â08'02,42"E