Hi all,
Awsome! OK, cannot user "ipaservers" hostgroup, but creating a new one
wil work!
Thanks a lot!
Create a new hostgroup and used that one for the sudorule:
[admin@freeipa1 ~]$ ipa sudorule-show sudo_freeipa_admins
Rule name: sudo_freeipa_admins
Enabled: TRUE
Command category: all
RunAs User category: all
RunAs Group category: all
User Groups: admins
Host Groups: freeipa-servers
The new hostgroup has one momeber: server-group "ipaservers", makes it
easier to manage rather than adding each host:
[admin@freeipa1 ~]$ ipa hostgroup-show freeipa-servers
Host-group: freeipa-servers
Description:
https://pagure.io/freeipa/issue/7284
Member host-groups: ipaservers
Member of Sudo rule: sudo_freeipa_admins
Indirect Member hosts: freeipa2.example.local, freeipa1.example.local
sudo will work now!
[admin@freeipa1 ~]$ sudo -l
Matching Defaults entries for admin on freeipa1:
!visiblepw, always_set_home, match_group_by_gid, 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 admin may run the following commands on freeipa1:
(ALL : ALL) ALL
Rob Crittenden schreef op 05-12-2018 14:04:
> Winfried de Heiden via FreeIPA-users wrote:
>> Hi all,
>>
>> On a brand new install, sudo for hostgroup seems not to work. Ik
>> create
>> a sudo rule for admins, only to to "averything" on all servers within
>> the hostgroup "ipaservers":
>>
>> Rule name: s3_sudo_freeipa_admins
>> Enabled: TRUE
>> Command category: all
>> RunAs User category: all
>> RunAs Group category: all
>> User Groups: admins
>> Host Groups: ipaservers
>>
>> However, user admins is not allowed to to so:
>>
>> admin@freeipa1 <mailto:admin@freeipa1> ~]$ sudo -l
>> [sudo] password for admin:
>> Sorry, user admin may not run sudo on freeipa1.
>>
>> Removing the group but adding the two FreeIPA-servers:
>> Rule name: s3_sudo_freeipa_admins
>> Enabled: TRUE
>> Command category: all
>> RunAs User category: all
>> RunAs Group category: all
>> User Groups: admins
>> Hosts: freeipa1.example.local, freeipa2.example.local
>>
>> After cleaning the sssd-cache:
>>
>> sudo -l
>> [sudo] password for admin:
>> Matching Defaults entries for admin on freeipa1:
>> !visiblepw, always_set_home, match_group_by_gid, 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 admin may run the following commands on freeipa1:
>> (ALL : ALL) ALL
>>
>> There are not clients yet, this issues was reproduced on a brand new
>> CentOS 7.5 IPA installation with no modifications or else...
>>
>> What's hapening here?
>
> This is a bug. ipaservers is treated specially internally, see
>
https://pagure.io/freeipa/issue/7284
>
> rob