On Mon, 2004-09-27 at 16:44, Andrey Panin wrote:
I'm pleased to see another project increasing compatibility with windows clients, by the addition of NTLM login support, but I'm a bit worried about a few implementation details, and hope to offer an alternate approach.
I mean no disrespect to those who have implemented to the code so far, but I feel that the idea of 'everybody re-implement NTLM' is prone to failure.
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 ? :)
A lot, actually. There are serious issues with even simple ASCII/CP850 interactions as it applies to usernames, domains and passwords - that is why Unicode is standard and expected in NTLMSSP. Perhaps more importantly, on the Samba team we have found that matching Microsoft in the move from ASCII to Unicode solved bugs, and avoided untested codepaths on the Microsoft client.
- NTLM2 (a negotiated scheme to avoid sending the LM response) is unsupported
Did you RTFS ? Or may be I missed something ?
I did. This is not NTLMv2, and yes, the naming is confusing. While NTLMv2 is configured, the NTLM2 case is negotiated.
NTLM2 replaces the LM response with a client-supplied challenge, to avoid server-side known plaintext attacks. http://davenport.sourceforge.net/ntlm.html#theNtlm2SessionResponse
- NTLMSSP is NDR, not 'C struct pushed to the wire', it needs to be correctly marshaled and unmarshaled.
Yes, it's not a C struct, so what ? Where is the actual bug ?
In my reading of the code, it appeared not to cope with the multiple forms that NTLMSSP can take, and in particular the Dovecot code seemed to perform some of the conversions by cast.
I'm just a bit worried about some of the parsing code, given the issues that we (the Samba Team) have had in the past. I'm also hoping that this particular nasty can of worms can be kept in one place, where we can implement all the protocol twists and turns, as we come across them.
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.
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...
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).
This is why I've been working with projects to see how we can best provide Samba's domain membership services beyond just PAM and nss_winbind.
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.
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.
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.
I have enjoyed using Dovecot on my own networks, backed against PAM for authentication. I'm still trying to see how Dovecot's own password database fits into all this however (and why we ended up with one password database per application.. :-)
I'm quite willing to work with developers of independent software packages to see how Samba can be of most assistance. If the issue of 'I need my own password db' is the real sticking point, I'm quite willing to add a callback in ntlm_auth, to fit into such a scheme (I did not propose this intiailly, as otherwise this function is present and working in every Samba 3.0 version).
Thanks,
Andrew Bartlett
-- Andrew Bartlett abartlet@samba.org Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net