Hi Jason,
The option I described in my previous post was actually used for exactly what you describe.
In my previous job we used an external authentication source called Cosign with user data fed by LDAP. We had an LDAP field for each user account (uolOwnerCid) which referred to a unique person object. Every person in the University had one, and only one, person object even if they had multiple user accounts.
As part of the login checking phase, we would:
- take the authenticated username, and feed it into LDAP to get the CID associated with that user account;
- check whether an account with that CID was present in the mapping table I described;
- if so, then take the username associated with that CID and pass that to the rest of the login phase;
- otherwise create a new mapping and pass the supplied username;
- continue login with the specified username
This allowed us to handle logins for different usernames belonging to the same user.
We called this username the authoritative username.
We also had to update our (custom) enrolment system to call the same mapping function when enrolling students to ensure that it would use the authoritative username for all enrolments regardless of which account the enrolment was associated with.
We also had a CLI script which was run every few minutes which ran through every CID in the LDAP tree and:
- created missing user records in Moodle;
- updated user records (e.g. firstname, lastname, phone, e-mail), but importantly the username; and
- soft-deleted old users (we didn't want to actually unenrol users fully).
This had the effect that:
- usernames could then be re-used in subsequent years; and
- a student starting a course, leaving, and then coming back several years later will still have access to all of their previous content, grades, messages, etc.
Hope that this sheds some light,
Andrew