The lost group. Find out the assignment of "strange" groups in AD

    Good time of day, habrag citizens!

    I hasten to share with you one of my gizmos, which were designed to facilitate the work of me, as a system administrator who understands the trash that he inherited in Active Directory.
    The most problematic of the good, in my opinion, are the groups. They will be discussed in this article.
    Namely: we go into Active Directory, plow open spaces of divisions and see groups with completely faceless names (for example, Ugin, Vassa, Opel, www etc) and without a description. Attention to the question: determine why these groups are needed.

    What we inherit


    So, we see the group, scratching the back of the head. The group includes users from different departments. No sign of common sense. Perhaps, by the name of the group, we can vaguely determine (or guess) what it is for. This will be a plus to the one who left you all this. What are we going to do?

    So at my work, as soon as I got involved in the domain, I found a carriage and a small cart of such groups. And although all the people who were in charge of them before me remained in place, no one could give me a sensible answer. If earlier it was possible to close our eyes to this, there were many other things, now the need has come to put things in order.

    What is the meaning of group life? As a rule, this is either access to resources in shared folders, or a filter for applying group policies (I do not take into account system groups like Domain Admins etc.)
    So the task has been set for us: we need to check the Access Control List (ACL) of folders in shared resources and in group policies.

    Hello mr. PoSh


    Here, our Swiss knife enters the arena with which we will open the ACL of folders and policies.
    Since it’s easier with politicians, let's start with them.

    Group Policy


    To work with group policies, the grouppolicy module will help us. From this module we use two cmdlets:
    1. get-gpo, which gives us a list of all group policies in the domain
    2. get-gppermissions, which allows us to view ACLs of policies.
    Then, we simply look for a match between the name of our group and the entry in the ACL, and if there are any, we display information about this policy:
    $name=read-host "Введите полное имя учетной записи или группы"
    Write-Host -Fore RED "Проверка в групповых политиках..."   
    $gpos=get-gpo -all
    Foreach ($gpo in $gpos)
        {
        $ACls=get-gppermissions -Name $gpo.DisplayName -all
        Foreach ($acl in $ACls)
            {
            if ($acl.Trustee.Name -match "$name") 
                {
                Write-Host -Fore GREEN "Найдена политика!"; $gpo
                If ($acl.Permission -eq "GpoApply") 
                    {if ($acl.Denied) {Write-Host -Fore RED "Применение политики запрещено"}}
                }
            }
        }
    

    I also want to note the Permission and Denied properties in the ACL.
    1. Permission - it contains permissions for the object, for example, applying a policy (GpoApply), reading a policy (GpoRead), changing a policy (GpoEdit), or all at once (GpoEditDeleteModifySecurity).
    2. Denied shows us what is displayed or allowed in Permission.
    If you look at a piece of the script, you can see that if the group’s ACL prohibits (Denied -eq $ true) application of the policy (Permission -eq “GpoApply”), a notification about this will be displayed. In principle, it was possible to paint notifications for all cases, but I am only interested in the prohibition on the distribution of policies.
    PS We will use the $ name variable, in which the name of our group is located, in the following pieces of code.

    Shared Folders


    Now let's take care of shared folders. There are two options:
    1. When permission is given directly to the shared resource.
    2. When permission is given to a folder hidden in the bowels of a shared resource.
    Let's go in order again.

    Looking on the surface

    The easiest and most understandable way is to give permissions to shared folders. So it’s better that you have all the permissions in one place, and don’t confuse your heirs when they dig into 4 layers of folders and find one folder with photos of your birthday, where only your friend from Accounting was allowed to enter. She will lose a shortcut, guess what folder she needed? But we will return to her later.
    Now we need to check the ACLs on shared folders on our file server (here it is called FileServer ... (yes, I'm original)). To do this, we use the beloved WMI for everyone. I note that I immediately throw aside folders that are not displayed with a simple login to our server. What for? Ordinary users will not get in there, but unusual ones, you can ask (if necessary, you can remove it):
    Write-Host -Fore RED "Проверка в папках \\FileServer"
    $dirs=get-wmiobject win32_Share -computername FileServer | where-object {$_.Name -notmatch "\$"}
    Foreach ($dir in $dirs)
        {
        Trap [System.UnauthorizedAccessException] 
        {"Был запрещен доступ к папке $share"; continue;}
        $out=$null
        $share=$dir.Path
        if ($share -match "^D:") {$share = $share.ToUpper().Replace('D:','\\FileServer\d$')}
        elseif ($share -match "^C:") {$share = $share.ToUpper().Replace('C:','\\FileServer\c$')}
        $out=($share | get-acl).Access | where-object {$_.IdentityReference -match "$name"}
        if ($out -ne $null) 
            {Write-Host -Fore green "Найдена папка!" $share}
        }
    

    We also catch an error that tells us that access to certain folders is closed, and instead of red frightening errors, we will receive a simple message.
    Two lines in which we replace 'D:' with '\\ FileServer \ d $' (and similar with the 'C' drive) are necessary, because if this is not done, cmdlet get-acl will try to search for these folders on our computer and most likely will not find it. And he (cmdlet get-acl) cannot search along the path \\ FileServer \ Folder. In our example, there are only 2 disks, but adding more is not a problem.

    We go down to the depths

    We return to a friend from accounting. Now we dig into subfolders.
    I think many will say why come up with something when you can use get-childitem -recurse. If you do not have a lot of folders on the server - yes, you can use recurse. But if you have about 7 TB of file server, then, in principle, there is no problem either, you just have to wait a couple of hours and everything will work. And pray to God that you do not have a mistake in the middle of the search.
    So -recurse won't help us, then what? Then we need to make a cycle that, at our whim, will go into the bowels of the folders as much as we want (it sounds like that). Suppose we have a folder with subfolders for departments (please forgive the tautology). These folders are not shared. In some of these folders are the folders we need, with the cherished permissions.
    Write-Host -Fore RED "Проверка в папках \\FileServer\WorkFolders..."
    $AllPath=@{}
    $sub=4
    $path=dir \\FileServer\c$\WorkFolders | where-object {$_.PSIscontainer}
    $AllPath=$path
    $cnt=0
    For ($o=1; $o -lt $Sub; $o++)
    {
        $PPath=$AllPath
        For ($i=$Cnt; $i -lt $PPath.Count; $i++)
            {
            $a = dir $PPath[$i].FullName | where-object {$_.PSIscontainer}
            if ($a -ne $null) {$AllPath = $AllPath + $a}
            }
        $cnt=$PPath.Count
    }
    Foreach ($WF in $AllPath)
        {
        Trap [System.UnauthorizedAccessException] 
        {"Был запрещен доступ к папке" + $WF.FullName; continue;}
        $out=$null
        $out=(get-acl $WF.FullName).Access | where-object {$_.IdentityReference -match "$name"}
        if ($out -ne $null) 
            {Write-Host -Fore GREEN "Найдена папка!"; $WF.FullName}
        }
    

    You may notice that we only need folders, so we filter the output using the PSIscontainer property.
    The $ sub variable sets the search depth. The $ AllPath variable stores the paths to all the folders we found. Well, then, the gestures already familiar to us, check the ACL of the found folders for the presence of our group in them.

    Eventually


    Thus, you can find in almost any subsoil permission for a particular group. Naturally, it can be used not only to search for groups, but also to search for users and computers (fortunately, I rarely encounter this).
    Whether to make one script out of all this, one or more functions is up to you.

    In conclusion, I want to say a few touching words: comrades, colleagues, let's not complicate each other's life in a new place of work. There is nothing difficult to write about its purpose in the description of the group. And there is nothing complicated to create this group and not to hang up permissions for accounts. If we all do this, soon there will be no need to write such articles.

    Also popular now: