Information for Chair Admins on deletion and extension of users

From autumn 2017, we will introduce the new automatic process for expiry and deleting user IDs. This means that identifiers are automatically deleted as soon as they are no longer needed.

What does the Chair-Admin have to do to prevent his users from being deleted?

Via the structure database admins can keep track of their users and their status. The overview with all columns necessary for this purpose is accessible via the URL https://rbgwebapp.in.tum.de/struktur/treeview/intum.I01.user?c=valid,status,dateexpire,tumuid . In the URL 'I01' can be replaced by the desired chair (for mathematics 'matum' instead of 'intum'). It is best to bookmark this URL.

The list can also be reached via the homepage https://rbgwebapp.in.tum.de/struktur/treeview by selecting the item 'user' under a chair, then the columns have to be displayed individually via 'Columns'.

To prevent users from expiring incorrectly, you should check the following points from time to time:

1. Are all users listed or are some missing? Users may be assigned to the wrong chairs.
2. Tumuid: As far as known, the TUMonline credentials should be entered here for all users. Then we use the TUMonline database to automatically extend the dateexpire again and again as long as the user is still listed as an employee.
3. Dateexpire (expiration date): If this is in the past, the user will be blocked at the next opportunity. If the automatic renewal (see point 2) does not work, you can increase this date yourself.
4. Status: S for Students, W for wscientific and notwscientific staff, G for Gguests. The automatic extension (see point 2) only works if the status here does not contradict TUMonline.

If the data, e.g. expiration date or deletion status, are wrong or have to be updated: Tumuid and Dateexpire can be changed by the admin himself (click on the user and then 'Update', see also StrukturDBfuerLehrstuhlAdmins).

The status cannot be changed directly, but as described in the following via an application.

Application to take over student accounts, accounts from other chairs, or former staff members

Some identifiers have a wrong status, usually in the following cases:

• Identifiers of IT staff members who had an identifier as a student: Here the status must be set to 'W
• Identifiers of mathematics staff who had a computer science identifier as a student: Here we have to create a mathematics identifier with status 'W' (and if necessary also change the computer science identifier to status 'W') - simplifications are already planned for the future.
• Identifiers of mathematics hiwis who have a computer science identifier as a student: A mathematics identifier with status 'S' must be created here.
• Identifiers of former employees who continue to work at the Institute as guests: Here the status must be changed to 'G
• Identifiers of employees or guests who have changed chairs
  In all cases, we ask that you submit a user request via one of the following two links, similar to new users. In particular, please indicate the date on which the employee started or became a guest.
• Application form for new account or additional account
• Request to reassign an existing user

If the web form is not suitable, the old paper form can also be selected in exceptional cases. The appropriate forms are available on the RBG homepage. Please also specify the data for the paper form as described in the paragraph above.

Since users are not assigned to a chair without an application, the chair admins have control over which users are assigned to their org unit.

After a user is assigned to a chair, the chair admin has to set the 'printaccount' for the user, if it is desired that the user should be able to print on chair costs.

It is not sufficient to hand in Guest Applications at the personell office (Personalbüro). These applications are not available to the RBG, i.e. the identifiers are still deleted.

What happens after the expiration date has passed?

Our ageing mechanism processes all expired identifiers at certain times once a week and marks them as 'flagged for deletion'. This starts the expiration process.

At first the chair admins will receive a mail for which users the expiration process has started. We try to accumulate the expiration dates in such a way that this mail usually comes 4 times a year in order to not to burden the admins with unnecessary mail floods. The mails are sent to the address which is entered in the StrukturDB as 'admin_mail' in the org unit.

We ask the admins to look through the mails to make sure that no users are erroneously deleted, and also to react if the maintainer needs to be changed for other entries (see below).
At this point, the admin can still stop the deletion process (as described in the sections above) without the user noticing or having to do anything.

About a week or two later, users will be notified by email that the identifier is expiring.

30 days later, the ID is then deactivated (in the user database: valid=0). This makes it unusable. Shortly before this, the users receive a second warning mail.

Another 30 days later, the identifier is deleted.

=> If all users read their computer science or math mailbox at least every few weeks, the deletion will never be unprepared.

What do I have to consider when deleting an account?

• Often the outdated users are still registered as maintainers for other users or hosts, project identifiers, groups, or similar. In order to keep our structure database clear, we ask that you always make sure that the successor is entered as the maintainer everywhere when these maintainers leave. You can list the maintained entries by clicking on 'Show references to this entry' in the user database of the maintainer. You will also be notified by email if a running user is still registered as a maintainer.
• Hosts where the user is listed as 'owner' instead of 'admin' will not be listed using the method described above. This is because 'owner' is a free text field and may also contain names that are not (anymore) known to the user database, e.g. because laptops occasionally still lie around somewhere until they are deinventarized or reassigned at some point. So you should check the chair's host entries from time to time and see if they can be deleted.
• Old files that belong to the user are sometimes found not only in the computer hall (Rechnerhalle), but also on chair servers. If the user is deleted, the files should either be deleted or chowned (change owner).
• We will automatically remove the following directories: Home directory in the computer hall - or in mathematics on the chair file server; mailboxes on the mail servers of the RBG.

Delete users manually

You can trigger the deletion process for user accounts yourself. This can be helpful, for example, if you do not want to wait for the expiration date, or if an account was created incorrectly or twice.

To delete a user, go to the entry in StructureDB ('Go to'), click Update, and set the deletion status to 'Flagged'. Then the user is treated as if the expiration date has been reached: First the admins receive another mail, then the user receives a mail, then he is deactivated after 30 days.

This only works with users who are correctly assigned to your chair.