On pwdGraceUseTime granularity

[Matus Honek]

Hello,

currently, granularity of pwdGraceUseTime is one second. This allows
client to successfully bind with old password as many times as they
want during N seconds (where N is equal to pwdGraceAuthnLimit) which
may be unwanted. Would it be possible to increase the granularity, and
if so, what size would make sense? Could it be made configurable?

FWIW, I know that basically every major LDAP server has one second
granularity, and that this does not mitigate the actual issue (only
lowers the time window during which this can be misused).

Thanks and regards.
-- 
Matúš Honěk
Software Engineer
Red Hat Czech

Re: RedHat 6 & 7 disable TLSv1.0

[Matus Honek]

Hello,

regarding this issue there are bugs opened:
https://bugzilla.redhat.com/show_bug.cgi?id=1249092
https://bugzilla.redhat.com/show_bug.cgi?id=1249093
https://bugzilla.redhat.com/show_bug.cgi?id=1375432

For further information, please, contact Red Hat Support.

I think this ITS case may be closed now as it is Red Hat specific.

Regards.

Gaurav Swami <swamigaura...@gmail.com> writes:

> Hello,
>
> I have Redhat 6  where  am trying to disable TLSv1.0 protocol.I have tried
> below configuration
>
> RHEL6
>
> -
> [root@ldap1 ~]# rpm -qa | grep -we openldap -we openssl -we nss
> krb5-pkinit-openssl-1.10.3-10.el6_4.6.x86_64
> openldap-servers-2.4.40-12.el6.x86_64
> nss-util-3.21.0-2.el6.x86_64
> nss-3.21.0-8.el6.x86_64
> openssl-devel-1.0.1e-48.el6_8.1.x86_64
> openssl-1.0.1e-48.el6_8.1.x86_64
> openldap-clients-2.4.40-12.el6.x86_64
> nss-softokn-freebl-3.14.3-23.3.el6_8.x86_64
> nss-sysinit-3.21.0-8.el6.x86_64
> nss-tools-3.21.0-8.el6.x86_64
> openldap-2.4.40-12.el6.x86_64
>
> nss-softokn-3.14.3-23.3.el6_8.x86_64
> 
>
> RHEL6 Configuration
>
> 
> TLSProtocolMin 3.2
> TLSCipherSuite  HIGH
> -
>
> But still when I ran third party tool to check offered protocol am getting
>
> --> Testing protocols (via sockets except TLS 1.2 and SPDY/NPN)
>
>  SSLv2  not offered (OK)
>  SSLv3  not offered (OK)
>  TLS 1  offered
>  TLS 1.1offered
>  TLS 1.2offered (OK)
>  SPDY/NPN   not offered
>
> --> Testing ~standard cipher lists
>
> TLSv1.0 is still offered  ,I want to disable TLSv1.0 also
>
> Any suggestiosn?
>
>
>
> -- 
> Thanks & Regards,
> **Gaurav Swami**

-- 
Matus Honek
Associate Software Engineer @ Red Hat, Inc.

Re: enforce TLS 1.2 in OpenLDAP server side

[Matus Honek]

Hello,

I am sorry for the inconveniences. I have filed a bug about this:
https://bugzilla.redhat.com/show_bug.cgi?id=1375432
This should be fixed with next release.

Regards.

Steve Zeng <steve.z...@booking.com> writes:

> Thanks for the LDAP tool box packages. I will give it a try. 
>
> Quick questions, I ran ldd to find out which TLS/SSL library and it shows:
>
> # ldd /usr/sbin/slapd
>
>linux-vdso.so.1 =>  (0x7fff5b044000)
>libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x7f3a36585000)
>libdb-4.7.so => /lib64/libdb-4.7.so (0x7f3a36211000)
>libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x7f3a35ff6000)
>libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f3a35dbf000)
>libresolv.so.2 => /lib64/libresolv.so.2 (0x7f3a35ba5000)
>libssl3.so => /usr/lib64/libssl3.so (0x7f3a35965000)
>libsmime3.so => /usr/lib64/libsmime3.so (0x7f3a35739000)
>libnss3.so => /usr/lib64/libnss3.so (0x7f3a353fa000)
>libnssutil3.so => /usr/lib64/libnssutil3.so (0x7f3a351cd000)
>libplds4.so => /lib64/libplds4.so (0x7f3a34fc9000)
>libplc4.so => /lib64/libplc4.so (0x7f3a34dc4000)
>libnspr4.so => /lib64/libnspr4.so (0x7f3a34b85000)
>libpthread.so.0 => /lib64/libpthread.so.0 (0x7f3a34968000)
>libwrap.so.0 => /lib64/libwrap.so.0 (0x7f3a3475d000)
>libc.so.6 => /lib64/libc.so.6 (0x7f3a343c8000)
>libdl.so.2 => /lib64/libdl.so.2 (0x7f3a341c4000)
>libfreebl3.so => /lib64/libfreebl3.so (0x7f3a33f4d000)
>libz.so.1 => /lib64/libz.so.1 (0x7f3a33d36000)
>librt.so.1 => /lib64/librt.so.1 (0x7f3a33b2e000)
>/lib64/ld-linux-x86-64.so.2 (0x7f3a3679c000)
>libnsl.so.1 => /lib64/libnsl.so.1 (0x7f3a33914000)
>
>
> # rpm -qf /usr/lib64/libssl3.so 
>
> nss-3.21.0-8.el6.x86_64
>
>
>
> Will that (the line containing libssl3.so) confirm it is the MozNSS libs? 
>
> I also tried the other settings and all clients immediately could not 
> connect. It that a suggested settings for this purpose, or it is simply due 
> to the wrong value I gave?
>
> olcTLSCipherSuite: ALL:!TLSv1.0:!TLSv1.1:!SSLv3
>
>
> Thanks,
> Steve
>
>
>
> On 9/12/16, 4:26 AM, "openldap-technical on behalf of Clément OUDOT" 
> <openldap-technical-boun...@openldap.org on behalf of 
> clement.ou...@savoirfairelinux.com> wrote:
>
>>
>>
>>Le 11/09/2016 à 03:25, Steve Zeng a écrit :
>>> Thanks for the note. So we need to rebuild it against OpenSSL?
>>>
>>>
>>
>>You can give a try to LDAP Tool Box packages which are built against 
>>OpenSSL:
>>* http://ltb-project.org/wiki/documentation/openldap-rpm
>>* http://ltb-project.org/wiki/download#openldap
>>
>>-- 
>>Clément OUDOT
>>Consultant en logiciels libres, Expert infrastructure et sécurité
>>Savoir-faire Linux
>>87, rue de Turbigo - 75003 PARIS
>>Blog: http://sflx.ca/coudot
>>

-- 
Matus Honek
Associate Software Engineer @ Red Hat, Inc.

Re: ldap user login attempt kills slapd service

[Matus Honek]

I must have missed the e-mail below from you, sorry for that. The link
to the archives is http://www.openldap.org/lists/openldap-technical/.

The related Red Hat Bugzilla is
https://bugzilla.redhat.com/show_bug.cgi?id=1335194

>From the backtraces provided by Liz in the case it seems to be
technically (except for presence of back_relay) the same as ITS#7384. So
it does not seem to be MozNSS-related. I will let Liz to include
additional backtraces (etc.) if asked for it.

"Real, Elizabeth (392K)"  writes:

> I reported the bug to red hat.
>
> What is the openldap technical URL where all of the submitted requests are 
> listed on?
>
> Thank you,
> Liz
>
>

-- 
Matúš Honěk
Associate Software Engineer @ Red Hat, Inc.

Re: problems connecting to ldaps:// under high load with ppc64 client

[Matus Honek]

Matthias Leopold <matthias.leop...@meduniwien.ac.at> writes:

> hi,
>
> i'm operating an owncloud server that connects to an IBM Tivoli 
> Directory Server as LDAP backend. the ldap admin tells me he is seeing 
> "null binds" from my owncloud server in his logs:
>
> 2016-05-24T14:32:56.349452+2:00 srvr_ssl_read: EIO in handshake. 
> EWOULDBLOCK timeout. Read: -2 of 0
> 2016-05-24T14:32:56.350445+2:00 GLPSSL019E The SSL layer has reported an 
> unidentified internal error, SSL extended error code:406.
> 2016-05-24T14:32:56.351813+2:00 GLPSRV022E Failed to initialize secure 
> connection from client (connection ID: 61786, IP address: x.x.x.x, Port: 
> 59921).
> 2016-05-24T14:32:56.357220+2:00 GLPSRV044W Client connection from 
> x.x.x.x bound as NULL closed by server.
>
> i investigated on my server and noticed that it has problems connecting 
> to the ldaps://ldap.example.com uri (which is the ITDS server) under 
> high client system load, whereas connection to ldap://ldap.example.com 
> is ok.
>
> $ ldapsearch -v -x -z 0 -H ldaps://ldap.example.com -b 
> "ou=groups,dc=example,dc=com" -v "objectClass=posixGroup"
> ldap_initialize( ldaps://ldap.example.com:636/??base )
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>
> my server (RHEL 7 on a ppc64 LPAR) is using the openldap 
> clients/libraries. the high load that is causing the problems is on _my_ 
> server. is there any specific tuning (besides increasing RAM/CPU) i can 
> do to optimize ldaps client queries? i'm thinking of tuning the tcp 
> stack or something similar, but i'm not an expert on this. where can i 
> look for debug info? i have strace and tcpdump output
>
> thx
> matthias

Hi Matthias,

as Quanah already stated RHEL7 builds use MozNSS and thus this problem
might be specific to these. If it is possible, please, try this
scenario with some OpenSSL-built OpenLDAP binaries (e.g. ones from
http://ltb-project.org). If these work correctly feel free to file a bug
to our bugzilla.redhat.com including all possible information. Anyway,
do not hesitate to contact our access.redhat.com customer assistance.

--
Matus Honek
Associate Software Engineer @ Red Hat, Inc.

Re: ldap user login attempt kills slapd service

[Matus Honek]

Hello,

as OpenLDAP distributed with RHEL uses NSS for crypto (which is
deprecated by OpenLDAP upstream community) please contact Red Hat
customer support with the issue. There, please supply full debug-level
logs from all servers and client. I have noticed the suppressed log lines
from journal in logs you have supplied bellow, which is not sufficient.
Thank you for your understanding.

"Real, Elizabeth (392K)"  writes:

> Openldap gurus:
>
> Here is my setup,
>
> LDAPSERVERS: I have two ldap servers running RHEL7.2 and openldap 2.4.40. 
> Both servers are configured with multi-master replication. Ldaps is enabled 
> and a ppolicy applied.
>
> LDAPCLIENT: My ldap client is running RHEL7.2 as well, sssd 1.13.0, and 
> openldap client 2.4.40.
>
> I have been troubleshooting this problem for a while and can’t figure out why 
> everytime I try to login to an ldap client with a test user account the slapd 
> service on only one of my ldap servers gets killed.
>
> Both getent and ldapsearch return the expected information when ran on the 
> ldap client:
> ldapclient ~]# getent passwd realtest
> realtest:*:1004:312:Liz RealTest:/home/real:/bin/tcsh
>
> ldapclient ~]# ldapsearch -x -s sub -b 'ou=People,dc=cluster,dc=sec312' 
> '(uid=realtest)'
> # extended LDIF
> #
> # LDAPv3
> # base