[Kolab-devel] [issue3087] How to deal with a domain change in the login name?

[Richard Bos]

New submission from Richard Bos <ml at radoeka.nl>:

How to deal with a domain change in the login name, say the login
should be changed from user at domain1.tld to user1 at domain2.tld.

A discussion started at the user kolab ML list.  This issue is to track
this.  Perhaps someone comes with the start of a conversion, and this issue
may help to show the progress or its succesfull usage, etc.

The ML discussion is archived here:
http://www.kolab.org/pipermail/kolab-users/2008-September/008769.html

> > It would be nice if a script pops up, that could take care of the change.
> > Perhaps that the script can be stored / developed on the wiki or perhaps an
> > issue should be opened for this.
> >
> > Related to this is a domain name change from domain1.tld to domain2.tld.  
At
> > the end the users login name (user at domain.tld) should be changed to.  This
> > will be quite challenging...  Also in this case a supporting script would 
be
> > nice to have.
> 
> I guess the old domain should be kept. 

That might be, but company names changes happen often.  Have a look at the
financials its changes everyday there nowadays...  Take for example
abnamro, which was bought was Fortis last year, and yesterday it was sold
to Ing.  I can't believe that people want to stick with the old company
names as that might be "political" incorrect.  As such it should be
possible to rename the stored data, isn't it?
Perhaps a solution is a domain that is not tight to the company domain,
something like user at group.wr, but that is a bit weird.

> Renaming all the users does not  
> make too much sense as that also affects the data stored in IMAP. Its  
> easier to solve that by using aliases.

Ah, that is a good trick.  But in the end it might be that there will
be user data stored under e.g. abnamro, fortis and ing (see example
above).

> On the other hand this might also cause problems if you add newer  
> users in your new domain. They won't be able to share IMAP folders  
> with user created in the old domain.
> 
> So there are indeed other things to think of. Would be nice to do that  
> via a script, yes.

Ah, we agree :)

And more was added by Andrew J. Kopciuch:
Not to mention the breakage of the mail itself.  The mail spool is stored on 
disk under the domain.  That would have to be moved, and I have no idea about 
the side-effects of that.

You already mentioned the ACLs stored in IMAP, which would also be broken.  
There's also the sieve and freebusy information that would need to be moved, 
and I'm also not sure about any data changes required there.

To throw another wrench in the mix, imagine multiple slaves?

There are several pieces that are tied to the FQDN, both in LDAP, and on disk.   
It's not a trivial thing to change the FQDN.

Aliases could instantly provide a new email address, but the UID would still 
remain under the previous domain (if you just used the default UID ... which 
I assume most people would).

I realize I am not providing much help here, but my brain is flying in all 
directions thinking about what a FQDN change would require.  Large 
installations would be a massive amount of work.

----------
messages: 16858
nosy: rbos
priority: wish
status: unread
title: How to deal with a domain change in the login name?
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3087>
___________________________________________________