openldap-technical

openldap-technical@openldap.org

12 participants
9980 discussions

Re: Meaning of "slapd[2606]: ppolicy_bind: Setting warning for password expiry for ... = ... seconds"
by Ondřej Kuzník 10 Dec '24

10 Dec '24

On Tue, Dec 10, 2024 at 07:23:55AM +0000, Windl, Ulrich wrote: >> It seems you are running with a loglevel that includes "trace", so I >> will repeat what I said before: >> >> "If you set your log level to trace, you will get logs that document >> decisions made during the tool/server operation. As a user, that is what >> I want out of a level with a name like that." > > The loglevel setup is this: > olcLogLevel: config > olcLogLevel: sync > olcLogLevel: none The message is clearly[0] emitted with level TRACE only, so either you're running a different slapd or these are not the logging options that are actually in use. Maybe -d <level> (debug level setting) and you're referring to the stderr output? [0]. https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/over… -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: [EXT] Re: Meaning of "slapd[2606]: ppolicy_bind: Setting warning for password expiry for ... = ... seconds"
by Ondřej Kuzník 09 Dec '24

09 Dec '24

On Wed, Dec 04, 2024 at 10:47:24AM +0000, Windl, Ulrich wrote: >> Not sure what makes you think this is even a bug? > > It's the number of messages: > (Uptime 56 days) > # journalctl -b |grep 'Setting warning for password expiry' | wc -l > 72697 It seems you are running with a loglevel that includes "trace", so I will repeat what I said before: "If you set your log level to trace, you will get logs that document decisions made during the tool/server operation. As a user, that is what I want out of a level with a name like that." Yes, that means you will have plenty of things logged that might not interest you under most circumstances. If it bothers you, set a reasonable loglevel like stats and sync. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

PP/expiry issues with Ubuntu22 and RH6
by Felix Natter 07 Dec '24

07 Dec '24

Dear openldap experts, the company I work for recently migrated to Ubuntu 22.04, and we use openldap with password policies and password expiry (once per year), with no changes to OpenLDAP config. However, we also use a scientific linux 6 (SL6, ~RH6) compile machine for backwards compatibility purposes (also using OpenLDAP). Now what happens is: - user ldaptestuser1's password expires - she/he changes her/his password on Ubuntu (problem 1: no PP checking, maybe due to cache_credentials = yes in /etc/sssd/sssd.conf) - SL6 (host X) does not know about that (problem 2: pwd checking on SL6 _always_ yields a Constraint violation, so user ldaptestuser1 cannot login there): ldaptestuser1@X's password: You are required to change your password immediately (password aged) You are required to change your LDAP password immediately. Last login: DATE from Y WARNING: Your password has expired. You must change your password now and login again! Changing password for user ldaptestuser1. Enter login(LDAP) password: New password: Retype new password: LDAP password information update failed: Constraint violation Password fails quality checking policy passwd: Authentication token manipulation error Connection to X closed. I cannot see any relevant error in the server (sys)log (with stats logging). Which log level shall I enable? - is there a workaround / fix for problem 1? - Regarding problem 2: shall I disable password expiry (shadow extension)? Many Thanks and Best Regards! -- Felix Natter

2 2

make the attribute mail SINGLE-VALUE
by A. Schulze 05 Dec '24

05 Dec '24

Hello, I'm planing a schema to store data (mostly mail addresses) in OpenLDAP. one (soft) requirement: the mail address should be a single value. secondary addresses goes in an other attribute which allow multiple values. The only way I found for now is to copy the definition of 'mail' in core.schema [1] and write attributetype ( <my oid> NAME ( 'mail-sv' ) DESC 'RFC1274: RFC822 Mailbox (copy from core.schema, but SINGLE-VALUE)' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE ) This would work but it's not convenient: Everybody expect a mail address in a attribute named "mail", not "mail-sv" Are there other options to fulfill the requirement or makes the requirement at all no sense? I appreciate any comments. Andreas [1] https://github.com/openldap/openldap/blob/master/servers/slapd/schema/core.…

2 1

Meaning of "slapd[2606]: ppolicy_bind: Setting warning for password expiry for ... = ... seconds"
by Windl, Ulrich 04 Dec '24

04 Dec '24

Hi! Me again after 10 years with basically the same question (https://www.openldap.org/lists/openldap-technical/201411/msg00044.html): What is the meaning of messages like these (note the number of messages created): Nov 19 11:53:47 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040879 seconds Nov 19 11:53:50 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040876 seconds Nov 19 11:53:52 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040874 seconds Nov 19 11:53:54 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040872 seconds Nov 19 11:53:57 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040869 seconds Nov 19 11:53:59 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040867 seconds Nov 19 11:57:41 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040645 seconds Nov 19 11:57:44 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040642 seconds Nov 19 11:58:01 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1040625 seconds ... Nov 19 13:18:35 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035791 seconds Nov 19 13:18:39 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035787 seconds Nov 19 13:18:41 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035785 seconds Nov 19 13:18:44 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035782 seconds Nov 19 13:18:46 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035780 seconds Nov 19 13:18:48 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035778 seconds Nov 19 13:18:51 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035775 seconds Nov 19 13:18:54 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035772 seconds Nov 19 13:18:56 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035770 seconds Nov 19 13:18:59 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035767 seconds Nov 19 13:19:02 v07 slapd[2606]: ppolicy_bind: Setting warning for password expiry for uid=user = 1035764 seconds So the server logs such an entry every few seconds. I might guess that the user tried to authenticate every few seconds (for whatever reason). But what I wonder most: The LDAP server does not seed to "set" the password expiration; it just has to check the value. And for the latter I see no need to log it in syslog. It seems the number is the number of seconds until the password actually expired. So is that a (historic) bug? And yes, I'm still running a historic 2.4 version of OpenLDAP, so no need to tell me that it's quite old. (Despite of that we really intend to upgrade, but the more persons involved, the loger it takes...) Kind regards, Ulrich

2 2

autoca Attribute olcAutoCAserverClass
by Stefan Kania 29 Nov '24

29 Nov '24

Hello, I try to add the autoca overlay with the following ldif: -------------- dn: olcOverlay=autoca,olcDatabase={2}mdb,cn=config objectClass: olcAutoCAConfig objectClass: olcOverlayConfig olcOverlay: autoca olcAutoCADays: 3652 olcAutoCAKeybits: 4096 olcAutoCAserverClass: ipHost olcAutoCAserverDays: 1826 olcAutoCAserverKeybits: 4096 olcAutoCAuserClass: person olcAutoCAuserDays: 365 olcAutoCAuserKeybits: 4096 -------------- ldapadd gives me: adding new entry "olcOverlay=autoca,olcDatabase={2}mdb,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcAutoCAserverClass> handler exited with 1 If I remove the attribute from my ldif, it works. What is wrong with the olcAutoCAserverClass attribute in my ldif? I try to look it up in the admin handbook but I could not find anything. I looked in the source code and found: ------------ { "serverClass", "objectclass", 2, 2, 0, ARG_STRING|ARG_MAGIC|ACA_SRVCLASS, autoca_cf, "( OLcfgOvAt:22.2 NAME 'olcAutoCAserverClass' " "DESC 'ObjectClass of server entries' " "EQUALITY caseIgnoreMatch " "SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL }, ------------ For me it looks the same as the attribute olcAutoCAuserclass. ------------- { "userClass", "objectclass", 2, 2, 0, ARG_STRING|ARG_MAGIC|ACA_USRCLASS, autoca_cf, "( OLcfgOvAt:22.1 NAME 'olcAutoCAuserClass' " "DESC 'ObjectClass of user entries' " "EQUALITY caseIgnoreMatch " "SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL }, ------------- Stefan

2 2

mdb_tassert(txn, rc == 0) fails in mdb_page_dirty()
by Christian Wendt 29 Nov '24

29 Nov '24

Hi, I have a system that fails to write to its lmdb based database. There is an assertion triggered from within mdb_txn_commit() inside mdb_page_dirty(). Further investigation shows that there is a duplicate page in a freelist entry: ~# mdb_stat -narrfff /home/skov/data/data.mdb Reader Table Status (no active readers) 0 stale readers cleared. (no active readers) Freelist Status Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 28 Transaction 128121111, 3 pages, maxspan 1 1281 1300 1468 Transaction 128121112, 6 pages, maxspan 1 [bad sequence] 229 229 569 1317 1444 1460 Transaction 128121113, 5 pages, maxspan 1 ... What could trigger such a duplicate entry and what could I try to do to figure out the root cause of the issue? Is there a recommended way of detecting or handling such errors at runtime? Thanks a lot for any pointers. Best regards, Christian Wendt

2 3

Client IP address in accesslog ?
by Benjamin Renard 21 Nov '24

21 Nov '24

Hi, I would like to know if there is a way to get the client's IP address in the events recorded by accesslog (at least during BINDs). I found traces of requests for this dating back to 2010, but I haven't been able to determine if it was ever implemented. Thanks! -- Benjamin Renard - Easter-eggs 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - mailto:brenard@easter-eggs.com

6 9

Technical account impersonation or not
by BECOT Jérôme 20 Nov '24

20 Nov '24

Hello all, We currently use two distinct accounts for chaining and replication purpose. We want to use a passwordless policy and we go for certificates. As we only own a single certificate per slave server, this means that we authenticate as a single user. We see two way to do things: * Either we just use one account (bound by olcAuthzRegexp rule) and merge ACLs to allow this account to read the directory for sync and write authentication attributes for chaining * Or we keep two accounts and use Proxy Auth to impersonate the other one I personnaly would go for the first one as I don't see any value to use another mechanism given that these are technical accounts that have only one purpose each, except having a distinct login in the logs. What would you advice ? I may have miss something intersting, any security issue, or maybe there is another way. Thank you ! Jerome

2 2

RE26 testing call (2.6.9) #1
by Quanah Gibson-Mount 19 Nov '24

19 Nov '24

This is the first testing call for OpenLDAP 2.6.9. Depending on the results, this may be the only testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.6.9 Engineering Fixed libldap TLS connection timeout handling (ITS#8047) Fixed libldap GnuTLS incompatible pointer type (ITS#10253) Fixed libldap OpenSSL set_ciphersuite error handling (ITS#10223) Fixed libldap to check for OpenSSL EVP_Digest* failure (ITS#10224) Fixed slapd cn=config disallowed modification of cn=schema (ITS#10256) Fixed slapd syncrepl assert during refresh at shutdown (ITS#10232) Fixed slapd syncrepl retry state during refreshDone (ITS#10234) Fixed slapd-ldap use of multi-precision add for op counters (ITS#10237) Fixed slapd-mdb idl intersection (ITS#10233) Fixed slapd-wt idl intersection (ITS#10233) Fixed slapo-memberof to omit dynamic values (ITS#10230) Fixed slapo-nestgroup leak in nestgroup_memberFilter (ITS#10249) Fixed slapo-translucent regression with subordinate databases (ITS#10248) Fixed slapo-translucent regression when requesting attributes (ITS#10272) Fixed slappw-argon2 defaults to be more secure (ITS#9827) Minor Cleanup ITS#10155 ITS#10218 ITS#10219 ITS#10227 ITS#10231 ITS#10235 ITS#10263 ITS#10264 Regards, Quanah

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical