Changing usernames for replacement positions

I have an employee who likes to just disable an account when a user leaves and then enable it and change the username to the new employee.

What are the communities thoughts on this?

I can say I am leaning towards not being a fan just for security purposes (I.e. reevaluating security permissions and group memberships with each new hire, muddying any sort of audit trail, etc).  

I don’t have a really strong reason, so looking for your thoughts.

Thanks!
Taylor HuckstepSenior Director, ITAsked:
Who is Participating?
 
AlanConsultantCommented:
Hi,

I can understand wanting to make things easy and being 'lazy' (in the nicest possible sense), but I would never do this.

For starters, having a newly created account means that any issues in the old account are automatically gone.

Creating a new account is a few minutes work, so why not do it the right way.

One thing to query - Does the other admin actually know what they are doing?  Maybe they don't, and are too embarrassed to admit it.  If so, perhaps create a check-list of what to do for a new starter, and get them to use that.

Alan.
1
 
serialbandCommented:
I see that as an absolute security no-no.  Calling him lazy is being too kind.  I'd just call him incompetent.
0
 
arnoldCommented:
Echo prior comments, not sure why renaming and going through all that, when a process, straight forward, copy to create a new accounts that maintains settings, while not including all the baggage from prior users.
this also masks and will prevent auditing.
File creation, ownership will change based on the new reference, having to look at HR file provided there is a record on whose old account is being used by the new user.
0
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

 
Lasse BodilsenSystem AdministratorCommented:
Echo prior comments:  Big no-no!..

esp. for this "muddying any sort of audit trail"

if it's for being lazy. get someone to develop a "new user" script, and run that instead.
0
 
masnrockCommented:
One word answer: NO

This is wrong for all sorts of reasons. For starters, the employee is instantly contaminating any evidence if an investigation or audit is ever required. Secondly, there will be the issue of having to basically dump all of the data from existing accounts (i.e. email)... and of course, the topic of investigations and audits has already been brought up. How is any data from the previous user of an account archived? How do we prevent the new user of the account from having access to the data of the old user of the account?

Also recommend putting in policies and standards to cover this.
0
 
Taylor HuckstepSenior Director, ITAuthor Commented:
I figured this was the case.  Everything you're saying echo's my own thoughts.  Thanks for the confirmations and listing out some of the real threats around this.
0
 
Taylor HuckstepSenior Director, ITAuthor Commented:
The core problem is definitely incompetence as alluded by several of you.  I like the idea of a new user script and a list to assist with that problem.  If only it were easy to recruit competent sys admins to rural Utah!
0
 
arnoldCommented:
The effort to change username, description, etc is longer than using the copy eXisting account settings if one did has not created a user template based on the position, etc. already.

Reusing an existing deactivated account seems incomprehensible and not sure what motivated a person to start down this road in the first place.
Potentially the access to files of the old account files while retained the new would need to scan to which directories one has access.

There are user creation scripts available on Ms site as well as the method used ......
0
 
Taylor HuckstepSenior Director, ITAuthor Commented:
Creating user templates is another good suggestion.
0
 
Taylor HuckstepSenior Director, ITAuthor Commented:
Here is the summary based on all your feedback I'm going to roll out to my department.

-----------------------------------------------------------------

Renaming user accounts is a big security no-no.

Here are a number of reasons we shouldn’t be renaming user accounts:
•      Creating brand new accounts eliminates any baggage getting copied over from the old user account.
•      Creating brand new accounts provides us the opportunity to clean up improper/changing group memberships and permissions by confirming with the hiring manager that the new user still needs certain access rights.  
•      Renaming accounts makes any sort of auditing difficult or impossible.  It immediately contaminates any evidence that might be required if an investigation of a previous employee (who don’t always leave on good terms) becomes necessary.  Not everybody remembers who replaced who without relying on good employee files.
•      Not dumping the previous user account data (like email, OneDrive, and user folders) before renaming and turning over the reins could result in a confidentiality breach.  HR MUST provide written (email) approval any time we give access to another user’s data.  Including, but not limited to forwarding email to a supervisor after a user has left.  The previous user could have had certain FMLA/health or disciplinary (i.e. Positive Drug Test) concerns that are confidential even to their previous manager.
  o      This creates problems with properly archiving and accessing old user data (per my deprovisioning policy)
  o      This could result in a lawsuit if not properly followed.
•      Renaming a user account doesn’t always grant access to third party systems the new user may need if it doesn’t rely on the Microsoft User Account SID.  It may still be looking for the old username.  

Action items:
•      Please discontinue the practice of renaming user accounts.
•      Start using the deprovisioning procedures I have previously provided.  I see no reason we couldn’t script the entire process.
•      Begin placing old / deleted users into a deleted users OU for a period of time before we archive and delete the old user and their data.
•      Do not keep data longer than a year, as this can be a legal liability.  Please start putting reminders in the IT calendar to delete that data, and/or enable policies that automatically delete that data as can be done with e-discovery policy in O365.
•      I understand wanting to simplify the onboarding process, so please look into a scripting process if creating new user accounts is too cumbersome.  There are user creation scripts available on Microsoft’s site as well as the method used.  Another good idea is to create user templates based on department for the standard access permissions shared by all members of a department.
•      Please ask all hiring managers to fill out a CARF (Computer Access Request Form), so we have in writing exactly what permissions the new user will need.
0
 
Lasse BodilsenSystem AdministratorCommented:
excellent summary i must say.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.