What ACLs do i need to read password from a driver

[Andi Spoerri]

Hi, im trying to set up a driver with only read rights on Users, accodring to Documentation i just need the 3#subtree#cn=testpwread,ou=users,o=system#[All Attributes Rights] to be able to read the password.

But when i debug the driver it cannot read it. As soon as i give the testpwread the supervisor rights, it worksl. How can i define the user to just be able to read the password?

Thanks for your help.

Andi

[jimgoodall]

Hi Andi,

you need to make sure that the password policy assigned to the user has the appropriate password retrieval rules set. Find them in the password policy under Universal Password > Configuration Options

Cheers

Jim

[Andi Spoerri]

Hi Jim, thx for the Hint, i double checked on that, but my testpwread user was allready set as user that is able to retrieve passwords. I now added another one User, but still no change. I also added the password policy to my testpwread user.

[jimgoodall]

OK, so your driver is running as security equivalent to testpwread ?

Can you  share the rule that you are using to read the password, and also a level 3 trace showing a full transaction containing the rule being executed please?

[Andi Spoerri]

The Driver is running with several ACL's that give exact the rights it needs. Everything works except the password. so I made this testpwread which is also a security equivalence of the driver.

Here is a trace level 3 of the policy I try to get the password working. I first log the password from the operation attribute which i want to use and then i trace the source password to double check on it. When i do the same thing with assigning admin rights to the User (testpwread) both log entries show the correct password.

What I noticed is, that on the password policy i can add a user that i can add under the "Allow the following user to retrieve passwords" when i save that option gets unselected (the user stays in the list).

Here is the Trace level 3

14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST:Applying policy: lib-base-sub-ctp-user-password.
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Applying to modify #1.
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Evaluating selection criteria for rule 'Break if no User'.
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: (if-class-name not-equal "User") = FALSE.
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Rule rejected.
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Evaluating selection criteria for rule 'tmp - log password'.
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Rule selected.
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Applying rule 'tmp - log password'.
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Action: do-trace-message(color="green",level="0",token-op-attr("nspmDistributionPassword")).
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: arg-string(token-op-attr("nspmDistributionPassword"))
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: token-op-attr("nspmDistributionPassword")
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Token Value: "".
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Arg Value: "".
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST:
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Action: do-trace-message(color="red",level="0",token-src-attr("nspmDistributionPassword")).
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: arg-string(token-src-attr("nspmDistributionPassword"))
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: token-src-attr("nspmDistributionPassword")
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Query from policy
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: 


DirXML
NetIQ Corporation







14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Pumping XDS to eDirectory.
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Performing operation query for \XXX\data\organizations\0999\users\U18287.
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: --JCLNT-- \XXX\system\idm\ds01\D64-cim-ldap-shp-SHP-D-ALL-E : Duplicating : context = 1021510101, tempContext = 1021510131
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: --JCLNT-- \XXX\system\idm\ds01\D64-cim-ldap-shp-SHP-D-ALL-E : Calling free on tempContext = 1021510131
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Query from policy result
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: 


DirXML
NetIQ Corporation



cn=u18287,ou=users,ou=0999,ou=e,ou=organizations,o=xxxx




14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Token Value: "".
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST: Arg Value: "".
14:58:14 AD28700 Drvrs: D64-cim-ldap-shp-SHP-D-ALL-E ST:

[jimgoodall]

As @geoffc mentions there is a pseudo attribute Password Management that you could grant your user rights to.  I thought (I've been wrong before - always willing to learn!) this attribute was used for granting users permissions to set passwords - but should get you over the line.

You may need to check the "Show all properties in the schema" box to get the attribute to show up.

The password management documentation should set you in the right direction around your password policy settings:

https://www.netiq.com/documentation/password_management33/pwm_administration/data/an4bun5.html

The bit you are after is at the very bottom.

[geoffc]

Jim,

I think the issue was (memories are coming back to me) was that pre eDir 8.8.something, R to Password management meant you could read the password.  Then post 8.8.x.something it changed so that R ACL meant you could write to the password. (As well as read it).  Maybe that is what I was remembering.

[geoffc]

There is a Password Management pseudo attribute that you need R or W permissions to.  The meaning of R or W changed in one of the eDir 8.8 patches as I recall. Details are vague in my memory but look for Password Management in the Attribute list when adding an ACL.

[Andi Spoerri]

Hi, I read that part and was thinking, what ACL you need, but it seems like you need read and write access to the ACL attribute. I will test everthing and write back what exactly I configured. So the solution is documented.

Thanks for all the help.

Greetings Andi

[Andi Spoerri · Accepted solution]

Thx to all the people helping me here.

I now have the solution that is working.

you need the have Read and Write permissions to the ACL attribute.

[7#subtree#cn=testpwread,ou=users,o=system#ACL]

as soon as i had this set it worked. Also don't needed to have the user set in the Password Policy to read passwords.

Greetings Andi

[jimgoodall]

Yeah, you might want to reconsider that from a security standpoint though.

You've given your user permissions to write to the ACL attribute on any object within scope.  So depending on the scope, the user can essentially grant himself supervisor rights to whatever he chooses.

Only ever a problem if you get compromised of course.

If that's OK with you, then all well and good.

Cheers

Jim

[Andi Spoerri]

You are right on this one, but I will use a role to assign rights to a driver and the driver will not modify this attri but. So this is fine for me.

The way with the attribute Password Management and the user in the Policy to be able to retrieve Passwords did not work.

As writen in the Documentation [if Allow admin to retrieve passwords is selected, then users that have write privileges on the target object’s ACL attribute can retrieve the target object’s password.] worked here.

If anyone has a way to just get the password with read rights im happy to try this