Active Directory Trusts

Let’s discuss AD trusts. And further in, after we discuss trusts types, we’ll revisit Kerberos authentication across a trust path, which I’ve previously discussed in the following blog and is pertinent in the scope of explaining trusts:

Active Directory Trusts

Active Directory domain to domain communications occur through a trust. An AD DS trust is a secured, authentication communication channel between entities, such as AD DS domains, forests, and UNIX realms. Trusts enable you to grant access to resources to users, groups and computers across entities.

The way a trust works is similar to allowing a trusted entity to access your own resources. It’s a two-step process. The first step is to establish the trust. The second step is to provide permissions.

For example, if users in the Contoso.com domain require access to a shared folder in the Trimagna.com domain, and the two domains are not in the same forest, you would establish the trust where Trimagna.com trusts Contoso.com, therefore the direction of the arrow would be Trimagna.com points to Contoso.com.

image

For an analogy, if you were to give your car keys to a friend to allow him or her to use your car, you are establishing a trust between you and your friend. In this case, you are the trusting friend, or domain, and the friend is the trusted friend, or domain. Once the keys have been provided, then the next step is to allow access to your resource, or car, by providing permissions to use the car. However, this trust is only in one direction, you trust your friend. If you want your friend to trust you, your friend, or the other domain, must be initiated by your friend, or the other domain.

AD DS Trust Types

There are various trust types. The trust that you create must be appropriate for the design. Trusts can be transitive or non-transitive. The one that you choose to create depends on the scenario and requirements. Other trusts types can be created as required, depending on the scenario. The table below shows the various trust types you can create.

Trusts can be created using the New Trust Wizard found in the Active Directory Domains and Trusts console, or using the Netdom command line utility. If you choose to create one of the one-way trust types in both directions, it can be created simultaneously, or separately. If you create it separately, you must re-run the procedure to establish the trust in the other direction.

image

Trust Type

Characteristics

Direction

Authentication
Mechanism

Notes

Parent-Child

Transitive

Two-way

Kerberos V5
or NTLM

Created automatically when a child domain is added.

Tree-Root

Transitive

Two-way

Kerberos V5
or NTLM

Created automatically when a new Tree is added to a forest.

Shortcut

Transitive

One-way
or
Two-way

Kerberos V5
or NTLM

Created Manually.
Used in an AD DS forest to shorten the trust path to improve authentication times.

Forest

Transitive

One-way
or
Two-way

Kerberos V5
or NTLM

Created Manually.
Used to share resources between AD DS forests.

External

Non-transitive

One-way

NTLM Only

Created Manually.
Used to access resources in an NT 4.0 domain or a domain in another forest that does not have a forest trust established.

Realm

Transitive or non-transitive

One-way
or
Two-way

Kerberos V5 Only

Created Manually.
Used to access resources between a non-Windows Kerberos V5 realm and an AD DS domain.

Trust Flow: Transitive vs. Non-Transitive

Trust communication flow is determined by the direction of the trust. The trust can be a one-way or a two-way trust. And the transitivity determines whether a trust can be extended beyond the two domains with which it was formed. A transitive trust can be used to extend trust relationships with other domains; a non-transitive trust can be used to deny trust relationships with other domains. Authentication requests follow a trust path. The transitivity of the trust will affect the trust path.

Transitive Trust

· Contoso.com trusts Trimagna.com.

· Contoso.com trusts Adatum.com.

· Therefore, Trimagna.com trusts Adatum.com.

One-way Trust

· Domain A trusts Domain B, but Domain B does not trust Domain A.

· Domain A trusts Domain C, but Domain C does not trust Domain A.

· Therefore, Domain B does not trust Domain C.

o For these two domains to trust each other, you would need a one way trust created between each other.

Automatic Trusts: and Tree-Root Trusts

By default, two-way, transitive trusts are created automatically when a child domain is added or when a domain tree is added. The two default trust types are parent-child trusts and tree-root trusts.

Parent-Child Trust

A transitive, two-way parent-child trust relationship automatically created and establishes a relationship between a parent domain and a child domain whenever a new child domain is created using the AD DS installation process process within a domain tree. They can only exist between two domains in the same tree with the same contiguous namespace. The parent domain is always trusted by the child domain. You cannot manually create a Parent-Child trust.

image

Tree-Root Trust

A transitive, two-way tree-root trust relationship automatically created and establishes a relationship between the forest root domain and a new tree, when you run the AD DS installation process to add a new tree to the forest. A tree-root trust can only be established between the roots of two trees in the same forest and are always transitive. You cannot manually create a tree-root trust.

image

Shortcut Trust

Shortcut trusts are manually created, one-way, transitive trusts. They can only exist within a forest. They are created to optimize the authentication process shortening the trust path. The trust path is the series of domain trust relationships that the authentication process must traverse between two domains in a forest that are not directly trusted by each other. Shortcut trusts shorten the trust path.

image

Forest Trust

Forest trusts are manually created, one-way transitive, or two-way transitive trusts that allow you to provide access to resources between multiple forests. Forest trusts uses both Kerberos v5 and NTLM authentication across forests where users can use their Universal Principal Name (UPN) or their Pre-Windows 2000 method (domainName\username). Kerberos v5 is attempted first, and if that fails, it will then try NTLM.

image

Forest trusts require DNS resolution to be established between forests, however to support NTLM failback, you must also provide NetBIOS name resolution support between the forests.

Forest trusts also provide SID filtering enforcement in Windows Server 2003 and newer. This ensures that any misuse of the SID history attribute on security principals (including the inetOrgPerson attribute) in the trusted forest cannot pose a threat to the integrity of the trusting forest.

Forest trusts cannot be extended to other forests, such as if Forest 1 trusts Forest 2, and another forest trust is created between Forest 2 and Forest 3, Forest 1 does not have an implied trust. If a trust is required, one must be manually created.

External Trust

An external trust is a one-way, non-transitive trust that is manually created to establish a trust relationship between AD DS domains that are in different forests, or between an AD DS domain and Windows NT 4.0 domain. External trusts allow you to provide users access to resources in a domain outside of the forest that is not already trusted by a Forest trust.

image

SID filter quarantining is enabled by default with Windows Server 2003 and newer AD DS domains. SID filtering verifies that incoming authentication requests made from security principals in the trusted domain contain only SIDs of security principals from the trusted domain.

External trusts are NTLM based, meaning users must authenticate using the Pre-Windows 2000 logon method (domain\username).NTLM requires NetBIOS name resolution support for functionality.

Additional reading on creating External Trusts and DNS Support:

Realm Trust

A Realm trust can be established to provide resource access and cross-platform inter-operability between an AD DS domain and non-Windows Kerberos v5 Realm.

  • A Realm trust only uses Kerberos V5 authentication. NTLM is not used.
  • When the direction of the trust is from a non-Windows Kerberos Realm to an AD DS domain (Realm trusts AD DS domain), the non-Windows realm trusts all security principals in the AD DS domain.
  • Realm trusts are one-way by default, but you can create a trust in the other direction to allow two-way access.
  • Because non-Windows Kerberos tickets do not contain all the information AD DS requires, the AD DS domain only uses the account to which the proxy account (the non-Windows principal) is mapped to evaluate access requests and authorization. With Realm trusts, all AD DS domain proxy accounts can be used in an AD DS group in ACLs to control access for non-Windows accounts.

image

Additional reading:

Trusted Domain Object (TDO)

To understand cross domain authentication, we must first understand Trusted Domain Objects (TDOs). Each domain within a forest is represented by a TDO that is stored in the System container within its domain. The information in the TDO varies depending on whether the TDO was created by a domain trust or by a forest trust.

When a domain trust is created, attributes such as the DNS domain name, domain SID, trust type, trust transitivity, and the reciprocal domain name are represented in the TDO.

When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and then stores the information in a TDO. The trusted namespaces and attributes that are stored in the TDO include domain tree names, child domain names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest. TDO objects are stored in each domain, then replicated to the global catalog.

Therefore, because trusts are stored in Active Directory in the global catalog as TDOs, all domains in a forest have knowledge of the trust relationships that are in place throughout the forest. If there are two or more forests that are joined together through forest trusts, the forest root domains in each forest know of the trust relationships throughout all of the domains in the trusted forests.

The only exception to the rule is External trusts to a Windows NT 4.0 domain do not create TDOs in Active Directory because it is NTLM based, in which SPN and domain SIDs do not exist, therefore do not apply.

Additional reading:

Trust Path between Domains

The trust path is the series of domain trust relationships that the authentication process must traverse between two domains in a forest that are not directly trusted by each other.

Before authentication for a user, computer or service can occur across trusts, Windows must determine if the domain being requested has a trust relationship with the requesting account’s logon domain. This is determined by quering the global catalog for TDO data. The Windows security system’s Netlgon service through an authenticated RPC (Remote Procedure Call) to the remote domain’s trusted domain authority, (the remote domain controller), computes a trust path between the domain controller for the server that receives the request and a domain controller in the domain of the requesting account.

The Windows security system extends a secured channel to other Active Directory domains through interdomain trust relationships. This secured channel is used to obtain and verify security information, including security identifiers (SIDs) for users and groups. The trust path is stored for authentication requests to the trusted domain.

Kerberos authentication Sequence between Domains in a Forest

image

A user in the marketing.trimagna.com domains needs to gain access to a file share on a server called fileserver.sales.contoso.com domain. This is assuming the User has already logged on to a workstation using credentials from the marketing.trimagna.com domain. As part of the logon process, the authenticating domain controller issues the User a ticket-granting ticket (TGT). This ticket is required for User1 to be authenticated to resources.

The User attempts to access a shared resource on \\FileServer.sales.contoso.com\share.

The following Kerberos V5 authentication process occurs:

1. The User’s workstation asks for a session ticket for the FileServer server in sales.contoso.com by contacting the Kerberos Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer.sales.contoso.com service principal name (SPN).

2. The KDC in the user’s domain (marketing.trimagna.com) does not find the SPN for FileServer.sales.contoso.com in its domain database and queries the GC to see if any domains in the forest contain this SPN.

a. The GC checks its database about all forest trusts that exist in its forest. If a trust to the target domain is found, it compares the name suffixes listed in the forest trust trusted domain objects (TDOs) to the suffix of the target SPN to find a match.

b. Once a match is found, the global catalog sends the requested information as a referral back to the KDC in marketing.trimagna.com.

3. The KDC in the marketing.trimagna.com then issues the workstation a TGT for the contoso.com domain. This is known as a referral ticket.

4. The workstation then contacts the KDC in the trimagna.com tree root domain to request a referral to the KDC in the sales.contoso.com.

5. The KDC in the trimagna.com domain recognizes the user’s request to establish a session with a resource that exists in a foreign domain’s server.

a. The KDC then issues a TGT for the KDC in the contoso.com domain.

6. The workstation then presents the TGT for the sales.contoso.com domain to the KDC in the contoso.com domain.

7. The contoso.com KDC queries a GC to see if any domains in the forest contain this SPN. The GC checks its database about all forest trusts that exist in its forest. If a trust to the target domain is found, it compares the name suffixes listed in the forest trust trusted domain objects (TDOs) to the suffix of the target SPN to find a match.

a. Once a match is found, the global catalog sends the requested information as a referral back to the KDC in contoso.com.

8. The KDC issues a TGT for the sales.contoso.com domain.

9. The workstation then contacts the KDC of the sales.contoso.com domain and presents the referral ticket it received from its own KDC.

a. The referral ticket is encrypted with the interdomain key that is decrypted by the foreign domain’s TGS.

b. Note: When there is a trust established between two domains, an interdomain key based on the trust password becomes available for authenticating KDC functions, therefore it’s used to encrypt and decrypt tickets.

10. The workstation also presents the KDC in the sales.contoso.com the TGT it received from the KDC in contoso.com for the sales.contoso.com domain and is issued a ST (Session Ticket) for the sales.contoso.com domain.

a. The ST is populated with the domain local group memberships from the sales.contoso.com domain.

11. The user presents FileServer.sales.contoso.com the ST to the server to gain access to resources on the server in sales.contoso.com.

12. The server, FileServer.sales.contoso.com compares the SIDs include in the session ticket to the ACEs on the requested resource to determine if the user is authorized to access the resource. If there is, the user is permitted to access the resource based on the ACL permissions.

Kerberos Authentication with a Shortcut Trust

If a shortcut trust exists from the sales.contoso.com domain to the marketing.trimagna.com domain, then the trust path will shortened, therefore the user authentication path will be direct between the two domains.

image

Additional Reading

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

 

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

clip_image0023 clip_image0043 clip_image0063 clip_image0083 clip_image0103 clip_image0123 clip_image0143 clip_image0163

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.

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

clip_image002[3] clip_image004[3] clip_image006[3] clip_image008[3] clip_image010[3] clip_image012[3] clip_image014[3] clip_image016[3]

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.

Kerberos Authentication Sequence Across Trusts

 

Intro

Hey everyone, Ace again. This is a quick publish on how Kerb authentication works across a trust.

Here’s how it works (no shortcut trusts)

AD Trusts - Kerberos Authentication Sequence across a trust (from the PPT slide)

A user in the marketing.trimagna.com domains needs to gain access to a file share on a server called fileserver.sales.contoso.com domain. This is assuming the User has already logged on to a workstation using credentials from the marketing.trimagna.com domain. As part of the logon process, the authenticating domain controller issues the User a ticket-granting ticket (TGT). This ticket is required for User1 to be authenticated to resources.

The User attempts to access a shared resource on \\FileServer.sales.contoso.com\share.

The following Kerberos V5 authentication process occurs:

1. The User’s workstation asks for a session ticket for the FileServer server in sales.contoso.com by contacting the Kerberos Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer.sales.contoso.com service principal name (SPN).

2. The KDC in the user’s domain (marketing.trimagna.com) does not find the SPN for FileServer.sales.contoso.com in its domain database and queries the GC to see if any domains in the forest contain this SPN.

a. The GC checks its database about all forest trusts that exist in its forest. If a trust to the target domain is found, it compares the name suffixes listed in the forest trust trusted domain objects (TDOs) to the suffix of the target SPN to find a match.

b. Once a match is found, the global catalog sends the requested information as a referral back to the KDC in marketing.trimagna.com.

3. The KDC in the marketing.trimagna.com then issues the workstation a TGT for the contoso.com domain. This is known as a referral ticket.

4. The workstation then contacts the KDC in the trimagna.com tree root domain to request a referral to the KDC in the sales.contoso.com.

5. The KDC in the trimagna.com domain recognizes the user’s request to establish a session with a resource that exists in a foreign domain’s server.

a. The KDC then issues a TGT for the KDC in the contoso.com domain.

6. The workstation then presents the TGT for the sales.contoso.com domain to the KDC in the contoso.com domain.

7. The contoso.com KDC queries a GC to see if any domains in the forest contain this SPN. The GC checks its database about all forest trusts that exist in its forest. If a trust to the target domain is found, it compares the name suffixes listed in the forest trust trusted domain objects (TDOs) to the suffix of the target SPN to find a match.

a. Once a match is found, the global catalog sends the requested information as a referral back to the KDC in contoso.com.

8. The KDC issues a TGT for the sales.contoso.com domain.

9. The workstation then contacts the KDC of the sales.contoso.com domain and presents the referral ticket it received from its own KDC.

a. The referral ticket is encrypted with the interdomain key that is decrypted by the foreign domain’s TGS.

b. Note: When there is a trust established between two domains, an interdomain key based on the trust password becomes available for authenticating KDC functions, therefore it’s used to encrypt and decrypt tickets.

10. The workstation also presents the KDC in the sales.contoso.com the TGT it received from the KDC in contoso.com for the sales.contoso.com domain and is issued a ST (Session Ticket) for the sales.contoso.com domain.

a. The ST is populated with the domain local group memberships from the sales.contoso.com domain.

11. The user presents FileServer.sales.contoso.com the ST to the server to gain access to resources on the server in sales.contoso.com.

12. The server, FileServer.sales.contoso.com compares the SIDs include in the session ticket to the ACEs on the requested resource to determine if the user is authorized to access the resource. If there is, the user is permitted to access the resource based on the ACL permissions.

Shortcut Trust

If a shortcut trust exists from the sales.contoso.com domain to the marketing.trimagna.com domain, then the trust path will shortened, therefore the user authentication path will be direct between the two domains.

image

Additional Reading
Kerberos Explained
http://technet.microsoft.com/en-us/library/bb742516.aspx

Accessing resources across domains [and trusts]
http://technet.microsoft.com/en-us/library/cc787646(v=ws.10).aspx

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

Summary

I hope this helps!

Published 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

clip_image00262 clip_image00462 clip_image00662 clip_image00862 clip_image01062 clip_image01262 clip_image01462

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.

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

clip_image002 clip_image004 clip_image006 clip_image008 clip_image010 clip_image012 clip_image014 clip_image016

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.