• State Not Answered
  • Replies 2 replies
  • Subscribers 65 subscribers
  • Views 75 views
  • Users 0 members are here
Options
Related

Importing/setting aliases for username

imkhonza
1 day ago

Hi All,

We have a situation where the IAM solution creates a username for the user/person, but the user then changes their surname, which is part of the username. We want to allow the user to have a new username based on the new surname but keep the old one so as not to create a new one or confuse the systems when a new user with the similar username criteria that makes the username joins the organization. 

So I am looking for a field in the IAM person record to map this and also to ensure we do not create duplicate/similar usernames that have been taken due to surname changes.

Example:
1 username: jdoe 

Marriages/Divorces:
2. username: jjones

I want to keep the jdoe and jjones linked to one person and also not allow another creation of jdoe or jjones.

Thanks

Kp

  • 0 1 day ago

    One suggestion I would have for this is to create a multi-valued-string Active Roles virtual attribute that could store the old user names (a.k.a. samaccountnames).

    You could call it something like edsvaPreviousSamAccount

    From a process flow perspective, I would suggest something like this:

    1. Active Roles Change Workflow detects a surname change
    2. Copies/appends the existing username (samaccountname) to the in process user's edsvaPreviousSamAccount virtual attribute
    3. New samaccountname gets constructed based on your rule.
    4. Some code checks all users' edsvaPreviousSamAccount virtual attributes for the existence of the new proposed samaccountname and if there are no dupe, the rename of the samaccountname is  allowed to proceed.

  • 0 10 hours ago

    Hi  

    Is this in One Identity Manager, opposed to Active Roles? Just as you mentioned the Person table?

    If so there are several ways to do this, depending on your full use case. IE if you just need to stored the last username of the identity, rather than all previous usernames that user held, you could use an existing column within Person like CustomProperty01 (or you could extend the schema for Person to include a new column), and when the value of CentralAccount (or whichever attribute you use for the username) is changed, that CustomProperty01's value is updated via a column template, where value = $CentralAccount[o]$

    If you need to hold a history of all identities current & previous usernames, you could create extend the schema to create an M for N table, where the FK of the new table links to the Person table, then when the username changes in Person, you add an entry in that table. So you might have 1 record per identity (and/or sub identities depending on naming standards etc),  or you could end up with lots of entries for a single identity, where they've got married, divorces, had a name changed, got married again etc etc.

    With either of these approaches you'd also want to update your username generation script / column template, so that when generating a username, you also check if the value you've generated exists in either the CustomProperty01 column (or column you decide to use) or in the custom table. 

    Also for either approach, if you want to allow them to be returned to their original username, if their name changes back, don't forget to update the username generation script, so that it checks the old username before generating a new value.

    If usernames can be re-used after that identity leaves the organization, when you'd also need to remember to clear out the entries in the custom table if you use that approach.

     

    Also as a follow up, in some organizations, if someone changes there name, they get a new email address, but retain the original to prevent NDR's, so you might need to this about this too.

    Kind regards

    Stu