[Freeipa-users] Distributing user keytabs for non-interactive auth question

[Martin Babinsky]

On 09/26/2016 04:22 AM, Matthew Sellers wrote:
> Hey Mike,
>
> Thanks for the reply.  I did use this originally when deploying my
> 'kerberized' service on my first host.   What I am trying to do is use
> ipa-getkeytab for keytab distribution on say...100 hosts, without
> having to copy around keytabs from host to host.
>
> Since using ipa-getkeytab without the '-r' option just creates a new
> keytab with bumped KVNO ..and.. when I do use '-r' I recieve a message
> for 'Insufficient access rights' I am still fuzzy....
>
> Can ipa-getkeytab be used for mass distribution of user keytabs with
> the -r option?
>
> Thanks Again!
> Matt
>
>
>
> On Sun, Sep 25, 2016 at 9:03 PM, Michael ORourke
> <mrorourke at earthlink.net> wrote:
>> Matt,
>>
>> Try the following...
>>
>> # Get admin TGT
>> kinit admin at REALM.COM
>>
>> # Get keytab for user account
>> ipa-getkeytab -s coipa100 -p cron_runner at REALM.COM -k ipa_cron_runner.keytab
>>
>> # Clear tickets
>> kdestroy
>>
>> # Request TGT using the keytab
>> kinit -k -t ./cron_runner.keytab cron_runner at REALM.COM
>>
>> # List tickets
>> klist
>>
>> I recommend including the username somewhere in the name of the keytab file itself which makes it easier to remember.  Of course be careful with the permissions on the keytab file, because anyone that has read access to the keytab can get a TGT as that user.
>>
>> -Mike
>>
>> -----Original Message-----
>>> From: Matthew Sellers <matt at indigo.nu>
>>> Sent: Sep 25, 2016 8:37 PM
>>> To: freeipa-users at redhat.com
>>> Subject: [Freeipa-users] Distributing user keytabs for non-interactive auth    question
>>>
>>> Hi Guys,
>>>
>>> What is the best way to distribute a 'user' keytab to distribute
>>> keytabs to allow 'system users' to run scripts with non-interactive
>>> auth?  Is it possible to use the ipa-getkeytab feature ( with "-r"
>>> option ) to request a keytab for a user principal?  I see support for
>>> HOST and SERVICE keytabs, but nothing specific to user  keytabs?
>>>
>>> Concept Example:
>>>
>>> ipa-getkeytab -s ipa_server -p cron_runner at REALM.COM -k ipa_cron.keytab -r
>>> KRB5_KTNAME=ipa_cron.keytab service.py
>>>
>>> Actual Results ( tried with tgt for cron_runner or admin ):
>>>
>>> [sysadmin at 01 ~]$ ipa-getkeytab -s coipa100 -p cron_runner at REALM.COM
>>> -kipa_cron.keytab -r
>>> Failed to parse result: Insufficient access rights
>>>
>>> My only other option is grab the keytab and copy it around after
>>> initial creation ( understanding that each keytab requests bumps the
>>> KVNO ).  My goal is to make password-less authentication for automated
>>> processes as easy as possible to setup....ipa-getkeytab seems like its
>>> almost there?
>>>
>>> Love the work you guys are putting out, its a really cool system.
>>>
>>> Thanks,
>>> Matt
>>>
>>> --
>>> Manage your subscription for the Freeipa-users mailing list:
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>> Go to http://freeipa.org for more info on the project
>>
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project
>

The problem is that in order to retrieve an existing Kerberos keys the 
getkeytab extended operation need to be able to read them. The support 
for these permissions is currently implemented for hosts and services 
only (see http://www.freeipa.org/page/V4/Keytab_Retrieval_Management for 
more details).

Maybe you can workaround this by retrieving keytabs as a directory 
manager but then you have to enter directory manager password everywhere.

Also there is a considerable security risk involved in storing user 
keytabs e.g. in their home directories, as anyone who gains privileged 
access to the enrolled machine can then impersonate any user that has a 
keytab stored on it.

-- 
Martin^3 Babinsky