openldap-technical December 2017

openldap-technical@openldap.org

22 participants
22 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 slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password" Please help me configure the option to force all users to change their password at first login or after pwd reset by administrator. Thanks & Regards Raj Tata Consultancy Services Mailto: rajagopal.rc(a)tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

5 9

Re: Syncrepl and multipe values
by Quanah Gibson-Mount 24 Feb '18

24 Feb '18

--On Friday, January 06, 2017 6:50 PM +0000 Matheus Eduardo Bonifacio Morais <matheus_morais(a)sicredi.com.br> wrote: > > > > Issue 8559 opened. > > > > I'm trying to work on a patch but I'm not sure if the best solution is to > fix accesslog to avoid duplicated values or if the sample LDIF (in its > description) should result in a constraint violation. What do you think? The accesslog should never write an operation that can't be replicated. If the MOD is a valid LDAP operation (which I think it is), then it should be accepted at the frontend. The issue may be more in delta-syncrepl's handling of the write op than anything else. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 3

[Q] what is the best practice or right way to change schemas order for cn=config case?
by Zeus Panchenko 09 Jan '18

09 Jan '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, what is the best practice or right way to change schemas order for cn=config case? 1. to move file? 2. to ldapmodify? for the one used to slapd.conf both of ways look weird ... :( - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlo6mMsACgkQr3jpPg/3oypRzwCdHNMNgUewiolW91I7DB7cK5dE BqoAn0tXLDIMIBg0W9uG39pwN7LPRPth =jKuI -----END PGP SIGNATURE-----

3 3

OpenLDAP slave failure in case of master indisponibility
by Matthieu Cerda 02 Jan '18

02 Jan '18

Greetings, I am observing a rather strange issue in the following setup: * 1 OpenLDAP master server (2.4.31) * 4 OpenLDAP slave servers (2.4.40) * The OpenLDAP slaves do forward any update attempt to the master using the chain overlay / proxyauthz (mainly to update the pwdFailureTime attribute for ppolicy) If I try to shut the master down (for maintenance let's say), the slaves behave properly, then begin to deadlock one after each other after a few minutes (by deadlock I mean no log output anymore, and any ldapwhoami / ldapsearch request connects and then times out) On the attached image, I monitored at the same time one of the slaves using collectd, to keep an eye on cn=monitor data (the period between 15:24:30 and 15:26:00 has been extrapolated by Grafana, no data is available at this time since cn=monitor access also deadlocks) I can see that backload / pending threads and waiters seem to increase gradually until the server gets unresponsive. I found nothing on the ML (except https://www.openldap.org/lists/openldap-technical/200912/msg00112.html) or searching for clues, Is this predictable behavior or and obvious misconfiguration, or it is an interesting occastion to dig a bit deeper ? Thanks in advance, -- Matthieu Cerda Infrastructure, BU Means @ NBS System

2 2

Error in dnx509Normalize when adding userCertificate value
by Cédric Couralet 28 Dec '17

28 Dec '17

Hello all, I encountered a problem when importing several client certificate in usercertificate attribute. The error was : [15362]: >>> certificateExactNormalize: <0x7f07019a9100, 1745> [15362]: dnX509Normalize: <(null)> (21) [15362]: <<< certificateExactNormalize: <0x7f07019a9100, 1745> => <(err)> [15362]: <= str2entry NULL (ssyn_normalize 21) [15362]: conn=1591 op=17 RESULT tag=103 err=21 text=userCertificate;binary: value #0 normalization failed Looking through the certificateExactNormalize in sourcecode, it seems the problem comes from the normalization of IssuerDn. Sure enough, in my case the issuer dn is : CN = Certigna Services CA 2.5.4.97 = NTRFR-48146308100036 OU = 0002 48146308100036 O = DHIMYOTIS C = FR Openldap has problem with the "2.5.4.97 = NTRFR-48146308100036" part, it is declared as organizationIdentifier but don't appear in openldap core schema (yet ?). I managed to avoid the error by adding an attribute to schema but I'm wondering if there is not a better way to do it, and why is the normalize called here ? My ldap version is the debian one : # slapd -V @(#) $OpenLDAP: slapd (Apr 23 2013 12:16:04) $ root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd Is an update sufficient? Thank you for your answers, Cédric Couralet

2 1

LDAP password policies don't seems to work
by André Rodier 24 Dec '17

24 Dec '17

Hello all, I have an LDAP server, that I use for system authentication, emails, etc, in a domain (homebox.space) I have the password policies defined in the LDAP database, but they don't seem to apply to the users when changing a password. Both "olcPPolicyDefault" and "olcPPolicyHashCleartext" are set up, but only the last is working, i.e. passwords sent in clear text by an LDAP client are automatically encrypted. There is an overlay entry for the domain, example: olcPPolicyDefault: cn=default,ou=pwpolicies,dc=homebox,dc=space and a correct entry "pwdPolicySubentry" for each user. However, when I try change the password with pam_ldap or using the roundcube password plugin, even the minimal length rule is ignored. The module configuration: > dn: cn=module{0},cn=config > objectClass: olcModuleList > cn: module{0} > olcModulePath: /usr/lib/ldap > olcModuleLoad: {0}back_mdb > olcModuleLoad: {1}ppolicy.la > olcModuleLoad: {2}deref.la > structuralObjectClass: olcModuleList > entryUUID: acbfbc52-7c3a-1037-9cc1-d74dec6fc011 > creatorsName: cn=admin,cn=config > createTimestamp: 20171223143824Z > entryCSN: 20171223143828.930245Z#000000#000#000000 > modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > modifyTimestamp: 20171223143828Z The overlay configuration > dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config > objectClass: olcPPolicyConfig > objectClass: olcOverlayConfig > olcOverlay: {0}ppolicy > olcPPolicyDefault: cn=default,ou=pwpolicies,dc=homebox,dc=space > olcPPolicyHashCleartext: TRUE > olcPPolicyUseLockout: FALSE > olcPPolicyForwardUpdates: FALSE > structuralObjectClass: olcPPolicyConfig > entryUUID: affa09e0-7c3a-1037-956b-0f107d4f36ac > creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > createTimestamp: 20171223143829Z > entryCSN: 20171223143829.643274Z#000000#000#000000 > modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > modifyTimestamp: 20171223143829Z The policy: > dn: cn=default,ou=pwpolicies,dc=homebox,dc=space > pwdExpireWarning: 259200 > pwdMaxFailure: 5 > cn: default > objectClass: pwdPolicy > objectClass: person > objectClass: top > pwdMinLength: 8 > pwdCheckQuality: 0 > pwdAttribute: userPassword > pwdLockoutDuration: 0 > pwdInHistory: 0 > sn: default > pwdMaxAge: 31536000 > pwdGraceAuthNLimit: 0 > pwdFailureCountInterval: 300 > structuralObjectClass: person > entryUUID: b083c4d2-7c3a-1037-956d-0f107d4f36ac > creatorsName: cn=admin,dc=homebox,dc=space > createTimestamp: 20171223143830Z > entryCSN: 20171223143830.545905Z#000000#000#000000 > modifiersName: cn=admin,dc=homebox,dc=space > modifyTimestamp: 20171223143830Z Example of one user: > dn:: Y249QW5kcsOpIFJvZGllcixvdT11c2VycyxkYz1ob21lYm94LGRjPXNwYWNl > pwdPolicySubentry: cn=default,ou=pwpolicies,dc=homebox,dc=space > shadowMin: 0 > uid: andre > objectClass: top > objectClass: person > objectClass: posixAccount > objectClass: shadowAccount > objectClass: inetOrgPerson > loginShell: /bin/bash > shadowFlag: 0 > uidNumber: 1001 > shadowMax: 999999 > gidNumber: 1001 > homeDirectory: /home/users/andre > sn: Rodier > shadowInactive: -1 > mail: andre(a)homebox.space > givenName:: QW5kcsOp > shadowWarning: 7 > structuralObjectClass: inetOrgPerson > cn:: QW5kcsOpIFJvZGllcg== > entryUUID: b12c4db4-7c3a-1037-9572-0f107d4f36ac > creatorsName: cn=admin,dc=homebox,dc=space > createTimestamp: 20171223143831Z > userPassword:: e1NTSEF9SHllVitOazkyekNHYlIwbVRUdkZJZWFpVUo2WElSVWM= > pwdChangedTime: 20171223150211Z > entryCSN: 20171223150211.599058Z#000000#000#000000 > modifiersName: cn=admin,dc=homebox,dc=space > modifyTimestamp: 20171223150211Z > I have the whole source code here: https://github.com/progmaticltd/homebox/ The Ansible tasks I am using to configure the LDAP server are here: https://github.com/progmaticltd/homebox/blob/master/install/playbooks/roles… Any help welcome. Kind regards, André Rodier. PS: Merry Christmas / Happy new year / for those concerned.

2 2

Re: [Q] what is the best practice or right way to change schemas order for cn=config case?
by Howard Chu 21 Dec '17

21 Dec '17

Christian Kratzer wrote: > Hi, > > On Wed, 20 Dec 2017, Zeus Panchenko wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> hi, >> >> what is the best practice or right way to change schemas order for cn=config >> case? Use ldapmodrdn. >> >> 1. to move file? >> 2. to ldapmodify? >> >> for the one used to slapd.conf both of ways look weird ... :( > > for those cases that ldapmodify that does not work you can use slapcat > to dump all of the cn=config database edit it and reimport using slapadd. > > Adding -n0 to slapadd and slapcat makes it use the cn=config database. > > Greetings > Christian > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: uidNumber for Service Accounts?
by Douglas Duckworth 19 Dec '17

19 Dec '17

Thanks John and everyone else. It's only performing binds for Apache, and sssd, as I do not allow anon binds to the LDAP server. This particular account does not perform any interactive logins on *Nix boxes. Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Wed, Oct 25, 2017 at 9:18 PM, John Lewis <jl(a)hyperbolicinnovation.com> wrote: > On Wed, 2017-10-25 at 09:32 -0400, Douglas Duckworth wrote: > > Hi > > > > Do I need uidNumber for Service Accounts used for application / > > server binding if this user won't actually be resolved by sssd or > > nslcd? > > > > I set a very high uidNumber but eventually this will conflict with > > users as in my ignorance I didn't put this in a lower range. > > > > Thanks, > > > > Douglas Duckworth, MSc, LFCS > > HPC System Administrator > > Scientific Computing Unit > > Physiology and Biophysics > > Weill Cornell Medicine > > E: doug(a)med.cornell.edu > > O: 212-746-6305 > > F: 212-746-8690 > > It depends on weather your service account needs to login to a UNIX > compliant system or not. If the account doesn't have a uid, it will > most likely not be able to login as a standard UNIX account via LDAP. > > If the binds go directly to an application without going through an OS > authentication layer, for example a web user login, it probably doesn't > matter either way whether the account has a uidNumber set or not. If > you have an interaction with sssd or nslcd in the middle, you are going > to need the uidNumber attribute set. >

3 4

Re: use-case for clientctrls?
by Howard Chu 19 Dec '17

19 Dec '17

Michael Ströder wrote: > After so many years passing around parameter clientctrls (e.g. in a > wrapper module) I'm still wondering which use-cases this argument is > meant for. > > I only found [1] but this seems akward today anyway. Agreed, OID-based controls for client-side library behavior seems rather unwieldy. I would agree though, that per-request control of library behavior is a good thing. The C API still has no ldap_search() parameter for alias deref behavior. It's a bit ridiculous that it's a library-level option, since the option only has relevance to search requests. > Any more client controls? > > Ciao, Michael. > > [1] > https://tools.ietf.org/html/draft-ietf-ldapext-ldap-c-api-05#section-11.3.1 > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

use-case for clientctrls?
by Michael Ströder 18 Dec '17

18 Dec '17

After so many years passing around parameter clientctrls (e.g. in a wrapper module) I'm still wondering which use-cases this argument is meant for. I only found [1] but this seems akward today anyway. Any more client controls? Ciao, Michael. [1] https://tools.ietf.org/html/draft-ietf-ldapext-ldap-c-api-05#section-11.3.1

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2017