[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