Multiple principals in a single application

[Bernardo Pastorelli]

My application uses openldap and GSSAPI to connect to a remote LDAP server. GSSAPI leverages kerberos as the transport mechanism.

I want to authenticate multiple different users at the same time, but kinit allows me only to store a single principal in the kerberos cache (at least in the default FILE cache).

I read about using the DIR cache or setting environment variables to use different caches, one for each user. But I was wondering if it is possible to avoid all of this, and simply not have a cache, but maintain all the tickets in memory.
The idea is to create the tickets using the kerberos APIs, not storing them in cache but simply keeping them in my process memory. And then pass these tickets to the ldap functions to connect to the ldap server.

Is this possible? Is there any sample available?

Regards,
Bernardo

[Nico Williams]

On Wed, May 8, 2013 at 2:05 AM, Bernardo Pastorelli <ber...@hotmail.com> wrote:
> My application uses openldap and GSSAPI to connect to a remote LDAP server. GSSAPI leverages kerberos as the transport mechanism.

a) It's one user at a time per-connection for LDAP. You can't
multiplex multiple user's LDAP PDUs over a single connection.

b) First use gss_acquire_cred() with the given user's gss_name_t as
the desired name, then call ldap_int_sasl_set_option() with
LDAP_OPT_X_SASL_GSS_CREDS as the option and the gss_cred_id_t as the
value.

c) Then call ldap_sasl_bind_s().

You need a version of OpenLDAP that has this option, and a version of
Cyrus SASL that has the SASL_GSS_CREDS options. But IIRC they've had
these for several years now.

Nico
--

[Nico Williams]

Oh, and yeah, you need DIR ccaches too.

[Greg Hudson]

On 05/08/2013 03:05 AM, Bernardo Pastorelli wrote:
> I read about using the DIR cache or setting environment variables to use different caches, one for each user. But I was wondering if it is possible to avoid all of this, and simply not have a cache, but maintain all the tickets in memory.
> The idea is to create the tickets using the kerberos APIs, not storing them in cache but simply keeping them in my process memory. And then pass these tickets to the ldap functions to connect to the ldap server.

This should be possible using memory ccaches, though I'm not aware of
any sample code. The outline would be:

1. Create a krb5_context with krb5_init_context

2. Create a memory ccache with krb5_cc_new_unique (with type "MEMORY"
and hint NULL)

3. Fetch tickets into the ccache.
- The old way is to do krb5_get_init_creds_password and then
krb5_cc_store_cred.
- The new way (requires MIT krb5 1.8+) is to create a
krb5_get_init_creds_opt structure with krb5_get_init_creds_opt_alloc,
then call krb5_get_init_creds_opt_set_out_ccache with the ccache handle,
then call krb5_get_init_creds_password.
The new way allows the library to write config values into the cache
such as "the KDC supports FAST," but it's not critical to making things
work.

4. Acquire GSSAPI creds from the ccache
- The old way is to call gss_krb5_ccache_name before the
gss_acquire_cred call, to set a thread-specific global variable.
- The new way (requires MIT krb5 1.9+) is to use gss_krb5_import_cred.

5. At this point we're at step (b) in Nico's instructions for using the
DIR ccache. Call ldap_int_sasl_set_option with
LDAP_OPT_X_SASL_GSS_CREDS as Nico suggested in his response, and then
call ldap_sasl_bind_s.

[Bernardo Pastorelli]

Following the steps and using the functions you described, I was finally able to implement the multiple principals logic.
Thank you very much for the support.

Regards,
Bernardo

[Nico Williams]

If you drop the need for having the tickets only in memory, then you
can drop a lot of C code: just kinit all the ccaches in the DIR and
then let the Kerberos GSS mechanism take care of the rest.

[Bernardo Pastorelli]

I further worked on my sample code and found an issue that I didn't realize before.

I tried to perform the binding, using the procedure described above in
the thread, but ldap_sal_bind_s is returning a challenge from the server
(with the return message LDAP_SASL_BIND_IN_PROGRESS).

If I call once again ldap_sasl_bind_s, passing as input the berval
struct returned by the previous invocation of this same function, it
fails with the following error:

80090300: LdapErr: DSID-0C0904C8, comment: AcceptSecurityContext error, data 5aa, v1772

where code 5aa looks referring to ERROR_NO_SYSTEM_RESOURCES
(Insufficient system resources exist to complete the requested service. )

How should I call ldap_sasl_bind_s multiple times? Does the challenge
message from server require any processing before reusing it?

Regards,

Bernardo

[Bernardo Pastorelli]

Hi Nico,

I run on an OS where the available version of the cyrus-sasl library does not support SASL_GSS_CREDS.
So openldap has LDAP_OPT_X_SASL_GSS_CREDS, but then when calling cyrus-sasl, it fails because it is not able to handle SASL_GSS_CREDS.

This is the reason why my code is failing (I didn't properly check the return codes). Is there any alternative to setting this option?

Regards,
Bernardo

> Date: Wed, 8 May 2013 06:47:34 -0500
> Subject: Re: Multiple principals in a single application
> From: ni...@cryptonector.com
> To: ber...@hotmail.com
> CC: kerb...@mit.edu

[Nico Williams]

On Sun, May 19, 2013 at 9:44 AM, Bernardo Pastorelli
<ber...@hotmail.com> wrote:
> I run on an OS where the available version of the cyrus-sasl library does
> not support SASL_GSS_CREDS.
> So openldap has LDAP_OPT_X_SASL_GSS_CREDS, but then when calling cyrus-sasl,
> it fails because it is not able to handle SASL_GSS_CREDS.
>
> This is the reason why my code is failing (I didn't properly check the
> return codes). Is there any alternative to setting this option?

You could interpose on gss_acquire_cred(), but really, I'd just build
a recent version of these two libraries.