As I think the message had been blocked (I'm still receiving messages, but seem to be unable to send due to address mis-matching), I'm re-sending it. Please ignore if it had been delivered.
From: Windl, Ulrich Sent: Thursday, June 20, 2024 9:53 AM To: openldap-technical openldap-technical@openldap.org Subject: Accessing ppolicy attributes as non-admin in 2.4
Hi!
Yes, we are still running an old 2.4 OpenLDAP (mostly because it still has "hdb"), but anyhow:
There's a request to search for accounts where the password will expire soon according to configured ppolicies. I wrote the code, realizing that a normal user cannot read other users policy attributes, while the admin user can. As the process should run automatically, I don't want to add admin credentials for that kind of reporting. Instead I added a new user role and tried to add access to the attributes, but somehow it does not work. I think I did not make an error, but ACL configuration can be tricky.
So the question is: Can it be done in 2.4, and if so, what might be wrong in this config (lines unfolded, sorry): olcAccess: {0}to * by dn.exact="uid=syncrepl,ou=system,dc=..." read by group/organizationalRole/roleOccupant.exact="cn=LDAP-Manager,dc=roles,dc=..." write by * break olcAccess: {1}to dn.children="dc=roles,dc=..." attrs=roleOccupant by * none olcAccess: {2}to attrs=pwdAccountLockedTime,pwdAllowUserChange,pwdChangedTime,pwdCheckQuality,pwdExpireWarning,pwdFailureCountInterval,pwdGraceAuthNLimit,pwdGraceUseTime,pwdHistory,pwdInHistory,pwdLockoutDuration,pwdMaxFailure,pwdMaxRecordedFailure,pwdMinAge,pwdMinLength,pwdMustChange,pwdPolicySubentry,pwdRe\ set,pwdSafeModify,shadowExpire,shadowInactive,shadowLastChange,shadowMax,shadowMin,shadowWarning by dn.exact="uid=PP-Checker,ou=system,dc=..." read break olcAccess: {3}to attrs=userPassword,userPKCS12 by self write by * auth olcAccess: {4}to attrs=shadowLastChange by self write by * read olcAccess: {5}to attrs=pwdHistory,pwdGraceUseTime,pwdChangedTime by self read by * none olcAccess: {6}to * by * read
The account in question is ="uid=PP-Checker,ou=system,dc=..." obviously, and the "cn=LDAP-Manager,dc=roles,dc=..." can access the attributes.
The account is like this:
dn: uid=PP-Checker,ou=system,dc=... objectClass: top objectClass: account objectClass: simpleSecurityObject structuralObjectClass: account uid: PP-Checker
The Admin object looks like this:
dn: cn=LDAP-Manager,dc=roles,dc=... objectClass: organizationalRole cn: LDAP-Manager description: Administrative Access to LDAP Directory roleOccupant: uid=me-for-example,ou=people,dc=... roleOccupant: uid=another,ou=people,dc=... structuralObjectClass: organizationalRole
Any help on this is highly appreciated. If you think something else is wrong, also tell me please.
Alternatively you could give an answer on https://superuser.com/q/1844359/964771
Kind regards, Ulrich
--On Thursday, June 20, 2024 11:50 AM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
Yes, we are still running an old 2.4 OpenLDAP (mostly because it still has "hdb"), but anyhow:
Why would one want to use an inferior, unreliable database subject to random corruption?
Instead I added a new user role and tried to add access to the attributes, but somehow it does not work.
Which attribute(s) does it need to read?
olcAccess: {2}to attrs=pwdAccountLockedTime,pwdAllowUserChange,pwdChangedTime,pwdCheckQual ity,pwdExpireWarning,pwdFailureCountInterval,pwdGraceAuthNLimit,pwdGraceU seTime,pwdHistory,pwdInHistory,pwdLockoutDuration,pwdMaxFailure,pwdMaxRec ordedFailure,pwdMinAge,pwdMinLength,pwdMustChange,pwdPolicySubentry,pwdRe \
set,pwdSafeModify,shadowExpire,shadowInactive,shadowLastChange,shadowMax, shadowMin,shadowWarning by dn.exact="uid=PP-Checker,ou=system,dc=…" read break
So you give your user read access to those attributes, except..
olcAccess: {5}to attrs=pwdHistory,pwdGraceUseTime,pwdChangedTime by self read by * none
You remove its ability to read these 3 attributes here (due to your use of "read break" in {2}.
I assume it needs read access to pwdChangedTime.
Maybe you meant in {2}:
attrs... by (your user) read by * read break? Or something along those lines, mabye you meant by (your user) read by * break. Hard to tell.
--Quanah
Hi
Sorry, I have to use Outlook that seems unable to support quoting a message for replying, so I top-post:
Why hdb? So far it worked fine for us, and mdb seems to need much more space in RAM and on disk.
" Which attribute(s) does it need to read?" Everything needed to examine the status of the account (change of password, policy, policiy's settings)
So my ACLs are not correct it seems.
What I don't understand is this: The manual says about break: "... while the break form allows for other <access> clauses that match the same target to be processed.", so I thought using break WILL allow the following clauses to be processed, while you seem to tell the opposite.
As I understand my ACLs is this: #0 allows read for replication #1: prevents the admin users to be read from roleOccupant #2: allows reading pp attributes for the checker account, and using "break" should mean to continue checking other rules #3 should allow users to change the password and certificate, as well as authenticate (not quite sure about that) #4 should allow the user to set shadowLastChange (unsure whether it's needed) while allowing others to read that (unsure whether it's a good idea, though) #5 should allow to read some password attributes by self (assuming it's needed to allow the OS to warn about expiry) #6 allows to read the rest
I'm not sure which attributes should be allowed for reading and writing to the specific user (self) to allow the OS to interact with password policy (and shadow attributes) correctly, meaning to display a warning that the password is about to expire, that grace logins are being used, that the account is (temporarily) locked, etc.
Pointers to any docs are appreciated.
Regards, Ulrich
-----Original Message----- From: Quanah Gibson-Mount quanah@fast-mail.org Sent: Thursday, June 20, 2024 8:55 PM To: Windl, Ulrich u.windl@ukr.de; openldap-technical openldap-technical@openldap.org Subject: [EXT] Re: FW: Accessing ppolicy attributes as non-admin in 2.4
--On Thursday, June 20, 2024 11:50 AM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
Yes, we are still running an old 2.4 OpenLDAP (mostly because it still has "hdb"), but anyhow:
Why would one want to use an inferior, unreliable database subject to random corruption?
Instead I added a new user role and tried to add access to the attributes, but somehow it does not work.
Which attribute(s) does it need to read?
olcAccess: {2}to attrs=pwdAccountLockedTime,pwdAllowUserChange,pwdChangedTime,pwdCheckQual ity,pwdExpireWarning,pwdFailureCountInterval,pwdGraceAuthNLimit,pwdGraceU seTime,pwdHistory,pwdInHistory,pwdLockoutDuration,pwdMaxFailure,pwdMaxRec ordedFailure,pwdMinAge,pwdMinLength,pwdMustChange,pwdPolicySubentry,pwdRe \
set,pwdSafeModify,shadowExpire,shadowInactive,shadowLastChange,shadowMax, shadowMin,shadowWarning by dn.exact="uid=PP-Checker,ou=system,dc=…" read break
So you give your user read access to those attributes, except..
olcAccess: {5}to attrs=pwdHistory,pwdGraceUseTime,pwdChangedTime by self read by * none
You remove its ability to read these 3 attributes here (due to your use of "read break" in {2}.
I assume it needs read access to pwdChangedTime.
Maybe you meant in {2}:
attrs... by (your user) read by * read break? Or something along those lines, mabye you meant by (your user) read by * break. Hard to tell.
--Quanah
--On Friday, June 21, 2024 9:24 AM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
Hi
Sorry, I have to use Outlook that seems unable to support quoting a message for replying, so I top-post:
Why hdb? So far it worked fine for us, and mdb seems to need much more space in RAM and on disk.
This is factually incorrect. MDB requires fewer resources to operate, including RAM and disk space.
https://mishikal.wordpress.com/category/openldap-benchmarking/
I would also note that:
a) You're using ppolicy, which has been substantially reworked and improved in later releases. b) OpenLDAP 2.4 only supports unsupported versions of OpenSSL that now have open CVEs against them (although if you're linked to the OS openssl, at least for now, they probably are paying for extended support). This will eventually run out however.
" Which attribute(s) does it need to read?" Everything needed to examine the status of the account (change of password, policy, policiy's settings)
So my ACLs are not correct it seems.
What I don't understand is this: The manual says about break: "... while the break form allows for other <access> clauses that match the same target to be processed.", so I thought using break WILL allow the following clauses to be processed, while you seem to tell the opposite.
As I understand my ACLs is this: # 0 allows read for replication # 1: prevents the admin users to be read from roleOccupant # 2: allows reading pp attributes for the checker account, and using # "break" should mean to continue checking other rules 3 should allow # users to change the password and certificate, as well as authenticate
You put break on *pp*'s access, meaning that the access rule for PP is modified by the following rules. If you want PP's access to be *unchanged* by the following rules, you need to remove "break" for *it*. And then add a rule that breaks it (continues processing) for all other identities.
These are terrible examples, but hopefully they help with understanding the difference:
Example 1:
access to attr=blah by joe read break access to attr=blah by * none
-> Joe has no access "blah" because his access line has a "break" clauses, so it is affected by the following ACL.
Example 2:
access to attr=blah by joe read by * break access to attr=blah by * none
-> Joe has full read acess to blah, all other identities will have no access.
--Quanah
Hi!
It seems I did not understand the "by * break" compared to plain "break" from the manual page: I thought the control "binds to" "<what>", while it seems it "binds to" "<who>". So I thought "by * break" means "by * none break", and as "by * none" seems to be the default, I left out the "by *". Maybe the manual page could be a bit more clearer on that.
Kind regards, Ulrich
-----Original Message----- From: Quanah Gibson-Mount quanah@fast-mail.org Sent: Friday, June 21, 2024 6:11 PM To: Windl, Ulrich u.windl@ukr.de; openldap-technical <openldap- technical@openldap.org> Subject: [EXT] RE: Re: FW: Accessing ppolicy attributes as non-admin in 2.4
--On Friday, June 21, 2024 9:24 AM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
Hi
Sorry, I have to use Outlook that seems unable to support quoting a message for replying, so I top-post:
Why hdb? So far it worked fine for us, and mdb seems to need much more space in RAM and on disk.
This is factually incorrect. MDB requires fewer resources to operate, including RAM and disk space.
https://mishikal.wordpress.com/category/openldap-benchmarking/
I would also note that:
a) You're using ppolicy, which has been substantially reworked and improved in later releases. b) OpenLDAP 2.4 only supports unsupported versions of OpenSSL that now have open CVEs against them (although if you're linked to the OS openssl, at least for now, they probably are paying for extended support). This will eventually run out however.
" Which attribute(s) does it need to read?" Everything needed to examine the status of the account (change of password, policy, policiy's settings)
So my ACLs are not correct it seems.
What I don't understand is this: The manual says about break: "... while the break form allows for other <access> clauses that match the same target to be processed.", so I thought using break WILL allow the following clauses to be processed, while you seem to tell the opposite.
As I understand my ACLs is this: # 0 allows read for replication # 1: prevents the admin users to be read from roleOccupant # 2: allows reading pp attributes for the checker account, and using # "break" should mean to continue checking other rules 3 should allow # users to change the password and certificate, as well as authenticate
You put break on *pp*'s access, meaning that the access rule for PP is modified by the following rules. If you want PP's access to be *unchanged* by the following rules, you need to remove "break" for *it*. And then add a rule that breaks it (continues processing) for all other identities.
These are terrible examples, but hopefully they help with understanding the difference:
Example 1:
access to attr=blah by joe read break access to attr=blah by * none
-> Joe has no access "blah" because his access line has a "break" clauses, so it is affected by the following ACL.
Example 2:
access to attr=blah by joe read by * break access to attr=blah by * none
-> Joe has full read acess to blah, all other identities will have no access.
--Quanah
-----Original Message----- From: Quanah Gibson-Mount quanah@fast-mail.org Sent: Friday, June 21, 2024 6:11 PM To: Windl, Ulrich u.windl@ukr.de; openldap-technical <openldap- technical@openldap.org> Subject: [EXT] RE: Re: FW: Accessing ppolicy attributes as non-admin in 2.4
--On Friday, June 21, 2024 9:24 AM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
...
Why hdb? So far it worked fine for us, and mdb seems to need much more space in RAM and on disk.
This is factually incorrect. MDB requires fewer resources to operate, including RAM and disk space.
https://mishikal.wordpress.com/category/openldap-benchmarking/
[Windl, Ulrich] That "test" only compared sizes directly after loading the database, but it did not compare the sizes when the databases are "in use". For example, how do they behave when you change one attribute in 50% of the entries (just for example). What happens when you do that 10 times?
Like with statistics you can tune any test to show the results you want to see. So I'm not convinced that I am "factually incorrect" yet. ...
--On Friday, June 28, 2024 7:41 AM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
[Windl, Ulrich] That "test" only compared sizes directly after loading the database, but it did not compare the sizes when the databases are "in use". For example, how do they behave when you change one attribute in 50% of the entries (just for example). What happens when you do that 10 times?
Like with statistics you can tune any test to show the results you want to see. So I'm not convinced that I am "factually incorrect" yet.
I did a write test too, MDB requires substantially fewer resource in that case as well:
https://wiki.zimbra.com/wiki/OpenLDAP_MDB_vs_HDB_performance
I will say that *early on* in the development of back-mdb/lmdb there were issues with the freelist that could cause explosive growth, but those were fixed years ago.
Regards, Quanah
--On Friday, June 28, 2024 7:30 AM -0700 Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Friday, June 28, 2024 7:41 AM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
[Windl, Ulrich] That "test" only compared sizes directly after loading the database, but it did not compare the sizes when the databases are "in use". For example, how do they behave when you change one attribute in 50% of the entries (just for example). What happens when you do that 10 times?
Like with statistics you can tune any test to show the results you want to see. So I'm not convinced that I am "factually incorrect" yet.
I did a write test too, MDB requires substantially fewer resource in that case as well:
https://wiki.zimbra.com/wiki/OpenLDAP_MDB_vs_HDB_performance
I will say that *early on* in the development of back-mdb/lmdb there were issues with the freelist that could cause explosive growth, but those were fixed years ago.
One thing I would note - If you have a multivalued attribute that has lots of values in a given entry and changes relatively often (say large ldap groups, where something like "member" changes), then it is important to configure multival (IIRC this is not available in the 2.4 release series). I generally use 100,10.
Regards, Quanah
-----Original Message----- From: Quanah Gibson-Mount quanah@fast-mail.org Sent: Friday, June 28, 2024 3:30 PM To: Windl, Ulrich u.windl@ukr.de; openldap-technical <openldap- technical@openldap.org> Subject: [EXT] RE: RE: Re: FW: Accessing ppolicy attributes as non-admin in 2.4
--On Friday, June 28, 2024 7:41 AM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
[Windl, Ulrich] That "test" only compared sizes directly after loading the database, but it did not compare the sizes when the databases are "in use". For example, how do they behave when you change one attribute in 50% of
the
entries (just for example). What happens when you do that 10 times?
Like with statistics you can tune any test to show the results you want to see. So I'm not convinced that I am "factually incorrect" yet.
I did a write test too, MDB requires substantially fewer resource in that case as well:
https://wiki.zimbra.com/wiki/OpenLDAP_MDB_vs_HDB_performance
[Windl, Ulrich]
But even that page only mentions the size of the acessslog, not the size of the databases after the changes. And I'm unsure whether "replication speed", specifically when done over a network, says much about (local) database performance.
I will say that *early on* in the development of back-mdb/lmdb there were issues with the freelist that could cause explosive growth, but those were fixed years ago.
[Windl, Ulrich]
Maybe it's that "bad news travels fastest".
Kind regards, Ulrich
Regards, Quanah
--On Monday, July 1, 2024 9:07 AM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
https://wiki.zimbra.com/wiki/OpenLDAP_MDB_vs_HDB_performance
[Windl, Ulrich]
But even that page only mentions the size of the acessslog, not the size of the databases after the changes. And I'm unsure whether "replication speed", specifically when done over a network, says much about (local) database performance.
The main db didn't change size. Thus no reason to list it.
I'm not sure what you mean about replication speed. The point about the accesslog is in that scenario, both the main DB AND the accesslog DB on the providers are taking write operations, which impacts write performance on those nodes.
In any case, your belief about hdb is incorrect. It takes significantly more resources across the board than mdb.
--Quanah
-----Original Message----- From: Quanah Gibson-Mount quanah@fast-mail.org Sent: Monday, July 1, 2024 5:54 PM To: Windl, Ulrich u.windl@ukr.de; openldap-technical <openldap- technical@openldap.org> Subject: [EXT] RE: RE: RE: Re: FW: Accessing ppolicy attributes as non-admin in 2.4
--On Monday, July 1, 2024 9:07 AM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
https://wiki.zimbra.com/wiki/OpenLDAP_MDB_vs_HDB_performance
[Windl, Ulrich]
But even that page only mentions the size of the acessslog, not the size of the databases after the changes. And I'm unsure whether "replication speed", specifically when done over a network, says much about (local) database performance.
The main db didn't change size. Thus no reason to list it.
[Windl, Ulrich]
OK, that could mean two things: 1) the attribute changes hat the same size, and changes were done "in place", overwriting the data 2) the attributes were written in a new place, but there was enough "slack space" avoiding the database to grow.
For case 1 that would mean "the database never grows" if the attributes changed are the same size as before, while For case 2 it means that either (2a) new values are written at some free space where old attributes once were (recycling free space), or (2b) the database has to grow at some point, allocating new "slack space" (what will become of "unsused old space" then?)
Of course I know that you (Quanah) know very well what happens, but the other users (like me) might not know (exactly) what will happen, so I'd think some explanation would not be bad to see.
I'm not sure what you mean about replication speed. The point about the accesslog is in that scenario, both the main DB AND the accesslog DB on the providers are taking write operations, which impacts write performance on those nodes.
In any case, your belief about hdb is incorrect. It takes significantly more resources across the board than mdb.
[Windl, Ulrich]
So you measured the speed of the local accesslog database, and NOT the remote database (and the local accesslog writing will never be blocked by remote replication)?
Maybe add a few more words to make it easier to understand what actually had been measured.
[Windl, Ulrich] Kind Regards, Ulrich
--On Thursday, July 4, 2024 8:00 AM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
For case 1 that would mean "the database never grows" if the attributes changed are the same size as before, while For case 2 it means that either (2a) new values are written at some free space where old attributes once were (recycling free space), or (2b) the database has to grow at some point, allocating new "slack space" (what will become of "unsused old space" then?)
It was modifications of data, with different size attribute values. It was not case #1. Since it was not adding new entries or new attributes + values, it is more along the line of case #2. But again, the same changes were made with both back-mdb AND back-hdb. Even if you were to be *adding* new entries or attribute-value pairs, back-mdb requires less resources than back-hdb, that's already covered via the database size differences with slapadd.
So you measured the speed of the local accesslog database, and NOT the remote database (and the local accesslog writing will never be blocked by remote replication)?
replication is a read OP, so no it doesn't block the accesslog being updated on the provider. The point was measuring performance when 2x write ops were being made for every change.
In any case, the point is, again, back-mdb requires substantially fewer resources than back-hdb, and it is more performant than back-hdb in every scenario.
--Quanah
openldap-technical@openldap.org
-
Quanah Gibson-Mount -
Windl, Ulrich