daknetworks.com

In my mind, it's very simple. You have USERS and you have GROUPS (anything that is more than 1 user). If I need to do something, I should create a rule and apply it to the group.

In Microsoft Server 2012, it doesn't exactly work that way. It, in true fashion, has to be as difficult as humanly possible.

To look at the default structure:

• -click SERVER-MANAGER (I'm pretty sure they ripped this name off another project).
• -click TOOLS > ACTIVE DIRECTORY USERS & COMPUTERS.
• -a DOMAIN TREE shows.
• (It has USERS, COMPUTERS but it doesn't have GROUPS. GROUPS are erroneously mixed in with USERS)

To add a GROUP.

• -click USERS.
• -right-click USERS.
• -click NEW > GROUP
• -type in the GROUP-NAME.

To add USERS to GROUP.

• -double-click GROUP NAME.
• -click MEMBERS tab (at the top).
• -click ADD.
• -type in the NAMES you want to add.

Since I'm a big fan of GROUPS, I want to apply a login script just for a certain GROUP.

To look at the default Group Policy structure:

• -click SERVER-MANAGER (I'm pretty sure they ripped this name off another project).
• -click TOOLS > GROUP POLICY MANAGEMENT.
• -a GROUP-POLICY DOMAIN TREE shows.
• (It has "GROUP POLICY OBJECTS". All your GPO's are here.)

Active Directory Hierarchy And The Way You See It Taught

Now what's interesting is that this doesn't match the USERS & COMPUTERS. There is no GROUPS section. Why? Because this is based off of LDAP. Why is that important? Because LDAP is hierarchical (and not relational). This means that one-child can only have one-parent. (But one parent can have many children. [Don't ask.]). So instead of GROUPS, they use ORGANIZATIONAL-UNITS. This hierarchical structure means that a USER cannot be a member of 2 different GROUPS in an ACTIVE DIRECTORY ORGANIZATIONAL UNIT (or AD and OU). The end result is that a USER-object can only be place in one OU.

This is why there are so many articles and videos about structuring your AD and OU's correctly. Because it doesn't make sense to rational thinking and someone has to explain it in details just to get it working. And even then, they have trouble getting it working smoothly. Most of the advice demonstrate that you should create OU's and then to put both the computer-objects and the user-objects inside of that OU. The GROUP-POLICY is then applied to the OU and consequently it will be applied to the USER and/or COMPUTER.

Of course it will. The GP is attaching to the individual USER or COMPUTER.

Active Directory And The Way It Should Be Enterprise

In short, this may work well for the ENTERPRISE (company more than 300 users). Traditionally you should create OU's along geographic boundaries and then to put both the computer-objects and the user-objects inside of that OU. It would look something like this:

OU-Kansas-City
----first-floor
--------computers
--------users
----basement
--------computers
--------users
OU-Chicago
----first-floor
--------computers
--------users
----basement
--------computers
--------users

The GROUP-POLICY is then applied to an OU and consequently it will be applied to the USER and/or COMPUTER.

Active Directory And The Way It Should Be Small Business

But what about everyone else? It doesn't work well for the small to medium enterprise (as defined by MS: a company less than 300 users). For this segment, it's faulty thinking. I don't have a bunch of offices across the globe. I don't have multiple floors, levels and locations. If I follow the common advice, I no longer have a section called USERS that contains all my users. And I don't have a section called GROUPS that contains all my groups.

My mind doesn't work the way of the enterprise. I group people all the time and they can be in many groups at the same time. I can group my friend Jason as being the WORK GROUP, FRIEND GROUP and CHURCH GROUP. But again, you can't do this in AD.

What is nice about AD is that it is highly customizable. Consequently, you will see many (and I stress many) different ways to do this in articles, videos and in practice. Also due to this customization, I can create the way I want it, I just have to create it myself rather than this feature coming ready out-of-the-box.

All of that set aside, ultimately at the root-level of AD I want to have an OU called GROUPS. Under that GROUPS-OU, I locate all my SECURITY-GROUPS objects (out of the USERS and into the GROUPS). These are common units like ACCOUNTING, PRODUCTION, HR, IT, MANAGEMENT, MARKETING, OPERATIONS, SALES, etc. Each SECURITY-GROUP has the members that are needed.

The result looks similar to:

DOMAIN
    BUILTIN
    COMPUTERS
    GROUPS
        ACCOUNTING
        BUILTIN
        HR
        IT
        MANAGEMENT
        MARKETING
        OPERATIONS
        SALES
    USERS

This makes it easy on myself. Just keep it simple and create those SECURITY-GROUPS in the new GROUPS-OU, leave the computers in the COMPUTERS-OU and the users in the USERS-OU.

For clarity, if you click on USERS, there are only USER-OBJECTS in there. There are no GROUP-OBJECTS in there. All of the GROUPS have all been moved to the appropriate place in the GROUPS-OU.

GROUP POLICY That Applies To Groups

Now the problem becomes the GROUP-POLICY.

Counter-intuitively, GROUP-POLICY-OBJECTS (GPO's) cannot be applied to GROUP-OBJECTS. GPO's can only be applied to USER-OBJECTS and COMPUTER-OBJECTS. Remember from above where many tutorials, classes, videos and articles say to put the objects in the OU? This is why they teach you to do it this way. If they don't put the OBJECTS in the OU, the GP doesn't work.

So how do I apply a GPO to a SECURITY-GROUP?

By creating a GPO on domain-level (not the OU level), editing the GPO and assigning the GPO to the GROUP through SECURITY-FILTERING.

To create a new GPO:

• -click SERVER-MANAGER (I'm pretty sure they ripped this name off another project).
• -click TOOLS > GROUP POLICY MANAGEMENT.
• -a GROUP-POLICY DOMAIN TREE shows.
• -right-click the domain-name (ie contoso.com).
• -click CREATE-A-GPO-IN-THIS-DOMAIN,-AND-LINK-IT-HERE [sic].
• -type in a NEW-NAME.
• -click OK

Edit the GPO:

• -right-click the GPO.
• -click EDIT.
• -make all your changes in here. Don't worry about anything else at this point.

Assign GPO to the GROUP:

• -click the GPO.
• -you should be on the SCOPE tab (at the top).
• -click ADD (at the bottom).
• -type in the name of the GROUP.
• -click OK.
• -click DELEGATION tab (at the top).
• -click ADVANCED button (at the bottom right).
• (a new windows pops up).
• -click AUTHENTICATED USERS (at the top section).
• -find APPLY GROUP POLICY (at the bottom section).
• -uncheck the ALLOW.
• -find READ (at the bottom section).
• -checkmark ALLOW (this should already be done but just to verify).
• (This is not a typo. This allows all users to READ the GPO but doesn't assign it to them.)

Run The GPO On The Client Computer

• -click START > RUN
• -type: CMD
• -type: gpupdate /force
• -type: gpresult /h new-report.html (or if you are savy, type: gpresult /R) (or if you want to punish yourself, type: gpresult /Z).
• -open new-report.html to view results

SUMMARY

In summary, there are USERS-&-GROUPS section in AD and there are OU's in GPO. They don't match. So we create our own GROUP-STRUCTURE in AD, create a GPO, link it to an OU and only give the AD GROUP access to the to the GPO through SECURITY-FILTERING.

NOTES:

-A good source of information is here: http://www.grouppolicy.biz
-And there are good videos on YouTube here:https://www.youtube.com/user/itfreetraining
-EVERYONE group does not include EVERYONE.
-AUTHENTICATED-USERS also includes DOMAIN-COMPUTERS. This is why it should not be entirely-removed from the GPO.
-On 06/22/16 a MS update breaks many GPO's but not the method above. Read the rest of the story here:
https://blogs.technet.microsoft.com/askds/2016/06/22/deploying-group-policy-security-update-ms16-072-kb3163622/