gss_acquire_cred failing with no keytable entry found

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

gss_acquire_cred failing with no keytable entry found

Amritanshu
Hello Kerberos!

I am trying to make a windows client authenticate with a Linux server in a
domain-joined scenario, I have created a service principal based on the
documentation provided as part of PBIS/gssapps and MSDN GSS/SSPI interop
documentation [0, 1]. Updated the relevant Keytab entry in
/etc/krb5.keytab. I am using krb5-1.15.2,
Then I am using the following code on server side to acquire_cred

static int server_acquire_creds(
    char *service_name,
    gss_cred_id_t *server_creds
    )
{
    int ret = 0;
    gss_buffer_desc name_buf = GSS_C_EMPTY_BUFFER;
    gss_name_t server_name = GSS_C_NO_NAME;
    OM_uint32 maj_stat = 0, min_stat = 0;

    name_buf.value = service_name;
    name_buf.length = strlen((char *)name_buf.value) + 1;
    maj_stat = gss_import_name(&min_stat, &name_buf,
                               (gss_OID) gss_nt_service_name, &server_name);
    if (maj_stat != GSS_S_COMPLETE) {
        display_status("importing name", maj_stat, min_stat);
        ret = -1;
        goto error;
    }


    maj_stat = gss_acquire_cred(&min_stat, server_name, 0,
                                GSS_C_NULL_OID_SET, GSS_C_ACCEPT,
                                server_creds, NULL, NULL); <<--- it fails
here
    if (maj_stat != GSS_S_COMPLETE) {
        display_status("acquiring credentials", maj_stat, min_stat);
        ret = -1;
        goto error;
    }

error:
    (void) gss_release_name(&min_stat, &server_name);

    return ret;
}

**The error I am running into**:

GSS-API error acquiring credentials: Unspecified GSS failure.  Minor code
may provide more information (851968, 851968, 0x000d0000)

GSS-API error acquiring credentials: No key table entry found matching gss\/
dell-vostro-155.domain.in/domain.in@ (39756033, 39756033, 0x025ea101)
The service_name passed is "gss/[hidden email]".

I downloaded and compiled the bits set up traces and breakpoints in libgss
bits while stepping through I found in krb5_gss_acquire_cred_from I see the
name that is passed is invalid and the gssalloc fails because it is asked
to allocate a very large amount of memory.



I do see the principal in ktutil/list
ktutil: list -e
...
114    2 gss/[hidden email] (des-cbc-crc)
Also,
~/work/gss$ hostname -A
dell-vostro-155.domain.in

This is happening on the server end, where it is going to do a gss_ASC,
command used to run the application is.

sudo ./gss-server gss/[hidden email]

so gss-server is acting as the "gss" part in the principal name.


Mostly looking for advice on how to go about debugging this.
TIA

[0]
https://github.com/josephholsten/pbis/tree/master/gssapps/proxy/sspi-sample
[1]
https://msdn.microsoft.com/en-us/library/windows/desktop/aa380496(v=vs.85).aspx
[2] https://pastebin.com/AVjkLsJY
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: gss_acquire_cred failing with no keytable entry found

Greg Hudson
On 11/28/2017 12:41 AM, Amritanshu wrote:
> GSS-API error acquiring credentials: No key table entry found matching gss\/
> dell-vostro-155.domain.in/domain.in@ (39756033, 39756033, 0x025ea101)
> The service_name passed is "gss/[hidden email]".

It looks like this code is importing a krb5 principal name, but with a
name type indicating a GSS host-based service name.  (gss_nt_service
name is more properly spelled GSS_C_NT_HOSTBASED_SERVICE; I'm not sure
why the Microsoft documentation is using the archaic identifier.)

You can do one of the following:

1. Don't import a name or acquire creds.  Pass GSS_C_NO_CREDENTIAL to
gss_accept_sec_context() as the verifier cred handle.  The client will
be able to authenticate to any key in the keytab, so make sure the
keytab doesn't contain extraneous entries.  This is the approach
recommended by most Kerberos developers.

2. Use the GSS_KRB5_NT_PRINCIPAL_NAME name type instead of
gss_nt_service_name, in order to treat the imported name as a krb5
principal name.

3. Use a GSS host-based service name instead of a principal name.  The
host-based service name might look like "[hidden email]"
for this key (although "gss" isn't really a proper first component as it
doesn't name a service protocol).  With MIT krb5 1.10+, you can also
just specify the first component ("gss" in this case), allowing the
client to authenticate to any keytab entry matching that first component.

For more, see
http://web.mit.edu/kerberos/krb5-latest/doc/appdev/gssapi.html
particularly the "Name types" and "Acceptor names" sections.

> I downloaded and compiled the bits set up traces and breakpoints in libgss
> bits while stepping through I found in krb5_gss_acquire_cred_from I see the
> name that is passed is invalid and the gssalloc fails because it is asked
> to allocate a very large amount of memory.

Did you build with optimization?  You might be getting deceptive results
from the debugger.  If this were the case, you would see an "Out of
memory" error instead of a "No key table entry found" error.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: gss_acquire_cred failing with no keytable entry found

Amritanshu
Greg many thanks! that worked I have used suggestion 2. I think it's best
for me to stick to MIT documentation than google for every API and take the
first link. :)

I will try other bits, the gssalloc failure was determined using a
printf on that line as well. The code actually goes very far for an invalid
name provided.
Many thanks again.


On Tue, Nov 28, 2017 at 11:38 AM, Greg Hudson <[hidden email]> wrote:

> On 11/28/2017 12:41 AM, Amritanshu wrote:
> > GSS-API error acquiring credentials: No key table entry found matching
> gss\/
> > dell-vostro-155.domain.in/domain.in@ (39756033, 39756033, 0x025ea101)
> > The service_name passed is "gss/[hidden email]".
>
> It looks like this code is importing a krb5 principal name, but with a
> name type indicating a GSS host-based service name.  (gss_nt_service
> name is more properly spelled GSS_C_NT_HOSTBASED_SERVICE; I'm not sure
> why the Microsoft documentation is using the archaic identifier.)
>
> You can do one of the following:
>
> 1. Don't import a name or acquire creds.  Pass GSS_C_NO_CREDENTIAL to
> gss_accept_sec_context() as the verifier cred handle.  The client will
> be able to authenticate to any key in the keytab, so make sure the
> keytab doesn't contain extraneous entries.  This is the approach
> recommended by most Kerberos developers.
>
> 2. Use the GSS_KRB5_NT_PRINCIPAL_NAME name type instead of
> gss_nt_service_name, in order to treat the imported name as a krb5
> principal name.
>
> 3. Use a GSS host-based service name instead of a principal name.  The
> host-based service name might look like "[hidden email]"
> for this key (although "gss" isn't really a proper first component as it
> doesn't name a service protocol).  With MIT krb5 1.10+, you can also
> just specify the first component ("gss" in this case), allowing the
> client to authenticate to any keytab entry matching that first component.
>
> For more, see
> http://web.mit.edu/kerberos/krb5-latest/doc/appdev/gssapi.html
> particularly the "Name types" and "Acceptor names" sections.
>
> > I downloaded and compiled the bits set up traces and breakpoints in
> libgss
> > bits while stepping through I found in krb5_gss_acquire_cred_from I see
> the
> > name that is passed is invalid and the gssalloc fails because it is asked
> > to allocate a very large amount of memory.
>
> Did you build with optimization?  You might be getting deceptive results
> from the debugger.  If this were the case, you would see an "Out of
> memory" error instead of a "No key table entry found" error.
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos