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/[email protected] 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/[email protected] -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 <[email protected]> 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 <[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
