trying to correctly handle account passwords via ldap

Andrew Bartlett abartlet at
Wed Mar 29 03:35:16 GMT 2006

On Tue, 2006-03-28 at 18:36 -0500, Alan DeKok wrote:
> Andrew Bartlett <abartlet at> wrote:
> > The --helper-protocol=ntlm-server-1 was designed to avoid the need to
> > keep forking, and run a long-term conversation.  Unfortunately i think
> > it has some memory leaks, but these could be addressed, if there is a
> > suitable user.
>   FreeRADIUS.  There are currently deployments with 10^5 users or more
> using ntlm_auth, and forking for every request.  With modern hardware
> it's not a serious problem, but it's one more thing to manage.

I actually built the ntlm-server-1 mode for the use of projects like
FreeRADIUS.  It allows multiple authentications on a single child, over
stdin/stdout.  I know I didn't test the multiple authentications part of
this well, so it may require some more work (I suspect memory leaks),
but it is there. 

In the end, those who worked on the patch for FreeRADIUS found it easier
to work with the fork()/exec() command-line mode, which was found in
more versions of Samba3.

> > The use of winbindd ensures that there is no wasted network traffic as
> > multiple authentications occur.  The network setup cost for NETLOGON is
> > far higher than the cost of a fork().
> > 
> > Which cost are you trying to reduce?
>   Ideally, administration.  When an authenticator needs access to AD,
> the admin doesn't want to install and configure yet another program.
> An ideal library API would be:
>   open_path_to_ad(args)
>   authenticate(user, args, ...)
>   close_path_to_ad()
>   So the authenticator program could control *all* of the information
> needed to contact the AD server.  The authenticator could just treat
> AD as another "oracle" back-end, where it passes user credentials, and
> gets returned OK/FAIL.
>   ntlm_auth supplies all of this from a functional perspective, but to
> use it you have to configure the authenticator to use ntlm_auth, the
> ntlm_auth command-line arguments, windbindd, maybe smbd & nmbd.
> That's a lot of overhead to say "is this mschap stuff OK?"

Very little of this would be reduced with any other approach.  You are
simply proposing moving run-time configuration to build-time
configuration, as FreeRADIUS must then find a not-yet-written (or
popular) samba library, and build against it.  Winbindd and nmbd must
still run, and be configured (or some other system, with equal
complexity in configuration and management of communication with the DC

If the cost to be reduced was the fork()/exec() and stdin/stdout
processing, then a shared library might be useful.

Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 
Student Network Administrator, Hawker College
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url :

More information about the samba-technical mailing list