On Thu, 2003-06-19 at 17:46, Andrew Bartlett wrote:
> On Thu, 2003-06-19 at 17:23, Howard Chu wrote:
> > This thread seems to be arriving out-of-order, so I'm a bit confused on the
> > context. The thread appears out of order on the samba.org mailing list
> > archives as well.
>
> Dunno - I'm wondering if I'm being moderated on the openldap.org side...
> (not got back my post there).
>
> > Since there's already plenty to do, first I'd like to understand why using
> > the SASL NTLM mechanism won't work. In looking at cyrus/sasl/plugins/ntlm.c,
> > this appears to use a plaintext userPassword, like most of the other SASL
I looked at that code, and it's an NTLMSSP implementation, not a way to
do authentication against an NT hash. Unfortunately NTLMSSP is much
more complex than is made out here... (Dealing with things like NTLMv2,
and a lot more flags just to start with...)
> I'm not looking at SASL logins here - that's a different kettle of
> fish. What I'm looking for is for a simple bind to an OpenLDAP server
> to use the ntPassword stored on that DN.
>
> (and the issue of plaintext password storage is one reason I would
> probably never use that mechanism).
Having looked again at the OpenLDAP archives I want to stress again that
we:
- Do not have access to the original passwords
- Could not, even if we wanted to, store the plaintext (would rule us
out of most organizations).
- We can't do an LDAP bind the authenticate the user, even to an
NTLMSSP aware server.
Furthermore, it would be *highly* advantageous if we could update the NT
and LM passwords on user password changes, but I'm not holding my
breath...
> > Using a scheme like '{NTPASSWORD}sambaNTpassword' isn't really practical with
> > the current password check/hash mechanism; the password functions aren't
> > given any context about the DN or entry being authenticated. As such, there
> > isn't enough info to specify which entry's sambaNTpassword to retrieve. And
> > also, the passwd library has no API to perform the retrieval, short of
> > issuing its own ldapsearch().
>
> OK. What would you required to be able to implement a password scheme
> that can use the same values? I'm not so sure about making Samba read
> the userPassword attribute - I don't want to get in the way of yet other
> applications using that attribute, and we need to store *both* the NT
> and LM passwords in a consistent manner, and not step on toes in the
> process.
>
> Samba 3.0 went to particular effort to avoid stepping on toes with
> attributes names, so I'm a little worried about using userPassword...
> I'm also unsure of the reasons behind the original decision.
>
> > If it were just a matter of fixing the case sensitivity issue in the {LANMAN}
> > mech, that would be OK. But Andrew mentioned something about needing to
> > extract a session key from the handshake - it would seem that none of these
> > simple password mechs would accomodate this requirement.
>
> What I'm meaning here is that Samba cannot pass it's authentication
> routines off to some other party to complete. It needs the
> sambaNTpassword itself.
>
> That's a side discussion - the real issue here is just the simple binds
> to the LDAP server, and sanity for our administrators.
On the sanity point - what I really don't want is to write a doco that
tells our admins to do this:
- Install (and configure Cyrus SASL)
- Configure it for PAM authentication.
- Configure PAM to use pam_winbind.
- Configure winbind with 'winbind use default domain = yes'.
- Configure Samba to use LDAP.
- Set the userPassword to '{SASL}x'.
- Hope the account Samba users doesn't ahve this set (loops).
- Pray that the chain doesn't fall apart....
It *has* to be easier than this...
Andrew Bartlett
--
Andrew Bartlett abartlet@pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet@samba.org
Student Network Administrator, Hawker College abartlet@hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
Attachment:
signature.asc
Description: This is a digitally signed message part