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
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]:
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
@simo do you know if it is expected in next release of freeipa ?
Metadata Update from @tbordaz: - Issue close_status updated to: None
This is a nice to have, not required atm
Duplicate of https://pagure.io/389-ds-base/issue/50018
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to None - Issue close_status updated to: duplicate - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/658
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: duplicate)
Login to comment on this ticket.