• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 362
  • Last Modified:

group rights assignment

I am trying to do something simple and it is just not working. I have win2k server sp3 running AD DNS DHCP. Nothing too special. I have a share setup for file sharing. I want to limit acces to a certain folder to a certain group of people. I go to AD users and computers and right click on the domain Controllers section and add group( I have done this in users section also). I add some members to it. I then right click on the domain controllers section and choose properties and then Group policy. I edit the default domain policy-- windows settings|security settings|local policies|user rights assignment. I add the group to the "access this computer from the network". Then go on to remove all propagation to a specific folder and remove the everyone group and add the new group and give it full control. Can't access it. I have no errors in the event viewer or anything to suggest it is a problem with my DC. I think the problem is with me. I have treid to assign this group rights in the Domain controller polcy and the domain policy and the local policy, no luck. Does a group need more rights than I am giving it? This should be simple. Help
  • 8
  • 8
  • 3
  • +2
1 Solution
PremierncAuthor Commented:
Also, I have be running secedit /refreshpolicy machine_policy in between all of the changes.
PremierncAuthor Commented:
Also, I have tried this on a local win2k machine just to test and it seems to work. Just not om my domain controller.
I think you've got lost. Please confirm my assesment of your scenario.

You have a W2K Domain Controller running DNS and DHCP. You want to create a file share on this server and restrict access based on group membership.

This is simple.
1. Run AD Users & Computers
2. Select the Users folder.
3. Create a Group called "TestGroup"
4. Add users to this group.
5. Close ADUC
6. Run Explorer, create a folder, right-click, select Sharing
7. Share as TestShare
8. Click Permissions tab
9. Remove Everyone group and add TestGroup
10. Log a TestGroup member onto their PC and map to the new share
11. There you go.

Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

PremierncAuthor Commented:
One issue is, what rights does the group get or need? In your scenario, the group has no rights and when you take away basic permissions for everyone group on the share and then add the new group, no access. The group you assigned to the new share has no rights to access it.
Also, I am not acrtually creating a new share, just trying to change the rights to a folder in a share if this makes a difference. Also, I am logged in as Administrator on the DC doing all this. Just for the sake of time, I am testing it all on the DC without running down the hall to a workstation to test it. I have been careful to include administrator in the group. Thanks for the help, any more ideas?
The Domain Controllers OU does not process the Default Domain Policy.

Move the Group to a new OU and either create a new GPO to link to it or leave the Domain Policy as you modified it.

Netman, i agree with your first statement, but i'm not sure about the second one. as far as i know, you can't apply group policy directly to groups - even if they're in an ou. only the actual user and computer objects in the ou get the policy applied. maybe i'm wrong...

but i do agree that premiernc's domain policy should work as is.

You are too correct.  The Group AND associated User objects should be in the same OU for ease of administration.  

Now that I re-read the question it is a double issue.  You cannot apply GPOs to security Groups - the actual User and/or Computer object must reside in the OU also before you can apply the associated portion of that GPO.

Good eye!

PREMIERNC... "I want to limit acces to a certain folder to a certain group of people".

Why don't you create a group for these people, and use share and ntfs-rights to the folder.

Remeber to add global admin group before you remove everybody and domain users.

Many Regards
Jorgen Malmgren
PremierncAuthor Commented:
If I follow Ryangorman's directions, which policy will apply to the group of it is in the users container, and where exactly should I access it. I think I am confused by all of the different policies and which one does what.
Ok, here it goes....

File shares can be configured in such a way to allow or prevent user's access based on Security Group membership.  There are two factors at play here; Share permissions and NTFS permissions.  The Share permission is used for access across the network, such as a share on a server that is accessed via a client.  The NTFS permissions are added to the Share permissions to give the most restrictive set of access premissions.  NTFS permissions are also used for purely local access (ie. from the console of the PC that holds the share) and at this point the Share permissions are not used.

An example, TestShare is a share on Server1.  The Share permissions are: Authenticated Users - Full Control.  Access to this share is via a drive map or UNC name - in this example, \\Server1\TestShare.

Now, the folder that is shared also has NTFS permissions associated with it (by default - Everyone - Full Control) - this is assuming your file system on the PC with the shared folder is NTFS.  By also configuring NTFS permissions on that folder you create a layered set of access controls.  If, for example, the NTFS permissions on that shared folder are only Read for Authenticated Users then even when accessed across the LAN, the effective access permissions for the Authenticated Users group is still only Read to the contents of that Shared folder.

Do not confuse access permissions (either Share-level or file-level) with Group Policy.

Group Policy can be used to apply User-specific or Computer-specific (or both) settings to multiple objects in Active Directory at one time, thereby creating a uniform environment from a central location.  BUT, in order for Group Policy to apply, it must be set either at the Domain level, Site level or OU level and will affect (through inheritance) all the nested levels below it unless you specifically block inheritance on each OU, Site or Domain below the highest level the GPO is linked to.  A very important thing to remember is that GPO's can only be applied onto User or Computer objects.  What this means is that if your OU only contains Security Groups and you create and link a GPO to that OU, nothing will happen.  The OU must contain the objects you are trying to control - either the User accounts or the Computer accounts or both.

If you are stictly trying to control access to a share, folder or subset of folders, then Share and NTFS permissions are all you need to deal with - leave GPOs out of the solution.

If, on the other hand, you are trying to lock down the workstation's desktop or Start Menu, then yes, by all means, use GPOs to accomplish this.  Keep in mind that the objects you are trying to apply GPOs onto must be contained in the OU you are trying to control.

Moving user and computer accounts out of the default containers is perfectly fine and is definitly necessary if you are going to control the user's environment.  Most commonly OUs are created that represent each of your internal departments and the within these OUs there are other OUs for just computers and just users.  This is done to further segregate PCs and Users in the event that you want to use Group Policy to push out software specifically for each department, then either for each user or computer.  It allows much more flexibility when using Group Policy to control the environment without the need to filter the application of these policies if you cannot separate your target groups using less OUs in your structure.

All that being said, the default containers in Active Directory should not be used to link GPOs to with the exception of the Default Domain Policy.  Your Domain Controllers will always default to the Domain Controllers OU and for lack of any specific reason, should be left there.  The Default Domain Policy does not get applied onto the Domain Controllers OU for the pure reason that if your Domain has a resticted environment and you log onto that DC, you do not want the Domain Policy messing up the operational environment of the server.  This is by design.

Logically arrange your Active Directory to make your administration of that Domain easier on you.  User accounts and machine accounts are designed to be moved into OUs that you create to more effectively manage them, they do not have to be left in their default containers.

I hope this makes it more easily understood.

I'm glad Netman66 wrote that - I was baulking at writing such an essay.

I agree with Netman66 in that the original poster merely wants to secure a folder based on security group membership and that the OP has strayed into dangerous water (Domain Controller/Default Domain policy).

I can confirm virtually all of Netman's post. The bottom line is that the OP should undo any changes they made to the DCP/DDP and just use NTFS permissions using a security group.

The example below illustrates the impact of the placement of user & computer objects within OUs and GPO applied to these OUs.

OU1 contains five Finance users
OU2 contains five Sales users and a security group 'Legal'
OU3 contains all the computer accounts and one IT user
The Users folder contains five users who are members of the 'Legal' group

GPO_OU1 and GPO_OU2 are GPOs that applies changes to the User Configuration
GPO_OU3 is a GPO that applies changes to the Computer Configuration

1. The users in OU1 apply GPO_OU1

2. The users in OU2 apply GPO_OU2. However the members of the 'Legal' group won't apply GPO_OU2 because the user objects are not in OU2.

3. The computers in OU3 apply GPO_OU3. The IT user reads GPO_OU3 but can't see anything in User Configuration and so won'y apply GPO_OU3 unless his computer is within OU3.


For the record (anyone googling this at a later date) it *is* possible to apply GPOs based on security groups. This is called Group Policy Filtering [1].

Many Active Directory administrators wonder where to place security groups. I recommend you place them next to the group members.

[1] www.jsifaq.com/SUBM/tip6400/rh6420.htm
A better technical explanantion of filtering is not the actual application of GPOs, but instead the denial of application.  The User objects for the filtered Security Group must still reside in the same OU or the effect is still non-application of the GPO.

You cannot apply GPOs to Security Groups only to the User objects within that Group and only if they exist in the container where the GPO is linked or within a nested container below the level of the linked GPO.

Netman66: "You cannot apply GPOs to Security Groups only to the User objects within that Group "

Isn't that illustrated by number 2

2. The users in OU2 apply GPO_OU2. However the members of the 'Legal' group won't apply GPO_OU2 because the user objects are not in OU2.

Anyway, this is all academic. We both agree that Premiernc needs NTFS file permissions and not Group Policies.
PremierncAuthor Commented:
Thanks for all the great answers. Now that I understand what GPO's should be used for, I can stop messing with them. I guess I am not getting my question across right, let me try again. In the local policy plugin, under user rights assignment, this is where you need to give a group you just created rights to do things(correct?). If i just create a group in my users OU where the members are, they have no rights to do anything by belonging to that group. If I take away the Everyone group NTFS permission to a specific folder at the server console and add the New group I just created and give them Full Control, no access. I also have selected no inherit from above. My question is basically, where and when do I assign a group rights to access the network, shares, printers etc.?
By default, most groups created on a domain controller have permissions to access the server from the network.

The snap-in you mention for User rights are used when the defaults are not good enough for your needs.  For the most part and in almost all cases, the default settings here are okay.

Also, by default Domain Users are not allowed to log onto the server at the console.

On this new folder you created, you need to do the following:

Ensure that Adminstrators (or Domain Admin) Group and System have Full control.  The Group you created may have Full control if that is what you desire.  The reason for the SYSTEM is in the event you want to run any automated scripts or routines against these folders when there is nobody logged into the console of the server.

Now, share the folder and give the Group you created Full control also (to illustrate this example).

From one of you client machines, while logged on as a member of that new Group - either map the new share, or connect to it via my Network Places.  This new share can be mapped via login script if desired or can be mapped manually and set to maintain the mapping in the future.

This is all assuming that this folder is on the server - not a peer workstation and you are running in domain mode.

PremierncAuthor Commented:
The folder is on an existing share, deep within the file structure. I can give individual users rights to the directory and any other directory I tested on. It worked as expected. When I try to do the same procedure by group assignment, the members have no access. Where can I view the default rights given to a group that was just created?
If the individual can access the folder, the group should be able to as well.  The rights you speak of are only visible on objects you add the group to.  The only problem that would prevent access to an object is the DENY attribute.  If some members of this group belong to another group that has been explicitly denied access, then those users will also have no access regardless of any other permissions inherited by other group membership.  Deny always takes precedence over anything else.  If you do not want other groups to access this folder the best thing to do is NOT add that group to the permissions tab.

Is the Group a security group or distribution group?  It must be a Security Group - Distribution Groups are not for object permission assignment.

Also, is the Group a Domain Local, Global or Universal?

The rule of thumb for MS file sharing is this:

Place Users into Global groups.  Create a Domain Local Group and assign the appropriate permissions for this group on the object (for example a file share or printer).  Nest the Global Group into the Domain Local Group and all should be well.

It is not good practice to place user objects directly into the ACE or ACL of objects.

Try this:

In the same OU as the users, create a Global Security Group named TestAccess.  Add the members you require.

Now, create a Domain Local Security Group in the same OU named ObjectAccess.

Go to the share and NTFS permissions of the folder you want to share out and remove all the permissions there.  Add the following: Administrators Group>Full Control, SYSTEM>Full Control and ObjectAccess>Full Control --- Do this on both the share and file-level permissions.

Now, add the TestAccess Group to the membership tab of the ObjectAccess Group.

Log into a workstation as a member of the TestAccess Group and attempt to access your share.


PremierncAuthor Commented:
Thank you,
I followed your steps and it worked like a charm. So basically, global groups can be members of local domain groups but not the other way around? It just seemed so confusing to have to make 2 different groups to make only 1 group work, sounds lame.
I did notice once it started working, you can take away rights to the folder from the oblectaccess group and they take affect immediately, but give them new rights and they have to log out and login to take affect, does that sound right to you?
You definitely get the points for this one, thanks for such a good step by step explanation. If you could exand on why the 2 groups are neccessary that would be great.
Thanks again
Sure thing.

It's not that it isn't technically possible to have only one group, but it's cleaner and more of an accepted way to do things with the way I explained.

Global Group are used to group users that need common permissions - such as Admin, Accounting, Sales ...you get the idea.  

Domain Local Groups are created on the server hosting the shared resource - this makes it easy to change permissions and only be concerned with one group.  You can nest any number of Global Groups inside this local group to better manage access.  Take away a member of the Global Group and it doesn't affect anyone else.

If you have a user listed in the ACE of the object and you then delete that user, you're left with an orphaned SID attached to the object which can cause some confusion later in life.

And, yes, removing permissions is immediate, but adding requires the group members to log in again to have them apply - just by design, don't hurt your head about it.

If you search TechNet on Groups, you'll find tons of explanations on how MS like to see it.

Glad you got it fixed and learned something too!


PremierncAuthor Commented:
I guess I got sidetracked because we only have one domain and no real need for global stuff.
Thanks again,
I upped the points because you deserve it.

It can get a bit confusing at times, but the principal is still the same.

Here are a few articles for you to read - I was rushed earlier and wanted to give you something in print.





Great, clear reading - print them out for reference.

Most of all, enjoy your learning curve - it's what we do!


Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 8
  • 8
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now