On Mon, 2007-07-02 at 20:19 +0400, Dmitry Butskoy wrote:
Timo Sirainen wrote:
- Currently I strip domain part of the username returned, i.e. from "DOMAIN\user" just to "user". Maybe better add some option "auth_winbind_strip_domain" for this?
What if you changed it to user@domain? Then you could use Dovecot's standard %n or %u variables.
AFAIK "user@domain" should have an actual form of "user@example.com", but "ntlm_auth" returns "EXAMPLE\user" in such a case, not "EXAMPLE.COM\user". At least for NTLM (against AD). OTOH the spnego could retrurn the actual "user@example.com", but it is still unknown to me :)
I don't think it's a problem even if it returned only user@example. %d then just expands to example. At least I think it's better than not having the domain at all.
There's one thing I'd want changed: make it non-blocking. Both input and output are currently blocking, so dovecot-auth is stuck while waiting for ntlm_auth to reply. I want to avoid this whenever possible (I don't ever want to see "authentication just gets stuck, why??" mails. "ntlm_auth timed out" message in log is much nicer).
I guess ntlm_auth can handle only a single session at a time?
No.
I mean simultaneously. Like you can't send multiple "begin/continue authentication" commands to it and then just wait until one of them finishes?
There's one thing I'd want changed: make it non-blocking
Still actual after the clarification above?..
Yep.
So this would pretty much require that you either implement some kind of a queue
Currently I prefer to use blocking io, which provides such "a queue" de-facto. At least for initial implementation. (I hope "ntlm_auth" is fast enough).
I think the problem isn't ntlm_auth itself, but that it also has to talk to AD. So any network problems there could leave it hanging.
But some timeout surely could be useful. How can it be implemented?
By using non-blocking I/O :)
or execute multiple ntlm_auths.
Does the use of worker for, say, PAM userdb affects us here too?
PAM is passdb. But anyway it shouldn't affect.
Or maybe both. Using auth worker processes would probably be best. Unfortunately that currently works only for passdbs and userdbs, not for mechanisms. I guess I could try changing this for v1.1, unless you want to try? :)
It seems that I prefer you try it... :)
Does "blocking io" + "worker" look like the best way?
I think so. Or some kind of a generic queue maybe.. Hmm. Doesn't GSSAPI have the exact same problem? I think it does. Maybe I could figure out something for them both.