ldap_sasl_bind_s(GSSAPI) - 应该在凭证 BERVAL 结构中提供什么 [英] ldap_sasl_bind_s(GSSAPI) - What should be provided in the credentials BERVAL structure

问题描述

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

I'm trying to use the ldap_sasl_bind_s method from the Microsoft LDAP C SDK, with GSSAPI as the authentication mechanism. ldap_sasl_bind_s expects the credentials as a BERVAL structure, which is opaque.

给定用户名(或 DN)和密码，我如何获得应该传递给 ldap_sasl_bind_s<的 BERVAL 结构/代码>?

Given a username (or a DN) and a password, how do I get to the BERVAL structure that I'm supposed to pass to ldap_sasl_bind_s?

到目前为止我发现的例子

The examples I've found so far

• 来自其他 LDAP C SDK - 而不是来自 Microsoft
• 在需要简单身份验证时使用 ldap_sasl_bind_s - 但我需要使用 GSSAPI
• 在需要其他 SASL 身份验证机制时使用 ldap_sasl_interactive_bind_s.但是，Microsoft SDK 中没有 ldap_sasl_interactive_bind_s.

• are from other LDAP C SDKs - not the one from Microsoft
• use ldap_sasl_bind_s when SIMPLE authentication is desired - but I need to use GSSAPI
• use ldap_sasl_interactive_bind_s when other SASL authentication mechanisms are desired. However, there is no ldap_sasl_interactive_bind_s in the Microsoft SDK.

附带说明，目标是能够通过 SASL 绑定到各种 LDAP 服务器；目前:ActiveDirectory 和 OpenLDAP.

As a side note, the goal is to be able to bind over SASL to a variety of LDAP servers; for now: ActiveDirectory and OpenLDAP.

任何指针将不胜感激.

推荐答案

我设法使用 ldap_sasl_bind_s 在 GSSAPI 上执行 LDAP SASL 绑定.有兴趣的可以参考一下.

I managed to perform an LDAP SASL bind over GSSAPI, using ldap_sasl_bind_s. For those interested, here are some pointers.

对于客户端和服务器在 GSSAPI SASL 身份验证期间需要执行的操作的抽象描述，Kerberos V5 ("GSSAPI") 简单身份验证和安全层 (SASL) 机制" 应该阅读 RFC；具体来说，身份验证协议交换的客户端"部分很有趣，因为它指示了我们需要执行的操作序列，以通过 Kerberos 成功绑定到 LDAP 服务器.

For an abstract description of the actions a client and server need to perform during a GSSAPI SASL authentication, "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism" RFC should be read; specifically, the 'Client Side of Authentication Protocol Exchange' section is of interest, because it gives an indication of the sequence of actions we need to perform to successfully bind to an LDAP server over Kerberos.

ldap_sasl_bind_s 期望的凭据 - 它们的形式和含义 - 取决于所使用的实际身份验证机制，在我们的例子中是 Kerberos.

The credentials ldap_sasl_bind_s expects - their form and their meaning - depend on the actual authentication mechanism being used, which in our case is Kerberos.

在微软 SDK 中，Kerberos 是通过 SSPI 提供的——大致是微软对 GSSAPI 的实现；与我们的特定案例相关的方法是:AcquireCredentialsHandle、InitializeSecurityContext、DecryptMessage、EncryptMessage

In the Microsoft SDK, Kerberos is available through SSPI - which is roughly the Microsoft implementation of GSSAPI; the methods that are relevant for our particular case are: AcquireCredentialsHandle, InitializeSecurityContext, DecryptMessage, EncryptMessage

基于 Kerberos 的 LDAP SASL 绑定有 3 个阶段.

An LDAP SASL bind over Kerberos has 3 phases.

调用 AcquireCredentialsHandle 和 InitializeSecurityContext.
重要说明:

Call AcquireCredentialsHandle and InitializeSecurityContext.
Important notes here:

• 向 AcquireCredentialsHandle 传递一个指向包含实际凭据(领域、用户名、密码)的 SEC_WINNT_AUTH_IDENTITY 结构的指针，如果凭据则为 NULL的当前线程将被使用
• 目标名称应该是映射到运行 LDAP 服务器的帐户的 SPN
• 调用InitializeSecurityContext时，必须请求相互认证.

• pass to AcquireCredentialsHandle a pointer to a SEC_WINNT_AUTH_IDENTITY structure containing the actual credentials (realm, username, password), or NULL if the credentials of the current thread are to be used
• the target name should be an SPN mapped to the account under which the LDAP server is running
• when calling InitializeSecurityContext, mutual authentication must be requested.

如果所有重要参数都正确 - 有效凭据、有效 SPN、NULL 输入令牌 - InitializeSecurityContext 调用应返回 SEC_I_CONTINUE_NEEDED 并正确填写输出令牌.此输出令牌的内容应进入 BERVAL 结构 ldap_sasl_bind_s 期望作为客户端凭据.

If all important arguments are correct - valid credentials, valid SPN, NULL input token - the InitializeSecurityContext call should return SEC_I_CONTINUE_NEEDED and properly fill the output token. The contents of this output token should go in the BERVAL structure ldap_sasl_bind_s expects as client credentials.

使用来自 InitializeSecurityContext 的输出令牌作为客户端凭据调用 ldap_sasl_bind_s.如果所有参数都正确 - 空 DN，GSSAPI 作为机制名称 - 实际调用应该返回 LDAP_SUCCESS 并且 LDAP 会话的最新 LDAP 错误应该是 LDAP_SASL_BIND_IN_PROGRESS.

Call ldap_sasl_bind_s with the output token from InitializeSecurityContext as client credentials. If all arguments are correct - empty DN, GSSAPI as the mechanism name - the actual call should return LDAP_SUCCESS and the most recent LDAP error for the LDAP session should be LDAP_SASL_BIND_IN_PROGRESS.

附带说明，LDAP 会话的最新 LDAP 错误可以通过在会话上调用 ldap_get_option 来发现，其中 LDAP_OPT_ERROR_NUMBER 作为选项.

As a side note, the most recent LDAP error for an LDAP session can be discovered by calling ldap_get_option on the session, with LDAP_OPT_ERROR_NUMBER as the option.

在成功调用 ldap_sasl_bind_s 后，它的最后一个参数指向一个包含服务器凭据的 BERVAL 结构.此 BERVAL 结构的内容现在应用作第二次调用 InitializeSecurityContext 的输入标记.

After the successful call to ldap_sasl_bind_s, its last argument points to a BERVAL structure containing the server credentials. The content of this BERVAL structure should now be used as the input token for the second call to InitializeSecurityContext.

第二次调用 InitializeSecurityContext 应该返回 SEC_OK 和一个空的输出令牌.

This second call to InitializeSecurityContext should return SEC_OK and an empty output token.

此空输出令牌应用作对 ldap_sasl_bind_s 的另一次调用的客户端凭据.对 ldap_sasl_bind_s 的第二次调用应返回 LDAP_SUCCESS，LDAP 会话的最新 LDAP 错误是 LDAP_SASL_BIND_IN_PROGRESS.

This empty output token should be used as the client credentials for another call to ldap_sasl_bind_s. This second call to ldap_sasl_bind_s should return LDAP_SUCCESS, with the most recent LDAP error for the LDAP session being LDAP_SASL_BIND_IN_PROGRESS.

在第二次成功调用 ldap_sasl_bind_s 之后，它的最后一个参数指向一个包含服务器数据的 BERVAL 结构.该服务器数据应作为 DecryptMessage 的输入.正如前面提到的 RFC 中规定的，解密后的数据必须是 4 个字节长.

After the second successful call to ldap_sasl_bind_s, its last argument points to a BERVAL structure containing server data. This server data should be given as input to DecryptMessage. As specified in the previously mentioned RFC, the decrypted data must be 4 bytes long.

客户端应根据同一RFC中的信息构建其回复.
注意:在我的例子中，我省略了 RFC 中提到的授权 ID.据我了解，空的授权 id 会导致身份验证 id 也用于授权.

The client should build its reply according to the information in the same RFC.
Note: In my case, I omitted the authorization id mentioned in the RFC. To my understanding, an empty authorization id leads to the authentication id being used for authorization as well.

客户端建立的回复应该作为输入传递给EncryptMessage.EncryptMessage 调用的输出应作为客户端凭据传递给第三次也是最后一次调用 ldap_sasl_bind_s.

The reply the client built should then be passed as input to EncryptMessage. The output of the EncryptMessage call should then be passed as the client credentials for the third and final call to ldap_sasl_bind_s.

注意:在 Kerberos 下使用 EncryptMessage 的 MSDN 文档似乎不完整.谷歌的代码搜索应该有助于提供一个工作示例.此外，对于上述流程的工作示例，可以参考 Samba 的源代码.

Note: The MSDN documentation for using EncryptMessage under Kerberos seems to be incomplete. Google's Code Search should assist with a working example. Also, for a working example of the flow described above, Samba's source code can be consulted.

这篇关于ldap_sasl_bind_s(GSSAPI) - 应该在凭证 BERVAL 结构中提供什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！