a few more questions

Jean-Michel Dault jmdault at mandrakesoft.com
Fri Sep 10 05:51:22 CEST 2004


Le jeu 09/09/2004 à 16:30, Martin Konold a écrit :
> In the future we want to have real multi-domain support. For this we must be 
> able to completly seperate user1 at domain1.tld from user1 at domain2.tld. Without 
> the domain part we cannot guarantee that there will be no conflicts.

Then, use this structure:

o=top
|-- uid=manager,o=top (global Kolab manager)
|
|-- dc=domain1.org,o=top
|    |
|    |-- uid=user1,dc=domain1.org,o=top
|  
|-- dc=domain2.org,o=top
|    |
|    |-- uid=user1,dc=domain2.org,o=top
| etc...

This way, each domain can have their own managers/maintainers, users,
folders, etc, and you can control everything using ACLs.

Then you instruct saslauthd to use:
ldap_filter: (|(&(uid=%U)(dc=%d))(uid=%u))

So it can either work with user at domain for those users who belong to a
specific domain, or with no domain part for global users.

> > Besides, what most ISPs do these days is assign a random user, for
> > example b1i8rug6, which gives 36^8 possibilities (enough for every human
> This is imho a very suboptimal solution as it requires people to memorize a 
> very odd sequenze of strange letters which are not necessarily globally 
> unique in order to log in.
> Remembering the email address (which is guaranteed to be globally unique) is 
> much more user and admin friendly.

You make a good point about user friendliness.

However, most ISPs prefer to have a random user instead of an e-mail
address, specially after the wave of mergers and acquisitions we have
seen. I've started three ISPs, and each time they were bought by a
bigger one, or merged. Some of my old customers from the good old days
told me they changed e-mail addresses 6 times!

Furthermore, most global ISPs (dial-up/cable/DSL) have reseller plans
where they give each local ISP a batch of random usernames that they can
assign to a domain or another. Or they mass-mail a bunch of CDs with
random usernames, like Compuserve/AOL. Then, resellers, or users
themselves can login, and create their own e-mail address.

Another thing I've found in my ISP history is that people like to change
their e-mails. It can be because they receive too much spam on an
address, or in the case of a divorce because their wife fell in love
with someone on IRC, they want to change peterandmary at domain.com to just
peter at domain.com. And don't laugh, I've seen this happen too many times,
it's very sad.

If the primary key is the user's email, it's a major hassle to change it
to something else. You need to rename the mailbox in Cyrus, change ACLs,
etc. Whereas if you use a random uid, you just remap that uid to another
email.

> > I have rewritten Kolab 1.0 to manage user without an @domain part, and
> > made it work with Samba and pam_ldap. There will be a lot of work to
> > port it to Kolab 2.0, but IMHO it's definitely the way to go.
> Kolab 2 is explicitly prepared to work with samba and pam_ldap.

There are many things missing: you need to add the right schemas, create
a globally unique uidNumber, sambaSID, and you need a way to synchronize
userPassword with sambaLMPassword and sambaNTPassword. I haven't seen
any code in Kolab 2.0 to do any of that, correct me if I'm wrong.

> Last but not least more and more other organizations including Microsoft 
> (sic!) are starting to use name at domain in order to separate different realms.

It's OK if they *choose* to.

As long as we can authenticate *with* or *without* the @domain part, I'm
happy.


-- 
Jean-Michel Dault <jmdault at mandrakesoft.com>




More information about the users mailing list