Delegate Permissions for an OU in Active Directory Users and Computers (ADUC) & Create a Custom MMC, or Just Use RSAT

Updated 9/20/2016

Note- this was put together and fast published and there may be errors. Check back for updates when I add RSAT info.

Prologue

Ace here again. Yep, me again. This scenario comes up time to time. Sure, you can use the RSAT tools, but here an old fashioned, truly tried method that works nicely so a delegated OU admin can only see and do what they need to do in their OU.

Scope

After you Delegate Permissions in to a limited admin in Active Directory, such as the ability to reset passwords, you may want to create a custom ADUC MMC (console or custom taskpad) for the delegated admin to control the portion of AD (the OU) they are allowed or delegated in.

For Windows 2003 AD – but it will work in 2008 and newer

The last time I set this up for a customer, involved a snap-in for each ‘location’ OU, I allowed to retain the rt-click context, and the tree view available in the custom console (left pane and right pane), but I removed everything else including the file menu buttons and such. So under View, Customize, uncheck everything except the top one that says Console Tree. This way they can’t go up level or click any of the things in there. But they will have the right-click feature.

You can also choose to remove the left hand pane (tree view).

MMC v2 and v3 are the same:

Start/run/mmc, hit enter
File, Add-Remove Snap-in, Add ADUC
Drill down under the domain to the OU you want.
Right-click on that OU, choose new window from here.
A new window pops up with the OU in the left pane and the contents in the right pane.
Close the original ADUC window leaving the new window open that you’ve just created.
Expand the window to take up the whole console. – This will keep them in this section and they will not be able to go up levels and are ‘stuck’ in this OU.
Select View/Customize
Uncheck everything but Console Tree.
File/Options Choose Console Mode, then select:

User mode: Limited Access single window
Check: Do not Save Changes to this console
Uncheck: Allow the user to customize views
Save it.

Logon as a test user that was delegated permissions and test it.

If you want to eliminate the ability for the delegated admin to right-click on a user account, uncheck the Console Tree above, then change the console view by right-clicking on the OU, choose New Task View, and choose a vertical or horizontal list, then choose to create a new task, menu command, highlight a user account, choose reset password, or anything else in the right column, choose an icon, and finish.

Copy the .MSC file via a UNC connected to the delegated person’s XP workstation’s \Documents and Settings\username\desktop folder, or if Windows Vista or newer, in the C:\users\username\desktop folder.

Keep in mind, the Active Directory Administration Center, RSAT tools or AdminPak tools, depending on what operating system version the client side is, needs to be installed on the workstation for the ADUC binaries to be available for this task pad to work.

For Windows 2003/Windows XP using the AdminPak tools just for the ADUC snap-in, nothing else:

Copy over the following three DLLS from the 2003 or newer DC you are on, to their client’s system32 folder. All three of these are needed on a 2003 DC or newer, or the ADUC won’t open. However, on an XP or newer machine, you only need two. If I were to allow users to change passwords and create a custom MMC for just that OU, then all I need is adprop.dll and dsadmin.dll, otherwise you need all three.

adprop.dll (for object properties)
dsadmin.dll (ability to alter object properties)
dsprop.dll (for object properties related to directory services)

Then you can use PSEXEC (one of the PSTools available free at Microsoft) to remotely register the DLLs listed below on their workstation using the regsrv32.exe utility.
Download PsExec v1.98, by By Mark Russinovich, Published: April 28, 2009
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

psexec \\machinename regsvr32 adprop.dll
psexec \\machinename regsvr32 dsadmin.dll
psexec \\machinename regsvr32 dsprop.dll

Here are some screenshots at the following link:

Create Taskpads for Active Directory Operations:
http://www.petri.co.il/create_taskpads_for_ad_operations.htm

===============================================

For AD on Windows 2008 and newer:

You can use the ADAC & RSAT Tools, or you can use the above method.
Note: ADAC does not have a feature to break down specific tools to create a custom console as shown above.

For the Active Directory Administration Center and the RSAT tools:

For the Related links below for the new AD Admin Center. However, the Admin Center does not have the feature to break down just specific tools to create a custom console as shown above.

Active Directory Administration Center (ADAC):

Active Directory Administrative Center: Getting Started
http://technet.microsoft.com/en-us/library/dd560651(WS.10).aspx

Active Directory Administrative Center — the New AD interface
http://techibee.com/active-directory/active-directory-administrative-center-a-new-ad-interface-for-win7-and-win-2008/290

Learn New Features in Active Directory Administrative Center
http://www.enterprisenetworkingplanet.com/windows/article.php/3887136/Learn-New-Features-in-Active-Directory-Administrative-Center.htm

Remote Server Administration Tools (RSAT) for Windows operating systems (Discusses how to install it for all versions of Windows)
https://support.microsoft.com/en-us/kb/2693643

Remote Server Administration Tools for Windows 10
https://www.microsoft.com/en-us/download/details.aspx?id=45520

Customizing – Installing Remote Server Administration Tools (RSAT) for Windows 7
http://www.petri.co.il/remote-server-administration-tools-for-windows-7.htm

Remotely managing your Server Core using RSAT
http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2008/04/27/remotely-managing-your-server-core-using-rsat.aspx
==================================================================

Summary

I hope this helps!

Last updated – 2/2006, updated 9/20/2016

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services

Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

September 4, 2014September 21, 2016

Delegate Permissions for an OU in Active Directory Users and Computers (ADUC) & Create a Custom MMC, or Just Use RSAT

Updated 9/20/2016

Note- this was put together and fast published and there may be errors. Check back for updates when I add RSAT info.

Prologue

Scope

For Windows 2003 AD – but it will work in 2008 and newer

MMC v2 and v3 are the same:

Start/run/mmc, hit enter
File, Add-Remove Snap-in, Add ADUC
Drill down under the domain to the OU you want.
Right-click on that OU, choose new window from here.
A new window pops up with the OU in the left pane and the contents in the right pane.
Close the original ADUC window leaving the new window open that you’ve just created.
Expand the window to take up the whole console. – This will keep them in this section and they will not be able to go up levels and are ‘stuck’ in this OU.
Select View/Customize
Uncheck everything but Console Tree.
File/Options Choose Console Mode, then select:

User mode: Limited Access single window
Check: Do not Save Changes to this console
Uncheck: Allow the user to customize views
Save it.

Logon as a test user that was delegated permissions and test it.

For Windows 2003/Windows XP using the AdminPak tools just for the ADUC snap-in, nothing else:

adprop.dll (for object properties)
dsadmin.dll (ability to alter object properties)
dsprop.dll (for object properties related to directory services)

psexec \\machinename regsvr32 adprop.dll
psexec \\machinename regsvr32 dsadmin.dll
psexec \\machinename regsvr32 dsprop.dll

Here are some screenshots at the following link:

Create Taskpads for Active Directory Operations:
http://www.petri.co.il/create_taskpads_for_ad_operations.htm

===============================================

For AD on Windows 2008 and newer:

You can use the ADAC & RSAT Tools, or you can use the above method.
Note: ADAC does not have a feature to break down specific tools to create a custom console as shown above.

For the Active Directory Administration Center and the RSAT tools:

For the Related links below for the new AD Admin Center. However, the Admin Center does not have the feature to break down just specific tools to create a custom console as shown above.

Active Directory Administration Center (ADAC):

Active Directory Administrative Center: Getting Started
http://technet.microsoft.com/en-us/library/dd560651(WS.10).aspx

Active Directory Administrative Center — the New AD interface
http://techibee.com/active-directory/active-directory-administrative-center-a-new-ad-interface-for-win7-and-win-2008/290

Learn New Features in Active Directory Administrative Center
http://www.enterprisenetworkingplanet.com/windows/article.php/3887136/Learn-New-Features-in-Active-Directory-Administrative-Center.htm

Remote Server Administration Tools (RSAT) for Windows operating systems (Discusses how to install it for all versions of Windows)
https://support.microsoft.com/en-us/kb/2693643

Remote Server Administration Tools for Windows 10
https://www.microsoft.com/en-us/download/details.aspx?id=45520

Customizing – Installing Remote Server Administration Tools (RSAT) for Windows 7
http://www.petri.co.il/remote-server-administration-tools-for-windows-7.htm

Summary

I hope this helps!

Last updated – 2/2006, updated 9/20/2016

Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

August 25, 2014May 26, 2017

OU Structures and Group Policy Objects (GPOs) Design Considerations and Guidelines

Original posting: 8/25/2014
Revised 5/26/2017

Hey everyone, Ace here, again. This is an accumulation of notes on OU structures. It’s not very well laid out, but I hope it gives you some ideas on how to design an OU structure and to help with applying GPOs.

Default Domain Policy and OU Design

It’s suggested and recommended to not change the Default Domain Policy.
Keep in mind, whatever you set at the domain level will flow downhill to
everything. I would suggest to design your OU structure to reflect your
organization and/or departments, which will also help you create GPOs for
the OU design.

For example, for a company with more than one location/site, I would suggest
the following – and this is just that… a suggestion.

Domain
…..Philly OU
…………..Accounting
…………..Sales
…………..Marketing
…………..Desktop
…………..Users
…………..Groups
…………..Laptops
…..Seattle OU
…………..Accounting
…………..Sales
…………..Marketing
…………..Desktops
…………..Users
…………..Groups
…………..Laptops

In the above example, I separated Laptops and Desktops because I have two different Windows Update GPOs set. The Desktop Windows Update GPO I created runs at 3:00 AM, whereas the Laptop Updates run at 3:30 PM while the users have the laptops in the
office.

I also separated groups just to “group” them together, and for no other reason.

This design also allows me to create GPOs for the different offices,
or I can create one and link them to both offices. The design possibilities
are endless, especially if you control flow with Block Inheritance, Loopback, WMI filtering, disabling the Computer or User portion of a GPO, etc., however in many cases I do not use these features because trying to support them 8 months later when there’s a problem it is difficult to remember what you had blocked, etc.

And yes, you can use RSOP to look at what is being applied, etc., but I find it easier to simply create another OU or a child OU to have a different setting than the parent, such as the following, where I created a GPO to lock the desktop with two different time settings.

The Desktops OU has a 30 minute setting, but I created a 15 Minute Timeout OU directly beneath it. Because the identical setting is different on the child, it overrides the parent’s setting. I can simply “look” at my OUs and know what I have applied.

…..Seattle OU
…………..Accounting
…………..Sales
…………..Marketing
…………..Desktops
………………..15 Minute Timeout OU
…………..Users
…………..Laptops

These are just suggestions, and you may find that it may work for you, or not. Even in a single site, I still do it this way, because it is flexible. You never know when the customer or your company may expand. If they do, simply create another OU for the new location.

GPO Inheritance:

There was one question that came up regarding the above example that I thought
I would share:

So lets say I open AD users and Computers and create a new OU named Philly OU,
then inside this OU I create another six sub-OU such as: Accounting,Sales,Marketing, etc..

My questions is do I need right click on each sub-OU such as Accounting,Sales,Marketing, etc… in the GPO tab to configure the same policy settings or just enough by setting up a GPO policy in the Philly OU parent OU folder to automatically apply to all other sub-OU?

The simple answer is yes, the policy will inherit or flow downhill (traverse), as long as:

• There are no blocks or filtering not allowing it to apply to the target (user or computer).
• No other policy has enforcement override with conflicting settings
• Whether the GPO is targeting user accounts or computer objects, the user and computer objects must have read rights to the following attributes:
– gpLink
– gpOptions

Note: The Read permissions is also important if you were to enable Loopback Processing, as well as List Object Mode on the directory, which is a form of filtering views in the ADUC and GPMC.

Loopback processing explained:

Loopback processing of Group Policy, explained. Sunday, 26 July 2009
http://kudratsapaev.blogspot.co.uk/2009/07/loopback-processing-of-group-policy.html

You can use the Loopback to apply a GPO that depend only on which computer the user logs on to, say for example if the computer object is in a different OU. It’s a feature normally used to lock down a computer that a user is on. It’s normally used with Kiosk mode, such as a self-checkout register at the grocery store, but it can be used for anything you need. More info on this feature:

Circle Back to Loopback – Part 1
By Jonathan Stephens, MSFT
http://blogs.technet.com/b/askds/archive/2013/02/08/circle-back-to-loopback.aspx

Back to the Loopback: Troubleshooting Group Policy loopback processing, Part 2
By Jonathan Stephens, MSFT
http://blogs.technet.com/b/askds/archive/2013/05/21/back-to-the-loopback-troubleshooting-group-policy-loopback-processing-part-2.aspx

Loopback processing of Group Policy
http://support.microsoft.com/kb/231287

Videos that should help understand this better:

Video: Active Directory: Introduction to Group Policy
Compiled From MOC 2279b Planning, Implementing & Maintaining a Microsoft Windows 2003 AD Infrastructure, Module 6, by Ace Fekay
https://www.youtube.com/watch?v=E0qjZhMNQUY

Active Directory: Introduction to Group Policy

Video: Introduction to Active Directory’s Logical Design
Compiled From MOC 2279b Planning, Implementing & Maintaining a Microsoft Windows 2003 AD Infrastructure, Module 1, by Ace Fekay
http://www.youtube.com/watch?v=TLZZ1iHMr2Q

Introduction to Active Directory’s Logical Design

References

Dude, where’s my GPO? Using PowerShell to find all of your Group Policy links.
“… you can easily create a report of all your Group Policy Objects (GPOs) …”
Cool article to list out all your GPOs in one spot with PowerShell. Can be helpful with troubleshooting.
http://blogs.technet.com/b/ashleymcglone/archive/2013/05/29/dude-where-s-my-gpo-using-powershell-to-find-all-of-your-group-policy-links.aspx

A good discussion on GPO Design in the following thread with good info by Christoffer Andersson:
Thread: “Building Organization Hierarchy with Active Directory” 6/2013
http://social.technet.microsoft.com/Forums/windowsserver/en-US/798bf766-a351-4fdb-b8f8-927ad60e1270/building-organisation-hierarchy-with-active-directory

Reviewing OU Design Concepts, Updated: April 11, 2008
Applies To: Windows Server 2008, Windows Server 2008 R2 (These concepts also apply to 2003):
Quoted: “While there is no technical limit to the number of levels in your OU structure, for manageability we recommend that you limit your OU structure to a depth of no more than 10 levels. There is no technical limit to the number of OUs on each level. Note that Active Directory Domain Services (AD DS)–enabled applications might have restrictions on the number of characters used in the distinguished name (that is, the full Lightweight Directory Access Protocol (LDAP) path to the object in the directory) or on the OU depth within the hierarchy.”
http://technet.microsoft.com/en-us/library/cc725715(v=ws.10).aspx

Here’s a basic visual of how GPOs work, and how it would flow downhill.
https://onedrive.live.com/?cid=0C7B9FD0852378B8&id=C7B9FD0852378B8%21237&parId=C7B9FD0852378B8%21234&o=OneUp

Design Considerations for Organizational Unit Structure and Use of Group Policy Objects
http://technet.microsoft.com/en-us/library/cc785903.aspx

TechNet Magazine: Group Policy
http://technet.microsoft.com/en-us/magazine/cc135925.aspx

Group Policy and Advanced Group Policy Management
http://technet.microsoft.com/en-us/windowsserver/grouppolicy/default.aspx

Win2k3 AD OU/GPO Design Discussion
http://www.tomshardware.com/forum/190896-46-win2k3-design-discussion

AD Scalability and GPOs
http://technet.microsoft.com/en-us/library/cc756101.aspx

You receive a “Failed to delete Group Policy Object” error message when you try to delete the default domain policy or the default domain controller policy in Windows Server 2003 and in Windows 2000 Server”
“… the default domain Group Policy object (GPO) and the default domain controller Group Policy object cannot be deleted.”
http://support.microsoft.com/kb/910201

Default Group Policy objects become corrupted: disaster recovery
http://technet.microsoft.com/en-us/library/cc739095(WS.10).aspx

Chapter 4: Strengthening Domain and Domain Controller Policy Settings (applies to all operating systems)
http://technet.microsoft.com/en-us/library/cc773205(v=WS.10).aspx

============================================================

Summary

Published 5/1262017
I hope this helps!

Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

Or just search within my blogs:
https://blogs.msmvps.com/acefekay/

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

February 16, 2012October 20, 2014

Create an Active Directory Fine Grained Password and Lockout Policy Passwords Settings Object (FGP & PSO) Step by Step

Create an Active Directory Fine Grained Password and Lockout Policy Passwords Settings Object (FGP & PSO)

Original publish date 2/16/2012
Revised 10/20/2014

Prelude

Ace here, again! I’ve updated this blog to reflect the fact that it’s much easier to create a PSO in Windows 2012, as well as a little background on PSOs.

Scope

Password policies are normally set in the Default Domain Policy. If they are created anywhere else, they won’t work. It’s just a fact of how AD and GPO account settings work. They are a domain specific settings.

Therefore, I thought I would put this blog together to explain them along with a step by step with lots of screenshots, on how to create a Fine Grained Password & Lockout Policy PSO (Password Settings Object) that you can apply to a group of users that will override the domain level Password and Lockout Settings.

And this is for Windows 2008 R2, which is a bit more tedious to create. If you are searching for how to create a PSO in Windows 2012 or Windows 2012 R2, the following link will help:

How to use Fine-Grained Passwords in Windows Server 2012
http://blogs.technet.com/b/uktechnet/archive/2012/08/28/guest-post-how-to-use-fine-grained-passwords-in-windows-server-2012.aspx

PSO and FGPP Guidelines

You can create one or more PSOs in your domain. Each PSO contains a complete set of password and lockout policy settings. A PSO is applied by linking the PSO to one or more global security groups or users. Actually, by linking a PSO to a user or a re modifying an attribute called msDSPSOApplied, which is empty by default. This approach now treats password and account lockout settings not as domain-wide requirements, but as attributes to a specific user or a group. For example, to configure a strict password policy for administrative accounts, create a global security group, add the service user accounts as members, and link a PSO to the group. Applying fine-grained password policies to a group in this manner is more manageable than applying the policies to each individual user account. If you create a new service account, you simply add it to the group, and the account becomes managed by the PSO.

Precedence:

A PSO can be linked to more than one group or user, an individual group or user can have more than one PSO linked to it, and a user can belong to multiple groups. So, which fine-grained password and lockout policy settings apply to a user? One and only one PSO determines the password and lockout settings for a s precedence.
The precedence value is any number greater than 0, where the number 1 indicates the highest precedence. If multiple PSOs apply to a user, the PSO with the highest precedence takes effect. The rules that determine precedence are as follows:

• If multiple PSOs apply to groups to which the user belongs, the PSO with the highest precedence wins.
• If one or more PSOs are linked directly to the user, PSOs linked to groups are ignored, regardless of
their precedence. The user-linked PSO with the highest precedence wins.
• If one or more PSOs have the same precedence value, Active Directory must choose. It picks the PSO with the lowest globally unique identifier (GUID). GUIDs are like serial numbers for Active Directory objects—no two objects have the same GUID. GUIDs have no particular meaning—they are just identifiers—so picking the PSO with the lowest GUID is, in effect, an arbitrary decision. You should configure PSOs with unique, specific precedence values so that you avoid this scenario.

These rules determine the resultant PSO. Active Directory exposes the resultant PSO in a user object attribute, msDS-ResultantPSO, so you can readily identify the PSO that will affect a user. PSOs contain all password and lockout settings, so there is no inheritance or merging of settings. The resultant PSO is the authoritative PSO.

To view the msDS-ResultantPSO attribute of a user:

1. Ensure that Advanced Features is enabled on the View menu.
2. Open the properties of the user account
3. Click the Attribute Editor tab.
4. Click Filter and ensure that Constructed is selected.
5. Locate the msDS-ResultantPSO attribute.

PSOs, OUs, and Shadow Groups:

PSOs can be linked to global security groups or users. PSOs cannot be linked to organizational units (OUs). If you want to apply password and lockout policies to users in an OU, you must create a global its membership shadows, or mimics, the membership of an OU.

Note: There is no graphical tool in Windows Server 2008 to create shadow groups.
However, you can create and manage them by using a very simple script that will run
periodically. This script should enumerate user objects in the desired OU and put them in a group.