[Freeipa-users] freeipa / sudo

[Chris Card]

> On 12/10/2014 04:54 PM, Chris Card wrote:
>>
>>
>>>
>>>> On 12/10/2014 12:57 PM, Chris Card wrote:
>>> thanks Martin,
>>>>> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa server and a freeipa client machine.
>>>>> I've set up a user with ssh keys, and can successfully ssh onto the client machine.
>>>>> I'm trying to setup sudo rules so that if the user is in a given user group, then the user can run "sudo su -" on the client to become root.
>>> <snip>
>>>>> [root at fedora21-freeipa log]# ipa hostgroup-show
>>>>> Host-group: cog
>>>>> Host-group: cog
>>>>> Member hosts: ipaclient21.testdomain21.com
>>>>> Member of Sudo rule: All
>>>>> [root at fedora21-freeipa log]# ipa sudorule-show All
>>>>> Rule name: All
>>>>> Enabled: TRUE
>>>>> Command category: all
>>>>> RunAs User category: all
>>>>> RunAs Group category: all
>>>>> User Groups: cog_rw
>>>>> Host Groups: cog
>>>>> Sudo Option: !authenticate
>>>>>
>>>>> but this setup doesn't work, i.e. even though the user is in the user group and the client machine is in the host group, sudo su - fails. Is this a bug, or have I missed something?
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>
>>>> With FreeIPA 4.1.1, client sudo integration should be automatically configured,
>>>> so it should just work, including hostgroups. In your case, I would start with
>>>> investigating
>>>>
>>>> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups
>>>>
>>>> If that does not help, I bet SSSD devs will ask for logs.
>>>>
>>> I've done the troubleshooting steps:
>>>
>>> [root at ipaclient21 log]# nisdomainname
>>> testdomain21.com
>>> [root at ipaclient21 log]# getent netgroup cog
>>> cog (ipaclient21.testdomain21.com,-,testdomain21.com)
>>>
>>> I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, but I'm not sure if that's the right file (it didn't exist before).
>>> I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.
>>
>> I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but I created /etc/sssd.conf with a line
>>
>> Debug sudo /var/log/sudo_debug all at debug
>>
>> and I saw this in the debug output:
>>
>> Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557
>> Dec 10 15:42:57 sudo[10046] val[0]=+cog
>> Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189
>> Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61
>> Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := false
>> Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false
>> Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899
>> Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false
>> Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758
>> Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false
>> Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not
>>
>> The problem is that the hostname command on the client was returning a short hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN the sudo command worked.
>>
>>
>> The short hostname comes from the fact that the client machine is an openstack instance, and that appears to be a feature of openstack instances :(
>
>
> So on the OpenStack instance, even "hostname -f" does not show the FQDN? If
> this is the case, I am not sure what we could do, sudo somehow needs to learn
> the FQDN.
>
I can set up the instance so that hostname -f returns the FQDN, but the only way I can get hostname to return the FQDN is if I explicitly run "hostname <FQDN>"; unfortunately this doesn't survive a reboot.

Chris