Lost group. We find out the appointment of "strange" groups in AD
Good time of day, habrahdrazhdane!
I hasten to share with you one of my gizmos, which were designed to facilitate my work, as a system administrator who understands the inherited trash in Active Directory.
In my opinion, the most problematic of the inherited good are groups. About them will be discussed in this article.
Namely: we go into Active Directory, we plow the spaces of divisions and see groups, completely with faceless names (for example, Ugin, Vassa, Opel, www etc) and without a description. Attention question: determine why these groups are needed.
So, we see a group, scratching the head. In a group of users from different departments. No sign on common washed away. Perhaps by the name of the group we can vaguely be able to determine (or guess) what it is for. It will be plus to the one who has left all this to you. What are we going to do?
I also had my job, as soon as I started a domain, I found a car and a small truck of such groups. And although all the people who were in charge of them before me remained in place, no one could give me an intelligent answer. If earlier it was possible to close our eyes to this, there were many other things, now there is a need to restore 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 for us is set: we need to check the Access Control List (ACL) of folders in shared resources and in group policies.
Here our Swiss knife comes into the arena, with which we will open the ACL of folders and policies.
Since politicians are easier, let's start with them.
To work with group policies will help us the module grouppolicy. From this module we use two cmdlets:
1. get-gpo, which sends us a list of all group policies in the domain
2. get-gppermissions, which allows us to view ACL 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:
I also want to note the Permission and Denied properties in the ACL.
1. Permission - it contains permissions for an object, for example, applying a policy (GpoApply), reading a policy (GpoRead), changing a policy (GpoEdit), or generally all at once (GpoEditDeleteModifySecurity).
2. Denied shows us what is allowed or denied what is displayed in Permission.
If you look at a piece of the script, you can see that if the application of the policy (Permission -eq "GpoApply") is denied (Denied -eq $ true) in the ACL group, a notification will be displayed. In principle, it was possible to paint notifications for all cases, but I am only interested in the ban on the dissemination of policies.
PS The variable $ name, in which the name of our group is located, will be used in the following pieces of code.
Now we will deal with shared folders. There are two options:
1. When permission is given directly to the shared resource.
2. When permission is given to the folder hidden in the depths of the shared resource.
Come again in order.
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 you shouldn’t confuse your heirs when they get to 4 layers of folders and find one folder with photos of your birthday where only your friend from Accounting was allowed to enter. She loses the label, guess what kind of folder she needed? But we will return to it later.
And now we need to check the ACL on shared folders on our file server (here it is called FileServer ... (yes, I am original)). For this, we use everyone's favorite WMI. I note that I immediately discard the folders that are not displayed when you simply log into our server. What for? Ordinary users will not get there, well, unusual, you can ask (if necessary, you can remove):
We also catch an error that tells us that access to certain folders is closed, and instead of red frightening errors we will get a simple message.
Two lines in which we replace the 'D:' with '\\ FileServer \ d $' (and the same with the 'C' drive) are necessary, because if this is not done, the cmdlet get-acl will try to search for these folders on our computer and most likely will not find it. And he cannot search for the path \\ FileServer \ Folder (cmdlet get-acl). In our example, only 2 disks, but adding more is not a problem.
We return to the familiar from the accounting. Now we dig in the subfolders.
I think many will say why to invent 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 the problems, in principle, either do not exist, you just have to wait a couple of hours, and everything will work. And pray to God that you would not have an error in the middle of the search.
So -recurse doesn't help us, then what? Then we need to make a cycle that, according to our whim, will go deeper into the depths of the folders as much as we want (it sounds like it went). Suppose we have a folder with subfolders for the departments (please forgive the tautology). These folders are not shared. In some of these folders are the folders we need, with cherished permissions.
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 and further, already familiar to us gestures, check the ACL of the found folders for the presence of our group in them.
Thus, it is possible to find in almost any subsoil of permission for a certain group. Naturally, you can use it not only to search for groups, but also to search for users and computers (fortunately, I rarely come across this).
Whether to make one script, one or several functions out of all this is up to you.
In conclusion, I would like 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 in the description of the group to write about its purpose. And there is nothing difficult to create this group and not to hang up account permissions. If we all do this, then soon there will be no need to write such articles.
I hasten to share with you one of my gizmos, which were designed to facilitate my work, as a system administrator who understands the inherited trash in Active Directory.
In my opinion, the most problematic of the inherited good are groups. About them will be discussed in this article.
Namely: we go into Active Directory, we plow the spaces of divisions and see groups, completely with faceless names (for example, Ugin, Vassa, Opel, www etc) and without a description. Attention question: determine why these groups are needed.
What we get by inheritance
So, we see a group, scratching the head. In a group of users from different departments. No sign on common washed away. Perhaps by the name of the group we can vaguely be able to determine (or guess) what it is for. It will be plus to the one who has left all this to you. What are we going to do?
I also had my job, as soon as I started a domain, I found a car and a small truck of such groups. And although all the people who were in charge of them before me remained in place, no one could give me an intelligent answer. If earlier it was possible to close our eyes to this, there were many other things, now there is a need to restore 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 for us is set: 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 comes into the arena, with which we will open the ACL of folders and policies.
Since politicians are easier, let's start with them.
Group Policies
To work with group policies will help us the module grouppolicy. From this module we use two cmdlets:
1. get-gpo, which sends us a list of all group policies in the domain
2. get-gppermissions, which allows us to view ACL 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 an object, for example, applying a policy (GpoApply), reading a policy (GpoRead), changing a policy (GpoEdit), or generally all at once (GpoEditDeleteModifySecurity).
2. Denied shows us what is allowed or denied what is displayed in Permission.
If you look at a piece of the script, you can see that if the application of the policy (Permission -eq "GpoApply") is denied (Denied -eq $ true) in the ACL group, a notification will be displayed. In principle, it was possible to paint notifications for all cases, but I am only interested in the ban on the dissemination of policies.
PS The variable $ name, in which the name of our group is located, will be used in the following pieces of code.
Shared folders
Now we will deal with shared folders. There are two options:
1. When permission is given directly to the shared resource.
2. When permission is given to the folder hidden in the depths of the shared resource.
Come again in order.
Looking for 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 you shouldn’t confuse your heirs when they get to 4 layers of folders and find one folder with photos of your birthday where only your friend from Accounting was allowed to enter. She loses the label, guess what kind of folder she needed? But we will return to it later.
And now we need to check the ACL on shared folders on our file server (here it is called FileServer ... (yes, I am original)). For this, we use everyone's favorite WMI. I note that I immediately discard the folders that are not displayed when you simply log into our server. What for? Ordinary users will not get there, well, unusual, you can ask (if necessary, you can remove):
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 get a simple message.
Two lines in which we replace the 'D:' with '\\ FileServer \ d $' (and the same with the 'C' drive) are necessary, because if this is not done, the cmdlet get-acl will try to search for these folders on our computer and most likely will not find it. And he cannot search for the path \\ FileServer \ Folder (cmdlet get-acl). In our example, only 2 disks, but adding more is not a problem.
We go down into the depths
We return to the familiar from the accounting. Now we dig in the subfolders.
I think many will say why to invent 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 the problems, in principle, either do not exist, you just have to wait a couple of hours, and everything will work. And pray to God that you would not have an error in the middle of the search.
So -recurse doesn't help us, then what? Then we need to make a cycle that, according to our whim, will go deeper into the depths of the folders as much as we want (it sounds like it went). Suppose we have a folder with subfolders for the departments (please forgive the tautology). These folders are not shared. In some of these folders are the folders we need, with 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 and further, already familiar to us gestures, check the ACL of the found folders for the presence of our group in them.
Eventually
Thus, it is possible to find in almost any subsoil of permission for a certain group. Naturally, you can use it not only to search for groups, but also to search for users and computers (fortunately, I rarely come across this).
Whether to make one script, one or several functions out of all this is up to you.
In conclusion, I would like 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 in the description of the group to write about its purpose. And there is nothing difficult to create this group and not to hang up account permissions. If we all do this, then soon there will be no need to write such articles.
Source: https://habr.com/ru/post/138600/
All Articles