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/dell-vostro-...@domain.in".

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/dell-vostro-...@domain.in (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/dell-vostro-...@domain.in

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

[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/dell-vostro-...@domain.in".

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 "g...@dell-vostro-155.domain.com"
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.

[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.