[Dovecot] Concerned about Dovecot's new NTLM code

[Andrew Bartlett]

On Mon, 2004-09-27 at 21:50, Andrey Panin wrote:
> > On Mon, 2004-09-27 at 16:44, Andrey Panin wrote:
> >> >
> >> > Firstly, to bugs I've noticed by casual inspection of your
> >> > implementation:
> >> >
> >> >  - Unicode support is by 'null padding' - there is no real support for
> >> > non-ascii characters.
> >>
> >> Does it really matter ? Do you know many people who use non-ascii
> >> characters in their email addresses and passwords ? :)
> 
> Never encountered a single one outside of LAN's. Anyway correct unicode
> support is impossible to implement without enormous amount of breakage.

That presumes that login name must map to an e-mail address directly,
and that no other part of the NTLMSSP packet matters.  I'm not
sufficiently familiar with Dovecot to comment on the former (exchange, I
understand, allows some mapping table between accounts and e-mail
addresses, for example), but the use of all ASCII/padded unicode
'because it seems to work' really bothers me, from my Samba experience.

> >> > There are other missing features, some of which are rumoured to become
> >> > mandatory flags in future, but more importantly, because the
> >> > implementation is standalone, it has no ability to integrate into an
> >> > NT/Win2k/Samba domain.
> 
> Domain membership was not a goal, at least until you started this thread.

That's partly why I started this thread - I've seen support for domain
membership hacked into too many other products, usually by adding the
really old, really crufty 'smbval' library into the source.  If I can
avoid it in this product, because I've raised a more viable alternative,
I'll by happy.

> >> It can be directly integrated with password backends using NTLM password
> >> scheme.
> >
> > I've looked over the source, and I'm having trouble seeing how you are
> > using the Samba passwords (as I can't find a use of the Samba password
> > attributes).  The userPassword attribute doesn't exactly count, as Samba
> > never reads nor writes that value directly...
> >
> > Even if the code was to change to read these attributes, there are two
> > very difficult problems with this.  Firstly, I strongly advise against
> > directly relying on the format of the Samba password database - we can
> > and do change that format, as we have done between Samba 2.2 and Samba
> > 3.0, and that presumes LDAP...
> 
> Long time passed after I used samba last time...
> Do you mean that samba authentication database can contain not only user,
> but also workstation and other "god knows what" accounts ?
> IMHO it's a matter of right SQL/LDAP request.

Samba does store much information about a user - and should be consulted
by the documented interfaces for user authentication.  I specifically
advise against directly using the password hash values.

> > This also assumes that the the mail server is privileged to have access
> > to the password-equivalent values in the database, and makes it
> > completely incompatible with a role as a domain member.
> >
> > (Domain membership allows the IMAP server to be separate from the DC, no
> > matter what it may be running.  This allows mail servers to run in a
> > windows or Samba domain, without change to the infrastructure).
> 
> Yes, I heard about domain infrastructure advantages, but not all use it as
> it's far too complex for many tasks.

I know Samba scares people, and we have tried hard to make it easier to
use.  Perhaps the biggest problem is that most of the example
configurations are just overly complex...

Then again, have you ever tried to set up a kerberos realm?  Did you
have any hair left - I know how I felt... ;-)

> >> > As part of the Samba team, I have worked with other projects - Squid
> >> in
> >> > particular, to deliver server-side (and client-side) NTLMSSP
> >> > authentication, without the need to re-implement the NTLMSSP protocol.
> >> >
> >> > This is done by a callout to 'ntlm_auth', a Samba 3.0 utility designed
> >> > for this purpose, which in turn can contact domain controllers,
> >> allowing
> >> > for seamless single sign on.
> >> >
> >> > http://samba.org/samba/docs/man/ntlm_auth.1.html
> >>
> >> So you'll need Samba to run POP3/IMAP server. Doesn't look convinent to
> >> me.
> >> Many people have no windows domain infrastructure, but want to provide
> >> secure authentication for poor MS Outlook users.
> >
> > Unfortunately, without support for NTLM2 at least, the client will send
> > the LM response, which is a particularly weak.
> 
> NTLMv2 ?

No, the NTLM2 Session response.

> On other hand I can't see a way to use non-NTLM (CRAM-MD5,APOP etc)
> authentication methods with ntlm_auth. Looks like they can't work together
> and IMHO it's not an interoperability improvement.

Use of ntlm_auth allows use of external password databases, but doesn't
prevent the use of other mechanisms in any way.  As I mentioned before,
I'm quite willing to work with developers in the implementation of an
appropriate callback to allow application that already assume 'I have
the plaintext' to have Samba at least handle the NTLMSSP parsing and
authentication.

> > Perhaps we have different aims - but I had hoped that there was some
> > interest in the corporate mail server space, where proper domain
> > integration is critical, and single-sign on (which is what NTLMSSP
> > provides) is expected.
> 
> Yes, my primary concern is standalone mail servers. It's what I'm payd for
> after all :)

Indeed, we all have our focus.  :-)

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at samba.org
Authentication Developer, Samba Team            http://samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://dovecot.org/pipermail/dovecot/attachments/20040927/206a9627/attachment-0001.bin>