On 21.01.25 11:54, Ronald Wimmer via FreeIPA-users wrote:
On 14.01.25 13:06, Ronald Wimmer via FreeIPA-users wrote:
What would be the best way to do this?
Remove "System: Change User password" permissions?
The plan I had in my mind was to add a usergroup and remove this exact permission for this group. But it seems like that only adding permissions is possible for a user group.
How could I accomplish removing "System: Change user password" permissions for a specific user group? Or is there an alternative approach to do that?
Cheers, Ronald
Ronald Wimmer via FreeIPA-users wrote:
On 21.01.25 11:54, Ronald Wimmer via FreeIPA-users wrote:
On 14.01.25 13:06, Ronald Wimmer via FreeIPA-users wrote:
What would be the best way to do this?
Remove "System: Change User password" permissions?
The plan I had in my mind was to add a usergroup and remove this exact permission for this group. But it seems like that only adding permissions is possible for a user group.
Correct. You can only add access, not take it away. Doing deny ACLs becomes very complicated very fast and troubleshooting it requires a wizard.
How could I accomplish removing "System: Change user password" permissions for a specific user group? Or is there an alternative approach to do that?
You can try excluding the group from the permission via targetfilter. Something like this using the --filter or --rawfilter options:
(targetfilter = "(&(!(memberOf=cn=no_passwords,cn=groups,cn=accounts,dc=example,dc=test)))"
See System: Remove Users as an example. In this ACI you can't delegate a user to be able to delete an admin.
If you run ipa permission-show with the --raw option you can see the actual ACI produced.
rob
On 12.02.25 14:34, Rob Crittenden via FreeIPA-users wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 21.01.25 11:54, Ronald Wimmer via FreeIPA-users wrote:
On 14.01.25 13:06, Ronald Wimmer via FreeIPA-users wrote:
What would be the best way to do this?
Remove "System: Change User password" permissions?
The plan I had in my mind was to add a usergroup and remove this exact permission for this group. But it seems like that only adding permissions is possible for a user group.
Correct. You can only add access, not take it away. Doing deny ACLs becomes very complicated very fast and troubleshooting it requires a wizard.
How could I accomplish removing "System: Change user password" permissions for a specific user group? Or is there an alternative approach to do that?
You can try excluding the group from the permission via targetfilter. Something like this using the --filter or --rawfilter options:
(targetfilter = "(&(!(memberOf=cn=no_passwords,cn=groups,cn=accounts,dc=example,dc=test)))"
See System: Remove Users as an example. In this ACI you can't delegate a user to be able to delete an admin.
If you run ipa permission-show with the --raw option you can see the actual ACI produced.
Thanks! Got it!
I modified the attribute ipapermtargetfilter of
DN: cn=System: Change User password,cn=permissions,cn=pbac,dc=linux,dc=mydomain,dc=at to (&(!(memberOf=cn=iam-managed-users,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at))(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at)))
but it did not work as expected. Do I have to explicitly assign this particular permission to a users group? (I thought that every users in IPA has this particular perm by default?)
Cheers Ron
On 12.02.25 16:02, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.25 14:34, Rob Crittenden via FreeIPA-users wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 21.01.25 11:54, Ronald Wimmer via FreeIPA-users wrote:
On 14.01.25 13:06, Ronald Wimmer via FreeIPA-users wrote:
What would be the best way to do this?
Remove "System: Change User password" permissions?
The plan I had in my mind was to add a usergroup and remove this exact permission for this group. But it seems like that only adding permissions is possible for a user group.
Correct. You can only add access, not take it away. Doing deny ACLs becomes very complicated very fast and troubleshooting it requires a wizard.
How could I accomplish removing "System: Change user password" permissions for a specific user group? Or is there an alternative approach to do that?
You can try excluding the group from the permission via targetfilter. Something like this using the --filter or --rawfilter options:
(targetfilter = "(&(!(memberOf=cn=no_passwords,cn=groups,cn=accounts,dc=example,dc=test)))"
See System: Remove Users as an example. In this ACI you can't delegate a user to be able to delete an admin.
If you run ipa permission-show with the --raw option you can see the actual ACI produced.
Thanks! Got it!
More specifics would help. How did it not work as expected? What is the full ACI you came up with?
The idea is that this is granted to all authenticated users EXCEPT those in the, in your case, iam-managed-users and admins groups.
rob
Ronald Wimmer via FreeIPA-users wrote:
I modified the attribute ipapermtargetfilter of
DN: cn=System: Change User password,cn=permissions,cn=pbac,dc=linux,dc=mydomain,dc=at to (&(!(memberOf=cn=iam-managed-users,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at))(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at)))
but it did not work as expected. Do I have to explicitly assign this particular permission to a users group? (I thought that every users in IPA has this particular perm by default?)
Cheers Ron
On 12.02.25 16:02, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.25 14:34, Rob Crittenden via FreeIPA-users wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 21.01.25 11:54, Ronald Wimmer via FreeIPA-users wrote:
On 14.01.25 13:06, Ronald Wimmer via FreeIPA-users wrote:
What would be the best way to do this?
Remove "System: Change User password" permissions?
The plan I had in my mind was to add a usergroup and remove this exact permission for this group. But it seems like that only adding permissions is possible for a user group.
Correct. You can only add access, not take it away. Doing deny ACLs becomes very complicated very fast and troubleshooting it requires a wizard.
How could I accomplish removing "System: Change user password" permissions for a specific user group? Or is there an alternative approach to do that?
You can try excluding the group from the permission via targetfilter. Something like this using the --filter or --rawfilter options:
(targetfilter = "(&(!(memberOf=cn=no_passwords,cn=groups,cn=accounts,dc=example,dc=test)))"
See System: Remove Users as an example. In this ACI you can't delegate a user to be able to delete an admin.
If you run ipa permission-show with the --raw option you can see the actual ACI produced.
Thanks! Got it!
On 12.02.25 19:15, Rob Crittenden wrote:
More specifics would help. How did it not work as expected? What is the full ACI you came up with?
The idea is that this is granted to all authenticated users EXCEPT those in the, in your case, iam-managed-users and admins groups.
We did not user RBAC much up to now. So it is very likely that I did not fully grasp the whole concept yet.
What I did was adding users to a group called cn=iam-managed-users,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at and modifying the target filter to (&(!(memberOf=cn=iam-managed-users,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at))(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at))).
Nothing else. Because I thought the "System: Change User" permission applies to all IPA users by default. This assumption might probably be wrong...
Ronald Wimmer wrote:
On 12.02.25 19:15, Rob Crittenden wrote:
More specifics would help. How did it not work as expected? What is the full ACI you came up with?
The idea is that this is granted to all authenticated users EXCEPT those in the, in your case, iam-managed-users and admins groups.
We did not user RBAC much up to now. So it is very likely that I did not fully grasp the whole concept yet.
What I did was adding users to a group called cn=iam-managed-users,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at and modifying the target filter to (&(!(memberOf=cn=iam-managed-users,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at))(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at))).
Nothing else. Because I thought the "System: Change User" permission applies to all IPA users by default. This assumption might probably be wrong...
It is controlled by 'Self can write own password'
$ ipa selfservice-show 'Self can write own password' Self-service name: Self can write own password Permissions: write Attributes: userpassword, krbprincipalkey, sambalmpassword, sambantpassword
aci: (targetattr = "userpassword || krbprincipalkey || sambalmpassword || sambantpassword")(version 3.0; acl "selfservice:Self can write own password"; allow (write) userdn="ldap:///self";)
rob
On 13.02.25 17:42, Rob Crittenden wrote:
Ronald Wimmer wrote:
On 12.02.25 19:15, Rob Crittenden wrote:
More specifics would help. How did it not work as expected? What is the full ACI you came up with?
The idea is that this is granted to all authenticated users EXCEPT those in the, in your case, iam-managed-users and admins groups.
We did not user RBAC much up to now. So it is very likely that I did not fully grasp the whole concept yet.
What I did was adding users to a group called cn=iam-managed-users,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at and modifying the target filter to (&(!(memberOf=cn=iam-managed-users,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at))(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at))).
Nothing else. Because I thought the "System: Change User" permission applies to all IPA users by default. This assumption might probably be wrong...
It is controlled by 'Self can write own password'
$ ipa selfservice-show 'Self can write own password' Self-service name: Self can write own password Permissions: write Attributes: userpassword, krbprincipalkey, sambalmpassword, sambantpassword
aci: (targetattr = "userpassword || krbprincipalkey || sambalmpassword || sambantpassword")(version 3.0; acl "selfservice:Self can write own password"; allow (write) userdn="ldap:///self";)
ipapermtargetfilter: (&(!(memberOf=cn=iam-managed-users,cn=groups,cn=accounts,dc=ipatest,dc=mydomain,dc=at))(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=ipatest,dc=mydomain,dc=at))) ipapermissiontype: SYSTEM ipapermissiontype: V2 ipapermissiontype: MANAGED aci: (targetattr = "krbpasswordexpiration || krbprincipalkey || passwordhistory || sambalmpassword || sambantpassword || userpassword")(targetfilter = "(&(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=ipatest,dc=mydomain,dc=at))(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=ipatest,dc=mydomain,dc=at";)
Modifying the ipapermtargetfilter (manually in LDAP) did not produce the aci I was expecting. Do I have to modify it by IPA API means (eg. CLI?) or did I modify the wrong attribute?
Cheers, Ronald
Ronald Wimmer wrote:
On 13.02.25 17:42, Rob Crittenden wrote:
Ronald Wimmer wrote:
On 12.02.25 19:15, Rob Crittenden wrote:
More specifics would help. How did it not work as expected? What is the full ACI you came up with?
The idea is that this is granted to all authenticated users EXCEPT those in the, in your case, iam-managed-users and admins groups.
We did not user RBAC much up to now. So it is very likely that I did not fully grasp the whole concept yet.
What I did was adding users to a group called cn=iam-managed-users,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at and modifying the target filter to (&(!(memberOf=cn=iam-managed-users,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at))(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at))).
Nothing else. Because I thought the "System: Change User" permission applies to all IPA users by default. This assumption might probably be wrong...
It is controlled by 'Self can write own password'
$ ipa selfservice-show 'Self can write own password' Self-service name: Self can write own password Permissions: write Attributes: userpassword, krbprincipalkey, sambalmpassword, sambantpassword
aci: (targetattr = "userpassword || krbprincipalkey || sambalmpassword || sambantpassword")(version 3.0; acl "selfservice:Self can write own password"; allow (write) userdn="ldap:///self";)
ipapermtargetfilter: (&(!(memberOf=cn=iam-managed-users,cn=groups,cn=accounts,dc=ipatest,dc=mydomain,dc=at))(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=ipatest,dc=mydomain,dc=at)))
ipapermissiontype: SYSTEM ipapermissiontype: V2 ipapermissiontype: MANAGED aci: (targetattr = "krbpasswordexpiration || krbprincipalkey || passwordhistory || sambalmpassword || sambantpassword || userpassword")(targetfilter = "(&(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=ipatest,dc=mydomain,dc=at))(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=ipatest,dc=mydomain,dc=at";)
Modifying the ipapermtargetfilter (manually in LDAP) did not produce the aci I was expecting. Do I have to modify it by IPA API means (eg. CLI?) or did I modify the wrong attribute?
This is the wrong permission. This handles who can change someone else's password. To manage who can change their own you have to modify 'Self can write own password' via the selfservice plugin.
rob
freeipa-users@lists.fedorahosted.org
-
Rob Crittenden -
Ronald Wimmer