[Freeipa-users] ldapsearch in cron job woes about no credentials

[Alexander Bokovoy]

On Mon, 13 Jun 2016, Harald Dunkel wrote:
>On 06/09/16 15:16, Harald Dunkel wrote:
>> Hi folks,
>>
>> Platform: freeipa 4.2 (Centos7)
>>
>> Problem: My cron job needs a ticket to run ldapsearch. The
>> error message is:
>>
>>         SASL/GSSAPI authentication started
>>         ldap_sasl_interactive_bind_s: Local error (-2)
>>         additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (No Kerberos credentials available)
>>
>> Google pointed me to this solution
>>
>> 	http://www.cmf.nrl.navy.mil/krb/kerberos-faq.html#kerbcron
>>
>> I wonder what is the "freeipa way" to handle this scenario,
>> esp. how to generate the additional kerberos entry without
>> confusing FreeIPA? Maybe I am too blind to see, but I haven't
>> found this problem in the FAQs.
>>
>
>Too much noob?
I appreciate your self-assessment but no need to be so intimidating. ;)

When you are using SASL GSSAPI, it is expected that there are
credentials obtained prior to running the utility that uses SASL GSSAPI.
Typically this is done with kinit or in case of a user logon, SSSD would
create a credentials cache with valid credentials for you.

For crontab-based environments you need to make that yourself. But it
would also be useful to avoid re-acquiring Kerberos tickets all the time
and re-use existing ticket during the time of its validity.

This problem of acquiring Kerberos tickets periodically on behalf of
some other application has long history, not really solved in stock MIT
Kerberos distribution as you can see.

You have few options but the one I'd recommend is to integrate your
application with GSS-Proxy. GSS-Proxy installs a special plugin into
GSSAPI infrastructure that triggers look up of credentials via GSS-Proxy
daemon. This allows to avoid giving access to actual credentials to 
the application but also allows to initiate acquisition of the
credentials on behalf of the application.

To do so, you need to configure couple things:

 - Create a service in IPA that would be used to present your job. The
   service is more correct to use here instead of a user account because
   if you don't need to have POSIX attributes associated with it, only
   Kerberos authentication, the service principal is a correct one.

   Add a service to the host where you'd be running the cron job:

      ipa service-add mycronservice/ipa.client.host

 - This host (ipa.client.host) will be able to fetch a keytab with a key
   for the service because the host always manages its services.

 - On ipa.client.host do:

      kinit -k
      ipa-getkeytab -s ipa.master.host -p mycronservice/ipa.client.host \
                    -k /etc/krb5.mycronservice.keytab

 - Now you have Kerberos keys (random password) for the
   mycronservice/ipa.client.host service principal stored in the keytab,
   you can set up gss-proxy to use it. Add a following configuration
   file to the /etc/gssproxy/80-mycronservice.conf

  --8<--8<--8<--8<--8<--8<--8<--8<--8<--
   [service/mycronservice]
   mechs = krb5
   cred_store = client_keytab:/etc/krb5.mycronservice.keytab
   cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_mycronservice_%U
   cred_usage = initiate
   euid = <set to UID of user running the cron job>
  --8<--8<--8<--8<--8<--8<--8<--8<--8<--

 - In your cronjob script add environmental variable GSS_USE_PROXY=yes 

That's it. Whenever GSSAPI is used, GSS-Proxy plugin is loaded, looks at
GSS_USE_PROXY=yes environmental variable and then contacts GSS-Proxy to
request a ticket to the service you want to access. This would trigger a
look up in the ccache if that ticket already exist and will also trigger
acquisition of the new credentials if that is needed, thanks to
client_keytab setting in the GSS-Proxy config.

See man pages for gssproxy, gssproxy-mech, and gssproxy.conf for
details.

-- 
/ Alexander Bokovoy