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