Lost group. Find out the purpose of the "strange" groups in AD
Good time of day, khobragade!
I hasten to share with You one of his gizmos, which were designed to facilitate the work to me as the system administrator, who knows, he'd inherited, the stuff in Active Directory.
The problem of inherited good, in my opinion, this group. About them will be discussed in this article.
Namely: go to Active Directory, cross the expanse of subdivisions and see a group of completely faceless names (e.g. Ugin, Vassa, Opel, www etc) and without a description. Attention a question: define what is needed by those groups.
the
Now, we see the group, scratching his head. In the group of users from different departments. No signs on common sense. Perhaps the group name we vaguely can determine (or guess) what it was for. It will be a plus to someone You all left. What are we going to do?
The same goes for me at work, once engaged in the domain, I found a car and small truck such groups. And although all the people who own it before me was in charge, remained in place, no sensible answer could not give. If earlier it was possible to close eyes to it, there were a lot of other things, now came the need to restore order.
What is the meaning of life groups? As a rule, or access resources in shared folders, or filter to apply a group policy (do not take into account system groups like Domain Admins etc.)
So the task set for us: we need to check the Access Control List (ACL) of the folders in shared resources and group policy.
the
Here comes into the arena of our Swiss army knife, with which we will open the ACL folder and politician.
As with politicians easier, start with them.
To work with group policy we can help the grouppolicy module. From this module we use two cmdlet'a:
1. get-gpo that gives us a list of all group policies in a domain
2. get-gppermissions, which allows us to view the ACL policies.
Then, we're just looking for a match between the name of our group and the entry in the ACL, and if available, displaying information about this policy,
the
Just want to note properties and Permission Denied in the ACL.
1. Permission — it contains the permissions for the object, such as applying a policy (GpoApply), read policy (GpoRead), policy changes (GpoEdit) or do it all at once (GpoEditDeleteModifySecurity).
2. Denied shows us permitted or prohibited, and what is displayed in the Permission.
If you look at a piece of script, we can see that if in the ACL group, will be denied (Denied-eq $true) application policy (Permission -eq "GpoApply"), then it displays a notification. In principle, it was possible to write notices for all cases, but my only concern is the prohibition of the dissemination policy.
PS Variable $name which is the name of our group, we will use the following piece of code.
Now shared folders. There are two options:
1. When permission is given directly to the shared resource.
2. When the permission on a folder, hidden in the depths of the shared resource.
Will go again in order.
The easiest and most intuitive way is to give permissions to shared folders. It is better that all the permissions You have in the 1st place, and do not confuse Your heirs, when they get to 4 layers of folders and find a folder with photos of your birthday, where he was allowed to enter only your friend from the Accounting Department. Lose it tab, guess what the folder she needed? But we will return to it later.
the
We also caught an error, which tells us that the access to certain folders closed, and instead of red scary error we will display a simple message.
Two lines, in which we replace 'D:' to '\\FileServer\d$' (and the same disk 'C') is necessary, because if this is not done, the cmdlet get-acl will attempt to scan these folders on our computer and, most likely, will not find. And look for path \\FileServer\Folder it is (the cmdlet get-acl) can not. In our example, only 2 disks, but adding another is not a problem.
Go back to the familiar from the accounting Department. Now dig in subfolders.
I think many will say, why come up with something when you can use get-childitem -recurse. If your server is not a lot of folders — Yes, you can use recurse. But if you have about 7 TB of fileserver problems, in principle, either, you just have to wait a couple of hours, and it would work. And pray to God that you had errors in the middle of a search.
So -recurse will not help us, what then? Then we need to make a cycle, which according to our whims will delve into the depths of the folders on as much as we want (sounds that matter). 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 needed folders with the coveted permits.
the
You may notice that we only need folder, for this we filter the output using the PSIscontainer properties.
The variable $sub specifies the search depth. In the variable $AllPath store paths to all the folders that we found. Well, then, the familiar gestures, check ACL found folders for the presence of our group in them.
Thus it is possible to find nearly any subsurface permissions to a specific group. Naturally, it is possible to use not only to search for groups, but also to search for user and computer (fortunately, I rarely encountered).
Do one script, 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 a life in a new place of work. There is nothing difficult that would be in the description of the group to write about her appointment. And there is nothing complex that would create this group and not to hang permissions on the account. If we all do this, we soon will not need to write such articles.
Article based on information from habrahabr.ru
I hasten to share with You one of his gizmos, which were designed to facilitate the work to me as the system administrator, who knows, he'd inherited, the stuff in Active Directory.
The problem of inherited good, in my opinion, this group. About them will be discussed in this article.
Namely: go to Active Directory, cross the expanse of subdivisions and see a group of completely faceless names (e.g. Ugin, Vassa, Opel, www etc) and without a description. Attention a question: define what is needed by those groups.
the
What we get by inheritance
Now, we see the group, scratching his head. In the group of users from different departments. No signs on common sense. Perhaps the group name we vaguely can determine (or guess) what it was for. It will be a plus to someone You all left. What are we going to do?
The same goes for me at work, once engaged in the domain, I found a car and small truck such groups. And although all the people who own it before me was in charge, remained in place, no sensible answer could not give. If earlier it was possible to close eyes to it, there were a lot of other things, now came the need to restore order.
What is the meaning of life groups? As a rule, or access resources in shared folders, or filter to apply a group policy (do not take into account system groups like Domain Admins etc.)
So the task set for us: we need to check the Access Control List (ACL) of the folders in shared resources and group policy.
the
Hello mr. PoSh
Here comes into the arena of our Swiss army knife, with which we will open the ACL folder and politician.
As with politicians easier, start with them.
Group policy
To work with group policy we can help the grouppolicy module. From this module we use two cmdlet'a:
1. get-gpo that gives us a list of all group policies in a domain
2. get-gppermissions, which allows us to view the ACL policies.
Then, we're just looking for a match between the name of our group and the entry in the ACL, and if available, displaying information about this policy,
the
$name=read-host "Enter the full name of the account or group"
Write-Host -Fore RED "Check in group policy..."
$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 "policy Found!"; $gpo
If ($acl.Permission-eq "GpoApply")
{if ($acl.Denied) {Write-Host -Fore RED "prohibited Use policy"}}
}
}
}
Just want to note properties and Permission Denied in the ACL.
1. Permission — it contains the permissions for the object, such as applying a policy (GpoApply), read policy (GpoRead), policy changes (GpoEdit) or do it all at once (GpoEditDeleteModifySecurity).
2. Denied shows us permitted or prohibited, and what is displayed in the Permission.
If you look at a piece of script, we can see that if in the ACL group, will be denied (Denied-eq $true) application policy (Permission -eq "GpoApply"), then it displays a notification. In principle, it was possible to write notices for all cases, but my only concern is the prohibition of the dissemination policy.
PS Variable $name which is the name of our group, we will use the following piece of code.
Shared folders
Now shared folders. There are two options:
1. When permission is given directly to the shared resource.
2. When the permission on a folder, hidden in the depths of the shared resource.
Will go again in order.
Looking for on the surface
The easiest and most intuitive way is to give permissions to shared folders. It is better that all the permissions You have in the 1st place, and do not confuse Your heirs, when they get to 4 layers of folders and find a folder with photos of your birthday, where he was allowed to enter only your friend from the Accounting Department. Lose it tab, guess what the folder she needed? But we will return to it later.
the
Write-Host -Fore RED "Check is in the folder \\FileServer"
$dirs=get-wmiobject win32_Share -computername FileServer | where-object {$_.Name-notmatch "\$"}
Foreach ($dir in $dirs)
{
Trap [System.UnauthorizedAccessException]
{"Was denied access to the folder $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 "folder Found!" $share}
}
We also caught an error, which tells us that the access to certain folders closed, and instead of red scary error we will display a simple message.
Two lines, in which we replace 'D:' to '\\FileServer\d$' (and the same disk 'C') is necessary, because if this is not done, the cmdlet get-acl will attempt to scan these folders on our computer and, most likely, will not find. And look for path \\FileServer\Folder it is (the cmdlet get-acl) can not. In our example, only 2 disks, but adding another is not a problem.
Descend in depth
Go back to the familiar from the accounting Department. Now dig in subfolders.
I think many will say, why come up with something when you can use get-childitem -recurse. If your server is not a lot of folders — Yes, you can use recurse. But if you have about 7 TB of fileserver problems, in principle, either, you just have to wait a couple of hours, and it would work. And pray to God that you had errors in the middle of a search.
So -recurse will not help us, what then? Then we need to make a cycle, which according to our whims will delve into the depths of the folders on as much as we want (sounds that matter). 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 needed folders with the coveted permits.
the
Write-Host -Fore RED "Check is in the folder \\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]
{"Was denied access to the folder" + $WF.FullName; continue;}
$out=$null
$out=(get-acl $WF.FullName).Access | where-object {$_.IdentityReference -match "$name"}
if ($out-ne $null)
{Write-Host -Fore GREEN "folder Found!"; $WF.FullName}
}
You may notice that we only need folder, for this we filter the output using the PSIscontainer properties.
The variable $sub specifies the search depth. In the variable $AllPath store paths to all the folders that we found. Well, then, the familiar gestures, check ACL found folders for the presence of our group in them.
the end
Thus it is possible to find nearly any subsurface permissions to a specific group. Naturally, it is possible to use not only to search for groups, but also to search for user and computer (fortunately, I rarely encountered).
Do one script, 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 a life in a new place of work. There is nothing difficult that would be in the description of the group to write about her appointment. And there is nothing complex that would create this group and not to hang permissions on the account. If we all do this, we soon will not need to write such articles.
Комментарии
Отправить комментарий