With the impending inclusion of the group-merging feature in glibc, it would be extremely handy if we added a simple user experience for the following behavior:
Among other projects, this will be useful to [Cockpit] as noted in this https://trello.com/c/izHSjxHV/209-administer-the-machine-with-domain-admins work-item. It will provide a simplified mechanism for defining administrators of individual machines centrally without requiring the ability to push PolicyKit policy or modify the applications to rely on a different group for access-control.
Stephen, do I understand it correctly that the proposed approach would use existing ID Views feature and it would not require any new functionality on a client(sssd), assuming the glibc extension is implemented.
If I rephrase it, e.g: I understand it that you would like something like (from backend perspective): 1. extend host group entry schema by two new attributes 1. one for defining which local group is "domain administrator" for hosts of the hostgroup 2. one for defining which IPA group should be merged into the group defined by the first attribute 2. add "action" which would create ID views based on the attributes above. The action would be executed e.g. when these attributes of a hostgroup are changed. 3. add attribute to, e.g., ipaconfig to define default value for attribute #1
If so, a further discussion is needed because on IPA meeting it was mentioned that usage of ID views might not be the best approach for solving the use case(local + domain group merging/mapping)
Btw, if the proposed was used, what about different GIDs? It might require a third attribute to define the local group gid so that the merge can happen.
What should be the time scope of it?
Replying to [comment:1 pvoborni]:
Yes. The ID View functionality should already provide all the necessary technical implementation, it's just hard to explain to a user.
If I rephrase it, e.g: I understand it that you would like something like (from backend perspective): 1. extend host group entry schema by two new attributes 1. one for defining which local group is "domain administrator" for hosts of the hostgroup 2. one for defining which IPA group should be merged into the group defined by the first attribute
Yes.
add "action" which would create ID views based on the attributes above. The action would be executed e.g. when these attributes of a hostgroup are changed.
I'm not sure I understand that, but maybe I'm not familiar-enough with the ID View feature. Is it normally applied to individual hosts, and thus would need to be triggered to update when the hostgroup composition changes?
add attribute to, e.g., ipaconfig to define default value for attribute #1
Possibly; I'd want to consult with UXD on that.
Could you go into detail on why? This seems like a good fit for the situation to me.
Right, both the local group name and local group GID must be identical to the one in the host's /etc/group or the merge won't happen.
What should be the time scope of it? The GroupMerging feature is expected to land in Fedora 24/Rawhide as soon as possible (the patch is under review right now). It would be ideal if FreeIPA could support this in time for Fedora 24 Alpha Freeze (2016-02-16).
Adding Alexander to the loop so he can comment on the usage of ID views. In any case I'll raise the topic on devel meeting.
Notes from devel meeting:
Simo: ID views is not a good idea, from performance/deadock POV that is currently with slapi-nis
proposal: use managed_by attribute for the use case, extend sssd, requires investigation for what users the managed_by attr is used. Should not be enabled on upgrade to avoid normal users becoming admins.
In other words UX for the ID views way won't be implemented. Other method is more likely.
Most likely won't be addressed in 4.4 release.
Metadata Update from @sgallagh: - Issue assigned to someone - Issue set to the milestone: Future Releases
This ticket is quite old, but this topic came up again in a recent discussion in Brno (Cockpit+security teams). The glibc "merge" support landed two years ago, but apparently the FreIPA admins@realm group does not currently (Fedora 28) get mapped to the wheel (or any other) local group, so that sudo/polkit still don't work out of the box. Is this feature still on the roadmap? Or is it already working, and needs to be turned on somewhere?
admins@realm
wheel
Ideally this would work without Cockpit's involvement (as part of realm join), as Cockpit does (and should) not have its own authentication magic, but simply rely on the usual NSS/kerberos/ssh auth methods. But I wonder if I'm missing something here.
realm join
Thanks!
I don't think we want to have it done by default. Instead, we'd like to see a polkit improved here. In FreeIPA we rely on HBAC rules on defining access permissions on the client systems where HBAC rules are enforced by pam_sss.
polkit uses PAM but it hard-codes own operations to be done as a single 'polkit-1' PAM service. As result, SSSD can grant access to 'polkit-1' HBAC service but that would be too wide: all polkitd-using apps get allowed instead of a specific one.
If polkit could run pam_acct_mgmt() with a more specific PAM service name, we could get fine-tuned HBAC rules to handle this access. The name, perhaps, could be based on a polkit action id with 'polkit-' prepended.
pam_acct_mgmt()
Metadata Update from @abbra: - Issue close_status updated to: None
One minor issue limiting us to propose this to polkit is that PAM library itself is a bit inflexible in this area: if you'd want to utilize something like 'polkit-org.freedesktop.policykit.exec' as a PAM service name (that would be our HBAC rule name), then you'd need to have /etc/pam.d/polkit-org.freedesktop.policykit.exec config file too. Such config file would typically be a symlink to a system-auth but it would be a lot of unnecessary symlinking.
Perhaps, we could cooperate with polkit on them setting a PAM variable with an action ID and pam_sss looking at that to automatically derive HBAC rule name...
As you can see, this needs further design and discussion outside of FreeIPA.
If the intention is to not always/implicitly just add admins@ to the wheel/admin group, then supposedly some configuration needs to be created at realm join time. This could be an /etc/polkit-1/rules.d/60-admins-REALMNAME.rules which calls polkit.addAdminRule for the corresponding IPA group (such as admins@realm.name), and a corresponding /etc/sudoers.d/ snippet, so that sudo works as well (which is muuuch more common on the command line than pkexec).
polkit.addAdminRule
admins@realm.name
/etc/sudoers.d/
But if that's the intent, then what was the purpose of that glibc merge patch? I thought that was meant to dynamically extend the members of wheel and avoid introducing a second admin group.
On normal IPA clients no configuration would be needed at all if what I proposed would happen. All you'd need to do is to create an HBAC rule that allows access of members of admins group to cockpit service via polkit. This is an action to be done centrally (and by default is not needed if allow_all HBAC rule is enabled on), not on each client.
Same with sudo, this is done centrally in FreeIPA, no need to perform any local configuration.
As to glibc merge feature, this is not for wheel cases only. Yes, you can use it for that but there are more use cases than just a wheel group. Again, we do not configure it by default because it is part of how administrators decide to set up their enrolment.
@abbra : Did I understand this correctly: You are saying that this is not currently possible, and this ticket is about making FreeIPA HBAC rules being able to configure sudo/polkit? I've checked various documentation [1][2][3], and don't see how with current FreeIPA I can enable sudo or polkit for admins@my.realm members on a host without manual sudo/polkit configuration. Right now HBAC rules are an additional way to disallow sudo/polkit service for IPA centrally managed users, but apparently cannot replace the per-host wheel group management?
Or am I missing something?
[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/hbac-configure-domain#hbac-rules-examples [2] https://www.freeipa.org/page/Howto/FreeIPA_PolicyKit [3] https://www.freeipa.org/page/Howto/HBAC_and_allow_all
HBAC rule that allows access of members of admins group to cockpit service via polkit
BTW, this is misleading. There is no "cockpit service" in this scenario (or in general) - Cockpit sessions have exactly the same privileges like ssh or VT logins, they are "just another" Linux session (also in the sense of systemd-logind). So what I'm trying here:
[admin@cockpit.lan@x0 ~]$ id uid=395000000(admin@cockpit.lan) gid=395000000(admins@cockpit.lan) groups=395000000(admins@cockpit.lan) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [admin@cockpit.lan@x0 ~]$ sudo whoami [sudo] password for admin@cockpit.lan: admin@cockpit.lan is not allowed to run sudo on x0. This incident will be reported.
(Same with pkexec). I'm trying to find out what to do to allow sudo/pkexec for the IPA managed admins@my.realm members to use sudo/pkexec in the same way as the locally managed wheel group. Whether the wheel group is centrally managed by FreeIPA, or sudo/polkit be told about a new admin group (like admins@my.realm) should not matter that much.
admins@my.realm
You definitely can enable sudo to work for you, no problem. What I was saying is that anything that uses polkit will need cooperation from the polkit side's use of pam to have HBAC rules set up properly for the same.
For sudo to work with centralized rules you need: - enable access to sudo/sudo-l via HBAC on this host for this user/group - set up proper sudo rules in FreeIPA that would be allowed for this user/group
The first part is enabled by default with HBAC allow_all rule. If admins disable it (as they typically do), explicit HBAC rules need to be added to allow other services to be accessible.
[root@nyx ~]# ipa sudorule-add whoami-rule ----------------------------- Added Sudo Rule "whoami-rule" ----------------------------- Rule name: whoami-rule Enabled: TRUE [root@nyx ~]# ipa sudocmd-add `which whoami` ------------------------------------ Added Sudo Command "/usr/bin/whoami" ------------------------------------ Sudo Command: /usr/bin/whoami [root@nyx ~]# ipa sudorule-add-allow-command whoami-rule --sudocmds /usr/bin/whoami Rule name: whoami-rule Enabled: TRUE Sudo Allow Commands: /usr/bin/whoami ------------------------- Number of members added 1 ------------------------- [root@nyx ~]# su - admin Last login: Fri Apr 27 21:49:18 CEST 2018 on pts/0 [admin@nyx ~]$ sudo whoami We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. [sudo] password for admin: root [admin@nyx ~]$ sudo whoami root
In order to get polkit to recognize IPA admins as members of wheel group, three things needs to be done: - you need to create wheel group in IPA and make admins group a member of it - you need to enable initgroups: files sss in /etc/nsswitch.conf - you need to restart polkit service so that glibc re-reads /etc/nsswitch.conf for that process
admins
initgroups: files sss
/etc/nsswitch.conf
When I did that, I was able to choose identities for authentication from all users that belong to wheel group in my setup:
[root@nyx ~]# ipa group-add wheel ------------------- Added group "wheel" ------------------- Group name: wheel GID: 1536000078 [root@nyx ~]# ipa group-add-member wheel --groups=admins Group name: wheel GID: 1536000078 Member groups: admins Indirect Member users: admin, simo Indirect Member groups: ad-admins-external ------------------------- Number of members added 1 ------------------------- [root@nyx ~]# su - admin Last login: Fri Mar 3 21:49:09 CET 2017 from YYYYYY on pts/1 [admin@nyx ~]$ id admin uid=1536000000(admin) gid=1536000000(admins) groups=1536000000(admins),1536000078(wheel) [admin@nyx ~]$ pkexec whoami ==== AUTHENTICATING FOR org.freedesktop.policykit.exec ==== Authentication is needed to run `/usr/bin/whoami' as the super user Multiple identities can be used for authentication: 1. Administrator (admin) 2. Omis Ecro (omis) 3. YO! (omis@ad.ipa.cool) 4. foo 4 (ab@ad.ipa.cool) 5. FooIsBar (administrator@ad.ipa.cool) Choose identity to authenticate as (1-5): 1 Password: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie ==== AUTHENTICATION FAILED ==== Error executing command as another user: Not authorized This incident has been reported. .... Apr 27 22:03:32 nyx.xs.ipa.cool polkitd[29027]: Registered Authentication Agent for unix-process:28903:2961789 (system bus name :1.95 [pkexec whoami], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) Apr 27 22:05:20 nyx.xs.ipa.cool polkit-agent-helper-1[29054]: pam_sss(polkit-1:auth): authentication success; logname= uid=1536000000 euid=0 tty= ruser=admin rhost= user=admin Apr 27 22:05:20 nyx.xs.ipa.cool audit[29054]: USER_AUTH pid=29054 uid=1536000000 auid=0 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_succeed_if,pam_succeed_if,pam_sss acct="admin" exe="/usr/lib/polkit-1/polkit-agent-helper-1" hostname=nyx.xs.ipa.cool addr=? terminal=pts/0 res=success' Apr 27 22:05:20 nyx.xs.ipa.cool audit[29054]: USER_ACCT pid=29054 uid=1536000000 auid=0 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit acct="admin" exe="/usr/lib/polkit-1/polkit-agent-helper-1" hostname=nyx.xs.ipa.cool addr=? terminal=pts/0 res=success' Apr 27 22:05:20 nyx.xs.ipa.cool polkitd[29027]: Operator of unix-process:28903:2961789 FAILED to authenticate to gain authorization for action org.freedesktop.policykit.exec for unix-process:28903:2961789 [-bash] (owned by unix-user:admin) Apr 27 22:05:20 nyx.xs.ipa.cool pkexec[29040]: admin: Error executing command as another user: Not authorized [USER=root] [TTY=/dev/pts/0] [CWD=/home/admin] [COMMAND=/usr/bin/whoami] Apr 27 22:05:20 nyx.xs.ipa.cool polkitd[29027]: Unregistered Authentication Agent for unix-process:28903:2961789 (system bus name :1.95, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
As you can see, SSSD did authenticate the user admin properly and did actually pass accounting step too (which is where pam_sss runs HBAC rules check, I have allow_all rule enabled). But polkit failed to understand that and failed my access.
I'm not sure why polkit fails (may be this is due to su - admin not creating actual session?) but the rest seems to work well once you set it up. We don't set it up by default to have admins a part of wheel group but this is left for admins to define in they specific environment.
su - admin
Thanks @abbra for pointing out the tools! Based on your answer and a similar ServerFault question, this now works for enabling sudo:
ipa sudorule-add --hostcat=all --cmdcat=all All ipa sudorule-add-user --groups=admins All sudo systemctl restart sssd
As for polkit, I'm getting a similar error as you, except that pam_sss auth also seems to fail:
pam_unix(polkit-1:auth): authentication failure; logname= uid=395000000 euid=0 tty= ruser=admin rhost= user=admin pam_sss(polkit-1:auth): authentication failure; logname= uid=395000000 euid=0 tty= ruser=admin rhost= user=admin pam_sss(polkit-1:auth): received for user admin: 4 (System error)
I am running a full logind session here, I logged into that machine right as the IPA user (ssh -l admin@cockpit.lan 127.0.0.2). So that's not it. But making sudo work is already a big step forward, I'll add that example and some pointers to Cockpit's documentation. Thank you!
ssh -l admin@cockpit.lan 127.0.0.2
ipa group-add-member wheel --groups=admins
This actually only creates an IPA wheel@realm group, but doesn't automatically attach the real local wheel group to the user:
wheel@realm
$ id uid=395000000(admin@cockpit.lan) gid=395000000(admins@cockpit.lan) groups=395000000(admins@cockpit.lan),395000001(wheel@cockpit.lan) $ getent group wheel wheel: x:10:admin
As this is a completly unrelated group to the local wheel group, this approach doesn't really work, I'm afraid. In other words, what's necessary is to centrally manage the real groups in sssd/IPA, not a completely separate tree? Alternatively, joining an IPA domain would need to set up parallel configuration files for sudoers.d/ and a polkit admin rule to include that parallel admins@DOMAIN group.
I figure that circles back to the original intent of this ticket - I feel that there is some connection or at least documentation missing here.
I think your issue is that you are using fully qualified domain for IPA users, thus 'wheel' in IPA is not a 'wheel' locally because for the system the former group looks 'wheel@cockpit.lan', not 'wheel'.
This is not a default configuration for IPA clients, though.
Another point is that group merging happens at initgroups step, e.g. with the calls covered by /etc/nsswitch.conf's initgroups statement. Do you have that part modified?
Group enumeration like getent group wheel does not use initgroups interface and thus only picks up group members from a single place, I guess. Initgroups codepath is applied when an application calls getgrouplist() call for a specific user.
getent group wheel
getgrouplist()
I think your issue is that you are using fully qualified domain for IPA users,
OK, if that is not intended then I'll adjust cockpit's tests and my experiments accordingly; I'll follow up here. This predates my by a long time, so I'm afraid I don't know why it was done that way.
/etc/nsswitch.conf's initgroups statement. Do you have that part modified?
Yes, like in your comment above: initgroups: files sss
I think your issue is that you are using fully qualified domain for IPA users
How would I change that? As far as I can see, we have no particular option related to that on the server.
On the client, I create a completely new user:
# echo foobar | ipa user-add --first=Martin --last=Pitt --password martin # ipa group-add-member --users martin admins # ipa user-show martin User login: martin First name: Martin Last name: Pitt Home directory: /home/martin Login shell: /bin/sh Principal name: martin@COCKPIT.LAN Principal alias: martin@COCKPIT.LAN Email address: martin@cockpit.lan UID: 953000003 GID: 953000003 Account disabled: False Password: True Member of groups: ipausers, admins Kerberos keys available: True
I can refer to it with the full qualification, but not as "short" user name:
# id martin id: ‘martin’: no such user # id martin@cockpit.lan uid=953000003(martin@cockpit.lan) gid=953000003(martin@cockpit.lan) groups=953000003(martin@cockpit.lan),953000000(admins@cockpit.lan)
As expected there is no local user (grep martin /etc/passwd /etc/shadow is empty), and nsswitch.conf looks as expected, I only added the initgroups:
grep martin /etc/passwd /etc/shadow
nsswitch.conf
initgroups
passwd: sss files systemd shadow: files sss group: sss files systemd initgroups: files sss
I read through the IPA documentation, including the user authentication part, and this isn't mentioned at all. The closest related page is Testing Client Installation for the admin user, but that exhibits the same behaviour.
admin
Note that sometimes sss_cache -E helped to recognize users at all, but it doesn't help to recognize short ones.
sss_cache -E
What is your sssd configuration on the client?
Oh, I know! When I use ipa-client-install directly, then the unqualified user names work. With that, realm list shows login-formats: %U. But when using realmd to join the domain (realm join COCKPIT.LAN), then it shows login-formats: %U@cockpit.lan instead. This does look like the culprit. So I suppose if the intention is to use unqualified names by default, then realmd should do that as well? Unfortunately realm join has no related option for that, the only way is to edit use_fully_qualified_names = False in /etc/sssd/sssd.conf (but that's not something Cockpit should do - this should be consistent with CLI behaviour).
ipa-client-install
realm list
login-formats: %U
realm join COCKPIT.LAN
login-formats: %U@cockpit.lan
use_fully_qualified_names = False
After changing that, realm list then shows login-formats: %U, and things start to work more sensibly:
# echo foobar | ipa user-add --first=Martin --last=Pitt --password martin # ipa group-add-member --users martin admins # ipa group-add wheel # ipa group-add-member wheel --groups=admins # ipa user-show martin|grep group Member of groups: admins, ipausers Indirect Member of group: wheel # id martin uid=953000001(martin) gid=953000001(martin) groups=953000001(martin),953000003(wheel),953000000(admins)
I can now ssh into the machine as martin@127.0.0.2 and get
martin@127.0.0.2
$ id uid=953000001(martin) gid=953000001(martin) groups=953000001(martin),953000000(admins),953000003(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ sudo whoami [sudo] password for martin: root
and I get exactly the same polkit error like you:
$ pkexec whoami ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === Authentication is needed to run `/usr/bin/whoami' as the super user Multiple identities can be used for authentication: 1. Martin Pitt (martin) 2. Administrator (admin) Choose identity to authenticate as (1-2): 1 Password: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie ==== AUTHENTICATION FAILED ===
There is no corresponding bugzilla about use_fully_qualified_names or against realmd, so I'll file one.
I filed https://bugzilla.redhat.com/show_bug.cgi?id=1575538 now. @abbra, I didn't find an email address of your's, so please feel free to subscribe yourself there. Thanks!
FTR, everything on the command line and in Cockpit is now working as expected, with the gotchas below. I created two new cockpit test cases to verify that.
Summary of the three issues that break this experience in the current releases:
Cockpit (up to version 167) relies on the wheel/sudo group to offer administrative actions. This gets fixed in PR#9127. Thus the above wheel group hack is not necessary any more.
sudo
FreeIPA should configure sudo to work out of the box for FreeIPA admins members. I filed #7538 about this, and added that to the tests above (and will document it as well).
realmd enables the use_fully_qualified_names option by default, while ipa-client-install doesn't. This is confusing and inconsistent, I filed this as rhbz#1575538. The above tests now cover both scenarios (with qualified and unqualified user names).
use_fully_qualified_names
Thanks again @abbra for helping me through this!
Log in to comment on this ticket.