olcAccess don't working
by bourguijl＠gmail.com
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.
9 months
olcDbIDAssertBind
by bourguijl＠gmail.com
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.
9 months
Please help to check the right schema.
by luckydog xf
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.
9 months, 1 week
dynlist few question (memberof replacement, reverse searches)
by Michal Soltys
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.
9 months, 1 week
ch_malloc of 0 bytes failed on Meta backend
by sumanbadra＠gmail.com
Hi,
We have been using Meta backend with multiple AD domain controllers as targets. OpenLDAP version is 2.4.56 and installed on RHEL 8.6 Azure hosted servers. We have two such nodes with the same setup.
I have been trying to find the root cause for the error "ch_malloc of 0 bytes failed on Meta backend" found on the two servers. Service was crashed on both servers after this error. After starting the OpenLDAP service, it has been working fine so far.
My observations so far:
- Our Azure team did not find any abnormalities on the servers w.r.t the memory utilisation by LDAP during the incident.
- Stats around the time when issue occurred
sar -r
kbmemfree kbavail kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty
01:50:01 PM 25202860 29022816 7519888 22.98 13808 5385664 4736872 14.48 2349572 4157132 64
02:00:01 PM 25195656 29018052 7527092 23.00 13808 5388120 4767748 14.57 2349572 4163232 44
02:10:00 PM 25197340 29010572 7525408 23.00 13808 5386752 4783920 14.62 2352524 4158856 3336
02:20:01 PM 25201220 29016192 7521528 22.99 13808 5388296 4789868 14.64 2352516 4154632 52
02:30:01 PM 25196500 29013836 7526248 23.00 13808 5390708 4789412 14.64 2352516 4159140 36
02:40:01 PM 25181840 29002912 7540908 23.04 13808 5402364 4782228 14.61 2352528 4173032 144
02:50:01 PM 25170748 28994608 7552000 23.08 13808 5413236 4758840 14.54 2352516 4185172 1092
03:00:01 PM 25172224 28997852 7550524 23.07 13808 5414920 4729152 14.45 2352520 4182356 48
03:10:01 PM 24976028 28806984 7746720 23.67 13808 5428036 5007976 15.30 2353012 4375608 4940
- We did not set any cache specifically as meta does not store any data
- Error shows 0 bytes rather than any specific number
I would really appreciate if you can share any pointer which would help dig further.
Thank you,
Suman
9 months, 1 week
