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 <[email protected]> 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 <[email protected]> >> 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 >>>> <[email protected]> wrote: >>>>> >>>>> >>>>> Matt, >>>>> >>>>> Try the following... >>>>> >>>>> # Get admin TGT >>>>> kinit [email protected] >>>>> >>>>> # Get keytab for user account >>>>> ipa-getkeytab -s coipa100 -p [email protected] -k >>>>> ipa_cron_runner.keytab >>>>> >>>>> # Clear tickets >>>>> kdestroy >>>>> >>>>> # Request TGT using the keytab >>>>> kinit -k -t ./cron_runner.keytab [email protected] >>>>> >>>>> # 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 <[email protected]> >>>>>> Sent: Sep 25, 2016 8:37 PM >>>>>> To: [email protected] >>>>>> 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 [email protected] -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 [email protected] >>>>>> -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
