[Kolab-devel] Custom UID and Kolab Future

[Mike Hurn]

Discussion moved from kroupware@

Some thoughts, observations and suggestions on UID's and Email servers
controlling multiple domains. This may only be of use to Kolab > 1.0 but
hope that the following is of some help in developing Kolab into a identify
management system.

First I suggest that the UID generation this split out into a separate PHP
program. For example the "genuid.php" would be passed all the necessary
values needed to generate a UID and check that it has not been used before.
The same principle could be applied to the generation of email addresses.

Moving on to Email servers controlling multiple domains, my wife makes use
of such an email server. Her true email account takes the form
domainnamenumber at domain.tld although to the outside world it is
claire.hurn at domain.tld as the account has been setup with an alias.

Therefore given the account password and the name of the mail server, I only
had to configure Outlook with:

Account Name: domainnamenumber
Password: xxxxxxxx
mail server: mail.domain.tld
email address: claire.hurn at domain.tld

When I do a packet capture on her email access (with a reverse lookup on the
IP address) I see that the email server is also known as
mail.serviceprovider.tld. No doubt the sysadmin has configured their DNS
server with a CNAME record for each of the multiple/virtual domains they
support.

Putting this into LDAP terms I would expect to see something like:

dn: uid=domainnamenumber, ou=People, dc=serviceprovider, dc=tld
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: Top
givenname: Claire
uid: domainnamenumber
sn: Hurn
mail: domainnamenumber at domain.tld
userpassword:
cn: Claire Hurn
mailaliasmap: domainnamenumber at domain.tld claire.hurn at domain.tld

Note: I have invented mailaliasmap to help with the explanation. That I put
users under the organizational unit of ou=People to follow conventions used
with other directory server configs that I have worked with. To learn more
take a look at the SAMBA documentation and how RedHat and other
distributions use the OSS LDAP tools from
http://www.padl.com/OSS/MigrationTools.html.

It also means that I can setup access controls to give anonymous read access
to a limited number of attributes under ou=People, dc=serviceprovider,
dc=tld. This may also help with the known flaw with Kolab <= 1.0, that too
much information is revealed under an anonymous LDAP browse of the directory
tree.

To quote Bernhard Reiter:
****
There is a complex interaction with email aliases and freebusy lists
and we needed to accommodate email names with dots in them
as main email addresses.  Only the main email address with give you
the right freebusy list because the name is used to save this file.
****

My suggestion is to reverse the primary and alias email addresses. To help
with system maintenance I think that the email address of uid at domain.tld
should always be kept even if it is only used internally. In this way it
will always be possible to send an email the a users logon. I thinking that
the directory server is also used as the common core to an identify
management system giving LDAP controlled Single Sign On (UID's) for multiple
systems.

To quote Bernhard Reiter again:
****
I don't see a principal problem with these login containing
an "@" sign. It has the advantage that you are remined where you try
to log-on in the name it self. :)
****

I think that you will find that a number of systems limit the number of
characters that can be used in a login ID, try using your email address as a
login ID on a Windows system. (The size limit under Windows is 20
characters.) The point is that you should be able to use the same ID
wherever you login. For most systems 6-8 character login's should be ok.

Please think about using the Kolab OpenLDAP server to authenticate:

Windows login's via a Samba Primary Domain Controller.
Standard Unix/Linux login's.
As well as the Kolab Email accounts.


Michael E Hurn, Mike at Hurn.ca, www.hurn.ca
11036 Swan Crescent, Surrey, British Columbia, V3R 5B6, Canada
Phone:1 604 585 HURN (4876) Cell:1 604 780 HURN (4876)
----- Original Message ----- 
From: "Bernhard Reiter" <bernhard at intevation.de>
To: <kroupware at mail.kde.org>
Sent: June 27, 2003 7:20 AM
Subject: Re: [Kroupware] Re: Custom UID and Kolab Future


> On Thursday 26 June 2003 01:36, Donald Loflin wrote:
> > On Wed, 25 Jun 2003, Bernhard Reiter wrote:
> > > On Tuesday 24 June 2003 18:00, Christopher Lewis wrote:
> > > > Martin is basically saying that the full e-mail address is the UID
> > > > now, and there are no plans to change this.
> > >
> > > The aim of the group of companies is to conclude the Kroupware-Project
> > > first and continue to support the resulting Kolab-Server (probably
> > > 1.0.x).
> >
> > If the aim is to fulfill the Kroupware contract goals, then why
> > was email-as-UID introduced in the first place?  I remember
> > reading that the contract did not require multiple/virtual domain
> > support (or did I read it wrong..), therefore the UID could have
> > been left as it was (or, the auto-generate code could have just
> > used the first part, up to but not including the "@").
>
> There is a complex interaction with email aliases and freebusy lists
> and we needed to accommodate email names with dots in them
> as main email addresses.  Only the main email address with give you
> the right freebusy list because the name is used to save this file.
>
> Thus the server guys decided that switching to this different
> concept would solve that problem in a better and be a general
> improvement, too.
>
>
> > > Martin already stated that having the option of using a different UID
> > > from the email will probably reintroduced, if there is good interest
> > > to make the easier again.
> >
> > Add me to the list of those interested in, like Christopher Lewis,
> > having custom or admin-settable UID's - mainly,
>
> Yes, thanks for the feedback and interest.
> As said you are all welcome to contribute to the further development
> as coordinated on kolab-devel at .
>
> > I object to any
> > login name having an "@" in it, and I know my users will too.
> > Chrisopher listed many of the reasons, but I'm also concerned that
> > for some systems, the extra-long name or the "@" sign will just
> > not work - ie not be an allowed character.
>
> True, like you cannot use this login name in an URL with login
information,
> because then you would have two @ signs in it. :)
>
> > Another umm, "desire"
> > (ie probably not possible anyway) is I want to "drop in" Kolab as
> > a replacement for the current mail server, and not require my
> > users to change any (or not many) settings in their client.
>
> Yes, though it will require a team effort to polish possible migration
paths.
> The components used for the Kolab-Server come with a lot of
> power and flexibility. For a system administrator that can setup
> up these components reasonably on her own, Kolab can already
> be nicely customized. And in many cases there are special requirements
> and you need to adapt your installation for it anyway.
>
> >  And, I think using the email
> > address as a login name (UID) will conflict with trying to expand
> > Kolab into a Single Sign On server later (do you use your email
> > address to log in via SSH?  I want my SSH login name and my IMAP
> > login name and my fileserver login name, intranet, etc, etc to be
> > the same).
>
> I don't see a principal problem with these login containing
> an "@" sign. It has the advantage that you are remined where you try
> to log-on in the name it self. :)
>
>
> _______________________________________________
> Kroupware mailing list
> Kroupware at mail.kde.org
> http://mail.kde.org/mailman/listinfo/kroupware
>