openldap-technical December 2021

openldap-technical@openldap.org

21 participants
32 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

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

mmr of cn=config with OpenLDAP 2.6
by Stefan Kania 10 Jan '22

10 Jan '22

Hi to all, is it now save to use mmr of cn=config with OpenLDAP 2.6? I got it running with 4 server. I'm installing all 4 server with Ansible so I created a basic configuration: ------------------ dn: cn=config objectClass: olcGlobal cn: config olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/symas/run/slapd.pid olcArgsFile: /var/symas/run/slapd.args olcToolThreads: 1 olcServerID: 4 dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema # Read all needed schema from variable in default/main.yml include: file:///opt/symas/etc/openldap/schema/core.ldif include: file:///opt/symas/etc/openldap/schema/cosine.ldif include: file:///opt/symas/etc/openldap/schema/nis.ldif include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif include: file:///opt/symas/etc/openldap/schema/dyngroup.ldif include: file:///opt/symas/etc/openldap/schema/kerberos.openldap.ldif # Read all modules from variable in default/main.yml dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /opt/symas/lib/openldap olcModuleLoad: back_mdb olcModuleLoad: back_monitor olcModuleLoad: autoca.la olcModuleLoad: otp.la olcModuleLoad: argon2.la olcModuleLoad: syncprov olcModuleLoad: back_monitor olcModuleLoad: accesslog.la dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcSizeLimit: 500 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcPasswordHash: {ARGON2} dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by * break dn: olcDatabase={1}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to dn.subtree="cn=monitor" by dn.exact=cn=admin,cn=config read by dn.exact=cn=admin,dc=example,dc=net read dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcmdbConfig olcDatabase: {2}mdb olcSuffix: dc=example,dc=net olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcSizeLimit: unlimited olcTimeLimit: unlimited olcDbCheckpoint: 512 30 olcDbDirectory: /var/symas/openldap-data olcDbIndex: default eq olcDbIndex: objectClass olcDbIndex: entryUUID olcDbIndex: entryCSN olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: description pres,eq,sub olcDbIndex: title pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbMaxSize: 85899345920 olcAccess: {0} to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcAccess: {3} to attrs=userPassword by anonymous auth by self write by * none olcLimits: {0} dn.exact="uid=repl-user,ou=users,dc=example,dc=net" time=unlimited size=unlimited olcLimits: {1} dn.exact="uid=ldap-admin,ou=users,dc=example,dc=net" time=unlimited size=unlimited ------------------ The "ServerID" is different for every server, every thing else is identical. Then I created a file to change the serverID: ------------------ dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://ldap01.example.net olcServerID: 2 ldap://ldap02.example.net olcServerID: 3 ldap://ldap03.example.net olcServerID: 4 ldap://ldap04.example.net ------------------ and a file to configure the replication: ------------------ dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=1 provider=ldap://ldap01.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes olcSyncRepl: rid=2 provider=ldap://ldap02.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes olcSyncRepl: rid=3 provider=ldap://ldap03.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes olcSyncRepl: rid=4 provider=ldap://ldap04.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes - add: olcMirrorMode olcMirrorMode: TRUE ------------------ When I configure the server via Ansible (everything in one playbook) the replication of cn=config is not working. When I only do the basic configuration via Ansible and then add the change of serverID and then the replication of cn=config step by step on every single server: ------------- ldapmodify -Y EXTERNAL -H ldapi:/// -f serverid.ldif ldapmodify -Y EXTERNAL -H ldapi:/// -f repl_config.ldif ------------- everything is fine. The two files "serverid.ldif" and "repl_config.ldif" are the files Ansible created, so the content of the file is the same. Can it be, that the problem is because Ansible first sets all the ServerIDs on all servers and then configure the replication of cn=config on all servers? For setting up the configuration I took: https://www.openldap.org/devel/admin/replication.html Starting at 18.3.3 What I don't understand: Do I realy have to put all Servers in the replication, even the server it self? So do I realy have to add on Server-01, the Server "server-01, server-02, server-03 ,server-04" to the replication? Dosn't it mean that server-01 is replicating to it self? If it's correct, can someone explain why? O did I understud something wrong on the webpage? Stefan

3 12

OpenLDAP's UB minefield
by openldap-technical＠kolttonen.fi 06 Jan '22

06 Jan '22

Someone recently wrote on openldap-bugs: > The kernel recently got bitten using the same pattern of unaligned > short pointers through casts. GCC produced code which corrupted > initramfs during unpacking. > > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100363. > OpenLDAP should fix that code. Correct. That's what I said long time ago, too. I wonder if OpenLDAP projects' delusions about Undefined Behaviour "not being a bug" still persist, or are they perhaps going to fix their buggy code? What a minefield to walk on, it can blow up anytime. I am very happy to not have to administer this server code anymore, but I sure am scared for those who do. best regards, Unto Sten

2 1

Guide to setup syncrepl with proxy-based push config
by David White 05 Jan '22

05 Jan '22

Hello, I have some basic experience interacting with & troubleshooting OpenLDAP as well as 389-ds, but I don't have a whole lot of experience setting them up or configuring an OpenLDAP server. My goal is to setup replication from a Primary inside a trusted network outwards to a Replica that is in an untrusted network, without allowing the replica any direct access to the primary, due to firewall flows and network requirements. This is true even for the initial connection, so a simple RefreshAndPersist configuration won't work. I have read that it is possible to setup a push-based replication using a proxy, such that: - The proxy gets installed as a "hidden" database onto the same server as the primary - The proxy sets up replication with the primary using RefreshAndPersist - The proxy is then able to push the data out of the replica I have skimmed over, and re-read, a lot of portions from this document: https://www.openldap.org/doc/admin24/replication.html I have also followed this basic guide to setup a Primary with replication capability: https://ubuntu.com/server/docs/service-ldap-replication What I'm having trouble with, is finding a useful guide that will walk me through the process to setup and configure the proxy as I've described above. Questions: - Based on my requirements above, will the proxy with syncrepl meet my needs? - If I put the proxy onto the same server as the primary, then due to firewall flows, the replica will not have any access to the primary. All communication will need to be initiated outbound - If I put the proxy into the same network as the replica, well.... that won't work either, for the same reason - The following URL from the OpenLDAP docs provides some example configs: https://www.openldap.org/doc/admin24/replication.html#Syncrepl%20Proxy - If I'm reading everything correctly, though, the "new" / "accepted" / "preferred" way to configure the ldap server is to use the `ldapadd`, `ldapmodify`, and related commands. My confusion and question here is.... should I try to configure all of this by editing the old slapd.conf file as the openldap.org docs provide examples, or is there a way to do this using the ldapmodify & related commands? - If I can / should do this from the command line... are there any guides or tutorials that will take me step-by-step through the process as I try to build this in a lab environment? Thanks in advance, David Sent with ProtonMail Secure Email.

4 15

dynamic groups seach for memberUID openldap 2.6
by Stefan Kania 03 Jan '22

03 Jan '22

Hi to all, two years ago I tried to use dynamic groups as Posix-groups see post: https://www.openldap.net/lists/openldap-technical/201911/msg00028.html Now I tried it again with OpenLDAP 2.6 and the attribute memberUID is still not showing up. Is it still not possible to search for memberUid? @Quanah You wrote: There's work to change this behavior (See ITS#9121) for OpenLDAP 2.5. Is the work on it still in progress? Stefan

3 6

A very simple olcAccess rule doesn't work
by Volodymyr Melnyk 03 Jan '22

03 Jan '22

Dear colleagues, There's a question I posted on ServerFault (https://serverfault.com/questions/1088252/a-very-simple-olcaccess-rule-does…), but it seems that asking my question in this mailing list would be a better idea/ So, long story short, I have a domain (let's call it `dc=example,dc=org`) . The domain has a branch (`ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org`). There's a simpleSecurityObject in this domain (`uid=admin,ou=managers,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org`). I need the uid=admin,*** user to have full (manage) access to the ou=users,*** branch, so I added the following olcAccess record: `to dn.subtree="ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org" by dn.exact="uid=admin,ou=managers,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org"`. It has added to the default set of rules: ``` dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break olcAccess: {1}to attrs=userPassword,shadowLastChange by self write by dn="cn=a dmin,dc=example,dc=org" write by anonymous auth by * none olcAccess: {2}to * by self read by dn="cn=admin,dc=example,dc=org" write by * none olcAccess: {3}to dn.subtree="ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc= infra,dc=example,dc=org" by dn.exact="uid=admin,ou=managers,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org" manage ``` But something seems to be wrong. When I run `ldapsearch -D uid=admin,ou=managers,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org -W -b ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org`, I get the following result: ``` # extended LDIF # # LDAPv3 # base <ou=users,ou=ftp,ou=services,dc=k9999,dc=z9999,dc=infra,dc=example,dc=org> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1 command terminated with exit code 32 ``` The object is actually available and `cn=admin,dc=example,dc=org` can see it without any difficulties, so it seems that my access rule is wrong. But what exactly it is? It seems that the default rule #2 (`{2} to * by self read by dn="cn=admin,dc=example,dc=org" write by * none`) fires up earlier than the rule I added. Does that mean that I should always add my custom rules before it? And why does this rule has `by * none`? Doesn't it contradict the OpenLDAP documentation? "The default access control policy is allow read by all clients" (https://www.openldap.org/doc/admin24/access-control.html). Thank you in advance. With best regards, V.Melnyk

2 2

openldap ppolicy pwdAccountLockedTime
by kevin martin 03 Jan '22

03 Jan '22

it appears from looking at ppolicy.c that pwdAccountLockedTime is not supported in openlda. is there another way to lock a users account in openldap outside of simply changing the users password? --- Regards, Kevin Martin

5 9

symas openldap-packages and kerberos
by Stefan Kania 03 Jan '22

03 Jan '22

Hello to all, I'm trying to get GSSAPI authentication running with the symas-packages. I generated a ldap.keytab file and it's readable for the ldap-user running the slapd. With the Debian-packages I ad: --------- export KRB5_KTNAME="/path/to/ldap.keytab" --------- I don't want to use the system keytab /etc/krb5.keytab. How do I tell slapd from the symas-packages to use my service-keytab? I try to add to my /etc/default/symas-openldap: --------- KRB5_KTNAME="/path/to/ldap.keytab --------- but it's not working. Stefan

6 19

remove overlay from cn=config 2.6
by Stefan Kania 03 Jan '22

03 Jan '22

hi to all, with 2.4.x the only way to remove an overlay from cn=config was exort cn=config edit the export and reimport it. I found a thread where it said: --------- This will probably be supported in OpenLDAP 2.5. --------- So is it possible somehow or do I still have to go the way with slapcat and slapadd? If it's possible where can I read how? Stefan

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2021