kerberos - gss_acquire_cred失败，找不到 key 表条目

我正在尝试使Windows客户端在加入域的情况下通过Linux服务器进行身份验证，我已经根据PBIS/gssapps和MSDN GSS/SSPI interop documentation提供的文档创建了服务主体。更新了/etc/krb5.keytab中的相关keytab条目。

确保DNS区域设置正确，并且计算机已加入域

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;
}

我遇到的错误:

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)

传递的service_name是"gss/[email protected]"。

我确实在ktutil/list中看到了校长

主要是寻找有关如何进行调试的建议。

编辑:
ktutil: list -e...114 2 gss/[email protected] (des-cbc-crc)

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

这是在服务器端执行gss_ASC的情况下发生的，
sudo ./gss-server gss/[email protected]
因此gss-server充当主体名称中的“gss”部分。

编辑

krb5.conf有点大，我想粘贴东西，因为它添加了Pastebin链接krb5.conf

最佳答案

实际上，我发送了一封电子邮件到[email protected]来帮助我，这是他们的建议。

此代码导入的是krb5主体名称，但带有
名称类型，表示基于GSS主机的服务名称。 (gss_nt_service
名称更正确地拼写为GSS_C_NT_HOSTBASED_SERVICE;我不知道
为什么Microsoft文档使用的是过时的标识符。)

我们可以执行以下操作之一:

不要导入名称或获取凭据。将GSS_C_NO_CREDENTIAL传递给
gss_accept_sec_context()作为验证者凭据句柄。客户将
能够通过 key 标签中的任何 key 进行身份验证，因此请确保
keytab不包含多余的条目。这是方法
由大多数Kerberos开发人员推荐。

使用GSS_KRB5_NT_PRINCIPAL_NAME名称类型代替
gss_nt_service_name，以便将导入的名称视为krb5
主体名称。

使用基于GSS主机的服务名称代替主体名称。这
基于主机的服务名称可能看起来像“[email protected]”
为此键(尽管“gss”并不是真正合适的第一个组件，因为它
没有命名服务协议(protocol))。使用MIT krb5 1.10+，您还可以
只需指定第一个组件(在这种情况下为“gss”)，就可以
客户端对与该第一个组件匹配的任何keytab条目进行身份验证。

有关更多信息，请参见
http://web.mit.edu/kerberos/krb5-latest/doc/appdev/gssapi.html
特别是“名称类型”和“接受者名称”部分。

我使用了GSS_KRB5_NT_PRINCIPAL_NAME使工作正常。

关于kerberos - gss_acquire_cred失败，找不到 key 表条目，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/47202357/