krb5 acceptor credentials

[letz.yaara]

My questions are below Greg's comments

Thank you
Ya'ara


On 21 August 2013 16:14, Greg Hudson <ghudson at mit.edu> wrote:

> On 08/21/2013 05:27 AM, letz.yaara wrote:
> > 1 - When *gss_acquire_cred* returns major error *GSS_S_FAILURE*, how do I
> > parse the minor mechanism error ? *gss_display_status *returns an *empty
> > string (*and I can't find the code anywhere else).
>
> gss_display_status is the right way.  Make sure you're calling it
> correctly; you can see an example at
>
>   https://github.com/krb5/krb5/blob/master/src/tests/gssapi/common.c#L45
>
> There are a few bugs (not common) where we don't return a useful minor
> code.
>

I'm doing exactly the same as in the example from the link but get :

callinggss_acquire_cred

> GSSAPI Major error: 'Unspecified GSS failure.  Minor code may provide more information' (code: 0xD0000)
GSSAPI Minor error: '' (code: 0x186A4)

Does anyone have an idea what this mechanism code is about?


(my printing line is:

LOG_ERR( "GSSAPI %s error: '%s' (code: 0x%X)", ( status_type ==
GSS_C_GSS_CODE ) ? "Major" : "Minor", static_cast<char
*>(status_str.value), status_code);
)

Thank you

> > 2 - In what use case scenarios I have multiples messages to be processed
> by
> > *gss_display_status* ( in which I need to call gss_display_status again
> > according to the message_context argument)
>
> I don't believe our implementation ever returns multiple messages, but
> you should check in case your code is linked against a different
> implementation which does.
>
> > 3 - *gss_acquire_cred* - where does it keep its cred cache? (not /tmp/
> > krb5cc_something) and if I'm calling this function again - will it use
> the
> > cached credentials?
>
> gss_acquire_cred doesn't usually create a new ccache; it just creates an
> in-memory object which represents an existing ccache or keytab.
>
> If you are creating an acceptor credential, there is no ccache.
>
> > 4 - *gsskrb5_register_acceptor_identity - *can I use this function
> instead
> > of setting the environment variable *KRB5_KTNAME *?(not using
> > /etc/krb5.conf at all)
>
> You can; it affects future calls for the current thread.  Depending on
> the version of libkrb5 you're using, there may be less hackish methods
> of doing the same thing, such as gss_krb5_import_cred (1.9) or
> gss_acquire_cred_from (1.10).
>
> > 5. In *gss_acquire_cred - t**ime_rec* argument is described as "The
> number
> > of seconds for which the credential will remain valid.* If the time
> > remaining is not required*, specify NULL for this parameter." --> what
> does
> > it mean "*If the time remaining is not required"
>
> It means "if you do not need to know the amount of time remaining."
>
> > can my cached
> > credentials be indefinitely valid? (Basically I want to know in advance
> > when my credentials are expired and how to I control this date while
> > creating the keytab)
>
> krb5 acceptor credentials are always indefinitely valid.  krb5 initiator
> credentials are not; there is always an expiry time on the TGT, although
> it may be a long time.
>
> I'm not sure I understand the acceptors credentials part - what kind of
tickets does the acceptor (which is an SPN in the active directory) has? Is
it only credentials that it has?