Bug 1686154
| Summary: | sudorule matching when no host or hostcat set | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Scott Poore <spoore> | ||||
| Component: | sssd | Assignee: | Pavel Březina <pbrezina> | ||||
| Status: | CLOSED ERRATA | QA Contact: | ipa-qe <ipa-qe> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 8.0 | CC: | amore, grajaiya, jhrozek, ksiddiqu, lslebodn, mzidek, pbrezina, rsroka, sgoveas, spoore, tscherf | ||||
| Target Milestone: | rc | Flags: | sgoveas:
mirror+
|
||||
| Target Release: | 8.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | sssd-2.2.0-1.el8 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-11-05 22:34:23 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1682305 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Is the !(memberHost=*) in the ldap search filter below possibly the problem here? Seems like that forces a True where the rest of the filter is false. If I drop that from the search, I can see it returns nothing. This is from the logs: (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipasudorule)(ipaEnabledFlag=TRUE)(|(!(memberHost=*))(hostCategory=ALL)(memberHost=fqdn=rhel8-3.example.com,cn=computers,cn=accounts,dc=example,dc=com)(memberHost=cn=ipaservers,cn=hostgroups,cn=accounts,dc=example,dc=com)(memberHost=cn=hostgrp1,cn=hostgroups,cn=accounts,dc=example,dc=com))(|(cn=sudorule2)))][cn=sudo,dc=example,dc=com]. (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaEnabledFlag] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoOpt] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAs] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsGroup] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberAllowCmd] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberDenyCmd] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberHost] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberUser] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotAfter] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotBefore] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOrder] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cmdCategory] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [hostCategory] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userCategory] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsUserCategory] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsGroupCategory] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsExtUser] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsExtGroup] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsExtUserGroup] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [externalUser] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 79 (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_op_add] (0x2000): New operation 79 timeout 6 (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x5638faa54bd0], connected[1], ops[0x5638faa2fee0], ldap[0x5638faa06cb0] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x5638faa54bd0], connected[1], ops[0x5638faa2fee0], ldap[0x5638faa06cb0] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [ipaUniqueID=ea1491f6-4020-11e9-b545-525400161dcd,cn=sudorules,cn=sudo,dc=example,dc=com]. (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaUniqueID] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaEnabledFlag] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberAllowCmd] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberUser] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [entryUSN] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x5638faa54bd0], connected[1], ops[0x5638faa2fee0], ldap[0x5638faa06cb0] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x2000): Total count [0] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_op_destructor] (0x2000): Operation 79 finished (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [sdap_search_bases_ex_done] (0x0400): Receiving data from base [cn=sudo,dc=example,dc=com] (Wed Mar 6 11:08:26 2019) [sssd[be[example.com]]] [ipa_sudo_fetch_rules_done] (0x0040): Received 1 sudo rules Created attachment 1541592 [details]
sssd logs
There was a patch that addressed the same issue in ldap provider, similar should be done for ipa: https://github.com/SSSD/sssd/commit/47ad0778be72994a2294b2e73cc5c670be6811a7 I'd like to check with sudo maintainers first. Radovan, what is the expected behavior if sudoHost attribute is missing in LDAP? From what I seen in my testing years ago, it should be: - if rule is cn=defaults, then use it even if it does not have sudoHost attribute - if it is any other rule, then require sudoHost attribute Is this correct expectation? (In reply to Pavel Březina from comment #4) > There was a patch that addressed the same issue in ldap provider, similar > should be done for ipa: > https://github.com/SSSD/sssd/commit/47ad0778be72994a2294b2e73cc5c670be6811a7 > > I'd like to check with sudo maintainers first. > > Radovan, what is the expected behavior if sudoHost attribute is missing in > LDAP? From what I seen in my testing years ago, it should be: > - if rule is cn=defaults, then use it even if it does not have sudoHost > attribute > - if it is any other rule, then require sudoHost attribute > > Is this correct expectation? There is no expected behavior because sudoHost is a required attribute of a sudoRole: """ Each attribute listed above should contain a single value, but there may be multiple instances of each attribute type. A sudoRole must contain at least one sudoUser, sudoHost and sudoCommand. """ Thank you. Upstream ticket: https://pagure.io/SSSD/sssd/issue/3980 Upstream PR: https://github.com/SSSD/sssd/pull/770 Upstream ticket: https://pagure.io/SSSD/sssd/issue/3980
master: 3b0ff29
sssd-1-16: e2f00ae
Scott, can you qa_ack the bug so that it gets auto-mirrored to Jira? Verified Using Version : ----------------------------------------------------------- ipa-client-4.8.0-8.module+el8.1.0+3977+ec23ef34.x86_64 ipa-server-4.8.0-8.module+el8.1.0+3977+ec23ef34.x86_64 sssd-ipa-2.2.0-11.el8.x86_64 ----------------------------------------------------------- Test-console logs from given test: comment #17 ----------------------------------------------------------- 2019-08-16T18:39:16+0000 [ci-vm-10-0-154-67.ho] :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2019-08-16T18:39:16+0000 [ci-vm-10-0-154-67.ho] :: Removing hostgroup and verifying from sudo client 2019-08-16T18:39:16+0000 [ci-vm-10-0-154-67.ho] :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2019-08-16T18:39:16+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:16 ] :: [ BEGIN ] :: Running 'ipa sudorule-remove-host sudorule1 --hostgroup=hostgrp1' 2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] Rule name: sudorule1 2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] Enabled: TRUE 2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] Users: user1 2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] Sudo Allow Commands: /bin/mkdir 2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] --------------------------- 2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] Number of members removed 1 2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] --------------------------- 2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:17 ] :: [ PASS ] :: Command 'ipa sudorule-remove-host sudorule1 --hostgroup=hostgrp1' (Expected 0, got 0) 2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:17 ] :: [ BEGIN ] :: Running 'ipa hostgroup-del hostgrp1' 2019-08-16T18:39:19+0000 [ci-vm-10-0-154-67.ho] ---------------------------- 2019-08-16T18:39:19+0000 [ci-vm-10-0-154-67.ho] Deleted hostgroup "hostgrp1" 2019-08-16T18:39:19+0000 [ci-vm-10-0-154-67.ho] ---------------------------- 2019-08-16T18:39:19+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:18 ] :: [ PASS ] :: Command 'ipa hostgroup-del hostgrp1' (Expected 0, got 0) 2019-08-16T18:39:19+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:18 ] :: [ BEGIN ] :: Running 'rm -rf /var/lib/sss/db/*;systemctl restart sssd;sleep 3' 2019-08-16T18:39:22+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:22 ] :: [ PASS ] :: Command 'rm -rf /var/lib/sss/db/*;systemctl restart sssd;sleep 3' (Expected 0, got 0) 2019-08-16T18:39:23+0000 [ci-vm-10-0-154-199.h] *** Current Time: Fri Aug 16 14:39:23 2019 Localwatchdog at: Fri Aug 16 16:26:23 2019 2019-08-16T18:39:29+0000 [ci-vm-10-0-154-67.ho] Password for user1: 2019-08-16T18:39:29+0000 [ci-vm-10-0-154-67.ho] Ticket cache: KCM:0:4273 2019-08-16T18:39:29+0000 [ci-vm-10-0-154-67.ho] Default principal: user1 2019-08-16T18:39:29+0000 [ci-vm-10-0-154-67.ho] Valid starting Expires Service principal 2019-08-16T18:39:29+0000 [ci-vm-10-0-154-67.ho] 08/16/2019 14:39:29 08/17/2019 14:39:29 krbtgt/TESTRELM.TEST 2019-08-16T18:39:29+0000 [ci-vm-10-0-154-67.ho] spawn ssh -l user1 ci-vm-10-0-154-67.testrelm.test 2019-08-16T18:39:34+0000 [ci-vm-10-0-154-67.ho] *** Current Time: Fri Aug 16 14:39:34 2019 Localwatchdog at: Fri Aug 16 16:26:34 2019 2019-08-16T18:39:35+0000 [ci-vm-10-0-154-67.ho] Activate the web console with: systemctl enable --now cockpit.socket 2019-08-16T18:39:35+0000 [ci-vm-10-0-154-67.ho] Last login: Fri Aug 16 14:38:58 2019 from 10.0.154.67 2019-08-16T18:39:35+0000 [ci-vm-10-0-154-67.ho] Could not chdir to home directory /home/user1: No such file or directory 2019-08-16T18:39:35+0000 [ci-vm-10-0-154-67.ho] [user1@ci-vm-10-0-154-67 /]$ sudo -l > /tmp/sudo_list_client_27703.out 2>&1 2019-08-16T18:39:35+0000 [ci-vm-10-0-154-67.ho] [sudo] password for user1: 2019-08-16T18:39:37+0000 [ci-vm-10-0-154-67.ho] [user1@ci-vm-10-0-154-67 /]$ 2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho] Connected to ci-vm-10-0-154-67.testrelm.test. 2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho] Fetching /tmp/sudo_list_client_27703.out to /tmp/sudo_list.out 2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho] ---- [/tmp/sudo_list.out] ---- 2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho] | Sorry, user user1 may not run sudo on ci-vm-10-0-154-67. 2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho] ------------------------------ 2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho] ---- [/tmp/sudo_list.out] ---- 2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho] | Sorry, user user1 may not run sudo on ci-vm-10-0-154-67. 2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho] ------------------------------ 2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:47 ] :: [ PASS ] :: File '/tmp/sudo_list.out' should contain 'Sorry, user user1 may not run sudo on' 2019-08-16T18:39:48+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:47 ] :: [ BEGIN ] :: Running 'ipa sudorule-add-host sudorule1 --hosts=ci-vm-10-0-154-67.testrelm.test' 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] Rule name: sudorule1 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] Enabled: TRUE 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] Users: user1 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] Hosts: ci-vm-10-0-154-67.testrelm.test 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] Sudo Allow Commands: /bin/mkdir 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] ------------------------- 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] Number of members added 1 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] ------------------------- 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:48 ] :: [ PASS ] :: Command 'ipa sudorule-add-host sudorule1 --hosts=ci-vm-10-0-154-67.testrelm.test' (Expected 0, got 0) 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] :: Duration: 32s 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] :: Assertions: 5 good, 0 bad 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] :: RESULT: PASS (Removing hostgroup and verifying from sudo client) 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] ** Removing-hostgroup-and-verifying-from-sudo-client PASS Score:0 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] use_pty:FALSE /usr/share/restraint/plugins/run_task_plugins /usr/share/restraint/plugins/run_plugins 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] <no matches> 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] Uploading avc.log 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] .done 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] Uploading resultoutputfile.log 2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] .done Based On this marking bz as verified. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:3651 |
Description of problem: An IPA User is allowed to use sudo via a rule even if hostcat is not set and no host or hostgroup is specified. [root@rhel8-3 sssd]# ipa sudorule-find --all -------------------- 2 Sudo Rules matched -------------------- dn: ipaUniqueID=3a149d22-401c-11e9-a1d8-525400161dcd,cn=sudorules,cn=sudo,dc=example,dc=com Rule name: sudorule1 Enabled: TRUE Users: user1 External host: test.example.com Sudo Allow Command Groups: sudogrp1 Sudo Option: !authenticate ipauniqueid: 3a149d22-401c-11e9-a1d8-525400161dcd objectclass: ipaassociation, ipasudorule dn: ipaUniqueID=ea1491f6-4020-11e9-b545-525400161dcd,cn=sudorules,cn=sudo,dc=example,dc=com Rule name: sudorule2 Enabled: TRUE Users: user2 Sudo Allow Command Groups: sudogrp1 ipauniqueid: ea1491f6-4020-11e9-b545-525400161dcd objectclass: ipaassociation, ipasudorule ---------------------------- Number of entries returned 2 ---------------------------- [root@rhel8-3 sssd]# !ssh ssh -l user2 $(hostname) Password: Last login: Wed Mar 6 11:08:24 2019 from 192.168.122.83 [user2@rhel8-3 ~]$ sudo -l [sudo] password for user2: Matching Defaults entries for user2 on rhel8-3: !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User user2 may run the following commands on rhel8-3: (root) /bin/mkdir ^^^ Here I expected to see: Sorry, user user2 may not run sudo on rhel8-3. Version-Release number of selected component (if applicable): sssd-client-2.0.0-43.el8.x86_64 How reproducible: Seems consistent. Was seen in a test and was reproduced manually. Steps to Reproduce: 1. Install IPA Server 2. Setup sudorule for user without host/hostgroup ipa user-add user2 --first=f --last=l --password kinit user2 kdestroy -A kinit admin ipa sudorule-add sudorule2 ipa sudocmd-add /bin/mkdir ipa sudocmdgroup-add sudogrp1 --desc=sudogrp1 ipa sudocmdgroup-add-member sudogrp1 --sudocmds=/bin/mkdir ipa sudorule-add-allow-command --sudocmdgroups=sudogrp1 sudorule2 ipa sudorule-add-user sudorule2 --users=user2 3. sudo as user first time without host ssh -l user2 $(hostname) sudo -l 4. Add hostgroup to sudorule and reset sssd ipa hostgroup-add hostgrp1 ipa hostgroup-add-member hostgrp1 --hosts=$(hostname) ipa sudorule-add-host sudorule2 --hostgroup=hostgrp1 systemctl stop sssd; sss_cache -E; systemctl start sssd 5. sudo as user second time with host ssh -l user2 $(hostname) sudo -l 6. remove hostgroup from rule and reset sssd ipa sudorule-remove-host sudorule2 --hostgroup=hostgrp1 systemctl stop sssd; sss_cache -E; systemctl start sssd 7. sudo as user third time with host removed from rule ssh -l user2 $(hostname) sudo -l Actual results: sudo as user third time (7.) works and shows list of commands that are available to run with sudo. Expected results: sudo failed with error message about not permitted. Additional info: It appears that the first time without the host info is the only time that it rejects the attempt. After adding and removing the host, it passes when we expect it to fail.