[Freeipa-users] freeipa / sudo

[Martin Kosek]

On 12/11/2014 04:38 PM, Dmitri Pal wrote:
> On 12/11/2014 08:08 AM, Martin Kosek wrote:
>> On 12/11/2014 01:57 PM, Chris Card wrote:
>>>> On 12/11/2014 09:42 AM, Chris Card wrote:
>>>>>> 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.
>>>> You should be able to just set the hostname to /etc/hostname (for older
>>>> platforms, it may also be in /etc/sysconfig/network) and it should survive the
>>>> reboot. I do not think that OpenStack really cares that much what hostname did
>>>> you set up in the system after the VM is created.
>>>>
>>>> At least my OpenStack VM with the FreeIPA demo works this way.
>>>>
>>> I found that simply editing /etc/hostname and rebooting didn't work, because
>>> cloud-init resets the hostname. But if I create the instance with a
>>> cloud-init script to set the hostname to the FQDN, and then reboot the
>>> instance after creation, /etc/hostname contains the FQDN and hostname
>>> returns the FQDN.
>>>
>>> Chris
>> Ah, right. I just remembered I also need to set it up with cloud-init. This is
>> the config I use for the FreeIPA demo:
>>
>> #cloud-config: FreeIPA cloud configuration
>> hostname: ipa.demo1.freeipa.org
>> fqdn: ipa.demo1.freeipa.org
>> manage_etc_hosts: false
>>
> Is it worth a howto? Seems like  a valuable piece of info...

It is, I added a task to my queue about generating howto with this and other 
updates I had to do to make FreeIPA demo run on OpenStack.