Assigning Permissions to Users & Groups
Last Updated: 04 Nov 2003
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*** PLEASE NOTE: Link(s), If Provided, May Be Wrapped ***
Here are some guidelines for assigning user and group
permissions to Windows NT/2000 resources:
Basically, there are three (3) ID containers. The names
can be a bit confusing, so for clarification they can be
thought of as follows:
• Local Groups ----------> Machine Groups
• Global Groups ---------> Domain Groups
• Users -----------------> Users
You can put Users into both types of groups, but you can
only put Global (Domain) groups into Local (Machine)
groups -- not the other way around.
Let's look at a scenario with two (2) domains which fully
trust one another, called DOMAIN1 and DOMAIN2. If you have
a member server in DOMAIN1 called FILESERV1, then the best
way to setup permissions is as follows:
1. Map out the directory/share structure that you want.
2. Make the necessary Local Groups on FILESERV1.
3. Assign the permissions to FILESERV1 using the Local Groups.
4. Make the necessary Global Groups in each domain.
5. Put the User accounts into the Global Groups in each domain.
6. Put the relevant Global Groups into the Local Groups on FILESERV1.
Now, let's say that each domain has an Accounting Dept and
that you want to provide these two departments with access
to a resource on FILESERV1. Here's how it would work:
1. Setup folders/files
2. Create Local Group "FILESERV1\Accounting"
3. Use CACLS, Explorer or WinFile to set the ACLs on
"D:\Storage\Acct" to "FILESERV1\Accounting"
4a. Create Global Group "DOMAIN1\Accounting Dept"
4b. Create Global Group "DOMAIN2\Accounting Dept"
5a. Put the user account "DOMAIN1\Mary" into "DOMAIN1\Accounting Dept"
5b. Put the user account "DOMAIN1\Sue" into "DOMAIN1\Accounting Dept"
5c. Put the user account "DOMAIN1\John" into "DOMAIN1\Accounting Dept"
5d. Put the user account "DOMAIN2\Bob" into "DOMAIN2\Accounting Dept"
5e. Put the user account "DOMAIN2\Phil" into "DOMAIN2\Accounting Dept"
6a. Put "DOMAIN1\Accounting Dept" into "FILESERV1\Accounting"
6b. Put "DOMAIN2\Accounting Dept" into "FILESERV1\Accounting"
The benefit of doing this, particularly if Step #1 is
well planned, is that various people could leave your
organization or be transferred to other departments,
and all you would need to do is create new accounts and
place them in the correct right Global Group. There
would be no need to hunt all over the file structure
trying to find out what privileges Mary used to have,
so that you could assign them to her replacement.
Another benefit is that if you happen to only control
FILESERV1, but not DOMAIN1 or DOMAIN2, then you don't
have to be concerned AT ALL with the movement of
employees. All you need to care about is that
"Accounting folks have access here" and let someone
else worry with who constitutes the Accounting folks.
The less often you have to run CACLS/XCACLS, or, worse
yet, set permissions via Explorer, the less likely the
chance that you'll accidentally overwrite permissions
on subfolders, and the happier you'll be.
This structure makes it easy to add or remove domains,
too. Add a new domain (DOMAIN3), make them adhere to
the same standard and then go straight to Step #4.
There is one drawback to this method -- when you assign
permissions directly to a file or folder, it takes effect
for the user right away, but when the assignment is done
through group membership, it requires logging off and
back on again. IMO, this is a very minor price to pay
for not having to run Auditing tools all over the network
to find out who has access to what...
WHITEPAPERS & TECH DOCUMENTS
• http://KB.UltraTech-llc.com/Docs/?File=Secure2000Pro.htm
• http://support.microsoft.com/?KBID=268546
• http://support.microsoft.com/?KBID=296865
• http://www.winnetmag.com/windowsnt20002003faq/Article/ArticleID/13753/windowsnt20002003faq_13753.html
• http://www.winnetmag.com/windowsnt20002003faq/Article/ArticleID/13758/windowsnt20002003faq_13758.html
• http://www.winnetmag.com/windowsnt20002003faq/Article/ArticleID/13741/windowsnt20002003faq_13741.html
• http://www.microsoft.com/windows2000/techinfo/planning/security/secdefs.asp
• http://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/standard/lsm_overview_01.asp
PERSONAL NOTES
• The command line provides greater flexibility (and
less chance for problems) with regards to setting
file and folder permissions.
• While some folks advocate leaving SHARE permissions
at the default (EVERYONE:F) and relying only on FILE
level permissions, I secure every entry point. I'd
rather have a user denied from making the SHARE
connection, than let them connect to the resource
and then receive an "Access Denied" message (thus
needlessly tying up server resources).