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 [EMAIL PROTECTED] Then you could use Dovecot's > > standard %n or %u variables. > > > > AFAIK "[EMAIL PROTECTED]" should have an actual form of "[EMAIL PROTECTED]", > 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 "[EMAIL PROTECTED]", but it is > still unknown to me :)
I don't think it's a problem even if it returned only [EMAIL PROTECTED] %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.
signature.asc
Description: This is a digitally signed message part
