PowerShell - Add-ADGroupMember Script - Improvements?
-
As part of my user on-boarding PowerShell script, I have a list of AD groups that cover the most common groups assigned "by default". The problem is that I have to manually go in and comment or "un-comment" the lines for the groups to which the user should be added as a member. I have excerpted this section of the script to use for role/job changes.
Here is an example:
Import-Module ActiveDirectory $sAMAccountName = Read-Host -Prompt "Enter sAMAccountName" #Add-ADGroupMember -Identity Office365Users -Members $sAMAccountName #Add-ADGroupMember -Identity SmartsheetUsers -Members $sAMAccountName #Add-ADGroupMember -Identity "Office Users" -Members $sAMAccountName #Add-ADGroupMember -Identity SlackUsers -Members $sAMAccountName #Add-ADGroupMember -Identity "Accounting Users" -Members $sAMAccountName Add-ADGroupMember -Identity SouthWareUsers -Members $sAMAccountName Add-ADGroupMember -Identity VPNUsers -Members $sAMAccountName Add-ADGroupMember -Identity OpenVPNUsers -Members $sAMAccountName Add-ADGroupMember -Identity TerminalServiceUsers -Members $sAMAccountName
Is there a better way to interact with, or even automate, the process of selecting which groups to add the user?
-
When HR does the hand-off to you what information do they give you? Most likely the new staff member's role
Usually the role can be the abstraction layer on top these groups (one-offs aside). So you could create role-based groups with the appropriate groups nested within.
-
@flaxking said in PowerShell - Add-ADGroupMember Script - Improvements?:
When HR does the hand-off to you what information do they give you? Most likely the new staff member's role
Usually the role can be the abstraction layer on top these groups (one-offs aside). So you could create role-based groups with the appropriate groups nested within.
That is true. At least, to some extent. It would definitely cut down on the number of options. Most are grouped by role or service specific, so I could combine them (nested) under respective groups.
-
I'm working on similar project a bit.
The script I'm working with pulls a bunch of info from CSV to create an AD account and populate.
Group membership is based heavily on location and job role here.
I'm thinking I'll use some of the info in the CSV about those attributes to help assign groups using If statements.
Curious what other ideas people may have for this.
-
@wrx7m said in PowerShell - Add-ADGroupMember Script - Improvements?:
@flaxking said in PowerShell - Add-ADGroupMember Script - Improvements?:
When HR does the hand-off to you what information do they give you? Most likely the new staff member's role
Usually the role can be the abstraction layer on top these groups (one-offs aside). So you could create role-based groups with the appropriate groups nested within.
That is true. At least, to some extent. It would definitely cut down on the number of options. Most are grouped by role or service specific, so I could combine them (nested) under respective groups.
I worked at one company where HR always named a specific user the wanted the new user to have the same permissions as. So it was a user copy operation instead. That would be like a template method.
-
@NDC said in PowerShell - Add-ADGroupMember Script - Improvements?:
I'm working on similar project a bit.
The script I'm working with pulls a bunch of info from CSV to create an AD account and populate.
Group membership is based heavily on location and job role here.
I'm thinking I'll use some of the info in the CSV about those attributes to help assign groups using If statements.
Curious what other ideas people may have for this.
Yeah, I have been trying to get to that point, myself. Slow going, so far. I am trying to figure out how to start using the "Department" field in the AD user properties for a Roles-based approach.
-
@flaxking said in PowerShell - Add-ADGroupMember Script - Improvements?:
@wrx7m said in PowerShell - Add-ADGroupMember Script - Improvements?:
@flaxking said in PowerShell - Add-ADGroupMember Script - Improvements?:
When HR does the hand-off to you what information do they give you? Most likely the new staff member's role
Usually the role can be the abstraction layer on top these groups (one-offs aside). So you could create role-based groups with the appropriate groups nested within.
That is true. At least, to some extent. It would definitely cut down on the number of options. Most are grouped by role or service specific, so I could combine them (nested) under respective groups.
I worked at one company where HR always named a specific user the wanted the new user to have the same permissions as. So it was a user copy operation instead. That would be like a template method.
That could work if we were larger. A lot of positions here are only a single user.
-
You could create a function that adds the specified user to the groups you specify as switch parameters.
That's the next best thing besides grabbing a list of groups automagically based off of a list HR provides in a CSV or something of that sort.... or a GUI with check-marks or list selection.
function Invoke-GroupLightning { Param( [Parameter (Mandatory)] [string]$sAMAccountName, [Parameter ()] [Switch]$Office365Users, [Parameter ()] [Switch]$SmartsheetUsers, [Parameter ()] [Switch]$OfficeUsers, [Parameter ()] [Switch]$SlackUsers, [Parameter ()] [Switch]$AccountingUsers, [Parameter ()] [Switch]$SouthWareUsers, [Parameter ()] [Switch]$VPNUsers, [Parameter ()] [Switch]$OpenVPNUsers, [Parameter ()] [Switch]$TerminalServiceUsers ) foreach ($key in $PSBoundParameters.Keys | Where-Object {$_ -NotMatch "sAMAccountName"}) { if ($key -match "OfficeUsers") { $key = "Office Users" } if ($key -match "AccountingUsers") { $key = "Accounting Users" } Add-ADGroupMember -Identity "$key" -Members "$sAMAccountName" } } Invoke-GroupLightning -sAMAccountName "test.user" -Office365Users -SlackUsers -AccountingUsers -OfficeUsers -SouthWareUsers
Looks dirty, but didn't spend much time on it. Likelysome better ways.
Of course, looking at this, it seems like more work to add the switches.
But you could turn it into a PowerShell module that automatically loads when you open PowerShell, that way the function is ready to type, and autocomplete will help you with the switches.
Again as i said earlier, best to have a script automatically grab the username and groups from something. This could be 100% automated if HR could stick them in a CSV somewhere on a share, or anywhere really. You could grab the data from anything via API or whatever.
-
@Obsolesce Thanks for the contribution. I think you are right about that being more work, though.
-
I was originally thinking like @Obsolesce, pass switches to know what groups, but if the number is large, that's a huge pain to type, though pulling from a CSV that HR creates - that could make it much easier and possibly less mistake prone on the typing side.
Like @flaxking I typically copy a user from that department, so it's less for me to worry about.
-
The script I started with was shamelessly stolen from a Technet post.
That gave me a pretty good start. I did some light editing to more accurately match what was going on at my employer when I first used it for a large batch of users rather a while ago.
Now I'm making some more changes and additions to turn it into something a bit more broadly useful day to day.