global admin without defaultdomain?

[Igor Brezac]

On Tue, 30 Dec 2003, Ken Murchison wrote:

> Igor Brezac wrote:
>
> >>Ummm.. there aren't many mechs on my system :-) But at least this
> >
> >
> > Read cyrus-sasl/doc/
> >
> >
> >>Would you like me to post my config again? I don't know what to tell you
> >>about my configuration to make you believe me when I say I can't connect a
> >>global admin through anything but localhost. If I had the time and I was
> >>more understanding of C, I'd dive in the code and hunt it down, but the
> >>best I can provide right now is evidence. I don't know how bad I could
> >>screw the configuration (and I'm pretty good about reading docs), so I
> >>really don't see why this looks suspicious.
> >
> >
> > Well, something has to be different.  I never ran 2.2.2-Beta and perhaps I
> > incorrectly assume that there is very little difference between it and cvs
> > head.  The code prior to recent Ken's commit discards domain part of the
> > username if the username is in defaultdomain.  So, I do not understand why
> > do your admin logins have domain in the queries.  This can also explain
> > why you are only able to connect to localhost with your admin userid.
> >
> > Ken, any ideas?
>
> You could verify by looking at the commit logs, but I don't recall
> changing much of anything in the virtdomains code recently.  So the
> current CVS should be identical to the last beta release.
>

Ken,

I think I found what is causing the problem or at least unpredicteble
behavior.  %r will have a value regardless of whether an application
(imapd in this case) passes the realm to the auxprop.  saslauthd auths do
not work this way.  This is also somewhat related to bug #2326.  Why does
serverFQDN need to be used to realm when user_realm is not available?
Other auxprop plugins do the same thing...

    if(sparams->user_realm) {
        user_realm = sparams->user_realm;
    } else {
        user_realm = sparams->serverFQDN;
    }

-- 
Igor