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]:

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.

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.

1. 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?

1. add attribute to, e.g., ipaconfig to define default value for attribute #1
   

Possibly; I'd want to consult with UXD on that.

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)

Could you go into detail on why? This seems like a good fit for the situation to me.

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.

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.

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?

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.

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.

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).

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?

Thanks!

[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.

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

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.

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!

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:

$ 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.

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

Thanks!

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:

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.

Note that sometimes sss_cache -E helped to recognize users at all, but it doesn't help to recognize short ones.

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).

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

$ 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.

• 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).

Thanks again @abbra for helping me through this!