Ronald Wimmer wrote: > > > On 19.02.25 19:37, Rob Crittenden wrote: >> Ronald Wimmer via FreeIPA-users wrote: >>> On 19.02.25 16:40, Rob Crittenden via FreeIPA-users wrote: >>>> Ronald Wimmer via FreeIPA-users wrote: >>>>> On 19.02.25 15:54, Rob Crittenden via FreeIPA-users wrote: >>>>>> Ronald Wimmer wrote: >>>>>>> On 19.02.25 13:48, Rob Crittenden via FreeIPA-users wrote: >>>>>>>> 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. >>>>>>> >>>>>>> I see. But when I remove all the password relevant attributes as an >>>>>>> admin users are still able to change their passwords... >>>>>>> >>>>>> >>>>>> You're saying users that are also admins can change their own >>>>>> passwords? >>>>>> admins are special so there may be additional ACIs involved. >>>>> >>>>> No. My eypectation was that regular users cannot change their >>>>> passwords >>>>> anymore after I removed the password attributes from the selfservice >>>>> permission you named above. >>>> >>>> It is very difficult to help you if you don't show your work. >>>> >>>> What does the selfservice entry look like? >>>> >>>> How are you testing the password change? >>> >>> Sorry. I try to be more specific. Initially I wanted to forbid password >>> change for a certain user group. But now I just wanted to see it working >>> in general. So... the IPA installation is completely unmodified in this >>> regard. >>> >>> What did I try? >>> Taking away all password-related attributes I found in the "Self can >>> write own password" permission. I did this with the IPA admin user. >> >> You still haven't shown the selfservice permission. > > ipa selfservice-show --raw > Self-service name: Self can write own password > aci: (targetattr = "krbprincipalkey")(version 3.0;acl > "selfservice:Self can write own password";allow (write) userdn = > "ldap:///self";) > > >> >> How did you remove all attributes? It should throw an error about >> invalid or missing values. > > Logged into IPA via the WebGUI as admin. Went to IPA Server->RBAC->Self > Service Permissions. Clicked on "Self can write own password". Unchecked > "userpassword". Clicked on "save". Logged out and logged back in as a > non-admin. Tried password change. Worked. (and my expectation was it > should not have worked.) >
krbprincipalkey is also the password, as are all the other attributes in the permission. If you delete the permission then the next upgrade will re-create it so I'd suggest removing all attributes from it and adding something a user already has for themselves, like ipasshpubkey. rob -- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
