Group Policy and OUs

I am trying to wrap my head around group policy and OUs by using my organization as a comparison.

First, every thing I read says OUs are mainly for organizing objects for administrative control. Now in my situation, we have a single domain and 3 IT staff (myself and 2 employees) that all currently have domain admin access. I have not delegated certain admin functions to my other 2 staff, but they can do everything I can do.

We are not currently using Group Policy or OUs, but will move to that with a migration later this year. It's a fairly small organization.

We have a majority of our staff that are simply low level end users. These staff should all have very minimal control because they move from post to post and may be assigned to different computers every day.

My original intent was to create an OU for these users (and basically one for each department) so that I can use group policy so they all have the same shortcuts to intranet resources on their desktop and block certain features of Windows.

From what I'm reading, OUs are meant to organize users, groups and computers to delegate admin control, not to define political and departmental boundaries. So essentially, I could delegate the administration of a particular OU to one of my staff. One of the examples for a single domain - single site was to have an OU each for Users, Groups and Computers.

So in this case, it seems I would create a group for these users. But if that's the case, if I create a GPO and link it to the Users OU, how can I apply the GPO to only that particular group instead of the whole OU? Or am I just looking at it completely wrong? I imagine that I will get to that answer eventually in my studies, but it is causing some confusion and want to make sure I understand how I will implement this in the future.

Find more posts tagged with

Comments

nmarlowe

I figured this would happen, I just reached a point in the TrainSignal video where he discusses OU functions and kind of addresses this. He advises to decide what's most important out of the functions (Being Organized, Delegation of Control, and Application of Group Policy) and structure your OUs that way. The most common structures are Location, Department, and Function.

In my case, I could either go with Department or Function. Function could be as simple as Users and Power Users, but I don't want to start off in a position of being so simple I can't easily grow my structure. Most of my users I want to have a very controlled environment due mainly to working on shared computers. I seem to have some "experts" working in the middle of the night that try to fix the perceived slow network by downloading and installing registry fixing apps, and then emailing me complaining that they don't have the ability to install software. However, I do have upper level staff that are assigned a computer and I have no problem with them installing software as they are smart enough to not do it until they talk to me first.

So now, my question is more of what's more or less the best practice approach for a fairly small environment. By small I'm talking ~400 users and 100 computers.

cruwl

I'm currently going through this. When i walked in our users were by Department OUs, and our computers were all together. Im currently working on restructuring our computer OU so i can apply certain GPOs to the VMs(by department), Certain ones to the laptops, and certain ones to the Desktops. and this is cause i want different settings on different ones.

Just my 2 cents.

nmarlowe

I don't want it to be so simple that I have to redo it next year. But I also don't want a complicated design for the sake of complication.

So I'm thinking my top level will be department. The advantage here is that if I have a department with 2-4 people, it will be much easier to give them identical experiences. My only fear with doing it by department is that it could get convoluted. But I think this may be the best way in my case.

Next level could be functional. It could either go supervisors and front line staff, or power users and restricted users.

crrussell3

This is how we do our OU structure

with the structure below, I can apply gpos that should apply to all computers at the top level computers ou (such as company wide policies and gpsi. Then I can do more specific gpos under that if need be. Same for users. Then at each user location, I can apply a specific gpo that maps GPP printers, shortcuts, mapped drives, etc filtered by security group membership.

Under each location you can get more specific with ou, such as desktop, laptop, vm, etc, or you can use WMI filtering to provide filtering also. Whichever works best for you, though wmi is more time consuming.

Company Name OU (I created this OU also, its not the top level domain name)

Users

Location 1
Location 2
Location 3
Location 4

Computers

Location 1
Location 2
Location 3
Location 4

Groups

Location 1
Location 2
Location 3
Location 4

Lunchbocks

nmarlowe wrote: »

I am trying to wrap my head around group policy and OUs by using my organization as a comparison.

From what I'm reading, OUs are meant to organize users, groups and computers to delegate admin control, not to define political and departmental boundaries. So essentially, I could delegate the administration of a particular OU to one of my staff. One of the examples for a single domain - single site was to have an OU each for Users, Groups and Computers.

That is both true and untrue. OUs are for administrative purposes, which includes organizing your security principals and applying group policy to them, not for defining boundaries. However while you are not using OUs to define your departmental boundaries, you might need to organize your OUs departmentally or politically. For instance, if your organizational structure is RBAC, then it would make sense to organize your OU structure by department or role because you are more likely applying your GPOs that way. On the other hand, if your organizational structure is a standard layout, then you are more likely to apply GPOs to users and computers by type rather than by their role or department.

The main thing to remember about OUs is that they are used to define your organization by how you are applying your group policies, that they cannot have security rights and permissions applied to them (that's what groups are for), and that each security principal can be in only one OU, but be in many groups.

Hope this helps. Good luck on your exam.

nmarlowe

Alright, I think this is starting to set in. I get the concepts, just going back and forth in how I am going to set up my particular environment.

Its a single domain, single location install. As of now, there is only a subset of end users that I want to restrict heavily. I work at a regional jail. Our housing officers should have very little access in terms of applications and control on their computers. The less they have to distract them from doing their job (ie monitoring a room full of inmates) the better. They need access to our jail management software, MS Word, our intranet site, and google apps (mail and calendar).

Another big change for them will be to get away from the shared generic logins they've been using since the Win 2000 domain was installed. So, they will all be issued individual logins. Now, I know my users. Most won't bother logging out when they leave their post. My intention is to force the current user to log off at shift change.

For the most part, these will be the only users and computers that get the extensive restrictions. So I am wondering if an OU for every department is all that necessary. Any other policies that I can think will be beneficial can be applied to the whole domain.

Since there are only 3 of us in IT, there is no real need or desire to delegate admin control on groups of users or departments.

But for organization sake, I could see a potential benefit of separating by department.

Anyway, while I still figure out how I am going to apply it, I'd still appreciate seeing how others handle OUs in their company, especially for single domain and location installs.

As a side question along the same lines: Is it common to have groups and OUs that match? Our investigators need access to the same network share and software so it seems there should be an Investigator group as well as an Investigations OU. Does this seem right?