Identity management over time

Posted by curiouscatinthehat@reddit | sysadmin | View on Reddit | 7 comments

Hi all, first post here so please bear with me if I commit any faux-pas.

We recently ran into a situation where a new employee inherited a recycled email address that was previously used by an old employee and, in doing so, gained access to a third-party account linked to the old employee containing personnal information.

This is a first time / one time problem, as we are well aware that emails equate to a unique ID. It was a mistake and has been rectified by putting processes in place both in-house and on the MSP side, but our information security team started discussing the possibility of going one step further, ie, creating new accounts for returning employees (quit, work elsewhere, come back). In that case, they would not regain their old account [person@contoso.com], but would get a brand new account [person2@contoso.com].

From an operations standpoint, this seems like hell and many systems do not communicate with each other (pay, hr, it, etc), so keeping track of one employee number linked to multiple accounts just seems like a massive headache, but I'm really curious to see if anyone else has a view on these few points:

a) recycling email addresses,

b) assigning new accounts to returning employees.

Also, there is the question of access management; making sure returning employees dont somehow retain individual rights to a network folder in case they were not added to a security group, as protocol requires.

Hopefully this makes sense. Thanks for letting me pick your collective brains.

[-]

Fine-Palpitation-528@reddit

How would you guarantee you never recycle emails? I've seen plenty of companies during their on-boarding process use automation to check if an email is actively taken using their naming convention (i.e. does firstname.lastname@company exist?) If yes, append 2 to the email. That's quite common at large orgs.

However, most orgs won't have corporate emails for employees who worked there 5+ years ago living in a datasource to reference. Curious if you have a master list like this and where it's kept if you do?

But assuming you don't/won't have a master list of corporate emails for every employee that ever worked at your company, then that makes the concept of recycling emails impossible to ensure it will never happen again.

This is why the whole IGA industry exists - to look at 3rd party systems and ensure users don't still have access to those systems on a consistent basis. You can probably imagine that accounts that still exist in 3rd party systems after an employee leaves, create a risk for data breach. The problem is referred to as "orphaned" accounts.

Depending on the size of your org, might worth checking on your IGA processes/tools to ensure they account for these scenarios. If you're a smaller org, you can probably get away with just checking and adding 2, 3, 4, etc. to the email to avoid recycling accounts. If you're at a larger org, you probably need to actually invest in an IGA program that will take care of (most) of these recycled account issues for you.

Trust me, I know IGA is a bear, but there is a reason basically every public company invest in a program for this (to pass audits and avoid lingering account permissions).

Sasataf12@reddit

Recycling email addresses is a massive no-no, as you've discovered. If they're a returning employee, I'm okay with them using their old email address (unless someone raises a valid concern). But as you mentioned, they're access should be appropriately managed, e..g. they shouldn't get access to their old resources if they no longer need to.

AppIdentityGuy@reddit

Since email address are mutable they shouldn't be used as user ID anyway. That is what things like object guid are for

We're not talking about using email addresses as UIDs.

We're talking about re-using email addresses, i.e. giving someone an email address that was previously used by another person.

But I think in the OP's case they were using the email address as rhs UID in that one app and then because the email address was reused the user with that email address got access to something he shouldn't have in another

That's not how I read it, because OP mentioned the new person getting access to a 3rd party account.

Bob A (bob@company) left the company. Bob B started and was given the email bob@company.

Bob B can now has the possibility to access any accounts tied to that username (using password resets, magic links, etc).

RadShankar@reddit

a) Recycling email addresses is most widely used by orgs.

Notable exceptions are data retention policies prevents deletion / reuse of info / or org policy is to leave email permanent (e.g. some govt entities / universities)

Indeed you're right to worry about multiple SaaS accounts that don't talk to each other / your IdP / HRIS. We work with companies where this is particularly intense as they are contractor-heavy and contractors constantly leave / return and could be working for a competing client on re-hire. Deactivation and deletion from all former user's accounts is a minimum, but depending on your company, also make sure other roles / permissions are deprecated / removed (e.g. admin / owner roles in groups, etc.). Each app / tool has its own quirk (e.g. a deactivated Okta user can still exist in an Okta group, a suspended Google user can still be a manager of a Google group) and these could auto inherited upon rehire, if the reactivation isn't done correctly.

The solution, as always, starts with reviewing the risks and adding / updating your infosec policy for offboarding users considering examples like above.