gss_acquire_cred failing with No key table entry found

Question

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. Updated the relevant keytab entry in /etc/krb5.keytab.

Ensured the DNS zones are set up correctly and the machine is domain joined

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);
    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-155.domain.in@domain.in".

I do see the principal in ktutil/list

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

Edit:

ktutil: list -e

...

114 2 gss/dell-vostro-155.domain.in@domain.in (des-cbc-crc)

~/work/gss$ hostname -A
dell-vostro-155.domain.in

This is happening on the server end, where it is going to do an gss_ASC,

sudo ./gss-server gss/dell-vostro-155.domain.in@domain.in

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

EDIT

krb5.conf is a bit big I wanted to paste things as it is so added a Pastebin link krb5.conf

Do you have a service named "gss" running on the Linux server? Can we see the command syntax you used to update the relevant keytab entry in /etc/krb5.keytab? Can we also see the klist output? — T-Heron, Nov 09 '17 at 15:27
Thanks @T-Heron, I have updated it with the relevant details, do let me know if it makes sense. — amritanshu, Nov 10 '17 at 06:58
What happens when you just do a sudo ./gss-server gss/dell-vostro-155.domain.in by itself? (without the '@domain.in' suffix part) Please update your question with the result. — T-Heron, Nov 23 '17 at 14:18
It has an identical error, I will get back to you on that by tomorrow :) ... in the process I have compiled krb5 linux bits and tracing through them. — amritanshu, Nov 23 '17 at 14:19
Ok. Please add your krb5.conf file into the question, it's a very relevant file and not that long. — T-Heron, Nov 23 '17 at 14:26
@T-Heron many thanks I have done the needful. also stepping through gss_acquire_cred, in krb5_gss_acquire_cred_from I see the name that is passed is invalid and the gssalloc fails. Which is why the lookup is failing. I need to step into gssint_import_internal_name and understand the equivalent KRb5 implementation to see what is going on there. — amritanshu, Nov 27 '17 at 13:12

amritanshu · Accepted Answer · 2018-09-08T05:39:10.757

I actually sent a mail to kerberos@mit.edu to help me out, this is what they recommended.

This code was 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.)

We can do one of the following:

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.
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.
Use a GSS host-based service name instead of a principal name. The host-based service name might look like "gss@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 used GSS_KRB5_NT_PRINCIPAL_NAME to make things work.

What name format did you use? "gss/dell-vostro-155.domain.in"? — Chris, Nov 08 '18 at 17:11
I think it was "gss/dell-vostro-155.domain.in@domain.in". I will try to dig out the details if it doesn't work for you. — amritanshu, Nov 09 '18 at 09:31
None of these are working for me, with exactly the same issue. I am wondering why it is so complicate... — benek, Dec 01 '22 at 09:40
@benek the long path you can start building the code and adding logs or reach out to the DL, where they might ask you to do the same. — amritanshu, Dec 01 '22 at 15:45
What worked for me was to only pass "HTTP" as principal. Don't know why exactly ... may be it is because I am somehow using LDAP authentication. — benek, Dec 01 '22 at 18:37

gss_acquire_cred failing with No key table entry found

1 Answers1