Get associated security group for each folder?












0















I am using the powershell code below to get a list of folders and subfolders on a network share. Is it possible to also display the associated security group with it? For instance Select-Object fullname,securitygroup? And if possible also then grab the list of users that are a member of that group? Thank you!



Output would be like:



ServerShareFolder1 Folder1-W John Doe....



Get-ChildItem \ServerShare | Where { $_.PSIsContainer } | Foreach  {Get-Childitem $_.FullName}| Where { $_.PSIsContainer } | Select-Object fullname









share|improve this question























  • I assume that by "associated security group" you mean a group used to grant users permissions to access the folder. You need some set of consistent criteria to identify which group is the "associated security group", because there's no way for the OS to identify inherently which group in the ACL is being used for a given purpose. For example, does it always have a name that can be derived from the folder name? Is it always the only group other than BUILTINAdministrators and NT AUTHORITYSYSTEM that has permissions? Is it the only group with explicit (i.e. non-inherited) permissions?

    – Adi Inbar
    Mar 11 '14 at 20:16











  • Ok, sorry per share we have 3 security groups folder1-r, folder1-w, folder1-o so maybe this isnt possible?

    – user1342164
    Mar 11 '14 at 20:25











  • I suppose by "associated group" you mean access permissions on the folders. You can use the Get-Acl cmdlet to obtain that information. It's also possible to retrieve the members of a given group. However, the code to do this depends on whether you have to resolve local or domain users/groups.

    – Ansgar Wiechers
    Mar 11 '14 at 21:17
















0















I am using the powershell code below to get a list of folders and subfolders on a network share. Is it possible to also display the associated security group with it? For instance Select-Object fullname,securitygroup? And if possible also then grab the list of users that are a member of that group? Thank you!



Output would be like:



ServerShareFolder1 Folder1-W John Doe....



Get-ChildItem \ServerShare | Where { $_.PSIsContainer } | Foreach  {Get-Childitem $_.FullName}| Where { $_.PSIsContainer } | Select-Object fullname









share|improve this question























  • I assume that by "associated security group" you mean a group used to grant users permissions to access the folder. You need some set of consistent criteria to identify which group is the "associated security group", because there's no way for the OS to identify inherently which group in the ACL is being used for a given purpose. For example, does it always have a name that can be derived from the folder name? Is it always the only group other than BUILTINAdministrators and NT AUTHORITYSYSTEM that has permissions? Is it the only group with explicit (i.e. non-inherited) permissions?

    – Adi Inbar
    Mar 11 '14 at 20:16











  • Ok, sorry per share we have 3 security groups folder1-r, folder1-w, folder1-o so maybe this isnt possible?

    – user1342164
    Mar 11 '14 at 20:25











  • I suppose by "associated group" you mean access permissions on the folders. You can use the Get-Acl cmdlet to obtain that information. It's also possible to retrieve the members of a given group. However, the code to do this depends on whether you have to resolve local or domain users/groups.

    – Ansgar Wiechers
    Mar 11 '14 at 21:17














0












0








0








I am using the powershell code below to get a list of folders and subfolders on a network share. Is it possible to also display the associated security group with it? For instance Select-Object fullname,securitygroup? And if possible also then grab the list of users that are a member of that group? Thank you!



Output would be like:



ServerShareFolder1 Folder1-W John Doe....



Get-ChildItem \ServerShare | Where { $_.PSIsContainer } | Foreach  {Get-Childitem $_.FullName}| Where { $_.PSIsContainer } | Select-Object fullname









share|improve this question














I am using the powershell code below to get a list of folders and subfolders on a network share. Is it possible to also display the associated security group with it? For instance Select-Object fullname,securitygroup? And if possible also then grab the list of users that are a member of that group? Thank you!



Output would be like:



ServerShareFolder1 Folder1-W John Doe....



Get-ChildItem \ServerShare | Where { $_.PSIsContainer } | Foreach  {Get-Childitem $_.FullName}| Where { $_.PSIsContainer } | Select-Object fullname






powershell






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Mar 11 '14 at 19:49









user1342164user1342164

575102653




575102653













  • I assume that by "associated security group" you mean a group used to grant users permissions to access the folder. You need some set of consistent criteria to identify which group is the "associated security group", because there's no way for the OS to identify inherently which group in the ACL is being used for a given purpose. For example, does it always have a name that can be derived from the folder name? Is it always the only group other than BUILTINAdministrators and NT AUTHORITYSYSTEM that has permissions? Is it the only group with explicit (i.e. non-inherited) permissions?

    – Adi Inbar
    Mar 11 '14 at 20:16











  • Ok, sorry per share we have 3 security groups folder1-r, folder1-w, folder1-o so maybe this isnt possible?

    – user1342164
    Mar 11 '14 at 20:25











  • I suppose by "associated group" you mean access permissions on the folders. You can use the Get-Acl cmdlet to obtain that information. It's also possible to retrieve the members of a given group. However, the code to do this depends on whether you have to resolve local or domain users/groups.

    – Ansgar Wiechers
    Mar 11 '14 at 21:17



















  • I assume that by "associated security group" you mean a group used to grant users permissions to access the folder. You need some set of consistent criteria to identify which group is the "associated security group", because there's no way for the OS to identify inherently which group in the ACL is being used for a given purpose. For example, does it always have a name that can be derived from the folder name? Is it always the only group other than BUILTINAdministrators and NT AUTHORITYSYSTEM that has permissions? Is it the only group with explicit (i.e. non-inherited) permissions?

    – Adi Inbar
    Mar 11 '14 at 20:16











  • Ok, sorry per share we have 3 security groups folder1-r, folder1-w, folder1-o so maybe this isnt possible?

    – user1342164
    Mar 11 '14 at 20:25











  • I suppose by "associated group" you mean access permissions on the folders. You can use the Get-Acl cmdlet to obtain that information. It's also possible to retrieve the members of a given group. However, the code to do this depends on whether you have to resolve local or domain users/groups.

    – Ansgar Wiechers
    Mar 11 '14 at 21:17

















I assume that by "associated security group" you mean a group used to grant users permissions to access the folder. You need some set of consistent criteria to identify which group is the "associated security group", because there's no way for the OS to identify inherently which group in the ACL is being used for a given purpose. For example, does it always have a name that can be derived from the folder name? Is it always the only group other than BUILTINAdministrators and NT AUTHORITYSYSTEM that has permissions? Is it the only group with explicit (i.e. non-inherited) permissions?

– Adi Inbar
Mar 11 '14 at 20:16





I assume that by "associated security group" you mean a group used to grant users permissions to access the folder. You need some set of consistent criteria to identify which group is the "associated security group", because there's no way for the OS to identify inherently which group in the ACL is being used for a given purpose. For example, does it always have a name that can be derived from the folder name? Is it always the only group other than BUILTINAdministrators and NT AUTHORITYSYSTEM that has permissions? Is it the only group with explicit (i.e. non-inherited) permissions?

– Adi Inbar
Mar 11 '14 at 20:16













Ok, sorry per share we have 3 security groups folder1-r, folder1-w, folder1-o so maybe this isnt possible?

– user1342164
Mar 11 '14 at 20:25





Ok, sorry per share we have 3 security groups folder1-r, folder1-w, folder1-o so maybe this isnt possible?

– user1342164
Mar 11 '14 at 20:25













I suppose by "associated group" you mean access permissions on the folders. You can use the Get-Acl cmdlet to obtain that information. It's also possible to retrieve the members of a given group. However, the code to do this depends on whether you have to resolve local or domain users/groups.

– Ansgar Wiechers
Mar 11 '14 at 21:17





I suppose by "associated group" you mean access permissions on the folders. You can use the Get-Acl cmdlet to obtain that information. It's also possible to retrieve the members of a given group. However, the code to do this depends on whether you have to resolve local or domain users/groups.

– Ansgar Wiechers
Mar 11 '14 at 21:17












2 Answers
2






active

oldest

votes


















0














I assume that by "associated security group" you mean a group used to grant users permissions to access the folder. There's no way for the OS to identify inherently what purposes the groups in the ACL are being used for, so you need to determine some set of consistent criteria that can be used to identify which groups are "associated security groups".



Some examples:




  • Are the "associated security groups" always the only security principals with permissions? (If so, that makes things simpler; but it's also very unlikely, because you'll generally have at least BUILTINAdministrators, Domain Admins, NT AUTHORITYSYSTEM, and CREATOR OWNER.)

  • Do the groups follow some naming convention that can be derived from the folder names? For example, I've used a naming convention like ACL_ServerName_ShareName_PermissionsCode (e.g. ACL_HQFP01_Shared-Folder1-M). In that scenario, it's always possible to identify the permissions group names given the share and subfolder names.

  • Are the groups always the only security principals with explicit (i.e. non-inherited) permissions?


I'm going to take a guess that you're following Microsoft's recommended best practices: that you're using NTFS permissions, and you're not assigning explicit permissions to anything other than domain groups designated for that purpose, which would make these "associated security groups" the only security principals with explicit permissions. In that case, you can include a comma-separated list of these groups like this:





| Select-Object FullName, @{Name = 'AssociatedSecuirtyGroups'; Expression = {((Get-Acl $_).Access | ?{! $_.IsInherited} | Select-Object -ExpandProperty IdentityReference) -join ', '}}


You can get the members of the groups by importing the Active Directory module and using Get-ADGroupMember (or there are more complicated ways to query AD without the module), but exactly how depends on which way you want to "grab" them, because if you can have multiple associated security groups for one folder, then you can't do it in a one line per folder display, at least not without making things very messy.






share|improve this answer
























  • When I run this I get the error Get-Acl : The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input

    – user1342164
    Mar 12 '14 at 12:04



















0














Rather than filter for folders after you pull the directory listing, why not filter first? It should speed things up considerably. Then you can run the results through a loop to pull security groups with Get-ACL, and get the members with Get-ADGroupMember at that point. Try this on for size...



$Output = @()
$DirList = GCI \servershare -directory | %{$_.FullName; GCI $_ -Directory|select -expandproperty FullName}
ForEach($Dir in $DirList){
$ACLs=@()
(get-acl $Dir).accesstostring.split("`n")|?{$_ -match "^(.+?admin(istrators|141))s+?(w+?)s+?(.+)$"}|%{
$ACLs+=[PSCUSTOMOBJECT]@{Group=$Matches[1];Type=$Matches[2];Access=$Matches[3]}
}
ForEach($ACL in $ACLs){
if($Members){Remove-Variable Members}
$Members = Get-ADGroupMember $ACL.Group -ErrorAction SilentlyContinue|%{[string]$_.SamAccountName}
$Output += "$Dir $($ACL.Group) $($ACL.Access) $($Members -join ",")"
}
}


Now, your output doesn't seem very realistic considering what all you want, so I made it one line per group for each folder in this format: such as:

\Server01ShareA ShareA-R ReadOnly JohnDoe,JaneSmith

\Server01ShareA ShareA-W Read,Write JackDaniels,CaptMorgan

\Server01ShareB ShareB-R ReadOnly JohnDoe

That just made more sense to me since you wanted groups split out to the user level. I suppose you could list each person on their own line for each share, but your list is going to be really long. Anyway, you should be able to get something that you want with what I gave you.






share|improve this answer
























  • Thanks, when I run this i get an error that Get-ChildItem : A parameter cannot be found that matches parameter name 'directory'.

    – user1342164
    Mar 12 '14 at 12:06











  • Ah, sorry, I forget that the -directory switch hasn't always existed. You will need to use the |?{$_.PSContainer} method you were using before

    – TheMadTechnician
    Mar 12 '14 at 14:52











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f22335164%2fget-associated-security-group-for-each-folder%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














I assume that by "associated security group" you mean a group used to grant users permissions to access the folder. There's no way for the OS to identify inherently what purposes the groups in the ACL are being used for, so you need to determine some set of consistent criteria that can be used to identify which groups are "associated security groups".



Some examples:




  • Are the "associated security groups" always the only security principals with permissions? (If so, that makes things simpler; but it's also very unlikely, because you'll generally have at least BUILTINAdministrators, Domain Admins, NT AUTHORITYSYSTEM, and CREATOR OWNER.)

  • Do the groups follow some naming convention that can be derived from the folder names? For example, I've used a naming convention like ACL_ServerName_ShareName_PermissionsCode (e.g. ACL_HQFP01_Shared-Folder1-M). In that scenario, it's always possible to identify the permissions group names given the share and subfolder names.

  • Are the groups always the only security principals with explicit (i.e. non-inherited) permissions?


I'm going to take a guess that you're following Microsoft's recommended best practices: that you're using NTFS permissions, and you're not assigning explicit permissions to anything other than domain groups designated for that purpose, which would make these "associated security groups" the only security principals with explicit permissions. In that case, you can include a comma-separated list of these groups like this:





| Select-Object FullName, @{Name = 'AssociatedSecuirtyGroups'; Expression = {((Get-Acl $_).Access | ?{! $_.IsInherited} | Select-Object -ExpandProperty IdentityReference) -join ', '}}


You can get the members of the groups by importing the Active Directory module and using Get-ADGroupMember (or there are more complicated ways to query AD without the module), but exactly how depends on which way you want to "grab" them, because if you can have multiple associated security groups for one folder, then you can't do it in a one line per folder display, at least not without making things very messy.






share|improve this answer
























  • When I run this I get the error Get-Acl : The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input

    – user1342164
    Mar 12 '14 at 12:04
















0














I assume that by "associated security group" you mean a group used to grant users permissions to access the folder. There's no way for the OS to identify inherently what purposes the groups in the ACL are being used for, so you need to determine some set of consistent criteria that can be used to identify which groups are "associated security groups".



Some examples:




  • Are the "associated security groups" always the only security principals with permissions? (If so, that makes things simpler; but it's also very unlikely, because you'll generally have at least BUILTINAdministrators, Domain Admins, NT AUTHORITYSYSTEM, and CREATOR OWNER.)

  • Do the groups follow some naming convention that can be derived from the folder names? For example, I've used a naming convention like ACL_ServerName_ShareName_PermissionsCode (e.g. ACL_HQFP01_Shared-Folder1-M). In that scenario, it's always possible to identify the permissions group names given the share and subfolder names.

  • Are the groups always the only security principals with explicit (i.e. non-inherited) permissions?


I'm going to take a guess that you're following Microsoft's recommended best practices: that you're using NTFS permissions, and you're not assigning explicit permissions to anything other than domain groups designated for that purpose, which would make these "associated security groups" the only security principals with explicit permissions. In that case, you can include a comma-separated list of these groups like this:





| Select-Object FullName, @{Name = 'AssociatedSecuirtyGroups'; Expression = {((Get-Acl $_).Access | ?{! $_.IsInherited} | Select-Object -ExpandProperty IdentityReference) -join ', '}}


You can get the members of the groups by importing the Active Directory module and using Get-ADGroupMember (or there are more complicated ways to query AD without the module), but exactly how depends on which way you want to "grab" them, because if you can have multiple associated security groups for one folder, then you can't do it in a one line per folder display, at least not without making things very messy.






share|improve this answer
























  • When I run this I get the error Get-Acl : The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input

    – user1342164
    Mar 12 '14 at 12:04














0












0








0







I assume that by "associated security group" you mean a group used to grant users permissions to access the folder. There's no way for the OS to identify inherently what purposes the groups in the ACL are being used for, so you need to determine some set of consistent criteria that can be used to identify which groups are "associated security groups".



Some examples:




  • Are the "associated security groups" always the only security principals with permissions? (If so, that makes things simpler; but it's also very unlikely, because you'll generally have at least BUILTINAdministrators, Domain Admins, NT AUTHORITYSYSTEM, and CREATOR OWNER.)

  • Do the groups follow some naming convention that can be derived from the folder names? For example, I've used a naming convention like ACL_ServerName_ShareName_PermissionsCode (e.g. ACL_HQFP01_Shared-Folder1-M). In that scenario, it's always possible to identify the permissions group names given the share and subfolder names.

  • Are the groups always the only security principals with explicit (i.e. non-inherited) permissions?


I'm going to take a guess that you're following Microsoft's recommended best practices: that you're using NTFS permissions, and you're not assigning explicit permissions to anything other than domain groups designated for that purpose, which would make these "associated security groups" the only security principals with explicit permissions. In that case, you can include a comma-separated list of these groups like this:





| Select-Object FullName, @{Name = 'AssociatedSecuirtyGroups'; Expression = {((Get-Acl $_).Access | ?{! $_.IsInherited} | Select-Object -ExpandProperty IdentityReference) -join ', '}}


You can get the members of the groups by importing the Active Directory module and using Get-ADGroupMember (or there are more complicated ways to query AD without the module), but exactly how depends on which way you want to "grab" them, because if you can have multiple associated security groups for one folder, then you can't do it in a one line per folder display, at least not without making things very messy.






share|improve this answer













I assume that by "associated security group" you mean a group used to grant users permissions to access the folder. There's no way for the OS to identify inherently what purposes the groups in the ACL are being used for, so you need to determine some set of consistent criteria that can be used to identify which groups are "associated security groups".



Some examples:




  • Are the "associated security groups" always the only security principals with permissions? (If so, that makes things simpler; but it's also very unlikely, because you'll generally have at least BUILTINAdministrators, Domain Admins, NT AUTHORITYSYSTEM, and CREATOR OWNER.)

  • Do the groups follow some naming convention that can be derived from the folder names? For example, I've used a naming convention like ACL_ServerName_ShareName_PermissionsCode (e.g. ACL_HQFP01_Shared-Folder1-M). In that scenario, it's always possible to identify the permissions group names given the share and subfolder names.

  • Are the groups always the only security principals with explicit (i.e. non-inherited) permissions?


I'm going to take a guess that you're following Microsoft's recommended best practices: that you're using NTFS permissions, and you're not assigning explicit permissions to anything other than domain groups designated for that purpose, which would make these "associated security groups" the only security principals with explicit permissions. In that case, you can include a comma-separated list of these groups like this:





| Select-Object FullName, @{Name = 'AssociatedSecuirtyGroups'; Expression = {((Get-Acl $_).Access | ?{! $_.IsInherited} | Select-Object -ExpandProperty IdentityReference) -join ', '}}


You can get the members of the groups by importing the Active Directory module and using Get-ADGroupMember (or there are more complicated ways to query AD without the module), but exactly how depends on which way you want to "grab" them, because if you can have multiple associated security groups for one folder, then you can't do it in a one line per folder display, at least not without making things very messy.







share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 11 '14 at 21:40









Adi InbarAdi Inbar

8,886103961




8,886103961













  • When I run this I get the error Get-Acl : The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input

    – user1342164
    Mar 12 '14 at 12:04



















  • When I run this I get the error Get-Acl : The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input

    – user1342164
    Mar 12 '14 at 12:04

















When I run this I get the error Get-Acl : The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input

– user1342164
Mar 12 '14 at 12:04





When I run this I get the error Get-Acl : The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input

– user1342164
Mar 12 '14 at 12:04













0














Rather than filter for folders after you pull the directory listing, why not filter first? It should speed things up considerably. Then you can run the results through a loop to pull security groups with Get-ACL, and get the members with Get-ADGroupMember at that point. Try this on for size...



$Output = @()
$DirList = GCI \servershare -directory | %{$_.FullName; GCI $_ -Directory|select -expandproperty FullName}
ForEach($Dir in $DirList){
$ACLs=@()
(get-acl $Dir).accesstostring.split("`n")|?{$_ -match "^(.+?admin(istrators|141))s+?(w+?)s+?(.+)$"}|%{
$ACLs+=[PSCUSTOMOBJECT]@{Group=$Matches[1];Type=$Matches[2];Access=$Matches[3]}
}
ForEach($ACL in $ACLs){
if($Members){Remove-Variable Members}
$Members = Get-ADGroupMember $ACL.Group -ErrorAction SilentlyContinue|%{[string]$_.SamAccountName}
$Output += "$Dir $($ACL.Group) $($ACL.Access) $($Members -join ",")"
}
}


Now, your output doesn't seem very realistic considering what all you want, so I made it one line per group for each folder in this format: such as:

\Server01ShareA ShareA-R ReadOnly JohnDoe,JaneSmith

\Server01ShareA ShareA-W Read,Write JackDaniels,CaptMorgan

\Server01ShareB ShareB-R ReadOnly JohnDoe

That just made more sense to me since you wanted groups split out to the user level. I suppose you could list each person on their own line for each share, but your list is going to be really long. Anyway, you should be able to get something that you want with what I gave you.






share|improve this answer
























  • Thanks, when I run this i get an error that Get-ChildItem : A parameter cannot be found that matches parameter name 'directory'.

    – user1342164
    Mar 12 '14 at 12:06











  • Ah, sorry, I forget that the -directory switch hasn't always existed. You will need to use the |?{$_.PSContainer} method you were using before

    – TheMadTechnician
    Mar 12 '14 at 14:52
















0














Rather than filter for folders after you pull the directory listing, why not filter first? It should speed things up considerably. Then you can run the results through a loop to pull security groups with Get-ACL, and get the members with Get-ADGroupMember at that point. Try this on for size...



$Output = @()
$DirList = GCI \servershare -directory | %{$_.FullName; GCI $_ -Directory|select -expandproperty FullName}
ForEach($Dir in $DirList){
$ACLs=@()
(get-acl $Dir).accesstostring.split("`n")|?{$_ -match "^(.+?admin(istrators|141))s+?(w+?)s+?(.+)$"}|%{
$ACLs+=[PSCUSTOMOBJECT]@{Group=$Matches[1];Type=$Matches[2];Access=$Matches[3]}
}
ForEach($ACL in $ACLs){
if($Members){Remove-Variable Members}
$Members = Get-ADGroupMember $ACL.Group -ErrorAction SilentlyContinue|%{[string]$_.SamAccountName}
$Output += "$Dir $($ACL.Group) $($ACL.Access) $($Members -join ",")"
}
}


Now, your output doesn't seem very realistic considering what all you want, so I made it one line per group for each folder in this format: such as:

\Server01ShareA ShareA-R ReadOnly JohnDoe,JaneSmith

\Server01ShareA ShareA-W Read,Write JackDaniels,CaptMorgan

\Server01ShareB ShareB-R ReadOnly JohnDoe

That just made more sense to me since you wanted groups split out to the user level. I suppose you could list each person on their own line for each share, but your list is going to be really long. Anyway, you should be able to get something that you want with what I gave you.






share|improve this answer
























  • Thanks, when I run this i get an error that Get-ChildItem : A parameter cannot be found that matches parameter name 'directory'.

    – user1342164
    Mar 12 '14 at 12:06











  • Ah, sorry, I forget that the -directory switch hasn't always existed. You will need to use the |?{$_.PSContainer} method you were using before

    – TheMadTechnician
    Mar 12 '14 at 14:52














0












0








0







Rather than filter for folders after you pull the directory listing, why not filter first? It should speed things up considerably. Then you can run the results through a loop to pull security groups with Get-ACL, and get the members with Get-ADGroupMember at that point. Try this on for size...



$Output = @()
$DirList = GCI \servershare -directory | %{$_.FullName; GCI $_ -Directory|select -expandproperty FullName}
ForEach($Dir in $DirList){
$ACLs=@()
(get-acl $Dir).accesstostring.split("`n")|?{$_ -match "^(.+?admin(istrators|141))s+?(w+?)s+?(.+)$"}|%{
$ACLs+=[PSCUSTOMOBJECT]@{Group=$Matches[1];Type=$Matches[2];Access=$Matches[3]}
}
ForEach($ACL in $ACLs){
if($Members){Remove-Variable Members}
$Members = Get-ADGroupMember $ACL.Group -ErrorAction SilentlyContinue|%{[string]$_.SamAccountName}
$Output += "$Dir $($ACL.Group) $($ACL.Access) $($Members -join ",")"
}
}


Now, your output doesn't seem very realistic considering what all you want, so I made it one line per group for each folder in this format: such as:

\Server01ShareA ShareA-R ReadOnly JohnDoe,JaneSmith

\Server01ShareA ShareA-W Read,Write JackDaniels,CaptMorgan

\Server01ShareB ShareB-R ReadOnly JohnDoe

That just made more sense to me since you wanted groups split out to the user level. I suppose you could list each person on their own line for each share, but your list is going to be really long. Anyway, you should be able to get something that you want with what I gave you.






share|improve this answer













Rather than filter for folders after you pull the directory listing, why not filter first? It should speed things up considerably. Then you can run the results through a loop to pull security groups with Get-ACL, and get the members with Get-ADGroupMember at that point. Try this on for size...



$Output = @()
$DirList = GCI \servershare -directory | %{$_.FullName; GCI $_ -Directory|select -expandproperty FullName}
ForEach($Dir in $DirList){
$ACLs=@()
(get-acl $Dir).accesstostring.split("`n")|?{$_ -match "^(.+?admin(istrators|141))s+?(w+?)s+?(.+)$"}|%{
$ACLs+=[PSCUSTOMOBJECT]@{Group=$Matches[1];Type=$Matches[2];Access=$Matches[3]}
}
ForEach($ACL in $ACLs){
if($Members){Remove-Variable Members}
$Members = Get-ADGroupMember $ACL.Group -ErrorAction SilentlyContinue|%{[string]$_.SamAccountName}
$Output += "$Dir $($ACL.Group) $($ACL.Access) $($Members -join ",")"
}
}


Now, your output doesn't seem very realistic considering what all you want, so I made it one line per group for each folder in this format: such as:

\Server01ShareA ShareA-R ReadOnly JohnDoe,JaneSmith

\Server01ShareA ShareA-W Read,Write JackDaniels,CaptMorgan

\Server01ShareB ShareB-R ReadOnly JohnDoe

That just made more sense to me since you wanted groups split out to the user level. I suppose you could list each person on their own line for each share, but your list is going to be really long. Anyway, you should be able to get something that you want with what I gave you.







share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 11 '14 at 22:38









TheMadTechnicianTheMadTechnician

25.3k21731




25.3k21731













  • Thanks, when I run this i get an error that Get-ChildItem : A parameter cannot be found that matches parameter name 'directory'.

    – user1342164
    Mar 12 '14 at 12:06











  • Ah, sorry, I forget that the -directory switch hasn't always existed. You will need to use the |?{$_.PSContainer} method you were using before

    – TheMadTechnician
    Mar 12 '14 at 14:52



















  • Thanks, when I run this i get an error that Get-ChildItem : A parameter cannot be found that matches parameter name 'directory'.

    – user1342164
    Mar 12 '14 at 12:06











  • Ah, sorry, I forget that the -directory switch hasn't always existed. You will need to use the |?{$_.PSContainer} method you were using before

    – TheMadTechnician
    Mar 12 '14 at 14:52

















Thanks, when I run this i get an error that Get-ChildItem : A parameter cannot be found that matches parameter name 'directory'.

– user1342164
Mar 12 '14 at 12:06





Thanks, when I run this i get an error that Get-ChildItem : A parameter cannot be found that matches parameter name 'directory'.

– user1342164
Mar 12 '14 at 12:06













Ah, sorry, I forget that the -directory switch hasn't always existed. You will need to use the |?{$_.PSContainer} method you were using before

– TheMadTechnician
Mar 12 '14 at 14:52





Ah, sorry, I forget that the -directory switch hasn't always existed. You will need to use the |?{$_.PSContainer} method you were using before

– TheMadTechnician
Mar 12 '14 at 14:52


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f22335164%2fget-associated-security-group-for-each-folder%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Monofisismo

Angular Downloading a file using contenturl with Basic Authentication

Olmecas