Re: saslpasswd2 and virtdomains


Subject: Re: saslpasswd2 and virtdomains
From: Igor Brezac (igor at ipass dot net)
Date: Sat May 17 2003 - 00:14:56 EDT


On Fri, 16 May 2003, Jeremy Rumpf wrote:

> On Friday 16 May 2003 07:20 pm, Igor Brezac wrote:
> > On Fri, 16 May 2003, Sean Chittenden wrote:
> > > > I've tried several alternative command lines but can't seem to get
> > > > saslpasswd2 to create a user unqualified by a realm.
> > > >
> > > > saslpasswd2 -c cyrus
> > >
> > > saslauthd doesn't jive well with virtual domains at the moment. You
> > > have to use the sasldb mech instead of saslauthd.
> > >
> > > That said, are there any plans to have virtual domain support work
> > > with saslauthd? I just bumped into this and found it painful to
> > > figure out.
> >
> > What do you need saslauthd to do? saslauthd gets user at dom dot tld, it is up
> > to the selected auth mech to handle this username.
>
> I suppose I should break out of my shell sometime soon with some of my ideas
> on saslauthd and request some feedback. Probably, most of which would have to
> be done in tandem with Igor's work.
>
> Please note, this is from a cyrus 2.1.x perspective. I have yet to start
> playing with cyrus 2.2. I'm also assuming that we put realms and domains into
> the same category. Hence, user at dom dot tld transposes into user=user
> realm/domain=dom.tld.

domain != realm. saslauthd can put them into the same category, but
I do not think this is the right solution.

> Now the idea is to make saslauthd multi realm/domain aware. Currently
> saslauthd (primarily from an LDAP perspective) queries a single server
> regardless of the realm/domain specified during the authentication. In
> addition, saslauthd can only use one mechanism per instance. Ie. using either
> LDAP, krb5, etc. but not all or any combination of the available mechanisms.

I like this idea. However, I think the biggest obstacle for the virt
support is the underlying auth mech. Most of them do not support
usernames in the form of an email address, pam and shadown come to mind.

> What if we made a global config file for saslauthd where the admin could
> define something as such.
>
> /etc/saslauthd.conf
>
> realm dom1.tld {
> mech krb5
> }
>
> realm dom2.tld {
> mech ldap
> ldap_servers ldap://ldap1.somedomain.com/
> ldap_bind_dn cn=roquery,ou=users,c=US
> ldap_bind_pw xxxxx
> ldap_timeout 20
> ldap_search_base ou=addresses,ou=mail,c=US
> .........
> .....
> ..
> }
>
> realm dom3.tld {
> mech ldap
> ldap_servers ldap://ldap.somedotheromain.com/
> ldap_bind_dn cn=roquery,ou=users,c=US
> ldap_bind_pw xxxxx
> ldap_timeout 20
> ldap_search_base ou=addresses,ou=mail,c=US
> .........
> .....
> ..
> }
>
> realm dom4.tld {
> mech krb5
> }
>

This is nice, but what do you do if you have hundreds or thousands of
realms/domains? I like the current ldap solution because it forces you to
solve this problem with the ldap design.

I think this type of setup still has its place specially for stacking
auth mechs.

>
> As you can see, the chosen mech to be used would be configurable based upon
> the realm/domain of the authentication. For the instance of the LDAP mech,
> even a different server could be queried based upon the realm/domain. This is
> also true for the krb5 mech, but the server to be queried is contained in the
> separate krb5 conf file where it makes server decisions based upon the realm
> passed to it via saslauthd. Hence only specifying "mech krb5" is necessary
> for the krb5 mech.
>
> This idea is more centric toward ISP style installations or collegiate
> "central services" type situations. In my arena, collegiate "central
> services", we could have a central email system accepting/storing email for
> the end users, but we leave authentication and password management to the
> lower level departments and their servers. Each department, usually Win2k or
> WinXP domain servers, maintain the end credential stores. Similar benefits
> could be had for ISP style setups.
>
> Does this sound feasible? Is this a feature that folks could possibly use?
> Would the CMU folks consider such a radical change to saslauthd?

I think efforts need to be redirected toward auxpropd.

> At any rate, from my perspective, the first step would be adopting a central
> config parser/loader similar to what cyrus has (or maybe even adopting
> cyrus's config parser). Then adapting the LDAP mech to use it (IIRC currently
> uses it's own internal config parser).

True. It is pretty much a copy of the cyrus' config parser.

-- 
Igor







Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD