FreeIPA: setting polkit / PolicyKit rules for users (make your user a polkit administrator on your clients)

Yup, it's another FreeIPA post!

One thing you might notice if you move your main user account to FreeIPA is that your client systems don't consider the user to be an 'administrator' for polkit (formerly known as PolicyKit) purposes. That is, when you run anything that uses PolicyKit for privilege escalation, you are prompted for the root password, not your user's password.

By default, PolicyKit considers all members of the 'wheel' user group to be administrators. We can see this in /etc/polkit-1/rules.d/50-default.rules:

polkit.addAdminRule(function(action, subject) {
    return ["unix-group:wheel"];
});

If your user is managed exclusively in FreeIPA, they're unlikely to be considered a member of the local system 'wheel' group. My first attempt to fix this involved creating a sort of clone of the 'wheel' group on my FreeIPA server and adding my account to that. This exposed a couple of interesting bugs in polkit but also caused the FreeIPA and polkit devs to break out words like 'completely wrong' and 'idiot', so I don't do that any more. The 'right' way to do it is to create a new group on the FreeIPA server which isn't trying to shadow/copy/override a group on the clients. I called mine 'sysadmins' and let FreeIPA generate one of its extremely high GIDs for it. Add all the user accounts you want to have admin privileges on your client machines to this group.

Then you add a file to /etc/polkit-1/rules.d on all your clients which will be evaluated before 50-default.rules (this is very important - polkit's behaviour is that it evaluates addAdminRule() functions in order until one returns a valid result and then ignores the others, so if your rules file comes after 50-default.rules, it will never take effect) which tells polkit to treat users of that group as administrators instead:

polkit.addAdminRule(function(action, subject) {
    return ["unix-group:sysadmins"];
});

I called mine /etc/polkit-1/rules.d/40-happyassassin.rules, following my own naming policy, but so long as it comes before 50-default.rules you'll be fine. Now any user in the FreeIPA-managed 'sysadmins' group will be considered an admin user by polkit on all systems with that rules file. You can of course use the same group for FreeIPA sudo rules, and then sudo and polkit admin privileges will be managed together.

You could tweak the rules file as you like, of course, and do other stuff with the mechanism. If you have a hybrid setup and you also want users in the local system's wheel group to be considered admins, you'd want the rule to return ["unix-group:sysadmins", "unix-group:wheel"] (I think that's the syntax, anyway). You can set up PolicyKit rules files to grant all sorts of privileges in different cases to different FreeIPA-managed user or group accounts; just remember that it's a bad idea to have collisions between group names and GIDs in FreeIPA and on your local systems, keep them separate.

Of course in a properly-managed domain you'd want to use ansible or Puppet or whatever to distribute the rules file to clients when they're set up.

Comments

Amir Hedayaty wrote on 2014-09-13 18:29:
I was recently setting up FreeIPA for a friend for a lab around 10 computers. Overall, FreeIPA is something I would still recommend. It made the kerberos and LDAP so easy to set up. However, I have some question/suggestion. First, I would like to ask about possiblity of having different sysadmin group per host. What I would like to see is having a different sudoer on different hosts and similarly policykit configured giving permission to different users per hosts. Second, NFS. It is something which seems esntial for a accounting system. However, it should be configured independently. Third, FreeIPA does some help with setting up automount for NFS; however, if domainname and realm are different. It will create buggy configuration.
Amir Hedayaty wrote on 2014-09-13 18:49:
Forgot to mention, another feature is NIS like printer sharing
adamw wrote on 2014-09-13 19:11:
If you check FreeIPA's sudoer configuration it lets you set pretty complex rules for sudo indeed, but if there's some level of control you were missing, I think they'd take a feature request for it. Different PolicyKit rules per host is kind of tricky for now, as FreeIPA doesn't really understand PolicyKit at all - the only way to 'control' it via FreeIPA is with users and groups, that's all the mechanism you have. Best you can do is set up various groups on the FreeIPA server and have different PolicyKit config per host which do different things with different groups, for now. Again, this is something they may be able to add, but of course they have big lists of plans already, like all projects :) I have not tried using NFS at all yet, but it does seem like it can be integrated with FreeIPA, there are docs at e.g. https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/kerb-nfs.html . As I haven't tried it I don't know about any bugs/limitations in this function. It seems interesting, but I just didn't get around to it yet. Same thing with printers; my printer is network aware itself, so I don't manage it via FreeIPA. Sorry I can't help more! I know a couple of folks working on FreeIPA have seen my posts, so perhaps one of them could help, or just poke them on #freeipa on IRC or file feature requests upstream.
Amir Hedayaty wrote on 2014-09-14 00:01:
It was not my first experieced I had some experience with LDAP/NIS. Eventually made them all work. I am telling you like a feedback from a comunity member to someone whose voice might be heard for the roadmap. Reporting bug on doain vs realm issue might help. But I do not see a better way to express about printer/NFS/policy. I like to see the IPA in a state which I can recommend it as a real replaement for AD.
D Jons wrote on 2015-02-13 01:48:
Personally, I think it's kind of pointless to have both sudo and policykit managing user privileges. It just ends up being another thing that wastes countless hours for users and admins trying to figure out why it doesn't work. It also makes it more difficult to manage access controls centrally. In theory, having multiple security methods adds layers and makes systems more secure. In practice, however, it just makes it more confusing for admins to configure, and much more likely that they'll do it wrong. What all too often ends up happening is they just disable everything they can, rather than spending the time to learn how to use all the different access controls. For examaple, it's become almost standard practice to immediately disable SELinux. The concept of it is great, but the reality can get quite painful.
Aditya wrote on 2020-01-22 11:50:
Hi, I am new to FreeIPA i installed the server and client. It is very easy part i can sign in with the user created from IPA server but i am unable to customize rules. My scenario is to i am having approx 70 users i would like to block particular URLs in my network is it possible in FREEIPA? Please suggest