On Wed, 20 Apr 2016, Tiemen Ruiten wrote:
Thanks Alexander, that got my past that error.
I created the sysaccount and I can bind successfully, but in accordance
with the documentation, it doesn't have rights to modify other users:
Unexpected error while testing ldap test user LDAP ⇨ LDAP Directories ⇨
default ⇨ LDAP Test User, error: javax.naming.NoPermissionException: [LDAP:
error code 50 - Insufficient 'write' privilege to the 'userPassword'
attribute of entry
'uid=test.user,cn=users,cn=accounts,dc=ipa,dc=rdmedia,dc=com'. ]
This LDAP Proxy User will try to do the following things to the LDAP Test
User:
"The following functionality (if enabled) will be tested using the test
user account.
Authentication
Password policy reading
Set password
Set challenge/responses
Load challenge/responses"
What is best practice here, should I grant more privileges to the
sysaccount (how?), or should I create a 'regular' user in the UI/through
the ipa cli and grant the necessary roles there?
Well, the situation is much more complex than you can realise. FreeIPA
does not really tolerate someone else doing password modifications other
than the user herself. FreeIPA password plugin marks the password as
expired if it was modified by someone else.
You can look at http://www.freeipa.org/page/Self-Service_Password_Reset
for more detailed reasoning.
If password reset and forcing it to be marked as 'expired' is OK, a
password change done by PWM would need to be performed by a user with
access to a permission 'System: Change User password'.
FreeIPA has a number of layered concepts for managing access rights:
permission, privilege, and role. They all support group-like granting.
For example, permission for changing user passwords looks like this:
$ ipa permission-show 'System: Change User password'
Permission name: System: Change User password
Granted rights: write
Effective attributes: krbprincipalkey, passwordhistory, sambalmpassword,
sambantpassword, userpassword
Default attributes: userpassword, krbprincipalkey, sambantpassword,
passwordhistory, sambalmpassword
Bind rule type: permission
Subtree: cn=users,cn=accounts,dc=vda,dc=li
Extra target filter: (!(memberOf=cn=admins,cn=groups,cn=accounts,dc=vda,dc=li))
Type: user
Granted to Privilege: User Administrators, Modify Users and Reset passwords
Indirect Member of roles: helpdesk, User Administrator
You can see that permission can be granted to a privilege. A privilege
can be given to a role and LDAP server access controls are based on
these group-like memberships.
The end result is that for 'System: Change User pasword' permission
following LDAP server access control rule is added:
aci: (targetattr = "krbprincipalkey || passwordhistory || sambalmpassword || sambantpassword ||
userpassword")(targetfilter =
"(&(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=ipa,dc=example))(objectclass=posixaccount))")(version
3.0;acl "permission:System: Change User password";allow (write) groupdn = "ldap:///cn=System: Change User
password,cn=permissions,cn=pbac,dc=ipa,dc=example";)
This means only members of the following LDAP group
"cn=System: Change User password,cn=permissions,cn=pbac,dc=ipa,dc=example"
are allowed to modify user passwords.
IPA commands (either in WebUI or command line) don't allow you to add
anything else than users and groups to roles, privileges, and
permissions. If you want to add a sysaccount, you'd need to do so
manually with LDAP tools.
A safer way to do that is to use ipa-ldap-updater tool. Let's say, you
have a sysaccount uid=pwm,cn=sysaccounts,cn=etc,$SUFFIX. Create
following file:
---------------------------------------------------------------------
# 70-add-sysaccount-to-permission.update
dn: cn=System: Change User password,cn=permissions,cn=pbac,$SUFFIX
add:member:uid=pwm,cn=sysaccounts,cn=etc,$SUFFIX
---------------------------------------------------------------------
and run
# ipa-ldap-updater ./70-add-sysaccount-to-permission.update
This would add a new value to attribute 'member' of the 'System: Change
User password' permission.
For more details on ipa-ldap-updater see its man page and my article
https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/
Now that I led you through the pain to see what is under the cover, it
would probably be easier to use IPA user user_pwm and call 'ipa
role-add-member helpdesk --users=pwm_user' to add it to the role.
:)
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
