In one of our previous articles we discussed automating group membership management. But there is a specific type of groups that deserves a bit more attention. Shadow groups.

Shadow groups are security groups in Active Directory that reflect all users in particular Organizational Units as their members. They are used when you need to assign things like permissions or Fine-Grained Password Policies to them, which you can’t do with just an OU in place, because it’s not a security principal. However, a group is. So, having a group that has the same members as the OU is pretty convenient.

The problem with shadow groups is that users can be moved around OUs a lot. Each time some account is moved, the shadow group membership must be updated as well. Doing it manually is obviously not good enough, this process clearly needs to be automated. Here’s how you can do that with the help of Adaxes. 

Scheduled Task

To make sure that shadow group membership is up to date you can run a scheduled task that will maintain it for you on a regular basis. There are couple different approaches you can take, so let’s have a closer look.

Conditions

With the first approach the scheduled task goes over users, adds them to the shadow groups that correspond to their location in AD and removes them from the others. In this example you can see two conditions that add the users to the London_Shadow group if they are located under the London OU and remove them from it, if they aren’t. Similar logic needs to be applied to each shadow group you want to automatically maintain.

Such approach fits perfectly for environments that have a relatively small number of shadow groups and with not many changes going on in them. This means that the task doesn’t get overloaded with too many conditions and you don’t have to constantly add new groups and remove the old ones to and from the task.

In this scenario you need to put in all your shadow groups once and forget about the task as it just works.  

PowerShell Script

For those who have a big number of shadow groups or a rapidly changing environment to deal with, there is another way to go with.

This scheduled task launches a PowerShell script. Instead of going over users, it goes over Organizational Units and updates the shadow groups located under those OUs.

Here’s the script itself.

$groupDN = "CN=%name%_Shadow,%distinguishedName%" # TODO: modify me

# Bind to group
try
{
    $group = $Context.BindToObjectByDN($groupDN)
}
catch [System.Runtime.InteropServices.COMException]
{
    if ($_.Exception.ErrorCode -eq 0x80072030)
    {
        return # object does not exist
    }
    throw $_.Exception
}

# Search all users in target container
$searcher = $Context.TargetObject
$searcher.SearchFilter = "(sAMAccountType=805306368)"
$searcher.SearchScope = "ADS_SCOPE_ONELEVEL"
$searcher.PageSize = 500

try
{
    $searchResultIterator = $searcher.ExecuteSearch()
    $searchResults = $searchResultIterator.FetchAll()
    
    $allUserGuids = New-Object "System.Collections.ArrayList"
    foreach ($searchResult in $searchResults)
    {
        $guid = [Guid]$searchResult.Properties["ObjectGuid"].Value
        $allUserGuids.Add("<GUID=$guid>")
    }
    
    # Update group members
    $group.Put("member", $allUserGuids.ToArray())
    $group.SetInfo()
}
finally
{
    # Release resources
    if ($searchResultIterator){ $searchResultIterator.Dispose() }
}

If at some moment you want to add a new shadow group to your environment, all you need to do is to create a group with the right name under a correct OU and it will then get automatically populated and be maintained from then on. No modifications to the script or to the scheduled task are needed.

Instant reaction

Scheduled tasks work great. But what if the time between the moment a user is moved and the moment the task fires up is critical for you? What if you need your shadow groups to be updated instantly? Normally, the only way to do that would be manually updating group membership, but Adaxes has got you covered on that.

In this example shadow group membership is maintained using Business Rules. They automatically trigger actions on certain events in AD. Here three different rules are used: before moving a user, after moving a user and after creating a user.

In each rule a template is used to define a shadow group. In this particular case, if a user is moved from an OU called London to an OU called Paris, Adaxes will first remove the user from the London_Shadow group, then move the user to a new OU and then add the user to the Paris_Shadow group.

Note, however, that some limitations apply. E.g. this solution will only work If the user is created or moved via Adaxes. You also need to make sure that every OU does have a respective shadow group. Otherwise, you need to exclude the OUs that don't have them from the tasks' scope. But if timing is critical for you, this is the way to go.

Conclusion

Whichever solution you choose based on your AD environment requirements, making sure that your shadow groups are always up to date can save you from a lot of headache. This way you can be sure that no users have wrong permissions or wrong Fine-Grained Password Policies applied to them because somebody has forgotten to add a user to a new group after the account has been moved to a new OU.

With automation in place you can free the time that you would otherwise spend updating shadow groups or troubleshooting and use it for some good. Don’t waste such an opportunity.