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

问题描述

我正在尝试使用 方法，并以 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.

在Microsoft SDK中，可以通过SSPI获得Kerberos-SSPI大致是Microsoft对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绑定分为三个阶段.

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_get_option并选择LDAP_OPT_ERROR_NUMBER来发现LDAP会话的最新LDAP错误.

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文档似乎不完整. Google的代码搜索应提供一个可行的示例.另外，对于上述流程的工作示例，可以查阅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屋！