Question

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.

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

• 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.

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.

Any pointers will be greatly appreciated.

Answer 1

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

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.

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.

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

An LDAP SASL bind over Kerberos has 3 phases.

Phase 1

Call AcquireCredentialsHandle and InitializeSecurityContext.
Important notes here:

• 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.

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.

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.

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.

Phase 2

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.

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

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.

Phase 3

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.

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.

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.

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.