openldap-technical January 2019

openldap-technical@openldap.org

30 participants
21 discussions

Problem with "force user to password reset at first login
by Rajagopal Rc 30 Oct '23

30 Oct '23

Hi, I am trying to force users to change their password at first login or after password reset by administrator. Tried following: 1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non of the users get prompt to change their password at first login. 2) used the 'pwdReset TRUE' attribute in users attributes, and it won't prompt to change the password and didn't allow to login i observe below messages in log "slapd[12684]: connection restricted to password changing only … [View More]

5 9

OpenLDAP 2.4.45 possible denial of service vulnerability?
by Juergen.Sprenger＠swisscom.com 10 Feb '19

10 Feb '19

Hi, After upgrading to the latest Release (Solaris 11.3 SRU35, OpenLDAP 2.4.45) we are experiencing massive workloads caused by single clients consuming all available threads and CPU-resources. Service does not longer respond to requests, even cn=monitor on loopback interface stops to respond properly. OS: # pkg info entire Name: entire Summary: entire incorporation including Support Repository Update (Oracle Solaris 11.3.35.6.0). Description: This package … [View More]constrains system package versions to the same build. WARNING: Proper system update and correct package selection depend on the presence of this incorporation. Removing this package will result in an unsupported system. For more information see: https://support.oracle.com/rs?type=doc&id=2045311.1 Category: Meta Packages/Incorporations State: Installed Publisher: solaris Version: 0.5.11 (Oracle Solaris 11.3.35.6.0) Build Release: 5.11 Branch: 0.175.3.35.0.6.0 Packaging Date: August 10, 2018 03:22:59 PM Size: 5.46 kB FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.3.35.0.6.0:20180810T152259Z OpenSSL: # pkg info entire Name: entire Summary: entire incorporation including Support Repository Update (Oracle Solaris 11.3.35.6.0). Description: This package constrains system package versions to the same build. WARNING: Proper system update and correct package selection depend on the presence of this incorporation. Removing this package will result in an unsupported system. For more information see: https://support.oracle.com/rs?type=doc&id=2045311.1 Category: Meta Packages/Incorporations State: Installed Publisher: solaris Version: 0.5.11 (Oracle Solaris 11.3.35.6.0) Build Release: 5.11 Branch: 0.175.3.35.0.6.0 Packaging Date: August 10, 2018 03:22:59 PM Size: 5.46 kB FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.3.35.0.6.0:20180810T152259Z OpenLDAP: # pkg info entire Name: entire Summary: entire incorporation including Support Repository Update (Oracle Solaris 11.3.35.6.0). Description: This package constrains system package versions to the same build. WARNING: Proper system update and correct package selection depend on the presence of this incorporation. Removing this package will result in an unsupported system. For more information see: https://support.oracle.com/rs?type=doc&id=2045311.1 Category: Meta Packages/Incorporations State: Installed Publisher: solaris Version: 0.5.11 (Oracle Solaris 11.3.35.6.0) Build Release: 5.11 Branch: 0.175.3.35.0.6.0 Packaging Date: August 10, 2018 03:22:59 PM Size: 5.46 kB FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.3.35.0.6.0:20180810T152259Z Part of slapd.conf: loglevel none stats sync sizelimit 15000 timelimit 30 threads 64 tool-threads 8 idletimeout 0 writetimeout 0 security tls=0 conn_max_pending 100 conn_max_pending_auth 1000 database mdb suffix "dc=scom" rootdn "cn=*****" rootpw {SSHA}***** maxsize 17179869184 maxreaders 4096 searchstack 64 checkpoint 0 1 dbnosync Machine is a X6-2, 44 cores, 88 threads, 256GB RAM: # prtdiag System Configuration: Oracle Corporation ORACLE SERVER X6-2 BIOS Configuration: American Megatrends Inc. 38070000 12/16/2016 BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style) ==== Processor Sockets ==================================== Version Location Tag -------------------------------- -------------------------- Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz P0 Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz P1 Even monitoring (cn=monitor) is no longer accessible when this occurs. So far we experienced this behavior with clients of Oracle Enterprise Linux 6.x, Redhat Enterprise Linux 6.x and AIX. Service requests are opened at vendors support, but I'd prefer to have an installation which is less vulnerable and more resilient to issues of this kind. No problems or issues with Solaris and HPUX clients. Has anyone experienced similar problems or suggestions for configuration? To avoid performance issues loglevel is now "none stats sync" but can be changed for some time to track down the cause. Best regards Jürgen Sprenger [View Less]

4 7

ldap client failing
by sami's strat 30 Jan '19

30 Jan '19

I'm installing ldap client on CentOS 7 hosts. Some work, some do not. For those that don't work, I don't know why. The install / setup process I used was the same on all hosts. yum install nss-pam-ldapd openldap-clients -y authconfig --enableldap --enableldapauth --ldapserver=172.19.33.1 --ldapbasedn="dc=users,dc=domain,dc=com" --enablemkhomedir --update systemctl start nslcd getent passwd useraccount The last command fails. Vital signs on all hosts are fine, network, connectivity, ports, … [View More]

4 5

RE: OpenLDAP 2.4.45 possible denial of service vulnerability?
by Juergen.Sprenger＠swisscom.com 30 Jan '19

30 Jan '19

Hi Henrik, Many thanks for Your advice, - Yes, we started using mdb-backend and did not use it before. - LDAP tree is not very large, a slapcat dump has about 1.050 Million lines and less than 50'000 dn entries. - LDAP tree contains attributes 21661 of type aliasedObjectName - Yes, alias-dereferencing is used and set to always. Clients should not, but may do searches using "sub" instead of "one" . I will check whether using hdb will mitigate the problem. Jürgen -----Original Message----- … [View More]

1 0

authz-regexp failures
by Dieter Klünter 29 Jan '19

29 Jan '19

Hi, I am facing some problems with authz-regexp configurations. These configurations run for ages on several systems. I only discovered recently, that some errors occured: # ldapwhoami -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth The appropriate lines in slapd.conf: authz-regexp "gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=… [View More]

2 2

Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40
by Janne Peltonen 29 Jan '19

29 Jan '19

Hi! We've got a proxy OpenLDAP setup using the "ldap" proxy database (the newer "meta" backend had some issues, so I couldn't use that one). Most of the time, the proxy bind goes OK, but sometimes, the connection goes like this (proxy log, using ldaps): --clip-- Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 ACCEPT from IP=128.214.54.152:36460 (IP=0.0.0.0:636) Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 TLS established tls_ssf=256 ssf=256 Jan 7 16:01:12 ldap-r-1 slapd[… [View More]16851]: conn=7716 op=0 BIND dn="<removed>" method=128 Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 closed (connection lost) --clip-- On the backend, this appears to be the case that a new connection kind of overruns the old one; see what happens with connection 6983: --clip-- Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 ACCEPT from IP=128.214.222.155:46144 (IP=0.0.0.0:389) Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 ACCEPT from IP=128.214.222.155:46146 (IP=0.0.0.0:389) Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 STARTTLS Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=1 UNBIND Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 closed Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 STARTTLS Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 RESULT oid= err=0 text= Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 TLS established tls_ssf=256 ssf=256 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" method=128 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 RESULT tag=97 err=0 text= [SRCH and result lines] Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=3 UNBIND Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 closed --clip-- This doesn't seem to have any correlation to the amount of binds of server load, at least that I'm aware - and anyway, the servers are nowhere near at capacity - we only get ~2 binds per second. Normal connection would look like this: --clip-- Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 ACCEPT from IP=128.214.54.152:36362 (IP=0.0.0.0:636) Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 TLS established tls_ssf=256 ssf=256 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" method=128 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 RESULT tag=97 err=0 text= [SRCH and SEARCH RESULT lines] Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 op=219 UNBIND Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 fd=159 closed --clip-- So this far, it looks as if the problem was that if we accept a second connection for the same client before the proxy has had time to do a bind (or indeed, a STARTTLS for the bind) on the backend for the second connection. But we seem to be getting spurious Start TLS failed messages also without any competing connections. Here's one using ldap+STARTTLS but no other ACCEPTs anywhere near: --clip-- Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 ACCEPT from IP=128.214.173.135:43148 (IP=0.0.0.0:389) Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 STARTTLS Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 RESULT oid= err=0 text= Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 TLS established tls_ssf=256 ssf=256 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 BIND dn="ou=shibboleth,ou=login,dc=helsinki,dc=fi" method=128 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 RESULT tag=97 err=52 text=Start TLS failed Jan 17 17:46:22 ldap-r-1 slapd[28738]: conn=529684 fd=62 closed (connection lost) --clip-- on the proxy, and backend: --clip-- Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 ACCEPT from IP=128.214.222.155:48996 (IP=0.0.0.0:389) Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 STARTTLS Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 RESULT oid= err=0 text= Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 closed (TLS negotiation failure) --clip-- Succesful ldap+starttls connection on proxy: --clip-- Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 ACCEPT from IP=128.214.173.137:48700 (IP=0.0.0.0:389) Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 STARTTLS Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 RESULT oid= err=0 text= Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 TLS established tls_ssf=256 ssf=256 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" method=128 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 RESULT tag=97 err=0 text= [SRCH and SEARCH RESULT lines] Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=3 UNBIND Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 closed --clip-- Any ideas what could be causing these? It's a bit hard to pinpoint the problem, since it happens so rarely - we seem to get a couple dozen of these every hour to around 16 000 succesful binds, not really depending on system load. This is RHEL 7 and OpenLDAP 2.4.40. It may be the case that the same DN binding very often increases the probability of a Start TLS failed error, which I guess would be the first case (a new ACCEPT + BIND for a DN too soon after the previous one). But as I said, these seem to also sometimes appear even without any other connections being opened at the same time. (Although there might be some old connections open for the same DN.) --Janne Peltonen University of Helsinki [View Less]

5 11

openldap proxy with uid/gid lookup cache
by vadud3＠gmail.com 27 Jan '19

27 Jan '19

How do I include uid/gid lookup caching to my openldap proxy server? $ cat slapd.conf ### Schema includes ########################################################### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema ## Module paths #####################… [View More]

3 3

Copying SSHA userPassword from Oracle to OpenLDAP
by Nicholas Carl 23 Jan '19

23 Jan '19

Currently doing a targeted sync of userPassword field from one LDAP to another following this process. 1) Query using ldapsearch and grab userPassword field. 2) Deode string using base64 –d 3) Import resultant encrypted password into other ldap using ldapmodify. This process worked when the password decoded into {crypt} format, but after they upgraded and changed to {SSHA} format passwords, it no longer works. Also confirmed with Oracle LDAP admins that the decode matches … [View More]

6 6

uniqueness on multiple attributes
by A. Schulze 21 Jan '19

21 Jan '19

Hello, my goal it to extend a uniqueness configuration. I do already enforce uniqueness of mail addresses: slapd.conf: moduleload unique.la overlay unique unique_uri ldap:///dc=basedn?mail?sub? that works. Now also address rewriting data should be migrated LDAP. Rewriting addresses are stored in the attribute "mailalternateaddress" Requirement: no address may occur twice no matter if stored as "mail" or "mailalternateaddress" Logical it's something like unique_uri (ldap:///dc=basedn?… [View More]

2 3

lastbind module and missing forwarding updates
by David Magda 17 Jan '19

17 Jan '19

Hello, So I'm looking at the code for the /lastbind/ module, and I see the following: > "MAY ( olcLastBindPrecision $ olcLastBindForwardUpdates) )", https://github.com/openldap/openldap/blob/master/contrib/slapd-modules/last… However, when selecting various tagged releases (OPENLDAP_REL_ENG_2_4_[37-47]) I do not see the code. It was committed in October 2013: https://github.com/openldap/openldap/commit/44e9bda0e42f40e0baf0a2c0ef733eb… This would have been around the time of 2.4.37, … [View More]

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2019