openldap-technical

openldap-technical@openldap.org

4 participants
9898 discussions

Re: Backup Mirrormode setup
by Meike Stone 08 Mar '23

08 Mar '23

Am Mi., 16. März 2022 um 21:39 Uhr schrieb Quanah Gibson-Mount <quanah(a)fast-mail.org>: > > > > --On Wednesday, March 16, 2022 10:23 PM +0100 Meike Stone > <meike.stone(a)googlemail.com> wrote: > > > > > We are still using the bdb backend and the latest 2.4.59 (don't ask, > > it will be replaced soon) and I remember, a "few" years ago, I had > > problems with slapcat and online databases, because the server was > > stucking for a while and answers were delayed .. > > (The Admin Guide tells, that "Backups are managed slightly differently" > > ...) Secondly, while offline, I can copy the whole database directory > > including the transaction logs .. > > Ah, ok. Yes, you could set up a read-only consumer node to take backups > from. I'd highly prioritize moving to a supported release of OpenLDAP with > the back-mdb backend as well (I see you say it should be replaced soon). :) > Oh my god, almost a year has passed - now finally our department wants to migrate to the latest version 2.5.14. I'm responsible for the Master LDAP-Server, but there are a few ro-replicas in other departments where I'm not responsible - and I have no access. Is it possible to migrate the master server to the new version and update the replicas (running 2.4.59) later, independent from the master (migration)? Are there any problems to be expected? Regards and many thanks Meike

2 1

dynlist's +memberOf attribute not searchable/fetchable with anonymous binds
by Michal Soltys 08 Mar '23

08 Mar '23

Hi, Consider following simple dynlist config (v2.5.13): groupOfURLs labeledURI uniqueMember+memberOf@groupOfUniqueNames So for static groups we get a dynamic memberOf for each user that is a member of some static group, for example: DN: cn=TouK,ou=TouK,ou=Group,dc=touk,dc=pl ... uniqueMember: cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl DN: cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl ... memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl Now this works fine if we bind with a user and do a search. But if we do an anonymous search no memberOf is returned or searchable by. For example: assume following ACLs at the top: {0}to * by dn=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break {1}to dn.subtree=ou=People,dc=touk,dc=pl attrs=entry,entryUUID,memberOf,@toukAnonAccess by anonymous =scr by * break {2}to dn.subtree=ou=Group,dc=touk,dc=pl attrs=entry,@groupOfUniqueNames,@groupOfNames by anonymous =scr by * break ... and the following search: ldapsearch -x -H ldaps://ldap.touk.pl -s sub -b 'ou=Touki,ou=People,dc=touk,dc=pl' -o ldif-wrap=no -LLL -v memberOf entryUUID we get the following results: ldap_initialize( ldaps://ldap.touk.pl:636/??base ) filter: (objectclass=*) requesting: memberOf entryUUID dn: ou=Touki,ou=People,dc=touk,dc=pl entryUUID: 6be7e4f8-a800-103a-9fd7-3100241d53c2 dn: cn=Jan Gajl,ou=Touki,ou=People,dc=touk,dc=pl entryUUID: 6c39df1a-a800-103a-8089-3100241d53c2 Why is memberOf omitted with anonymous binds when search explicitly (or implicitly via +) requests it and acls grant required rights ? With explicit binds or EXTERNAL - memberOf is returned (and searchable) correctly. Is there something else that is required for memberOf to work with anonymous binds ?

1 1

Re: Adding to the schema
by Eric Fetzer 07 Mar '23

07 Mar '23

So by configuration loading module, do you mean the slapd.ldif file? If so, since I already loaded it, can I modify and reload it or would that not work? If that's the case, can I load just a subset of it? Thanks, Eric On Tue, Mar 7, 2023 at 12:21 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Tuesday, March 7, 2023 12:16 PM -0700 Eric Fetzer > <eric.fetzer(a)gmail.com> wrote: > > > > > I'm using 2.6.4. Sorry, brand new at this, how do I enable it? I > > don't see any references to it in the slapd.conf... I'm in the process > > of converting an ISDS db to OpenLDAP. Kind of daunting so far... > > > Generally speaking: > > In the portion of your configuration loading module: > > modulepath .... > moduleload ppolicy.so > > > In the database section of your configuration where you want to apply > password policies > > > database mdb > ... > > overlay ppolicy > > > Regards, > Quanah > > >

1 0

Re: Adding to the schema
by Eric Fetzer 07 Mar '23

07 Mar '23

I'm using 2.6.4. Sorry, brand new at this, how do I enable it? I don't see any references to it in the slapd.conf... I'm in the process of converting an ISDS db to OpenLDAP. Kind of daunting so far... Thanks, Eric On Tue, Mar 7, 2023 at 12:10 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, March 6, 2023 11:23 AM -0700 Eric Fetzer > <eric.fetzer(a)gmail.com> wrote: > > > > > Hi All, > > > > > > I need to add to my schema on my freshly built server. > > If you're using OpenLDAP 2.5 or later, the ppolicy schema is built into > the > ppolicy overlay and you should not be loading it separately at all. I > would note that all releases prior to OpenLDAP 2.5 are historic and not > supported. > > Regards, > Quanah > > > >

2 1

Adding to the schema
by Eric Fetzer 07 Mar '23

07 Mar '23

Hi All, I need to add to my schema on my freshly built server. I found a schema that meets my needs @ https://opensource.apple.com/source/OpenLDAP/OpenLDAP-143/OpenLDAP/servers/…. My problem is that it doesn't seem to include a "ppolicy.ldif" file. The only way I know how to add to the schema is with an include statement in slapd.ldif. What am I missing? Thanks, Eric

2 2

issues with disabling filtered searches for memberURL groups
by Kartik Subbarao 07 Mar '23

07 Mar '23

One of the changes from 2.4 to 2.5 is that dynlist groups are now returned with (member=memberDN) searches. This is potentially appealing, but even with the ITS#9929 performance improvements, given the number of dynlist groups we have, search times are significantly impacted. We'd like to be able to cleanly disable this feature and exclude dynlist groups from (member=memberDN) filter consideration. The only way I've found so far is to patch the dynlist code itself. What I'm currently doing is adding a continue statement right above this line in dynlist_search(): https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5_14/s… That way the member searches are excluded, but dynlists otherwise work as expected. Here is the dynlist config we're using, just basic support for groupOfURLs/memberURL: overlay dynlist dynlist-attrset groupOfURLs memberURL member Is there some way to achieve my goal without having to patch the code? Or should I open an ITS feature request to add a configurable option to exclude dynlists from member searches? Thanks, -Kartik

1 0

olcAccess don't working
by bourguijl＠gmail.com 07 Mar '23

07 Mar '23

Dears, I've configured a META ldap instance pointing to a LDAP backend. In this backend, there are a few ACLs but which ones don't restrict ldapsearch that I do from the META frontend. I just have an issue when I set some ACLs on the META frontend and more specially when I insert attrs=xxx in the ACL. Here is my ACL = OK olcAccess : {0}to dn.one="ou=staff,o=mobistar.be" by dn="uid=a0621004,ou=ObeExternalITOnGcp,ou=partners,o=mobistar.be" read NOT OK olcAccess : {0}to dn.one="ou=staff,o=mobistar.be" attrs=uid by dn="uid=a0621004,ou=ObeExternalITOnGcp,ou=partners,o=mobistar.be" read Can you explain why when I restrict to an attribute, my ldapsearch didn't provide me any response as expected ? Thx in advance, J-L.

2 1

olcDbIDAssertBind
by bourguijl＠gmail.com 06 Mar '23

06 Mar '23

Dears, I've used olcDbIDAssertBind in a META ldap config to use another login/password to search in backend but it's not taken into account, that's still the client user that's used to fetch data in the backend. Is it he correct parameter to use in order to "supersede" the client user by another one (generic) known by the backend ? Thx for help. Brgds, Jean-Luc.

1 0

Please help to check the right schema.
by luckydog xf 03 Mar '23

03 Mar '23

Hi, list, I'm trying to migrate opendj to openLDAP. Here is a customized schema. === dn: cn=schema objectclass: top objectclass: ldapSubentry objectclass: subschema cn: schema attributeTypes: ( 1.12.23.34.45.56.780 NAME 'active' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 X-SCHEMA-FILE '99-user.ldif' ) attributeTypes: ( 1.12.23.34.45.56.782 NAME 'accountName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-SCHEMA-FILE '99-user.ldif' ) attributeTypes: ( 1.12.23.34.45.56.784 NAME 'djGroups' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-SCHEMA-FILE '99-user.ldif' ) attributeTypes: ( 1.12.23.34.45.56.786 NAME 'departmentId' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-SCHEMA-FILE '99-user.ldif' ) attributeTypes: ( 1.12.23.34.45.56.788 NAME 'department' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-SCHEMA-FILE '99-user.ldif' ) attributeTypes: ( 1.12.23.34.45.56.790 NAME 'companyCode' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-SCHEMA-FILE '99-user.ldif' ) attributeTypes: ( 1.12.23.34.45.56.792 NAME 'parent' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-SCHEMA-FILE '99-user.ldif' ) ds-sync-generation-id: 8408 ds-sync-state: 01050186432c61a90000f9ca10880 ds-sync-state: 0105017a002b3170002f4a1b16311 modifiersName: cn=Administrator modifyTimestamp: 20190711063414Z objectClasses: ( 1.12.23.34.45.56.880 NAME 'idmExt' DESC 'idm user extended attributes' SUP top AUXILIARY MUST active MAY ( accountName $ djGroups $ departmentId $ department $ companyCode ) X-SCHEMA-FILE '99-user.ldif' ) objectClasses: ( 1.12.23.34.45.56.890 NAME 'idmDept' DESC 'idm department extended attributes' SUP top AUXILIARY MAY parent X-SCHEMA-FILE '99-user.ldif' ) === I changed it to LDAP compliant one. --- dn: cn=djuser,cn=schema,cn=config objectClass: olcSchemaConfig cn: djuser olcAttributeTypes: ( 1.12.23.34.45.56.780 NAME 'active' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) olcAttributeTypes: ( 1.12.23.34.45.56.782 NAME 'accountName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: ( 1.12.23.34.45.56.784 NAME 'djGroups' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: ( 1.12.23.34.45.56.786 NAME 'departmentId' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: ( 1.12.23.34.45.56.788 NAME 'department' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: ( 1.12.23.34.45.56.790 NAME 'companyCode' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: ( 1.12.23.34.45.56.792 NAME 'parent' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcObjectClasses: ( 1.12.23.34.45.56.880 NAME 'idmExt' DESC 'idm user extended attributes' SUP top AUXILIARY MUST active MAY ( accountName $ djGroups $ departmentId $ department $ companyCode ) ) olcObjectClasses: ( 1.12.23.34.45.56.890 NAME 'idmDept' DESC 'idm department extended attributes' SUP top AUXILIARY MAY parent ) ----- It can be imported by `ldapadd -Y EXTERNAL -H ldapi:/// -f 99-user.ldif` However, there is nothing in === [root@hq-repo cn=config]# more cn\=schema/cn\=\{10\}djuser.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 310b21fa dn: cn={10}djuser objectClass: olcSchemaConfig cn: {10}djuser structuralObjectClass: olcSchemaConfig entryUUID: 6b852150-4b97-103d-86fe-7b79b4eef873 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20230228093837Z entryCSN: 20230228093837.038174Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20230228093837Z === I'm using openldap 2.4. Anything wrong with my schema ? Thanks.

2 3

dynlist few question (memberof replacement, reverse searches)
by Michal Soltys 02 Mar '23

02 Mar '23

Hi, Few questions regarding dynlist as a replacement of memberof overlay. Version: 2.5.13+dfsg-2~bpo11+1 on debian bullseye 1) in relatively simple environment (2 servers, multiprovider, syncrepl and keepalived) we've been using memberof overlay - with memberOf explicitly filtered out in syncrepl configuration (exattrs=memberOf). This has been working fine so far across many versions - but considering the warning in slapo-memberof manpage is this overlay used in this fashion safe or are there other issues that eventually might show up ? 2) I've been experimenting a bit with dynlist as a replacement; judging from examples/manual it seems it was primarily created to populate a dynamic group while doing the search over users under a constraint of a filter; but it seems it's working just fine in reverse way as well, e.g. consider: dynlist config: olcDynListAttrSet = toukPerson labeledURI dgMemberOf group with manually added members: cn=ADM,ou=TouK,ou=Group,dc=touk,dc=pl a user: uniqueMember=cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl and relevant attributes in user's entry: objectClass = toukPerson labeledURI = ldap:///ou=TouK,ou=Group,dc=touk,dc=pl??sub?(uniqueMember=cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl) This seems to be doing what we are expecting - populating dynamically dgMemberOf with the groups the user has membership in. While this is working, is it ok to use this overlay in this fashion (search over groups instead of over users) ? 3) my last question is more of a curiosity - what case scenario are for additional [+<memberOf-ad>[@<static-oc>[*]]] attributes ? No matter what I tried in what way, neither +memberOf-ad nor +static-oc had any effect whatsoever.

1 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