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.