This is an old post but I didn't see any
responses....
o I wouldn't recommend ACLing the share, ACL the
folder under the share. Just leave the share open for everyone FC and lock down
at the folder/file level for less issues in troubleshooting.
o Don't do FC, do CHANGE and READ perms. GC grants people
the ability to modify permissions so Admins can't easily see them when they need
to.
o Try to have as few shares shared for multiple users
as possible. I.E. Have a home share unique to everyone, but for data that
is shared to groups (a project share) consider having one share per
server and then the project info is in folders under that share. What that does
is reduce the number of drive letters people have to have and
remember.
For instance you could have the following
layout
Server
Share1
folder
Share2
folder
Share3
folder
Share4
folder
And if someone needed access to folders in Share1,2,3, and
4, they have burned up 4 drive letters.
I think a better solution is
Server
Share
folder1
folder2
folder3
folder4
And then you would have DLGs specific to each folder.
SRV-Folder1-R, SRV-Folder1-C, etc....
The biggest downside I can think of here is that if you
have access to only folder2, you still see 1,3,4. You don't have that issue in
Novell but MS has the issue. That sucks but I have found the benefits outweigh
that problem.
o Try to determine a group strategy and stick to it. Try to
stay with as few scopes as possible because group scoping confused the crap out
of people. If you pick one or maybe two groups to work with and say this is the
way it is people can work within it though it may not be completely flexible it
is generally more supportable. I personally like Domain Local Groups because
when someone says where does this group have access, it tends to be considerably
easier than it is for a universal or global group. It is still a pain, but at
least you have a tighter scope of where to look in a multiple domain forest or
if you have trusts. At the very least try to keep DLGs focused on resources.
I.E. Resource based groups. Role based groups are fun and all but tend to grow
in use outside of what they were intended for so when you want to clean up
later, it is tougher. If you know a group is specific to a certain folder in a
certain share, you know you can clean that up much easier because you simply
ask, who needs access to that folder. Though if you do role groups, those will
tend to be Uni's or globals. If you use UNIs, understand the limitations and
that you have to have GCs available. Some large companies have implemented
IgnoreGCFailure because they can't have GCs everywhere and can't have logons
failing when a GC can't be found. This means Uni groups may not be in your
token. Group caching is sort of an answer but I'll let Dean speak to issues with
it if he feels like it. I don't ever recommend using UNI's for denies. It is
possible that you not get a Uni in your token. It may not be likely if you
get one DC that has IgnoreGCFailures set and you hit it, you may not get
it. I actually don't recommend denies at all because they suck and are
confusing to the troubleshooting process but definitely don't do uni
denies.
o I am not a big fan of nesting groups into resource
groups. Why? Because the person who controls access to the resource probably
controls the membership of the resource group. If they had another group to that
resource group, they may not control membership of that other group and someone
could get added that shouldn't have access.
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Fontana
Sent: Tuesday, September 07, 2004 7:45 PM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] Suggestions on group deployment
In an effort to
improve file server security and group management as a whole I find myself
curious about what other folks do in similar situations.
The environment: 1
File Server, 1 Win2k3 Forest, 3 domains, Exchange 2k
Current config: A
bunch of global security groups that are pretty much useless and many, many
Universal Distribution Lists. How are permissions assigned to our shares
you ask? Domain Users - Full Control, except in those instances where
someone said, "hey, that's private, make me a group and remove everyone else's
permissions!"
So my current
thought is the following:
- Create Domain
Local groups on a "per share/per perm" basis, i.e.: sales-share_FC, for the
share called "Sales Share" and the access of Full Control, and give that group
the proper perms on the share. Those groups would be populated with either
users or mail-enabled Universal Security Groups (all UDGs would need to be
converted to USGs). The result: The ACLs on all shares will only ever have
groups, not users.
- All mail-enabled
groups will be mail-enabled Universal Security Groups
- Global groups will
be used if (1.) there's no need for this group to contain users from other
domains, or (2.) this group must be given access to resources in another
domain.
I have the feeling
I'm missing something.... If anyone sees something ridiculously wrong with
this setup please let me know.
TIA
-Alex
