Renaming Luminis User Accounts (uid)
Recently, we had to change about 20,000 student accounts on our network from legacy format (old_userid), to Banner generated spriden ID's (new_userid). When I contacted Luminis Support, we were told that there's no tool to change the accounts in luminis, and the only way to change the account, is to create a new one, and delete the old one. The problem with this approach is that any customization to uPortal layouts, or cpip connector passwords, INB pins, self service credentials etc, etc, will be recreated. Of course, those are just a few of the potential problems. I've heard that Luminis developers are working on a tool that will have a capability to rename user IDs in the future, however, we had to the change on January 1st.
There is a way to change the account, however, this method has NOT been approved by SCT. Therefore, please use this information at your own risk.
To change the user ID in luminis, there are 2 general areas to modify:
SUMMARY:
I. Luminis uid entry in LDAP.
II. uPortal Database entry at UP_USER.USER_NAME.
III. Clean up with an XML import for cptool, just in case...
IMPLEMENTATION:
I. The Luminis LDAP entry controls the login, single signon credentials and portal roles. To change the luminis uid entry, the easiest way to do this is to create an LDIF file. Then run ldapmodify to apply the changes.
The ldap file student_renames.ldif should be the following format:
dn: uid=old_userid1,ou=People,o=your.edu,o=your.edu
changetype: modrdn
newrdn: uid=new_userid1
deleteoldrdn: 1
dn: uid=old_userid2,ou=People,o=your.edu,o=your.edu
changetype: modrdn
newrdn: uid=new_userid2
deleteoldrdn: 1
...
The command to apply the changes is:
ldapmodify -c -v -f student_renames.ldif -D "enter your DS user here" -w enter ldap passsword here
II. uPortal tables control the interface, channel layouts, targeted Announcments, etc, etc. If UP_USER table is NOT updated, a brand new record will be created for new_userid1, and to the user it will look like the portal layout has reverted to default. Therefore, it's a good idea to run this also. To change the uPortal account, create an sql script student_renames.sql with the format below for accounts to be renamed:
update LUMADMIN.UP_USER set UP_USER.USER_NAME='new_userid1' WHERE USER_NAME like 'old_userid1';
update LUMADMIN.UP_USER set UP_USER.USER_NAME='new_userid2' WHERE USER_NAME like 'old_userid2';
...
To update the records, execute
sqlplus lumadmin_db_username/enter_db_password_here @student_renames.sql
To automate the entire thing, you can create a script in your favorite language to generate the student_renames.ldif and student_renames.sql files. I have an MSSQL server and therefore created a DTS that scanned a cross-walk table which had the old and the new user id, and then wrote out an ldif and sql files. Then it uploaded the files to Luminis (our luminis is on Oracle, but you can create a DTS that will do the database update directly in DTS via an oracle driver, or mssql. I wanted to keep a file for the record). After the files were uploaded to Luminis server, I executed the following script:
#update the ldap entries for users
#get rid of DOS ^M characters
echo "Cleaning Files from DOS ^M "
dos2unix student_renames.ldif student_renames.1.ldif
mv student_renames.1.ldif student_renames.ldif
dos2unix student_renames.sql student_renames.1.sql
mv student_renames.1.sql student_renames.sql
echo "Updating DN entries in LDAP (Luminis accounts)"
ldapmodify -c -v -f student_renames.ldif -D "cn=your_directory_manager_account" -w enter_ldap_passsword_here
#update the database entries (accounts)
echo "Updating UP_USER uPortal accounts"
sqlplus luminis_db_owner_account/enter_db_password_here @student_renames.sql
III. get an XML import of all renamed accounts and use cptool to import them. This is just in case you missed something. This step is not necessary...
Dmitriy Bond.
But wait, there's more
We have been talking about user name changes for some time now and recently began developing a script to perform them. We found that there are many places where data would need to be changed if the name change was going to be 'complete'.
The ldap record also has entries in it for e-mail which had the users old id. Plus, we had an external system integraded via CPIP that had a pdsExternalSystemID containing the old id. There are potentially others, but we know those exist. So, our approach has been to export a complete ldif file for the old user, then string replace the old user id to the new one. Then import that new ldif file.
The ldap entries for courses contain attributes for the students and facutly in the course. For example, they would have entries like pdsStudents=uid=,ou=People, and pdsInstructor=uid=,ou=People,. So, we get a list of all the courses the person is attending or teaching and then run process a file via cptool that has add instructor/student commands in it accordingly.
Then, there are other places we found in the database that could potentally (and quite likely) have the old id. I am not certain if these changes are neccessary...but for safety sake, we want to have them changed. The 'grouptools' database has a few tables with the old id in it. For groups there is a GT_USER table that has a USER_NAME column with uids in it. However, it also has a USER_ID column (internally used as the key between the tables) which corresponds to a pdsExternalSystemID attribute on the person record. It may not be neccessary to make these two items match between the LDAP record and the DB record...but, we thought it was safest to make sure they did. Also in the grouptools database are tables for targeted announcements. One of these (TA_X_USER) has a USERID column with user ids in it which would need to be updated. Then, there is a table called IC_MEMBER which has a USERID column which might have a user id in it which we include in the update. I say might because I actually don't know what the table is used for...for us the table is empty. As for the uPortal tables, we found UPC_GROUP_MGR has an OWNER_ID, UP_PERMISSION has OWNER, and UP_PESON_DIR has USER_NAME. We include these in our DB update because the columns are varchar rather than numeric. It seems that the columns which are primary/foriegn keys within the application are numeric. However, if we happened to be wrong and one of these tables/columns is not a uid then it is highly unlikely that the column would contain a 'real' uid...so, nothing would get updated and no harm done. On the other hand, if these are indeed uids, then we would want it updated. Those are all the places we had found and believe it is complete...but of course we could have missed one.
Now, on to the calendar. The most complicated problem turns out to be the calendar. The calendar database has entries in it with your user id. Also, the ldap contains idsCalendar, icsCalendarOwned, and icsSubsribed entries with the uid in it. Since we took the approach of modifying the entire person record, these attributes would be changed. Therefore we need to change the calendar accordingly. To do this, we get a list of all the calendars for which the user is primary owner. We then export all of these calendars into ics files. The ICS file is text, so we perform a string replacement on it for old id to new id. Then, import these ics files back into the calendar. There are still some issues when doing it this way. For example, if someone else has invited 'this user' to an event, we think the linkage to 'this users' calendar would be broken...if the other user updated or deleted the event we think 'this user' would not see the modification. This has not been verified yet. These modifications may not be neccessary if the ics* entries in the person record are left alone. We had not gone through that very much, so I could not say.
We have tested the process/script internally and it seems to do what we want. The next step is to get some users who are willing to test it for us. I am not sure when this would happen.
So, what is my point? Well, to give food for thought to the name change process I suppose. It is rather complicated, in my opinon anyway, and I could have missed something. I have not explicitly offered to provide the script because I am not sure it is 'ready'. I have a high degree of confidence in it...but we haven't even gone into a production state with it. Also, I would offer no support nor assurances that it would not completely destroy your system. I am hoping that if you are interested in doing a name change, then the info would help. Plus, he script was created with what I believe is a deep understanding of the system. I don't feel particulary protective about the knowledge or the script. Rather, I think it is good to know about the data elemets being modified. Lastly, I talked with SCT at the Winter JA-SIG conference and was told that user name changes will be in Luminis 4. So, maybe it is better to wait for a vendor supported version...assuming it does not get cut out for some reason. Having said all of that, I can provide the script...with lots of stipulations about its support and reliability or lack there of.
Steve
You are right
Steve, you are right that there are more areas, like TA_X_USER and pdsExternalUser entires, and email, etc... I didn't have to change those because we are not using email, groups, or calendar. For all cpips, we're using the luminis userid (_CPUSERNAME) and therefore have a random entry in pds. But I'm glad you mentioned this, since others maybe relying on this information.
It's easier to pull a tooth, than to change an account in luminis.
Thanks,
Dmitriy B.