gss_acquire_cred 失败，未找到密钥 table 条目

Question

我正在尝试让 windows 客户端在加入域的情况下通过 Linux 服务器进行身份验证，我已经根据作为 [=21 的一部分提供的文档创建了一个服务主体=].更新了 /etc/krb5.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/dell-vostro-155.domain.in@domain.in".

我确实在 ktutil/list

看到了校长

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

编辑：

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

这是在服务器端发生的，它将在服务器端执行 gss_ASC、

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

所以 gss-server 充当主体名称中的 "gss" 部分。

编辑

krb5.conf有点大我想贴东西就加了个Pastebinlinkkrb5.conf

Answer 1

我实际上给 kerberos@mit.edu 发了一封邮件来帮助我，这是他们推荐的。

此代码导入了一个 krb5 主体名称，但带有名称类型指示 GSS 基于主机的服务名称。 (gss_nt_service 名称拼写更正确 GSS_C_NT_HOSTBASED_SERVICE；我不确定为什么 Microsoft 文档使用古老的标识符。）

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

不要导入名称或获取信誉。将 GSS_C_NO_CREDENTIAL 传递给 gss_accept_sec_context() 作为验证者信用句柄。客户将能够对密钥表中的任何密钥进行身份验证，因此请确保 keytab 不包含无关的条目。这是方法大多数 Kerberos 开发人员推荐。
使用 GSS_KRB5_NT_PRINCIPAL_NAME 名称类型代替 gss_nt_service_name，以便将导入的名称视为 krb5 主体名称。
使用 GSS 基于主机的服务名称而不是主体名称。这基于主机的服务名称可能类似于 "gss@dell-vostro-155.domain.com" 对于这个键（尽管 "gss" 并不是真正合适的第一个组件，因为它不命名服务协议）。使用 MIT krb5 1.10+，您还可以只需指定第一个组件（在本例中为 "gss"），允许客户端对与第一个组件匹配的任何密钥表条目进行身份验证。

更多请看 http://web.mit.edu/kerberos/krb5-latest/doc/appdev/gssapi.html 特别是 "Name types" 和 "Acceptor names" 部分。

我用 GSS_KRB5_NT_PRINCIPAL_NAME 使事情正常进行。

gss_acquire_cred 失败，未找到密钥 table 条目

gss_acquire_cred failing with No key table entry found

kerberos

gssapi