[Kolab-devel] Re: a few more questions/ldap-frontend

[Jochem Ippers]

Hi,
probably you already know it: there is a web-frontend for ldap called gosa, which has just been gpl'ed, you can administrate unix (nis) and samba accounts with it (and a lot of other things, they have some own object schemas), maybe you could use some of its code / melt it together with the kolab-frontend (perhaps by changing the basic ldap-structure).
Regards
Jochem Ippers

gosaproject-homepage: https://alioth.debian.org/projects/gosa/
demopage: https://gosa.gonicus.de/


> Jean-Michel Dault <jmdault at mandrakesoft.com> schrieb am 10.09.04 05:54:53:
> > 
> > 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>
> > 
> > _______________________________________________
> > Kolab-users mailing list
> > Kolab-users at kolab.org
> > https://kolab.org/mailman/listinfo/kolab-users
> 
>