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.
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.
Domain membership was not a goal, at least until you started this thread.
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.
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.
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.
NTLMv2 ? 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.
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 :)