akynaston Absent Member.
Absent Member.
1669 views

LDAP extensions and controls libraries are outdated.

Hey all!

I've been using getEffectivePrivileges from the SDK downloaded from:

https://www.novell.com/developer/ndk/ldap_extensions_and_controls_for_jndi.html

As you can see, it's 11 years old, and appears to still use an old inherit_ctl ACL flag (is it still used??), and is missing the dynamic, nested and RBS related ACL flags. I know I can implement the getEffectivePrivileges extension in eDirectory myself, but would rather use an API if it's available. Does any one know who would be responsible for maintaining this? If there is no one, what would be the proper path forward here?

--Aaron
Labels (1)
0 Likes
11 Replies
Knowledge Partner
Knowledge Partner

Re: LDAP extensions and controls libraries are outdated.

On 2017-11-17 00:14, akynaston wrote:
>
> Hey all!
>
> I've been using getEffectivePrivileges from the SDK downloaded from:
>
> https://www.novell.com/developer/ndk/ldap_extensions_and_controls_for_jndi.html
>
> As you can see, it's 11 years old, and appears to still use an old
> inherit_ctl ACL flag (is it still used??), and is missing the dynamic,
> nested and RBS related ACL flags. I know I can implement the
> getEffectivePrivileges extension in eDirectory myself, but would rather
> use an API if it's available. Does any one know who would be
> responsible for maintaining this? If there is no one, what would be the
> proper path forward here?
>
> --Aaron
>
>

Most of the SDKs look unmaintained or maybe they work so good that no
further development is needed 😉

You can always try to open a service request and see what kind of answer
you get.

There is also the source code for GetEffectivePrivilegesListRequest
and GetEffectivePrivilegesRequest in JLDAP if that helps with
implementing it for JNDI?

http://www.openldap.org/devel/gitweb.cgi?p=openldap-jldap.git;a=tree;f=com/novell/ldap/extensions;
0 Likes
akynaston Absent Member.
Absent Member.

Re: LDAP extensions and controls libraries are outdated.

I've responded to this twice now, and it isn't sticking . . trying again . . .

I have two questions now regarding the API. After looking at the code you mentioned, it has forced me to rethink some things.

The first question, is I consistently see an inherit_ctl flag, along with the standard read/write/browse flags. What does this one mean? It doesn't seem to relate to whether or not the flags are 'subtree' or 'entry'; Do you know what this flag is for?



Second, I may have answered this already, but was hoping to check in with you and see if you can confirm this. I noticed the SDK I downloaded from https://www.novell.com/developer/ndk/ldap_extensions_and_controls_for_jndi.html didn't expose the dynamic, nested, and RBS ACL flags. However, I realized they are really just "rights-modifiers": they affect effective rights, but don't come back in the getEffectivePrivileges response correct?


Let me give you an example:


Here's a test:

I wrote an ACL on my o=ABC container with the value of:

536870944#subtree#cn=testgroup,o=ABC#telephoneNumber

Meaning that members of my dynamic group (536870912 dynamic + 32 attr supervisor) have full administrative access to the telephonenumber attribute. When I run getEffectiveRights, I see properly that members of this group have supervisor rights to the telelphoneNumber attribute, but no dynamic flag is sent back( the string I get back is . . .compare:true, read: true, write: true, self:true, supervisor: true, inherit_ctl:false; no mention of dynamic . .) I think this is expected, can you confirm?

This just means that I can get my effective rights, but I can't necessarily tell if they came from a dynamic group, a nested group, nor an RBS granted right. I think I'm ok with this limitation, I just need to be rock solid on my understanding.
0 Likes
Knowledge Partner
Knowledge Partner

Re: LDAP extensions and controls libraries are outdated.

On 11/21/2017 04:54 PM, akynaston wrote:
>
> The first question, is I consistently see an inherit_ctl flag, along
> with the standard read/write/browse flags. What does this one mean? It
> doesn't seem to relate to whether or not the flags are 'subtree' or
> 'entry'; Do you know what this flag is for?


The SDK reference I see
https://www.novell.com/documentation/developer/njcl/njcl_enu/apic/com/novell/service/nds/NdsAttributeRights.html
does not give much more than you already thought. While I could probably
think of better wording, it was probably deemed to be clear enough among
those who regularly used it, and as far as I can tell it means what you
think/thought it means, namely that the rights are inheritable. I cannot
think of anything else that makes much sense, so next I'll ask how you
tested to see if the inheritance worked as you thought, and determined it
did not?

Since these are effective rights, I would not expect for you to need any
explicit entry for this flag to show up, or any ACL at all on this
particular object, as they could all be inherited from the top of the
tree. Also, because I would probably do this myself, be sure the user
used for testing does not accidentally get rights from higher up (which
would then be inherited at some lower level) and confuse that inheritance
flag's interpretation.

--
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
akynaston Absent Member.
Absent Member.

Re: LDAP extensions and controls libraries are outdated.

ab,

I agree with your thoughts on the inherit_ctl flag. However, in testing it doesn't match up. To answer your question, When you call getEffectiveRights, a string similar to the one below appears:

"compare: false, read: true, write: false, self: false, supervisor: false, inherit_ctl: false"

The inherit_ctl flag seems to be randomly true or false; despite whatever the 'entry' or 'subtree' value says in the corresponding ACL that granted that set of rights in the first place. Also, for it to be true or false, which of the flags is it referring to is being inherited? When getting effective rights, each one of these flags could have been set or cleared by any number of ways; including IRFS, dynamic/nested groups, explicit ACLs, or securityEquals.

For example, if I look at the standard public browse right on the tree root, it looks like this:

1#subtree#[Public]#[Entry Rights]

Since it is 'subtree', I would expect any one connecting to the tree (with anonymous or a specific user) looking anywhere in the tree, wouldn't inherit_ctl be true? And if it were true or false, it still doesn't seem to have any context: how would I know what flag has been, or has not been inherited? The flag is just confusing and doesn't seem to have any context.

I need to run more tests I think: like calling getEffectveRights for every object in my tree (it's quite fast, and I have a small test tree), and see where it is set or cleared; I just don't have much time to do this sort of testing at the moment.

ab - any thoughts about the second item regarding the dynamic,nested,rbs ACL flags?

--Aaron


ab;2470537 wrote:
On 11/21/2017 04:54 PM, akynaston wrote:
>
> The first question, is I consistently see an inherit_ctl flag, along
> with the standard read/write/browse flags. What does this one mean? It
> doesn't seem to relate to whether or not the flags are 'subtree' or
> 'entry'; Do you know what this flag is for?


The SDK reference I see
https://www.novell.com/documentation/developer/njcl/njcl_enu/apic/com/novell/service/nds/NdsAttributeRights.html
does not give much more than you already thought. While I could probably
think of better wording, it was probably deemed to be clear enough among
those who regularly used it, and as far as I can tell it means what you
think/thought it means, namely that the rights are inheritable. I cannot
think of anything else that makes much sense, so next I'll ask how you
tested to see if the inheritance worked as you thought, and determined it
did not?

Since these are effective rights, I would not expect for you to need any
explicit entry for this flag to show up, or any ACL at all on this
particular object, as they could all be inherited from the top of the
tree. Also, because I would probably do this myself, be sure the user
used for testing does not accidentally get rights from higher up (which
would then be inherited at some lower level) and confuse that inheritance
flag's interpretation.

--
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
Knowledge Partner
Knowledge Partner

Re: LDAP extensions and controls libraries are outdated.

I agree; it should be more-granular than that for the exact reasons you
state; inheritance is on a per-property/permission basis. I also noticed,
when going through the SDK, that I only saw references to that on Entry
stuff, at least in the docs, and not on actual attribute rights. Maybe
that is an oversight in docs, and I have not tested at all myself, but it
makes me curious.

I am afraid I do not have much else to provide right now. I'll post
internally to see if I can get a response from somebody.

Regarding the dynamic bits, I agree with your conclusion, with the huge
gulf of a caveat that I have never tested it, and generally do little with
dynamic groups when it comes to permissions.

--
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
akynaston Absent Member.
Absent Member.

Re: LDAP extensions and controls libraries are outdated.

ab,

Not a problem: it has been great to talk with some one about this that has some familiarity with this.

I was able to test the dynamic group flag at least; and found my assumption to be true: while the dynamic flag is not returned explicitly, the 'effective rights' granted by the dynamic group were properly reflected. I didn't test the nested group or iManager/RBS ACL, though I assume the same would occur with the rights granted through those flags. Now to tie it back to inherit_ctl and understand it some day . . .

BTW - I'd love to chat with any one and every one about this; I assumed this kind of functionality would have been more widely used. I'm surprised to have had such a lack of people that have done this.

My office number is 801 877 0903 if any one is available to chat through it; thank you for your thoughts.

--Aaron
0 Likes
Knowledge Partner
Knowledge Partner

Re: LDAP extensions and controls libraries are outdated.

I am now looking at this a bit more, and I am curious exactly how your
code is working. The term "Object" is used over and over in the
documentation, and I wonder if it means a Java object of type
javax.naming.directory.Attribute instead of an eDirectory object. If so,
then the inherited bit may start to make more sense, but that leads me to
wonder how you are doing the checks in code.

Making me believe this may be more useful than I originally supposed, the
sample code at
https://www.novell.com/documentation/developer/samplecode/jldap_sample/extensions/GetEffectivePrivileges.java.html
seems to do this, where it starts off getting the object (trustor), the
trustee, and then explicitly passes in a 'rightName' which is checked for
effective privileges.

Perhaps you have gone down this route already and I am just trying to
catch up, but if possible it may be useful to see some code, maybe
understand what the stack is like in Java (or whatever) at the time you
print out rights, plus know for sure which right you are checking and how
that right is defined in the hierarchy up to the trustor/trusting object.

--
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
akynaston Absent Member.
Absent Member.

Re: LDAP extensions and controls libraries are outdated.

ab,

The catalyst for this was that we have a lot of service accounts that need specific rights in eDirectory; and we have 'too many cooks in the tree'. Some people have changed rights, while we have been somewhat drowning in the pile of rights needed for these various accounts. The changes needed have been too specific and fluid to use RBS (though this could change), so we needed a way to have a automated testing approach to confirming all service accounts have the rights they need. Eventually, we'll remove rights for these people so there's less changing going on, but until then we need to be able to immediately know what rights service accounts have.

We are working on cleaning up the rights; creating groups and more heavily using 'security equals' to make the management eaiser; though my thought is that if I can test the rights on demand, I can safely rebuild rights in production since I can dynamically and very quickly check I haven't messed anything up.


For example:

Lets say we have the following entry in our service accounts LDIF file:

dn: cn=employeeMailAdmin,o=services
changetype: add
objectClass: user
sn: service account
userpasword: 12345

dn: ou=Employees,ou=Personnel,o=Staff
changetype: modify
add: ACL
ACL: 6#subtree#cn=employeeMailAdmin,o=services#mail
(and other ACLS here . . )

My code searches for the ACL lines, then loops through each ACL checking the rights. The first ACL, this would happen:

Resource DN: ou=Employees,ou=Personnel,o=Staff
Trustee dn: cn=employeeMailAdmin,o=services
attr/right name: mail
Assert string: write:true, read:true



A call to get effective rights (using the SDK at https://www.novell.com/developer/ndk/ldap_extensions_and_controls_for_jndi.html) returns something like this:

compare: true, read: true, write: true, self: true, supervisor: false, inherit_ctl: false

compare: this is true because 'read' effecitvely grants it.
read: this is true because it is explicitly assigned.
write: this is true because it is explicitly assigned.
self: this is true because 'write' effectively grants it.
supervisor: not true; it's not set explicitly or otherwise.
Inherit_ctl: who knows 🙂

Since my assert strings above included only a write & read check, then the test would pass, and I would have confirmed that the service account has their specific right. Does this help?
0 Likes
akynaston Absent Member.
Absent Member.

Re: LDAP extensions and controls libraries are outdated.

A few more items:

After reading the code a bit more, when they refer to 'object, or objectDN' it seems like they're referring to the 'resource dn'; or the object in the tree that is being reviewed for rights; know what I mean?
In every case, I've had the explicit 'trustee' or 'resource' meaning the user being trusted or the object for which rights are in question. The JNDI Attribute/BasicAttribute/etc class isn't used in this context, right? Did I miss something?

Also, it looks like the stuff you are using seems to be using Novell's LDAP libraries rather then just the SDK wrapper I mentioned above: do you recommend using that one over the one I'm using? It looks like i'd get the same results either way; thoughts?

Sorry for the multiple postings, I admit I'm quite happy to be able to chat about this finally. :cool:
0 Likes
Knowledge Partner
Knowledge Partner

Re: LDAP extensions and controls libraries are outdated.

Aaron,
Did you try to use my ECMAScript library?
I use it for the number of years in the IDM driver and I didn't see any issue with this method of permission validation.
akynaston Absent Member.
Absent Member.

Re: LDAP extensions and controls libraries are outdated.

al_b;2470672 wrote:
Aaron,
Did you try to use my ECMAScript library?
I use it for the number of years in the IDM driver and I didn't see any issue with this method of permission validation.



al_b,

No, I haven't used it, though it met my goal: My intent with getting a copy of your rights checker was to see if you had used the inherit_ctl, dynamic, nested, or rbs flags; and how you dealt with them. After a few more conversations with others, it occurred to me that these flags are really only rights modifier flags: it at least makes partial sense that these wouldn't come back in an effective rights query; since they just result in granting a right.

I love the ECMA script though: it's quite useful for lots of reasons; thank you for your assistance.
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.