Help with: openldap / active directory / sasl

[Benjamin Scott]

On Thu, Aug 12, 2010 at 9:06 PM, Bruce Dawson <jbd at codemeta.com> wrote:
> If I remember correctly Active Directory requires Kerberos.

  "Active Directory" is basically NTLM plus LDAP plus Kerberos plus
dynamic DNS plus some proprietary Microsoft glue.

  I know Windows computers in an Active Directory domain definitely
use Kerberos for authentication.  It's been that way going back to the
first release in Win 2000.

  Samba can act as a "native" AD member.  When used that way, one has
to configure Kerberos on the Samba box.  Samba can also act as an NT
domain member.  That uses the old NTLM protocol and doesn't require
Kerb.  (Windows/AD supports NT domain members as "Pre-Windows 2000
clients".  However, NTLM is nothing like LDAP, so that doesn't help
the OP much.)

  It may be possible that AD Domain Controllers support other LDAP
auth methods.  If so, it may be that they are not active by default.

  I've got a Perl script I use to extract email addresses from AD.
There's no mention of Kerberos in it.  I just fed it a username and
password and it worked.  However, it may be that Perl's LDAP libraries
automagically use Kerb if needed.  It's also possible Perl is picking
up the Kerb config done on the same box for Samba.  It could also be
that the password is going plaintext across the wire, or some other
magic is happening.

  Ah, Google to the rescue!  This query was useful:

http://www.google.com/search?q=%22Active+Directory%22+%22DIGEST-MD5%22

  The results reminds me that DIGEST-MD5 requires a shared secret.
That is, the client and server both  have to have the password in
plaintext.  Just like Unix, Windows stores passwords only as hashed
values by default.

  The Windows GUI for Active Directory member management is called
"Active Directory Users &  Computers"; it lives in "DSA.MSC".  When
you bring up the properties for a user in that thing, one of the
options you can set under the "Account" tab is something like "Store
password using reversible encryption".  I've never used it but I bet
that's what the OP needs.

  Note that storing passwords this way is a security exposure.  If you
can use Kerberos instead, you're probabbly better off.

  Note that simply enabling this option doesn't magically let Windows
"un-hash" a hashed password.  Perhaps Windows can  grab the plaintext
password the next time the user logs on and store it then.  (That may
not be possible, given the design  of Kerberos.)  If not, the user
would have to change their password before a plaintext password was
stored.

-- Ben