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 <aboko...@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 <mbabi...@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
>>>> <mrorou...@earthlink.net> wrote:
>>>>>
>>>>>
>>>>> Matt,
>>>>>
>>>>> Try the following...
>>>>>
>>>>> # Get admin TGT
>>>>> kinit ad...@realm.com
>>>>>
>>>>> # Get keytab for user account
>>>>> ipa-getkeytab -s coipa100 -p cron_run...@realm.com -k
>>>>> ipa_cron_runner.keytab
>>>>>
>>>>> # Clear tickets
>>>>> kdestroy
>>>>>
>>>>> # Request TGT using the keytab
>>>>> kinit -k -t ./cron_runner.keytab cron_run...@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 <m...@indigo.nu>
>>>>>> Sent: Sep 25, 2016 8:37 PM
>>>>>> To: freeipa-users@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_run...@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@01 ~]$ ipa-getkeytab -s coipa100 -p cron_run...@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

-- 
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

Reply via email to