On-boarding new employees can be one of the most repetitive tasks that IT personnel have to do. Think about it; there are so many steps and variables that it’s easy to miss steps. A checklist can help ensure steps aren't missed, but I find that using pre-written PowerShell scripts will deliver the same consistent results every time. Here are some of the steps we will be scripting in this article:
Click below to view the full .ps1 on github
Note: Be sure to take your environment and requirements into consideration when running scripts. Be careful defining your variables.
Create the User:
In Active Directory I find that it's easier to copy an exisiting user who is considered a peer and already has the same security groups that the new user will need. Before creating (or copying) a user, it is necessary to know which Organizational Unit the user needs to be placed into in Active Directory so that the correct Group Policies apply to that user. We'll accomplish this by finding out all of these variables BEFORE creating the user. Here's a sneak peek:
#Get Department and verify correct spelling *************************************
If you copy an existing user, the new user will inherit the original user's group membership by default. This includes security groups and dsitribution groups. Depending on your environment, you may not want this behvior. For today's article we will be assuming that it is ok to copy existing users to make new users. Be sure when making this decision that you take into consideration the 'least priviledge' principle for security measures.
Pro tip: Role-based access is always preferred over user-based access. Be sure to configure appropriate security groups and use them throughout your environment to grant access to network shares, applications, websites, etc. For more details, see my article called Security Groups: Sweet Dreams or Worst Nightmare?
Additionally some users need to be assigned groups based on location, department, gender, etc. That can be accomplished with variables and 'if' statements. Here's an example in PowerShell of how you could assign the user a group based on their gender:
#Assign distribution group based on gender *************************************
Users must be provisioned an email address in the right format in accordance with your organization's standards. Different organizations use different syntax for their user's emails. Examples for John Smith include email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, etc. These email addresses don't even factor in distribution groups or additional aliases such as email@example.com or firstname.lastname@example.org. Another consideration; should this user have Active Sync / IMAP enabled so they can access their email on a mobile device?
# Define the email to be used in Active Directory
Most environnts place all user folders in the same root direct for “easy” management. I put “easy” in quotes because this can become a permissions nightmare if it’s not set up properly from the start and maintained properly, by every admin, forever. In this environment we have created an NTFS folder that has all of the default permissions we want. The script creates a new folder, pulls the permissions of the template folder, assigns those same permissions to the new folder, and then grants the user access to the new folder. The result; every folder has the same default permissions plus Modify access for the user the folder belongs to.
Pro tip: Don’t let users take ownership of their folders or change the permissions. You’ll just be in for a challenge when the time comes to archive their folder at termination. That’s why we remove that ability from the start.
#User's home folder where they will store personal files
Some organizations have applications that require each user be created a directory for a specific application. Creating that directory in the right place, with the right name, and the right permissions can leave room for human error. Just like the home folder above we create a new folder, reference the permissions of a template folder, assign those same permissions to the new folder, and then grant the user access to the new folder.
What about logging your steps so that they can be audited later? Does your organization require that this process have auditable logs? Many organizations do. You may choose to log the execution of the script verbosely, but verboseoutput will be difficult for auditors to read unless they know PowerShell. In this script, our log has predefined text fields and variables are inserted into the logs that contain the items required by most auditors. These items include date, username, security groups, e-mail addresses, mailbox settings (such as ActiveSync), and more.
# Write logs to log file ******************************************************
Security Badges & Tokens:
Many organizations today utilize security badges or tokens as a Physical Access control. Usually this is part of the onboarding process, otherwise the new employee wouldn’t e able to move around the building. Explaining the rules around accessing certain rooms to every new administrator is important, but leaves room for interpretation. What access should they be granted? Is that based on variables such as role, department, location, gender, etc? If so, those rules can be written into your PowerShell script so that your administrator doesn't have to use their judgement on this step each time. Because every organization uses a different system, and for security measures, I haven’t included commands for this function in my public scripts. I place this section here though to stimulate your mind of the possibilities.
For automating the off-boarding (or terminating) of employees check out my article Off-Boarding (Terminating) Users with PowerShell.
Sheridan's interests are in technology, business, music, and adventures