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

Tue Sep 27 17:03:41 UTC 2016

Hi Guys,

I found docs on roles and was able to permission my IPA DNS scripts as follows:

ipa role-add "DNS Admin"
ipa role-add-privilege "DNS Admin" --privileges="DNS Administrator"
ipa role-add-member "DNS Admin" --services="buildslave/host.domain.com at REALM.COM

Now I am able to authenticate with this service principal and access
LDAP attributes from IPA as you suggested.   I was a little caught
off-guard as it seems even the built-in 'admin type' roles do not have
access to read DNS ?   Adding this role puts a smile on my face.

ipa-getkeytab -s myipahost  -p buildslave/host.domain.com at REALM.COM -k
/etc/named/ipa_automation.keytab -r
export KRB5_CLIENT_KTNAME=ipa_automation.keytab
export KRB5_KTNAME=ipa_automation.keytab
./buildslave.py

Thanks,
Matt

On Mon, Sep 26, 2016 at 6:01 PM, Matthew Sellers <matt at indigo.nu> wrote:
> Hi Alexander,
>
> Thanks for the hint, I was able to create a keytab and authenticate as
> a service, but using this method IPA returns zero results ( u'result'
> : [] ) for calls like "dnszone_find()".  I tried adding some of the
> predefined ROLES to the service principal, but no luck there.  Any
> hints are greatly appreciated.
>
> Thank You!
> Matt
>
>
>
> On Mon, Sep 26, 2016 at 9:59 AM, Alexander Bokovoy <abokovoy at redhat.com> wrote:
>> On ma, 26 syys 2016, Matthew Sellers wrote:
>>>
>>> Hi Martin,
>>>
>>> Thank you for clarification.   In my example I am configuring
>>> 'unprivileged' service users.   Specifically, I wrote a script to pull
>>> data from IPA from its wonderful REST interface that will run on a
>>> group of hosts.  Since this has to run non-interactively I would like
>>> to use a keytab.
>>>
>>> I initially went down the road of grabbing an initial keytab with
>>> ipa-getkeytab and then distributing the 'service user keytab' with
>>> Puppet.    I see the security implications here the same as
>>> un-encrypted ssh keys for service users.
>>>
>>> My second option was to jump on the host, grab a TGT for the service
>>> user with kinit, and download the lastest KVNO of my service user
>>> keytab using ipa-getkeytab with '-r' option.
>>>
>>> This seemed pretty cool and solved the issue of asking the KDC 'give
>>> me the lastest keytab for service user abc_service'.   What is the
>>> best way to do this?
>>>
>>>
>>> If anybody can share similar deployment stories that would be great.
>>
>> If you are not tied to POSIX users, you can create actual Kerberos
>> services and use them to talk to IPA framework. To the framework there
>> is no difference whether it is a user or a kerberos service that is
>> authenticating. You can create roles that reference Kerberos services
>> instead of users when assigning permissions to access certain objects
>> and their attributes.
>>
>> For services there is already a good way to delegate retrieval rights
>> for keytabs.
>>
>>
>>
>>>
>>> Thank You!
>>> Matt
>>>
>>>
>>>
>>> On Mon, Sep 26, 2016 at 2:22 AM, Martin Babinsky <mbabinsk at redhat.com>
>>> wrote:
>>>>
>>>> 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
>>>>
>>>>
>>>> --
>>>> 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
>>
>>
>> --
>> / Alexander Bokovoy