Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
AS78 Absent Member.
Absent Member.
846 views

Exclude specific attribute from [All Attribute Rights]?

Hi all,

I'm strolling through the marvellous world of eDir rights these days and though I thought, there were not many mysteries left to uncover, eDir managed to surprise me once again, when I tried to exclude a single specific attribute from the list of "all attributes" writable by a certain trustee.

The task is to exclude one or two specific attributes of an object from being writable, e.g., by a certain trustee (in fact by the object itself, but any other trustee should work). The idea was to grant write access to [All Attribute Rights] to the parent container of the object in question and mark these rights as "inheritable" in iManager. (Adding "64" to the privilege field of the relevant ACL in ADS returns the rights bitmask without addition of "64", by the way, therefore with ADS I cannot see, whether the „inheritable“ flag presented in iManager has been set or not.)

By changing the rights of the parent container I could prove, that they were correctly assigned to the child object as well. Revoking at object level was working as well, however only as long, as [All Attribute Rights] were specified again. I tested with an IRF letting only "compare" rights through and with explicit object ACLs allowing only "compare". Whenever a specific attribute instead of [All Attribute Rights] was specified in the IRF or in the object's ACLs, it seemed to have no effect: The object could still write to the attribute in question and iManager reported effective rights as inherited from the container.

I therefore wonder, if it is possible to exclude one or two specific attributes from rights inherited from a parent where these rights were granted using [All Attributes Rights]? — Constructing a custom list of all object attributes that _should_ be writable except for the one or two that should lack this possibility, seems somewhat tedious and difficult to maintain, whenever new attributes are added at a later stage.

Axel
Labels (1)
Tags (1)
0 Likes
7 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Exclude specific attribute from [All Attribute Rights]?

On 10/17/2018 07:14 AM, AS78 wrote:
>
> The task is to exclude one or two specific attributes of an object from
> being writable, e.g., by a certain trustee (in fact by the object
> itself, but any other trustee should work). The idea was to grant write
> access to [All Attribute Rights] to the parent container of the object
> in question and mark these rights as "inheritable" in iManager. (Adding
> "64" to the privilege field of the relevant ACL in ADS returns the
> rights bitmask without addition of "64", by the way, therefore with ADS
> I cannot see, whether the �inheritable� flag presented in iManager has
> been set or not.)


I think either I do not understand the '64' part fully, or else you do not
understand the inheritance part. As you probably realize, an ACL has four
(4) parts, an integer (permission), scope (entry or subtree), trustee (who
gets the permission to the attribute) and attribute (which may include
pseudo attributes like [All Attributes Rights] or [Entry Rights]). What I
think you are indicating is that the integer has something to do with
inheritance, but that is not the case. On the other hand, some rights
mean you get a lot more rights than you may think, e.g. if you have rights
to write to ACL you effectively can do anything to that object because you
can write your own permissions to it.

> By changing the rights of the parent container I could prove, that they
> were correctly assigned to the child object as well. Revoking at object
> level was working as well, however only as long, as [All Attribute
> Rights] were specified again. I tested with an IRF letting only
> "compare" rights through and with explicit object ACLs allowing only
> "compare". Whenever a specific attribute instead of [All Attribute
> Rights] was specified in the IRF or in the object's ACLs, it seemed to
> have no effect: The object could still write to the attribute in
> question and iManager reported effective rights as inherited from the
> container.


I'm not sure this is wrong, but I have not looked into it as much as you
have. On the other hand, I have never wanted to block just one or two
attributes since either I want an admin or else I know the attributes and
I assign just those. Schema extensions are rare, and most attributes are
not needed by most applications anyway (I think I've defined as many as
thirty (30) attributes at a time for a given trustee, several being custom
attributes added via aux class).

> I therefore wonder, if it is possible to exclude one or two specific
> attributes from rights inherited from a parent where these rights were
> granted using [All Attributes Rights]? � Constructing a custom list of
> all object attributes that _should_ be writable except for the one or
> two that should lack this possibility, seems somewhat tedious and
> difficult to maintain, whenever new attributes are added at a later
> stage.


Your testing seems to be complete. A few last notes may help, but
otherwise you may be seeing how it is implemented. First, I'd guess in
99.9% of cases adding all attributes except a couple is not necessary,
either because not all attributes are really needed or else because one of
those attributes you need is 'ACL' which effectively means you are giving
full rights, since having write to ACL means you have all rights. Also,
there is a default ACL written on every object for itself granting read
rights to all attributes, and write to at least one attribute too. Maybe
those are confusing some of the test results (I do not really think so
based on what you've written, but I've been tripped up by default ACLs in
the past). This mostly applies because, as I understand it, you are
trying to block the user's rights to itself.

This is a pretty interesting setup. If you could provide more details on
why you want this kind of ACL setup (block user's rights to itself) and
why so many attributes are needing to be modified, that may be interesting
to help figure out the best way to handle this, as well as possibly come
up with ways to enhance eDirectory in the future, or to report a bug now.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
AS78 Absent Member.
Absent Member.

Re: Exclude specific attribute from [All Attribute Rights]?

ab;2489056 wrote:
On 10/17/2018 07:14 AM, AS78 wrote:
>
> The task is to exclude one or two specific attributes of an object from
> being writable, e.g., by a certain trustee (in fact by the object
> itself, but any other trustee should work). The idea was to grant write
> access to [All Attribute Rights] to the parent container of the object
> in question and mark these rights as "inheritable" in iManager. (Adding
> "64" to the privilege field of the relevant ACL in ADS returns the
> rights bitmask without addition of "64", by the way, therefore with ADS
> I cannot see, whether the �inheritable� flag presented in iManager has
> been set or not.)


I think either I do not understand the '64' part fully, or else you do not
understand the inheritance part. As you probably realize, an ACL has four
(4) parts, an integer (permission), scope (entry or subtree), trustee (who
gets the permission to the attribute) and attribute (which may include
pseudo attributes like [All Attributes Rights] or [Entry Rights]). What I
think you are indicating is that the integer has something to do with
inheritance, but that is not the case. On the other hand, some rights
mean you get a lot more rights than you may think, e.g. if you have rights
to write to ACL you effectively can do anything to that object because you
can write your own permissions to it.


"64" meant setting bit 0x64 of the permission integer in ADS. Bit 0x64 disappeared the moment it was entered.
Nevertheless, as far as I remember, the "inherit" flag depicted in iManager was set afterwards. Setting and unsettling this flag in iManager didn't make any difference in ADS on the other hand. I therefore concluded, the "inherit" information must be stored elsewhere, triggered by (temporarily) setting bit 0x64.

ab wrote:


> By changing the rights of the parent container I could prove, that they
> were correctly assigned to the child object as well. Revoking at object
> level was working as well, however only as long, as [All Attribute
> Rights] were specified again. I tested with an IRF letting only
> "compare" rights through and with explicit object ACLs allowing only
> "compare". Whenever a specific attribute instead of [All Attribute
> Rights] was specified in the IRF or in the object's ACLs, it seemed to
> have no effect: The object could still write to the attribute in
> question and iManager reported effective rights as inherited from the
> container.


I'm not sure this is wrong, but I have not looked into it as much as you
have. On the other hand, I have never wanted to block just one or two
attributes since either I want an admin or else I know the attributes and
I assign just those. Schema extensions are rare, and most attributes are
not needed by most applications anyway (I think I've defined as many as
thirty (30) attributes at a time for a given trustee, several being custom
attributes added via aux class).

> I therefore wonder, if it is possible to exclude one or two specific
> attributes from rights inherited from a parent where these rights were
> granted using [All Attributes Rights]? � Constructing a custom list of
> all object attributes that _should_ be writable except for the one or
> two that should lack this possibility, seems somewhat tedious and
> difficult to maintain, whenever new attributes are added at a later
> stage.


Your testing seems to be complete. A few last notes may help, but
otherwise you may be seeing how it is implemented. First, I'd guess in
99.9% of cases adding all attributes except a couple is not necessary,
either because not all attributes are really needed or else because one of
those attributes you need is 'ACL' which effectively means you are giving
full rights, since having write to ACL means you have all rights. Also,
there is a default ACL written on every object for itself granting read
rights to all attributes, and write to at least one attribute too. Maybe
those are confusing some of the test results (I do not really think so
based on what you've written, but I've been tripped up by default ACLs in
the past). This mostly applies because, as I understand it, you are
trying to block the user's rights to itself.

This is a pretty interesting setup. If you could provide more details on
why you want this kind of ACL setup (block user's rights to itself) and
why so many attributes are needing to be modified, that may be interesting
to help figure out the best way to handle this, as well as possibly come
up with ways to enhance eDirectory in the future, or to report a bug now.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.


I had deleted the standard ACL of the user object in question. Accordingly, this user couldn't even see his own attribute values before I gave [All Attributes Rights] inheritable read right to the parent container. Finally I added the IRF to the user object prohibiting to inherit one specific test attribute. This didn't work unless I put [All Attributes Rights] in the IRF. I may add, the test attribute was belonging to an auxiliary class not used by the parent container.

The idea of limiting the owner's rights to one or two of his own attributes comes from our IDMS: We are using a few "private" attributes that contain values that only make sense for dedicated IDMS drivers, not for the user him- or herself. To avoid questions by users not understanding those values when they access eDir with a LDAP browser, e.g., excluding "private" attributes from display seemed a promising idea to me. Anyway the question has raised my academic research instinct ;-), no matter of write or read rights should be excluded.

Axel
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Exclude specific attribute from [All Attribute Rights]?

On 10/19/2018 12:54 PM, AS78 wrote:
>
> "64" meant setting bit 0x64 of the permission integer in ADS. Bit 0x64
> disappeared the moment it was entered.
> Nevertheless, as far as I remember, the "inherit" flag depicted in
> iManager was set afterwards. Setting and unsettling this flag in
> iManager didn't make any difference in ADS on the other hand. I


Something is wrong then; either you are not hitting Apply/Ok/Submit/Finish
enough times in iManager (a common issue for everybody), or Directory
Studio is not refreshing (another common issue), but the inheritance is
definitely always shown on each ACL as part of the overall value in the
second component.

> therefore concluded, the "inherit" information must be stored elsewhere,
> triggered by (temporarily) setting bit 0x64.


Nope.

> I had deleted the standard ACL of the user object in question.
> Accordingly, this user couldn't even see his own attribute values before
> I gave [All Attributes Rights] inheritable read right to the parent
> container. Finally I added the IRF to the user object prohibiting to
> inherit one specific test attribute. This didn't work unless I put [All
> Attributes Rights] in the IRF. I may add, the test attribute was
> belonging to an auxiliary class not used by the parent container.


No problem, and that's very normal. Many user attributes are not
available on containers, and yet set set ACLs on containers all the time
for efficiency; auxiliary attributes are no different.

> The idea of limiting the owner's rights to one or two of his own
> attributes comes from our IDMS: We are using a few "private" attributes
> that contain values that only make sense for dedicated IDMS drivers, not
> for the user him- or herself. To avoid questions by users not
> understanding those values when they access eDir with a LDAP browser,
> e.g., excluding "private" attributes from display seemed a promising
> idea to me. Anyway the question has raised my academic research instinct
> ;-), no matter of write or read rights should be excluded.


My guess is that what you see is correct then.

Be careful of giving users too many rights to themselves. If allowed they
could invalidate password policies (by writing nspmPasswordPolicyDN to
point to some other password policy), or change/relax password or login
restrictions (by writing one of many attributes on themselves, or give
themselves an infinite number o grace logins. While it is their user, and
it seems like users should be able to tweak themselves in most ways, it
usually turns out that users should be able to tweak themselves in limited
ways (in an enterprise or organization environment anyway), so they need a
few rights, at best, not the majority or all.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
AS78 Absent Member.
Absent Member.

Re: Exclude specific attribute from [All Attribute Rights]?

Thanks for your answer. Sorry for my late reply, but we'd tunneled to the island to spend a sunny week in the British capital comparing today's skyline with it's state in 1983, the year of our last visit. Elizabeth Tower being scaffolded as it used to be 35 years ago the rest of the view revealed some differences, indeed...

ab;2489131 wrote:
On 10/19/2018 12:54 PM, AS78 wrote:
>
> "64" meant setting bit 0x64 of the permission integer in ADS. Bit 0x64
> disappeared the moment it was entered.
> Nevertheless, as far as I remember, the "inherit" flag depicted in
> iManager was set afterwards. Setting and unsettling this flag in
> iManager didn't make any difference in ADS on the other hand. I


Something is wrong then; either you are not hitting Apply/Ok/Submit/Finish
enough times in iManager (a common issue for everybody), or Directory
Studio is not refreshing (another common issue), but the inheritance is
definitely always shown on each ACL as part of the overall value in the
second component.

> therefore concluded, the "inherit" information must be stored elsewhere,
> triggered by (temporarily) setting bit 0x64.


Nope.


First of all: "64" meant 0x40, of course, not 0x64. Meanwhile I've been able to investigate once again in a more systematic way. I may have been misled by TID 7006280 which caused me to expect the ACLs integer value would display the inheritance bit "attr_inherit_ctl" 0x40 as well. This is, however, not the case.
Changing just the inheritance flag in iManager does not affect the integer value reported by ADS. Instead, the second ACL field gets updated, changing from "entry" to "subtree" and vice versa. This second field is not dealt with in TID 7006280 at all and I had missed it before, unfortunately. My earlier description was therefore wrong in this respect, as you already suspected.

When entering the inheritance control bit 0x40 in the ACL displayed by ADS, it gets masked out and only the remaining bits are returned. Entering "0x46" thus produces "0x06" and this value is reported by ADS an instant later, without having to refresh the view. I had no luck activating inheritance by setting bit 0x40 in ADS in any way, but succeeded by directly entering "subtree" into the second ACL field. Three test cases are given below:

[table="width: 500, class: grid"]

initially
input
result


3#entry#...
70#entry#...
6#entry#...


3#entry#...
70#subtree#...
6#entry#...


3#entry#...
6#subtree#...
6#subtree#...

[/table]

A colleague in contrast could trigger inheritance by setting bit 0x40 in ADS with her eDir 8 (I'm at eDir 9). Bit 0x40 was immediately cleared, too, but contrary to my findings the second field was changing from "entry" to "subtree". We have not investigated, whether this difference can be attributed to different eDir versions, configurations or ADS setup.

ab;2489131 wrote:


> I had deleted the standard ACL of the user object in question.
> Accordingly, this user couldn't even see his own attribute values before
> I gave [All Attributes Rights] inheritable read right to the parent
> container. Finally I added the IRF to the user object prohibiting to
> inherit one specific test attribute. This didn't work unless I put [All
> Attributes Rights] in the IRF. I may add, the test attribute was
> belonging to an auxiliary class not used by the parent container.


No problem, and that's very normal. Many user attributes are not
available on containers, and yet set set ACLs on containers all the time
for efficiency; auxiliary attributes are no different.

> The idea of limiting the owner's rights to one or two of his own
> attributes comes from our IDMS: We are using a few "private" attributes
> that contain values that only make sense for dedicated IDMS drivers, not
> for the user him- or herself. To avoid questions by users not
> understanding those values when they access eDir with a LDAP browser,
> e.g., excluding "private" attributes from display seemed a promising
> idea to me. Anyway the question has raised my academic research instinct
> ;-), no matter of write or read rights should be excluded.


My guess is that what you see is correct then.

Be careful of giving users too many rights to themselves. If allowed they
could invalidate password policies (by writing nspmPasswordPolicyDN to
point to some other password policy), or change/relax password or login
restrictions (by writing one of many attributes on themselves, or give
themselves an infinite number o grace logins. While it is their user, and
it seems like users should be able to tweak themselves in most ways, it
usually turns out that users should be able to tweak themselves in limited
ways (in an enterprise or organization environment anyway), so they need a
few rights, at best, not the majority or all.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.


Security

We are presently not granting write rights to any normal user in our production system. In fact, we are using an even more restrictive set of rights as the standard imposes following David Gersic's great Cool Solution on securing eDir. (We may allow users to enter their own mobile phone number someday, but extending rights will be accomplished on a per-attribute basis.)

I was experimenting with write rights in our development system for testing purposes in ADS only. And since our dev system isn't available to anybody but me, no harm will be done to any ACL or PP link by our normal users. Maybe I should have made this clear from the beginning.

ACL order

The simplest approach to define two different sets of rights ("allow right k to all attributes", "withdraw right k from attribute i") that came to my mind was to define two ACLs like

3#entry#user j#[All Attribute Rights]
1#entry#user j#attribute i

Originally, I'd been concerned about the order in which these ACLs would be evaluated. Clearly, the second one has to take effect after the first one. Unfortunately, I didn't find much documentation on how different contradicting ACLs of the same object are implemented. (In fact, section 3.a. in "How effective rights are calculated" states:

"eDirectory includes every right held by any trustee in the list and excludes only those rights that are missing from every trustee in the list. eDirectory does not mix right types. For example, it does not add rights for a specific property to rights for all properties or vice versa."

This could be understood, as if changing standards rights granted using [All Attributes Rights] to single specific attributes wasn't possible at all.)

Anyway, inheritance came to my mind to avoid the supposed problem with an undefined order of ACL execution: ACLs at the top of the tree are evaluated first, all ACLs further down later. After having sorted out the role of the second field of the ACL's LDAP representation ("entry" vs. "subtree"), adding and withdrawing rights to a specific attribute finally worked as imagined, both with an IRF at an intermediate container blocking inheritance of rights to a specific attribute, as with an explicit ACL defining limited rights to a single attribute at the intermediate container or the target object itself.

To my surprise, even the simple approach with the two ACLs mentioned above both located at the target object worked. That seems to suggest, ACL order has no relevance at all, but ACLs dealing with explicitly named specific attributes are always overriding rights defined by the general [All Attributes Rights] designator. I wonder, if this behaviour is guaranteed, because I failed to unearth any documentation on this so far (or I've missed or misunderstood some crucial statements). If one could rely upon this overriding mechanism, inheritance wouldn't be needed in the present case at all.

Thorsten;2489193 wrote:
[...]
Just my two cents:

Assigning rights to 'the user itself' is best done using the [self]
special trustee (+inheritence) somewhere above the users' contexts.

...


"Self" and "This" being somewhat cumbersome search terms, may I ask, if you have a link or a short explanation at hand, what their differences are? (I have so far tested with "[This]".) Our present test case with the two ACLs given above at the user container denotes the user's container DN itself as the trustee and apparently this works for the inheriting users as well.

Axel
0 Likes
Knowledge Partner
Knowledge Partner

Re: Exclude specific attribute from [All Attribute Rights]?

AS78;2489984 wrote:


"Self" and "This" being somewhat cumbersome search terms, may I ask, if you have a link or a short explanation at hand, what their differences are? (I have so far tested with "[This]".) Our present test case with the two ACLs given above at the user container denotes the user's container DN itself as the trustee and apparently this works for the inheriting users as well.

Axel


I believe Thorsten meant [This] there, not [Self].

[This] refers to a logged in object's rights to itself, a handy feature if you want users to be able to update an attribute, like mobile, on their own object, but not on any other objects. You could also do this with an ACL on each user, but that's cumbersome to manage.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Exclude specific attribute from [All Attribute Rights]?


On 11/2/18 5:04 PM, dgersic wrote:

>
> I believe Thorsten meant [This] there, not [Self].
>


Jesus, yes. I meant [This].

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Exclude specific attribute from [All Attribute Rights]?

[...]
Just my two cents:

Assigning rights to 'the user itself' is best done using the [self]
special trustee (+inheritence) somewhere above the users' contexts.
Example:
setting the [self] trustee with a [write] to TelephoneNumber to O=myORG
enables all users to write to THEIR attribute 'TelephoneNumber' (only)
below O=myORG .

Removing a right somewhere down the tree is best done using a
re-assignment of trusteerights (based on the same trustee).
Example:
Assigning [write] for attribute 'myAttribute' to O=myORG using the same
trustee O=myORG results in all objects below that O=myORG to be able to
write to that attribute. Suppose you have ou=sub.O=myORG, and add the
trustee O=myORG to that OU with [read] on attribute 'myAttribute', the
result is that all objects below ou=sub.O=myORG can only read it.
(Re-assignment based on same trustee)


IRF's are a nice thing to shot yourself in the foot, as well as
assigning [write] to [all attributes] as already mentioned here.

T.


0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.