ldap_sasl_bind_s(GSSAPI) - 应该在凭证 BERVAL 结构中提供什么

Question

我正在尝试使用 ldap_sasl_bind_s 来自 Microsoft LDAP C SDK 的方法，带有 GSSAPI 作为认证机制。 ldap_sasl_bind_s期望凭据为 BERVAL结构，不透明。

给定用户名(或 DN)和密码，我怎么去BERVAL结构 我应该传递给 ldap_sasl_bind_s ?

到目前为止我发现的例子

来自其他 LDAP C SDK - 不是来自 Microsoft

使用 ldap_sasl_bind_s当需要简单的身份验证时 - 但我需要使用 GSSAPI

使用 ldap_sasl_interactive_bind_s当需要其他 SASL 身份验证机制时。但是，没有ldap_sasl_interactive_bind_s在微软 SDK 中。

附带说明一下，目标是能够通过 SASL 绑定(bind)到各种 LDAP 服务器；现在:ActiveDirectory 和 OpenLDAP。

任何指针将不胜感激。

Answer 1

我设法通过 GSSAPI 执行 LDAP SASL 绑定(bind)，使用 ldap_sasl_bind_s .对于那些感兴趣的人，这里有一些指示。
有关在 GSSAPI SASL 身份验证期间客户端和服务器需要执行的操作的抽象描述， “Kerberos V5(“GSSAPI”)简单例份验证和安全层 (SASL) 机制”应该阅读 RFC；具体来说，“身份验证协议(protocol)交换的客户端”部分很有趣，因为它指示了我们需要执行的操作序列，以通过 Kerberos 成功绑定(bind)到 LDAP 服务器。
凭据 ldap_sasl_bind_s期望——它们的形式和意义——取决于所使用的实际身份验证机制，在我们的例子中是 Kerberos。
在微软 SDK 中，Kerberos 是通过 SSPI 提供的——大致是微软对 GSSAPI 的实现；与我们的特殊情况相关的方法是:AcquireCredentialsHandle , InitializeSecurityContext , DecryptMessage , EncryptMessage基于 Kerberos 的 LDAP SASL 绑定(bind)有 3 个阶段。
阶段1
调用 AcquireCredentialsHandle和 InitializeSecurityContext .
这里的重要说明:

转至 AcquireCredentialsHandle指向 SEC_WINNT_AUTH_IDENTITY 的指针包含实际凭据(领域、用户名、密码)的结构，或 NULL如果要使用当前线程的凭据

目标名称应该是映射到运行 LDAP 服务器的帐户的 SPN

调用InitializeSecurityContext时，必须请求相互认证。

如果所有重要参数都正确 - 有效凭据、有效 SPN、 NULL输入 token - InitializeSecurityContext调用应该返回 SEC_I_CONTINUE_NEEDED并正确填写输出 token 。这个输出 token 的内容应该放在 BERVAL 中。结构 ldap_sasl_bind_s期望作为客户端凭据。
调用 ldap_sasl_bind_s来自 InitializeSecurityContext 的输出 token 作为客户端凭据。如果所有参数都正确 - 空 DN，GSSAPI 作为机制名称 - 实际调用应该返回 LDAP_SUCCESS LDAP session 的最新 LDAP 错误应该是 LDAP_SASL_BIND_IN_PROGRESS .
附带说明一下，可以通过调用 ldap_get_option 来发现 LDAP session 的最新 LDAP 错误。在 session 中，与 LDAP_OPT_ERROR_NUMBER作为选项。
阶段2
成功调用 ldap_sasl_bind_s后, 它的最后一个参数指向 BERVAL包含服务器凭据的结构。本篇内容 BERVAL现在应该将结构用作第二次调用 InitializeSecurityContext 的输入标记。 .
第二次调用 InitializeSecurityContext应该返回 SEC_OK和一个空的输出 token 。
此空输出 token 应用作对 ldap_sasl_bind_s 的另一次调用的客户端凭据。 .第二次调用 ldap_sasl_bind_s应该返回 LDAP_SUCCESS ，LDAP session 的最新 LDAP 错误是 LDAP_SASL_BIND_IN_PROGRESS .
第三阶段
在第二次成功调用 ldap_sasl_bind_s 之后, 它的最后一个参数指向 BERVAL包含服务器数据的结构。此服务器数据应作为 DecryptMessage 的输入。 .正如前面提到的 RFC 中所规定的，解密后的数据必须是 4 个字节长。
客户端应根据同一 RFC 中的信息构建其回复。
备注 :就我而言，我省略了 RFC 中提到的授权 ID。据我了解，一个空的授权 id 会导致身份验证 id 也被用于授权。
客户端建立的回复应该作为输入传递给 EncryptMessage。 . EncryptMessage 的输出然后调用应作为客户端凭据传递给 ldap_sasl_bind_s 的第三次也是最后一次调用。 .
备注 : 使用 EncryptMessage 的 MSDN 文档在 Kerberos 下似乎是不完整的。谷歌的代码搜索应该有助于提供一个工作示例。此外，对于上述流程的工作示例，可以查阅 Samba 的源代码。