I'm building a PowerShell script that assigns new Active Directory users to groups based on attributes such as location, department, and job title. At the moment, I use hashtables whose values are arrays of groups—for example, one list for each department—and the script checks the user's attributes before adding the matching groups.
That approach works for simple, single-attribute rules, but I also need to support combinations. For example, managers at a particular location may need access to a restricted resource specific to that office. My organization has more than 60 locations, with several departments and job roles at each, so hard-coding every possibility in a large if/else or switch statement would become difficult to maintain.
What is a clean way to represent and evaluate these combinations? I'm considering nested hashtables, generated group names, or storing the rules in an external JSON or CSV file, but I'd like to avoid awkward keys made by concatenating multiple attributes or a huge hard-coded table. How have others structured this kind of role and group-assignment logic?
3 Answers
If the rules are becoming numerous or complicated, this is usually better handled by an identity governance or role-management system. In environments that support it, dynamic group membership can also evaluate user attributes automatically.
If you stay with PowerShell, use a consistent group naming convention and generate the expected name from the relevant attributes. For example, a group such as `NewYork-AssociateTechnician` could be looked up after normalizing the location and title. That avoids writing a separate branch for every possible combination, although it only works well when the combinations and naming rules are predictable.
For more complex cases, keep the rules in structured data—JSON or CSV are both reasonable—and have the script interpret the rules. This keeps policy separate from code and makes changes easier to review. Good group hierarchy and naming conventions will save a lot of maintenance effort.
Avoid building a massive switch statement or maintaining a separate array for every permutation. Treat the assignment as a collection of rules: each rule has one or more attribute conditions and a list of groups. For example, a general department rule could assign department groups, while a more specific location-plus-title rule could assign the restricted manager group.
When processing a user, evaluate every rule, collect the matching groups, remove duplicates, and compare the result with the user’s current memberships. This also lets you add exceptions or exclusions without changing the core script. CSV is simple for administrators to edit, while JSON is more suitable if each rule contains nested conditions or lists of exclusions.
I’d define the roles first, then store each role’s group memberships in a JSON configuration file. The script can load the file, determine which roles apply to the user, combine the resulting group lists, remove duplicates, and then add the user to the groups.
For combinations, make the rule itself explicit rather than creating a strange key from concatenated attributes. A rule could contain conditions such as `Location = New York`, `Department = Sales`, and `Title = Manager`, along with the groups to assign. The script loops through the rules and applies the groups when all conditions match.
That gives you a manageable separation: the PowerShell code handles evaluation and AD changes, while the JSON contains the roles, conditions, and group names. You can also validate the configuration and run the script in report-only mode before making changes.
That approach makes sense for keeping the data outside the script, but I’d still need the configuration to represent a role that depends on multiple attributes rather than only simple roles such as Developer or Manager. I’m leaning toward defining those combined conditions directly in the JSON rules.