Bind succeeds!!!
However, when I try to do search on the same connection, search still goes without any Kerberos and obviously AD doesn't respond.
What should I do to force connection to use Kerberos on search requests?
Thanks in advance,
Sergey
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The LDAP SDK currently doesn't provide any direct support for Kerberos SPNEGO, and there are currently no plans to add this support.
I'm not really familiar with that mechanism, so I can't say whether it's sufficient to simply use the bytes that comprise a Kerberos token as the SASL credentials in a bind request. If the LDAP server returns a bind result with a result code of SUCCESS, then that would suggest that it is sufficient.
However, if I understand your question, though, the problem is that you're not getting any quality of protection (QoP) on the connection after the authentication has completed. That is definitely true for the approach that you're taking. It would be difficult to use QoP without using the javax.security.sasl.SaslClient, but even then the elements you would need to secure communication over a connection aren't publicly accessible to third-party code. It would require at least making the com.unboundid.ldap.sdk.SASLHelper class public.
However, at the present time, since it doesn't look like there is SaslClient support for SPNEGO, it's not really feasible to add support for QoP with SPNEGO.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Neil,
You got it absolutely right. My bind request succeeds, but search doesn't use any QoP.
Since, there are no plans to support SPNEGO, I will use GSSAPI for now. The only limitation for GSSAPI on Windows is the requirement to change registry key to be able to bind as currently logged in user. Not all customers want to do that. Bind with SPNEGO doesn't require changing registry key.
Thanks,
Sergey
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I do bind to AD with GenericSASLBindRequest, using Kerberos token.
byte[] kerberosToken = getKerberosToken(user, password);
ASN1OctetString credentials = new ASN1OctetString(kerberosToken);
GenericSASLBindRequest genericSASLBindRequest = new GenericSASLBindRequest(null, "GSS-SPNEGO", credentials, null);
bindResult = ldapConnection.bind(genericSASLBindRequest);
Bind succeeds!!!
However, when I try to do search on the same connection, search still goes without any Kerberos and obviously AD doesn't respond.
What should I do to force connection to use Kerberos on search requests?
Thanks in advance,
Sergey
The LDAP SDK currently doesn't provide any direct support for Kerberos SPNEGO, and there are currently no plans to add this support.
I'm not really familiar with that mechanism, so I can't say whether it's sufficient to simply use the bytes that comprise a Kerberos token as the SASL credentials in a bind request. If the LDAP server returns a bind result with a result code of SUCCESS, then that would suggest that it is sufficient.
However, if I understand your question, though, the problem is that you're not getting any quality of protection (QoP) on the connection after the authentication has completed. That is definitely true for the approach that you're taking. It would be difficult to use QoP without using the javax.security.sasl.SaslClient, but even then the elements you would need to secure communication over a connection aren't publicly accessible to third-party code. It would require at least making the com.unboundid.ldap.sdk.SASLHelper class public.
However, at the present time, since it doesn't look like there is SaslClient support for SPNEGO, it's not really feasible to add support for QoP with SPNEGO.
Hello Neil,
You got it absolutely right. My bind request succeeds, but search doesn't use any QoP.
Since, there are no plans to support SPNEGO, I will use GSSAPI for now. The only limitation for GSSAPI on Windows is the requirement to change registry key to be able to bind as currently logged in user. Not all customers want to do that. Bind with SPNEGO doesn't require changing registry key.
Thanks,
Sergey