openldap-technical July 2022

openldap-technical@openldap.org

26 participants
25 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

iNetOrgPerson doesn't exist?
by Luca Stancapiano 16 May '23

16 May '23

Hi all, I'm triing to create a user with openldap 2.4 dn: uid=rrrrrr,ou=users,dc=my-domain,dc=com objectClass: iNetOrgPerson uid: iiiiii but it doesn't seem recognize the objectClass producing this error: adding new entry "uid=rrrrrr,ou=users,dc=my-domain,dc=com" ldap_add: Invalid syntax (21) additional info: objectClass: value #0 invalid per syntax Using other object classes is ok. What's the problem?

5 11

dynlist vs memberof performance issues
by Mark Cairney 11 Jan '23

11 Jan '23

Hi, I've been out the LDAP loop for a bit but the recent discussion of the memberof overlay on 2.5 piqued my curiosity. Having upgraded a Dev box, removed the memberof elements from the database and replaced the memberof overlay with dynlist the queries appear to work as expected but are both a) slow and b) heavily CPU-intensive on the LDAP server. 2021-09-01T12:47:17.603513+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 fd=12 ACCEPT from IP=192.168.152.33:58738 (IP=129.215.17.9:636) 2021-09-01T12:47:17.687488+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 2021-09-01T12:47:17.688032+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" 2021-09-01T12:47:17.688470+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=0 SRCH attr=supportedSASLMechanisms 2021-09-01T12:47:17.688878+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=0 SEARCH RESULT tag=101 err=0 qtime=0.000014 etime=0.000214 nentries=1 text= 2021-09-01T12:47:17.811279+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=1 BIND dn="" method=163 2021-09-01T12:47:17.819249+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=1 RESULT tag=97 err=14 qtime=0.000030 etime=0.009084 text=SASL(0): successful result: 2021-09-01T12:47:17.908889+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=2 BIND dn="" method=163 2021-09-01T12:47:17.909836+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=2 RESULT tag=97 err=14 qtime=0.000031 etime=0.000181 text=SASL(0): successful result: 2021-09-01T12:47:17.938839+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 BIND dn="" method=163 2021-09-01T12:47:17.939621+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 BIND authcid="mcairney(a)EASE.ED.AC.UK" authzid="mcairney(a)EASE.ED.AC.UK" 2021-09-01T12:47:17.940213+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 BIND dn="uid=mcairney,ou=people,ou=central,dc=authorise-dev,dc=ed,dc=ac,dc=uk" mech=GSSAPI bind_ssf=256 ssf=256 2021-09-01T12:47:17.940616+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 RESULT tag=97 err=0 qtime=0.000024 etime=0.000409 text= 2021-09-01T12:47:18.227342+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=4 SRCH base="dc=authorise-dev,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(uid=mcairney)" 2021-09-01T12:47:18.227703+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=4 SRCH attr=* + 2021-09-01T12:47:31.392255+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=5 UNBIND 2021-09-01T12:47:31.460705+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=4 SEARCH RESULT tag=101 err=0 qtime=0.000031 etime=13.233679 nentries=1 text= 2021-09-01T12:47:31.461098+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 fd=12 closed I'm guessing that as the values are computed that this will be heavier on the CPU but it seems a bit excessive? Has anyone else noticed any similar performance issues? This is a relatively low-specced DEV server (2 vCPUs, 4GB RAM) so I guess this could be a factor but there's no io waiting on the server and no swapping? The database is on a par in size with our Production service ( about 400K user objects with 1 group object per user and then about 80K actual groups of users) The config for the primary DB (ACLs and rootPW redacted) is: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /opt/openldap/var/openldap-data/authorise olcSuffix: dc=authorise-dev,dc=ed,dc=ac,dc=uk olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 2 olcReadOnly: FALSE olcSecurity: ssf=1 olcSecurity: update_ssf=112 olcSecurity: simple_bind=64 olcSizeLimit: unlimited olcSyncUseSubentry: FALSE olcTimeLimit: unlimited olcMonitoring: TRUE olcDbEnvFlags: writemap olcDbEnvFlags: nometasync olcDbNoSync: FALSE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: eduniType eq olcDbIndex: gecos pres,eq,sub olcDbIndex: eduniCategory eq olcDbIndex: mail pres,eq,sub olcDbIndex: eduniSchoolCode eq olcDbIndex: eduniIDStatus eq olcDbIndex: eduniCollegeCode eq olcDbIndex: eduniOrgCode eq olcDbIndex: memberOf pres,eq olcDbIndex: eduniLibraryBarcode pres,eq olcDbIndex: eduniOrganisation pres,eq,sub olcDbIndex: eduniServiceCode pres,eq olcDbIndex: krbName pres,eq olcDbIndex: eduPersonAffiliation pres,eq olcDbIndex: eduPersonEntitlement pres,eq olcDbIndex: sn pres,eq,sub olcDbIndex: eduniIdmsId pres,eq olcDbIndex: member pres,eq olcDbIndex: memberUid pres,eq olcDbIndex: eduniRefNo pres,eq olcDbIndex: eduniTitle pres,eq olcDbIndex: title pres,eq,sub olcDbIndex: eduniCardNumber pres,eq olcDbIndex: eduniYearOfStudy eq olcDbIndex: description pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbIndex: aliasedObjectName eq olcDbIndex: yubiKeyId pres,eq olcDbIndex: isMemberOf pres,eq olcDbIndex: hasMember pres,eq olcDbIndex: proxyAddresses pres,eq,sub olcDbMaxReaders: 96 olcDbMaxSize: 32212254720 olcDbMode: 0600 olcDbSearchStack: 16 structuralObjectClass: olcMdbConfig dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 02+00:00 00+04:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynListConfig olcOverlay: {2}dynlist olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames structuralObjectClass: olcDynListConfig -- /**************************** Mark Cairney ITI Enterprise Services Information Services University of Edinburgh Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk *******************************/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

12 27

Empty error when configuring OpenLDAP
by Cezary Drożak 23 Aug '22

23 Aug '22

Hello, I am trying to set up OpenLDAP on Arch Linux on my server, following instruction on Arch Wiki[1]. I prepared the config.ldif file, replacing every $BASEDN and $PASSWD in the example configuration: # The root config entry dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /run/openldap/slapd.args olcPidFile: /run/openldap/slapd.pid # Schemas dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema # TODO: Include further schemas as necessary include: file:///etc/openldap/schema/core.ldif # The config database dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcRootDN: cn=Manager,dc=example,dc=com # The database for our entries dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcSuffix: dc=example,dc=com olcRootDN: cn=Manager,dc=example,dc=com olcRootPW: {SSHA}xZqSQN4wG4+C5I57dB/Qm02vJ+kQcwd7 olcDbDirectory: /var/lib/openldap/openldap-data # TODO: Create further indexes olcDbIndex: objectClass eq Then I executed the following command: sudo -u ldap slapadd -n 0 -F /etc/openldap/slapd.d/ -l ./config.ldif This gave me the following error: invalid config directory /etc/openldap/slapd.d/, error 2 slapadd: bad configuration directory! I checked that the directory did not exist, so I created it and changed owner to `ldap`. The wiki page did not mention that the directory should be created earlier, so maybe it should have been created by a post installation script. If that's the case, I will report it to package maintainers. After I created the directory, I ran the command again, this time having a different error message: slapadd: could not add entry dn="cn=config" (line=1): Closing DB... I have no idea what is wrong now and I cannot find anything useful on the internet. Does anyone have an idea what I may be doing wrong here? [1]: https://wiki.archlinux.org/title/OpenLDAP

3 4

Re: Pass-through
by Stéphane Veyret 20 Aug '22

20 Aug '22

Could it be that the SASL global configuration (also given in first message) is wrong? I only set those 2 options: olcSaslHost: localhost olcSaslSecProps: none

2 4

OpenLDAP on Debian 11: missing TLS ciphers?
by Jochen Keutel 03 Aug '22

03 Aug '22

Hello, we installed the standard OpenLDAP package on Debian 11. Checking the TLS ciphers offered by the server we could see that all six Camellia ciphers are gone (128 and 256, for TLS 1.0, 1.1, 1.2) compared with the standard OpenLDAP package on Debian 9. Is this special to the Debian package? Or: Has Gnutls changed something? We did run into this issue because some special devices (e.G. Cisco Prime Collaboration Assurance) cannot connect to the new OpenLDAP server. The server logfile states: TLS handshake: negotiation failure. It's not yet clear whether they really can "speak" only Camellia ... Regards Jochen.

5 7

OpenLDAP 2.6 is holding connections open
by Bradley T Gill 02 Aug '22

02 Aug '22

All, I have been struggling with upgrading OpenLDAP from 2.4 to 2.5/2.6 for some time. We have finally found that we needed to rebuild the schema from scratch and re-add our customizations. The database is now running much better with one lingering problem. Our Established connections just continues to grow until we run out of resources. Below is our cn=config (minus some unrelated info). This is on the same server as where the previous version was running, so changes are openldap and openssl versions. Any insights as to what might be causing the ESTABLISHED connections to continually grow would be very appreciated. # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 422b88f4 dn: cn=config objectClass: olcGlobal cn: config olcAttributeOptions: lang- olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexHash64: FALSE olcIndexIntLen: 4 olcListenerThreads: 1 olcLocalSSF: 71 olcLogLevel: 256 olcLogFileOnly: FALSE olcMaxFilterDepth: 1000 olcReadOnly: FALSE olcSaslAuxpropsDontUseCopyIgnore: FALSE olcSaslSecProps: noplain,noanonymous olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcThreadQueues: 1 olcTLSCRLCheck: none olcTLSVerifyClient: never olcTLSProtocolMin: 0.0 olcToolThreads: 1 structuralObjectClass: olcGlobal creatorsName: cn=config createTimestamp: 20220726200129Z olcAuthzPolicy: any olcWriteTimeout: 30 olcSizeLimit: size.soft=unlimited size.hard=unlimited size.unchecked=unlimited size.pr=1000 size.prtotal=unlimited

3 5

SASL GSSAPI Channel Binding testing
by Andreas Hasenack 26 Jul '22

26 Jul '22

Hello, openldap 2.5.12 cyrus-sasl 2.1.28 + sasl channel binding patch[1] + gss-spnego maxssf=0 patch[2] openldap linked with gnutls libsasl2-modules-gssapi-mit I'm currently testing the patches[1][2] for sasl channel binding over GSSAPI + ssl/tls connection, and was wondering if I could get openldap to reject ldaps connections without sasl channel binding. Currently it seems to always accept it, but I can't be sure CB was even checked by the server by looking at logs (even with -d -1). I got windows 2016 AD to reject ldaps connections without CB over gssapi and gss-spnego, so the client part of openldap (ldapwhoami specifically) seems ok. I looked at test 077[3] and it runs the server with this configuration: dn: cn=config changetype: modify replace: olcSaslCBinding olcSaslCBinding: ${acb} Where `${acb}` loops over the 3 valid values of "none" "tls-unique" "tls-endpoint". Then a simple connection with ldapwhoami is attempted, also looping -o SASL_CBINDING=$icb over those values. I have seen the comment in that test script that it looks like tls-unique is broken when used with gnutls[4], and also a comment about MIT failing in another case[5]. When trying it manually, though, I could never get the client connection to be refused by the server. Before digging in deeper, let me just ask if my understanding is correct: - server configured with: dn: cn=config changetype: modify replace: olcSaslCBinding olcSaslCBinding: tls-endpoint - client connecting to that server over ldaps://, with GSSAPI, and with -o SASL_CBINDING=none Should that client be rejected? Sample run: $ sudo ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcSaslCBinding=*)' olcSaslCBinding SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=config olcSaslCBinding: tls-endpoint $ ldapwhoami -Y GSSAPI -H ldaps://k-slapd.lxd -o SASL_CBINDING=none SASL/GSSAPI authentication started SASL username: ubuntu@VMS SASL SSF: 256 SASL data security layer installed. dn:uid=ubuntu,cn=gssapi,cn=auth And the server logs (olcLogLevel: stats): Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 fd=14 ACCEPT from IP=10.0.100.36:33800 (IP=0.0.0.0:636) Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 fd=14 TLS established tls_ssf=256 ssf=256 tls_proto=TLS1.3 tls_cipher=AES-256-GCM Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=0 BIND dn="" method=163 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=0 RESULT tag=97 err=14 qtime=0.000011 etime=0.002447 text=SASL(0): successful result: Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=1 BIND dn="" method=163 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=1 RESULT tag=97 err=14 qtime=0.000012 etime=0.000069 text=SASL(0): successful result: Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 BIND dn="" method=163 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 BIND authcid="ubuntu" authzid="ubuntu" Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 BIND dn="uid=ubuntu,cn=gssapi,cn=auth" mech=GSSAPI bind_ssf=256 ssf=256 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 RESULT tag=97 err=0 qtime=0.000012 etime=0.000109 text= Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=3 EXT oid=1.3.6.1.4.1.4203.1.11.3 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=3 WHOAMI Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=3 RESULT oid= err=0 qtime=0.000016 etime=0.000087 text= Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=4 UNBIND Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 fd=14 closed 1. https://github.com/cyrusimap/cyrus-sasl/commit/975edbb69070eba6b035f08776de… 2. https://github.com/cyrusimap/cyrus-sasl/pull/603/commits 3. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/test… 4. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/test… 5. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/test…

2 3

help ldap_sasl_bind_s failed (-1)
by mohammad jamshidi 17 Jul '22

17 Jul '22

HiI have configured the openldap multimaster based on this guide: https://kifarunix.com/setup-openldap-master-master-replication-on-centos-8/ but the replication between two servers doesn't work. and I get these errors: on server1: slap_client_connect: URI=ldaps://ldapmaster02.kifarunix-demo.com DN="cn=admin,dc=ldapmaster,dc=kifarunix-demo,dc=com" ldap_sasl_bind_s failed (-1) on server 2:slap_client_connect: URI=ldaps://ldapmaster01.kifarunix-demo.com DN="cn=admin,dc=ldapmaster,dc=kifarunix-demo,dc=com" ldap_sasl_bind_s failed (-1). I didn't receive any reply from the article writer.what is wrong in the guide? Regards

1 0

Re: Pass-through
by Stéphane Veyret 14 Jul '22

14 Jul '22

> Ok, you may need to run slapd under debug mode (-1) and then try binding as > one of the users with userPassword set to the {SASL}username@realm value > to see what it's doing. Is this what I did in my first post (https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…, the log is at the end of the message) or is there some missing information ? By the way, I don’t know why GMail is starting a new thread each time I answer to you… :-/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2022