Re: Associate Groups With Folders
- From: "Al Dunbar" <AlanNOSPAmDrub@xxxxxxxxxxx>
- Date: Mon, 17 Oct 2005 17:25:57 -0700
<colin.steadman@xxxxxxxxx> wrote in message
news:1129560971.048217.121550@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> I've written a simple script to return a list of groups that a user is
> a member of:
>
>
> -----------------------------------8<-----------------------------------
>
> sUser = inputbox ("Enter username", "Find Groups")
>
> Set WshNetwork = CreateObject("WScript.Network")
> Set UserObj = GetObject("WinNT://" & WshNetwork.UserDomain & "/" &
> sUser)
>
> For Each Group In UserObj.Groups
> groupList = groupList & Group.Name & vbcr
> Next
>
> msgbox groupList
>
> -----------------------------------8<-----------------------------------
>
> This works fine, but I need to know which folders these security groups
> have been assign too. For example, assume a user is a member of a
> group called PRJ-HRADMIN-RW, how could I find out that this group has
> been assigned to S:\HRADMIN?
>
> Is this possible in script?
Yes it is possible, but tedious (so tedious, in fact, that I do not have an
example to share with you). The permissions on folders are properties of the
folders not of the groups, so the only way is to check each possible folder
on each possible server to see which groups (and individuals!) have been
assigned permissions, and what types of permissions these are.
IMHO your best tool is a well-defined standard and the discipline necessary
to enforce/encourage the standard. The way we have implemented our security
would actually allow the type of information you are looking for to be
determined by looking only in AD:
First: for every folder to which you will be assigning permissions different
from its parent, create a single security group for each of the permission
types you will be using( i.e. read, modify, full). The name should end in a
code indicating the type of access, i.e. "Application xyz program files-R",
"Application xyz program files-W", and etc. Your example group name suggests
that this is the way you are already doing it.
Second, populate the description with the UNC of the resource being shared.
Third, grant the specified access to the groups created on the folder in
question.
Fourth, never, under any circumstances, ever permit any other resource to
these groups.
Fifth, populate these "resource permission" groups with groups and/or users,
as best fits your situation. My preference is to use another level of nested
groups here. This tends to increase the number of groups that exist, but it
will also reduce the number of group memberships managed for each user. For
example, if the users of application xyz need read access to the program
files, read access to the documentation, and change access to the data
files, create a group called "application xyz users", populate it with the
users (again, either directly, or with groups), then add it to the following
"resource permission" groups:
"application xyz program files-R"
"application xyz data files-W"
"application xyz documentation-R"
Of course, one could still ask the question: "but is the folder shared
correctly". The solution to that problem would be a QA process that is
unrelated to whether or not a particular user has the required access.
/Al
.
- Follow-Ups:
- Re: Associate Groups With Folders
- From: colin . steadman
- Re: Associate Groups With Folders
- References:
- Associate Groups With Folders
- From: colin . steadman
- Associate Groups With Folders
- Prev by Date: how to create 'my documents' folder
- Next by Date: Re: problem creating a shortcut on my desktop
- Previous by thread: Associate Groups With Folders
- Next by thread: Re: Associate Groups With Folders
- Index(es):
Relevant Pages
|
