gss_acquire_cred failing with No key table entry found

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

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:

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