directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "kevin creason" <>
Subject re: ntlm gateway
Date Fri, 22 Aug 2008 19:36:03 GMT
Please bear with me, I'm really really green with the Apache directory.

I'm referencing this page:

which says <<EOF
ApacheDS will not do much with the NTLM messages besides shuffle them back
and forth as an intermediary through a Win32 JNI wrapper. The Win32 library
will allow callers to start an NTLM negotiation by the host through some
protocol (most likely SMB) to authenticate the user with a Windows Server.
What server is used to do this is dependent on the configuration of the host
ApacheDS is running on. The authentication may simply take place locally or
require communication with another Windows server.

ApacheDS thus acts as an LDAP Gateway to interface with the Win32 SSPI. It
takes the NTLM Type 1 request, base64 decodes the opaque data structure, and
calls methods on the Win32 API Java wrapper to get back a Type 2 request
containing the NTLM challenge. ApacheDS then tunnels back the Type 2 NTLM
response to the client in the serverSaslCreds field, as described above, in
the SASL Bind Response. The client generates the Type 3 NTLM challenge
response, from the user password, the domain and the Type 2 challenge. The
LDAP client tunnels this structure after base64 encoding it to ApacheDS in
the second SASL Bind Request. ApacheDS again extracts this Type 3 message
from the SaslCredentials.credentials field, base64 decodes it and makes
another call to the Win32 API Java wrapper.

ApacheDS simply tunnels the requests with base64 encode/decode operations on
the NTLM requests/responses. The NTLM data is opaque and ApacheDS need not
be concerned with the content it contains. The SASL Bind Request's mechanism
is sufficient for ApacheDS to switch the mechanism and understand how to
deal with the authentication. Even the DN supplied in the Bind operation is
not considered since the NTLM payloads contain all the information needed to
perform the handoff to the host via the Win32 API.


Then, to my earlier question, Alex responded and wrote:

> There is a configuration example in the stock server.xml that shows you need
> to setup your NtlmProvider class and set up various SASL mechanisms.  The
> problem is you'll need to write your own NtlmProvider.  I could not include
> the JCifs implementation with ADS because of licensing issues with using

So is the section you are referring to in the stock server.xml?
It's the only thing that references ntlm. Is the FQCN supposed to be in
reverse order?

   <!-- The list of supported authentication mechanisms.
      <simpleMechanismHandler mech-name="SIMPLE"/>
      <cramMd5MechanismHandler mech-name="CRAM-MD5"
      <digestMd5MechanismHandler mech-name="DIGEST-MD5"
      <gssapiMechanismHandler mech-name="GSSAPI"
      <ntlmMechanismHandler mech-name="NTLM"
      <ntlmMechanismHandler mech-name="GSS-SPNEGO"

And that can't be enough information. There is an awful lot of important
data in between what my eyes read and what needs to be done to make this
work. Some of my questions are-- do I need to have data in the same
namespace as the NTLM FQCN? Or can it be totally separate?

And that's not even touching the comment from similar thread "ntlm

You just have to write an NtlmProvider implementation class using the JCIFS
jar here:

It's rather easy to do since the NtlmProvider interface is trivial but
you'll have to grok jcifs.

It's obviously been done by someone smart. Could someone share their example
code & configurations? A nice walk-through shouldn't violate any licenses,
and I hate to admit it, I really need some extra help understanding these
tools (since it is a combination of ADS and JCIFS).


/* Never argue with an idiot. They drag you down to their level and beat you
with experience. */

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message