Changing usernames for replacement positions

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.

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!

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 ......

Creating user templates is another good suggestion.

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.

excellent summary i must say.