openldap-technical December 2024

openldap-technical@openldap.org

24 participants
22 discussions

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2024