Hi,
I'd like to let my account managers to clear the passwords of their managees in the event that an employee is no longer active. So, I've got an ACL like this:
access to attrs=userPassword,sambaNTPassword by set="this/manager & user" write by * break
But I realized that the ACL also allows the manager to -change- a user's password, which I don't really want.
Is there some ACL that I can grant that would let a manager remove an attribute from another user's account, but not otherwise change the value of that attribute?
Tim Gustafson Baskin School of Engineering UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354
On Tue, 29 Jun 2010, Tim Gustafson wrote:
access to attrs=userPassword,sambaNTPassword by set="this/manager & user" write by * break
But I realized that the ACL also allows the manager to -change- a user's password, which I don't really want.
Is there some ACL that I can grant that would let a manager remove an attribute from another user's account, but not otherwise change the value of that attribute?
Probably depends on what your LDAP clients are looking for. Some ideas to think about:
grant delete access, then the user shouldn't be able to bind. (Assuming compatible schema and applications.)
grant write access to some sort of "enabled" attribute:
* Perhaps you're using shadowAccounts, or an LDAP group that you could allow managers to write to (perhaps with a set and/or regex that ensures that they only write/delete DNs relevant to their own employees), or it'd be worth registering your own localAttributeManagerDisabled, or.....
Probably depends on what your LDAP clients are looking for.
We use LDAP for all sorts of things - directory lookups, Linux/SunOS system authentication, web site authentication, and lots more. Using an additional attribute, like "localLockedAccount" won't work because lots of our clients probably can't be configured to pay attention to that, and even if they could there are just too many different types of clients that change all the time, some of which I don't have any direct control over. Somehow breaking the ability for a user to bind against the server is really the only way to go.
Which makes me wonder if I could modify the bind ACI to disallow binding to accounts who have the "localLockedAccount" attribute set...something like:
access to attrs=userPassword,sambaNTPassword filter=(localLockedAccount!=TRUE) by self write by anonymous auth by * compare
Would that work? Can you stack "to attrs" with a "filter" statement like that?
grant delete access, then the user shouldn't be able to bind.
Can you grant delete access to a particular attribute? I guess that was my original question.
Tim Gustafson Baskin School of Engineering UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354
On Wed, 30 Jun 2010, Tim Gustafson wrote:
access to attrs=userPassword,sambaNTPassword filter=(localLockedAccount!=TRUE) by self write by anonymous auth by * compare
Would that work? Can you stack "to attrs" with a "filter" statement like that?
Yes, that's a supported syntax.
grant delete access, then the user shouldn't be able to bind.
Can you grant delete access to a particular attribute? I guess that was my original question.
Sure. That's documented as one of the supported <level> choices in slapd.access(5) man page. (Note that that same page has the explicit answer to your earlier question; "The dn, filter, and attrs statements are additive; they can be used in sequence to select entities the access rule applies to based on naming context, value and attribute type simultaneously.") Perhaps a look through that is in order...
Tim Gustafson wrote:
I'd like to let my account managers to clear the passwords of their managees in the event that an employee is no longer active. So, I've got an ACL like this:
access to attrs=userPassword,sambaNTPassword by set="this/manager & user" write by * break
But I realized that the ACL also allows the manager to -change- a user's password, which I don't really want.
Is there some ACL that I can grant that would let a manager remove an attribute from another user's account, but not otherwise change the value of that attribute?
If by "manager" you mean the rootdn, it bypasses ACL checking. If you mean a normal user which application-wise is granted higher privileges by ACLs, you need to make use of the granular "a" (add) and "z" (zap) privileges (their union is "w", write).
Something like
access to attrs=userPassword,sambaNTPassword by set="this/manager & user" z by * break
p.
If you mean a normal user which application-wise is granted higher privileges by ACLs, you need to make use of the granular "a" (add) and "z" (zap) privileges (their union is "w", write).
Pardon my thickness, but the documentation at http://www.openldap.org/doc/admin24/access-control.html specifically calls out the possible values of the "level" part of the ACL clause:
<level> ::= none | disclose | auth | compare | search | read | write | manage
Is this an undocumented feature? Should perhaps the documentation be updated, or maybe an example of this sort of ACL included in the examples section?
Tim Gustafson Baskin School of Engineering UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354
--On Thursday, July 01, 2010 8:48 AM -0700 Tim Gustafson tjg@soe.ucsc.edu wrote:
If you mean a normal user which application-wise is granted higher privileges by ACLs, you need to make use of the granular "a" (add) and "z" (zap) privileges (their union is "w", write).
Pardon my thickness, but the documentation at http://www.openldap.org/doc/admin24/access-control.html specifically calls out the possible values of the "level" part of the ACL clause:
<level> ::= none | disclose | auth | compare | search | read | write | manage
Is this an undocumented feature? Should perhaps the documentation be updated, or maybe an example of this sort of ACL included in the examples section?
I suggest you refer to the man page, which is always the end authority on documentation.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On 01/07/2010 17:48, Tim Gustafson wrote:
If you mean a normal user which application-wise is granted higher privileges by ACLs, you need to make use of the granular "a" (add) and "z" (zap) privileges (their union is "w", write).
Pardon my thickness, but the documentation at http://www.openldap.org/doc/admin24/access-control.html specifically calls out the possible values of the "level" part of the ACL clause:
<level> ::= none | disclose | auth | compare | search | read | write | manage
Is this an undocumented feature? Should perhaps the documentation be updated, or maybe an example of this sort of ACL included in the examples section?
This syntax is not a "level" but a "priv". From the slapd.access(5) man page: <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+
The online admin guide does seem to be out of date on this subject...
Thanks, Jonathan
This syntax is not a "level" but a "priv". From the slapd.access(5) man page: <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+
The online admin guide does seem to be out of date on this subject...
Awesome, thanks for the pointer. I don't know why I prefer web-based documentation...but I'll stick to the man pages from now on.
Tim Gustafson Baskin School of Engineering UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354
--On Thursday, July 01, 2010 9:12 AM -0700 Tim Gustafson tjg@soe.ucsc.edu wrote:
This syntax is not a "level" but a "priv". From the slapd.access(5) man page: <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+
The online admin guide does seem to be out of date on this subject...
Awesome, thanks for the pointer. I don't know why I prefer web-based documentation...but I'll stick to the man pages from now on.
As noted in my reply -- The man pages are online as well.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
As noted in my reply -- The man pages are online as well.
Yeah, but as each version of OpenLDAP can have a slightly different set of documentation, I think it's probably safer for me to just "man slapd.whatever" on the box in question instead of Googling on-line documentation that may (as in this case) be different than the actual implementation.
Tim Gustafson Baskin School of Engineering UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354
openldap-technical@openldap.org
-
Aaron Richton -
Jonathan Clarke -
Pierangelo Masarati -
Quanah Gibson-Mount -
Tim Gustafson