openldap-technical

openldap-technical@openldap.org

8 participants
9792 discussions

Re: [EXT] Re: openldap ppolicy pwdAccountLockedTime
by kevin martin 03 Jan '22

03 Jan '22

Hmm, module loaded. I'm not doing a moduleload of anything ppolicy related, simply setting the overlay ppolicy, the ppolicy_default, and ppolicy_use_lockout. What's the module to load as I don't find a ppolicy la file after compiling? Can you point me to a doc that explains the proper way to use this now? On Mon, Jan 3, 2022, 10:41 AM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Monday, January 3, 2022 9:39 AM -0600 kevin martin <ktmdms(a)gmail.com> > > wrote: > > > > > In 2.4 I was still pulling in the schema. In 2.5 ppolicy is compiled as > > part of the code. Assuming it just works, how does one go about setting > > pwdAccountLockedTime for a user then? I can't add it as an attribute of > > the user so I'm not sure how it can be set. > > If it has been moduleloaded into the slapd process, the ppolicy schema is > known to slapd and available for use. If you are finding the attribute to > not be defined it would suggest you've failed to load the module as > required. I would note that you want to ensure you're running 2.5.8 or > later (See ITS#9671). > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

3 8

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

Interpreting username@domainname
by Volodymyr Melnyk 03 Jan '22

03 Jan '22

Hello, Is that possible to tweak some settings that would make OpenLDAP always interpreting `uid=username@domainname` as `uid=username,ou=domainname` in authentication queries? Of course, making the clients to do its job would be preferred, but this would be less preferable option in my case. With thanks in advance, V.Melnyk

2 1

right order mmr-main-DB combined with mmr cn=config
by Stefan Kania 15 Dec '21

15 Dec '21

Hello, I'm still working on replication of cn=config. The replication of the main DB is working with delta-syncrepl but I still have problems getting mmr running for cn=config. As I use Ansible to configure it here my question: Is the order of setting up the replication relevant? What I do at the moment: Setting up a basic config for all 4 servers: ----------------------------------------- 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: 1 ldap://ldap01.example.net olcServerID: 2 ldap://ldap02.example.net olcServerID: 3 ldap://ldap03.example.net olcServerID: 4 ldap://ldap04.example.net # create cn=config #dn: olcBackend={0}mdb,cn=config #objectClass: olcBackendConfig #olcBackend: {0}mdb dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema 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 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 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: 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 ----------------------------------------- As you can see serverID is already set to URL-style for all servers ;-) But now I'm not sure, do I have to set up the replication for cn=config on all 4 servers and then set up replication of the main DB on just one of the servers and let it be replicated by the cn=config-replication? Or do I have to set up replication of the main DB on all servers first and then add the replication of cn=config to all servers and only replicate the changes made afterwards? Or do I have to set up the replication of main-DB and replication of cn=config on one server at a time? Or can I do it either way? The testsuit is showing using updateref on the replication of the main-DB do I really need it for mmr? If yes, do I need it for mmr of cn=config? I could not find any example that uses both, mmr for main-DB and mmr for cn=config. here is the order of my set up for cn=config 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 tls_reqcert=allow 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 tls_reqcert=allow 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 tls_reqcert=allow 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 tls_reqcert=allow - add: olcMultiprovider olcMultiprovider: TRUE ------------------------ And last but not least the set up of the main-DB replication: ----------------------- dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: rid=102 provider=ldap://ldap02.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes tls_reqcert=allow olcSyncrepl: rid=103 provider=ldap://ldap03.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes tls_reqcert=allow olcSyncrepl: rid=104 provider=ldap://ldap04.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes tls_reqcert=allow - add: olcMultiprovider olcMultiprovider: TRUE ----------------------- This is the ldif for the first server so olcSyncrepl for ldap01.example.net is not configured. On the other servers is the same the own URI has no olcSyncrepl entry. Here olcUpdatRef is not configured. Replication of the main-DB is running. BTW olcUpdateRef is also not configured in the howto of Quanah ;-) So it must be ok :-) Could you please take a look if I did something wrong. I don't know where to look anymore.

2 5

ldap_search_ext_s fails with "Operations error" when using root as base dn
by Alex Ditu 15 Dec '21

15 Dec '21

Hi, When I try to query the root of my AD with scope LDAP_SCOPE_SUBTREE ldap_search_ext_s() fails with "Operations error". It happens only when I set the ldap_search_options.base to the domain DN (eg. DC=example,DC=com). If I use a more specific base, such as CN=Computers,DC=example,DC=com the operation succeeds. Is there a limitation to the search function? pseudocode snippet: ``` ldap_search_options ldap_opts; ldap_opts.base = "DC=example,DC=com"; ldap_opts.scope = LDAP_SCOPE_SUBTREE; ```

2 1

Ldap sync has broken from time to time
by skeletor 15 Dec '21

15 Dec '21

Hi. We have a one master and 8 slaves. From time to time replication has broken and data has stopped to update on slaves. In logs i see next: syncrepl_null_callback : error code 0x50 syncrepl_entry: rid=000 be_modify cn=union,ou=roles,dc=staff,dc=com (80) syncrepl_entry: rid=000 be_modify failed (80) do_syncrepl: rid=000 rc 80 retrying do_syncrep1: rid=000 starting refresh (sending cookie=rid=000,csn=20211213150433.004754Z#000000#000#000000) do_syncrep2: rid=000 LDAP_RES_INTERMEDIATE - SYNC_ID_SET syncrepl_message_to_entry: rid=000 DN: cn=union,ou=roles,dc=staff,dc=com, UUID: 67c22522-0749-1039-933a-fdc6b5a9b3b7 syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 4 "error code 0x50" means other ldap error. How to determine, what exactly wrong? There is no dependence with slaves or versions: - master has 2.4.50 - slaves have different versions: 2.4.50, 2.4.55, 2.4.57. All of slaves can breake. We use next configuration: syncrepl rid=000 provider=ldaps://ldap-master.domain.com type=refreshAndPersist retry="5 5 300 +" searchbase="dc=staff,dc=com" attrs="*,+" bindmethod=simple binddn="cn=slapd-slave,ou=services,dc=staff,dc=com" We can't try newer version, because use Oracle solaris and there are only 2.4.X versions. Should we create a bug or it was fixed in newer versions?

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical