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.
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@samba.org Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net