#47321 Use new cred_store API to configure GSSAPI in 389ds
Opened 6 years ago by simo. Modified 2 years ago

In MIT 1.11 there is a new feature [1] that allows an application to programmatically define where credentials and keys are stored which is also thread safe as it operates on a specific set of credentials and does not set global variables.

It would be useful for DS to use this API so that keytabs and credential cache locations could be defined in dse.ldif and the server does not need to rely on setting environmental variables.

[1] http://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions


Here is the current status

  • RHDS is using cyrus sasl library 2.1.x

  • cyrus sasl library does not support in its gssapi plugin
    gss_acquire_cred_from, gss_add_cred_from or gss_store_cred_into

Here are the next steps

  • evaluate if other sasl implementations support those functions

Replying to [comment:3 tbordaz]:

Here is the current status

  • RHDS is using cyrus sasl library 2.1.x

  • cyrus sasl library does not support in its gssapi plugin
    gss_acquire_cred_from, gss_add_cred_from or gss_store_cred_into

Here are the next steps

  • evaluate if other sasl implementations support those functions

I don't think we want to evaluate other SASL implementations. If we need the SASL GSSAPI plug-in to use this new functions, we will need to wait until they implement the changes before DS can leverage them,

Nathan,
do you know how receptive is cyrus-sasl to patches in this direction ?
I might consider sending them something assuming a friendly upstream with quick turn around.

Replying to [comment:5 simo]:

Nathan,
do you know how receptive is cyrus-sasl to patches in this direction ?
I might consider sending them something assuming a friendly upstream with quick turn around.

I believe that they are generally pretty receptive. I have no idea on how quickly they would accept a patch and turn around a release. We should ask about adding this support on the Cyrus-SASL mailing list (cyrus-sasl@lists.andrew.cmu.edu).

Looks like it is there now:

[root@vm-239 ~]# yum list installed | grep gss
cyrus-sasl-gssapi.x86_64 2.1.26-14.fc20 @Fedora-20-x86_64-main
[root@vm-239 ~]# grep gss_acquire_cred_from /usr/include/gssapi/*
/usr/include/gssapi/gssapi_ext.h:gss_acquire_cred_from(

Using gss_acuire_cred_from() can also allows us to add future options to replication agreements (and/or plugins) so that you can have different principals/keytabs/ccaches ie different credetials active at the same time.

But I am not sure we want to conflate adding functionality with thius ticket which intended only to replace the current code with GSS-Proxy-compatible code and not change the user contract (which surrently uses the KRB5_KTNAME variable).

Metadata Update from @lkrispen:
- Issue assigned to tbordaz
- Issue set to the milestone: FUTURE

3 years ago

@simo do you know if it is expected in next release of freeipa ?

Metadata Update from @tbordaz:
- Issue close_status updated to: None

2 years ago

This is a nice to have, not required atm

Login to comment on this ticket.

Metadata