I've created a working custom BIND Class for NTLM (GSS-SPNEGO) to connect to Microsoft AD/ADAM/LDS directories: https://sourceforge.net/projects/javaldapntlmbind
Its based on NTLM-handling code from JCIFS/samba.org
Maybe you guys want to take a look, if this would be suitable to add to the SDK?
(The class and JCIFS all is GPL/LGPL like the SDK).
Regarding NTLM Transport Layer security (currently not implemented in my example):
From studying the source code I've understood, that the SDK's StartTLS can use any custom SSL socket factory and will use SSLSocketFactory.createSocket(Socket, String, int, boolean) to enable another layer on an open socket to get a protection layer and that StartTLS uses that to enable any transport layer security on an existing socket.
So it should actually be possible to create a custom SSL socket factory that provides custom sockets with adapted in/out streams to inject NTLM specific transport layer security into the existing SDK. I'll try that.
Last edit: Alex 2013-12-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for pointing this out. Unfortunately, it's not something that we can include in the LDAP SDK itself because we need copyright ownership of all the code that we include in the LDAP SDK so that we can offer it under other licenses (like the UnboundID LDAP SDK Free Use License, and the licenses for the Commercial Edition). But it definitely looks like this could be a useful addition for people who want NTLM authentication, and I'll make sure to mention this as an option for anyone who asks about that.
You are correct in that the LDAP SDK currently only provides support for the SASL "auth" quality of protection, and not "auth-int" (for integrity protection -- ensuring that requests haven't been altered) or "auth-conf" (for confidentiality protection -- ensuring that requests are encrypted). This is a known deficiency of the LDAP SDK that I've been meaning to get to eventually but so far hasn't been specifically requested. I'll look into providing a framework for supporting these modes, including updating support for DIGEST-MD5 and GSSAPI to make use of them. Given the upcoming holidays, I can't make any guarantees about how quickly I'll be able to implement this functionality, but I'll let you know when it's available.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I apologize for the length of time it took to get back to this, but the LDAP SDK has been updated so that the DIGEST-MD5 and GSSAPI SASL mechanisms have support for SASL integrity and confidentiality. Although it's not publicly documented at present, you could potentially leverage the same framework for SPNEGO authentication.
The basic requirement is that you would need to create your own SaslClient implementation (you just need to have a class that implements SaslClient -- you don't actually need to register it as a provider with the JVM or anything like that). If the authentication negotiates a security layer, then you should have the getNegotiatedProperty return a value of either "auth-int" or "auth-conf" for the Sasl.QOP property, and you should have the wrap and unnwrap methods perform the necessary cryptographic processing. Then use the undocumented com.unboundid.ldap.sdk.SASLHelper class to perform the authentication processing. See the DIGESTMD5BindRequest class (and especially the process method) for an example.
If this works for you, then I can consider making the SASLHelper class more public.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there
I've created a working custom BIND Class for NTLM (GSS-SPNEGO) to connect to Microsoft AD/ADAM/LDS directories:
https://sourceforge.net/projects/javaldapntlmbind
Its based on NTLM-handling code from JCIFS/samba.org
Maybe you guys want to take a look, if this would be suitable to add to the SDK?
(The class and JCIFS all is GPL/LGPL like the SDK).
Regarding NTLM Transport Layer security (currently not implemented in my example):
From studying the source code I've understood, that the SDK's StartTLS can use any custom SSL socket factory and will use SSLSocketFactory.createSocket(Socket, String, int, boolean) to enable another layer on an open socket to get a protection layer and that StartTLS uses that to enable any transport layer security on an existing socket.
So it should actually be possible to create a custom SSL socket factory that provides custom sockets with adapted in/out streams to inject NTLM specific transport layer security into the existing SDK. I'll try that.
Last edit: Alex 2013-12-21
Thanks for pointing this out. Unfortunately, it's not something that we can include in the LDAP SDK itself because we need copyright ownership of all the code that we include in the LDAP SDK so that we can offer it under other licenses (like the UnboundID LDAP SDK Free Use License, and the licenses for the Commercial Edition). But it definitely looks like this could be a useful addition for people who want NTLM authentication, and I'll make sure to mention this as an option for anyone who asks about that.
You are correct in that the LDAP SDK currently only provides support for the SASL "auth" quality of protection, and not "auth-int" (for integrity protection -- ensuring that requests haven't been altered) or "auth-conf" (for confidentiality protection -- ensuring that requests are encrypted). This is a known deficiency of the LDAP SDK that I've been meaning to get to eventually but so far hasn't been specifically requested. I'll look into providing a framework for supporting these modes, including updating support for DIGEST-MD5 and GSSAPI to make use of them. Given the upcoming holidays, I can't make any guarantees about how quickly I'll be able to implement this functionality, but I'll let you know when it's available.
I apologize for the length of time it took to get back to this, but the LDAP SDK has been updated so that the DIGEST-MD5 and GSSAPI SASL mechanisms have support for SASL integrity and confidentiality. Although it's not publicly documented at present, you could potentially leverage the same framework for SPNEGO authentication.
The basic requirement is that you would need to create your own SaslClient implementation (you just need to have a class that implements SaslClient -- you don't actually need to register it as a provider with the JVM or anything like that). If the authentication negotiates a security layer, then you should have the getNegotiatedProperty return a value of either "auth-int" or "auth-conf" for the Sasl.QOP property, and you should have the wrap and unnwrap methods perform the necessary cryptographic processing. Then use the undocumented com.unboundid.ldap.sdk.SASLHelper class to perform the authentication processing. See the DIGESTMD5BindRequest class (and especially the process method) for an example.
If this works for you, then I can consider making the SASLHelper class more public.
I should also point out that this is all available in the new 2.3.6 release of the LDAP SDK.