Joining a computer to a domain over a client VPN connection

Joining a computer to a domain over a client VPN connection


Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP: Directory Services


 


From time to time, this has come up occassionally for my customers to configure new laptops. Normally, I would visit the office to setup a new laptop, but in some cases, such as with one of my customers with 90% of their users are on the road in various parts of the country, they’ll either have the new laptop shipped to me, or they will ship it to me once they’ve received it, or someone local will drop it off to my office. I’ll configure the laptop, then either ship it back, drop it off at the main office, or someone will stop by to pick it up.


Let me know if any of these steps are not clear or if something else needs to be added that I may have missed, and I’ll do my best to integrate or clean it up.


 
1. First, I must state as a rule of thumb, that all of your internal domain controllers, member servers, and clients are set to only use the internal DNS servers, more than likely your domain controllers. This means do not your ISP’s DNS servers, or use your router/firewall as a DNS address. It simply won’t work. You can configure your ISP’s DNS as a Forwarder.


The reason I’m stating this right off the bat, is if using your ISP’s DNS configured on any internal machine’s NIC DNS settings, is inviting trouble. This is a very common misconfiguration due to an admin not understanding AD and its DNS reliance. I always mention this to prevent AD issues. If not sure what I am referring to, please read the following:


Active Directory’s Reliance on DNS, and why you should never use an ISP’s DNS address or your router as a DNS address, or any other DNS server that does not host the AD zone name
http://msmvps.com/blogs/acefekay/archive/2009/08/17/ad-and-its-reliance-on-dns.aspx


2. Therfore, make sure DHCP Option 006, the DNS addresses being given out to DHCP clients, is only set to use the company’s internal DNS servers, and no others. This includes, as previously mentioned, to NOT use the router as a DNS address. If not sure what I’m referring to, please read the link above.



3. For NetBIOS name resultion, you may need to consider using WINS to allow seamless NetBIOS name resolution. Please read the following for more information on how to configure WINS. But you MUST configure a DHCP Relay agent on the VPN server (the RRAS or NAS server), or the DHCP options will not be provided to the VPN clients.


WINS – What Is It, How To Install It, and how to Configure DHCP Scopes For WINS Client DHCP Distribution 
http://msmvps.com/blogs/acefekay/archive/2010/10/27/wins-what-is-it-how-to-install-it-and-how-to-configure-dhcp-scopes-for-wins-client-distribution.aspx


4. Configure a DHCP Relay Agent to insure DHCP Options are provided to VPN clients, otherwise they will get the VPN server’s WINS and DNS addresses, and they will not get any other options, such as Option 015, the Connection Specific Search Suffix. 


Understanding DHCP IP Address Assignment for RAS Clients
http://support.microsoft.com/kb/160699/EN-US


IP Address Assignment
http://technet.microsoft.com/en-us/library/dd469712(WS.10).aspx


Thread Discussion: DNS DHCP option 006 not being applied to VPN clients via RRAS
This is a good discusion with specifics about how an IP config is passed to a RRAS client and DHCP relay agents
http://www.petri.co.il/forums/showthread.php?t=35748


Configuring the DHCP Relay Agent to Support VPN Client TCP/IP Addressing Options
http://www.isaserver.org/img/upl/vpnkitbeta2/dhcprelay.htm


RRAS (VPN) DHCP options
http://msmvps.com/blogs/robwill/archive/2008/05/09/rras-dhcp-options.aspx



5. Keep in mind, there is a chicken and the egg thing going on here with initially joining a machine over a VPN and logging on, and allowing the new domain account profile to initialize.


Therefore, the one main thing, of course, is the client VPN connection must be established prior to adding it to the domain. This is a bit tricky at times, and for Windows XP and prior operating systems, the VPN client must be configured to come up and be available to connect to the VPN prior to logging into the machine at the remote location, or at initial restart in order to log into the
domain for the first time, or you may have some trouble because there may not be a local profile created yet for the domain account. Many third party VPN clients work hand n hand with Windows GINA (the logon box) to offer a dialup or VPN connection capability. Connect first, then logon.


With Windows Vista or Windows 7, and you’re using the Windows VPN, you can establish a VPN connection using the domain administrator account, join it to the domain, then without loggin off, select to “Switch User” while it’s still connected to the VPN, then logon with the domain user account that will be using this laptop. 


6. Once you’ve joined the machine to the domain and restarted, connect to the VPN, then logon with the domain admin account. Make sure you can connect to resources, etc. Then logoff. If the VPN cuts off during logoff, either reconnect to the VPN or configure the VPN client to stay active when logging off. This depends on the client if this is possible. Then logon as the domain user account, making sure they can access all resources as if they were in the office.


7. If name resolution does not work, to troubleshoot it depends on how you are connecting. If connecting using \\servername\share, then you are expecting NetBIOS name resolution to  work, which means WINS. Run an ipconfig /all on the VPN client PPP (VPN) connection to make sure it shows the WINS address. If it doesn’t, go back to step 5 and see what you did wrong with DHCP. Also, check your DHCP settings and DHCP Relay Agent settings.


If connecting using \\servername.internalDomain.local\share, then you are using DNS.


Once again, run an ipconfig /all to make sure the client is getting the company’s DNS setting on the PPP (VPN) connection.  If not, check your DHCP settings adn DHCP Relay Agent settings.


8. Also, this is important – you want to configure the VPN connection to use the local gateway (the remote machine’s ISP gateway) and not the remote gateway (the company’s internet  connection).


This way any non-company connections (say you are on  IE connecting to your Yahoo or MSN email) does not send all that traffic through the tunnel and the company’s Internet conenction. In Windows client, Network Tab, IPv4 settings, you can simply uncheck the box that says use remote gateway. For Cisco, it’s a setting on the PIX or ASA side to use split-tunneling. I don’t know if this is supported with other vendors’ VPN solutions, but I can’t imagine they don’t have an option for this.


9. After completion, and the user account is logged on, you can easily setup the user’s Outlook profile, assuming you are using Outlook Anywhere or RPC/HTTPS.


Don’t forget to provide them a copy of their NK2 file, or if Outlook 2010 or newer using Exchagne 2010, this should come across automatically with the Autocomplete.xml file from the Exchange 2010 mailbox.


Oh, and you might want to setup their signature from a previously sent email, and if you have a copy of their Favorites and Link Bar, provide that, too.


If not using Folder Redirection, I would highly recommend it. THis way their My Docs show up automatically. More info in the following links, if interested in learning more on this cool feature:


Folder Redirection
Published by Ace Fekay, MCT, MVP DS on Sep 8, 2009 at 12:16 PM  3640  2
http://msmvps.com/blogs/acefekay/archive/2009/09/08/folder-redirection.aspx


Best Practice: Roaming Profiles and Folder Redirection (a.k.a. User State Virtualization)
Excellent write up on Folder Redirection by Alan Burchill, Microsoft, including screenshots, permissions settings, and much much more.
08/18/2010, 7:00 pm | by Alan Burchill
http://www.grouppolicy.biz/2010/08/best-practice-roaming-profiles-and-folder-redirection-a-k-a-user-virtualization/


 


Comments, suggestions and corrections are welcomed.


Ace Fekay

Using Group Nesting Strategy – AD Best Practices for Group Strategy

Using Group Nesting Strategy – AD Best Practices for Group Strategy


Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP: Directory Services


Published 1/6/2012


Preface:


I put this blog together hoping I can provide insight on how Active Directory groups were meant to be used to provide access to resources based on how Microsoft’s engineers originally designed them to be used.


The method presented here is similar to how I would teach and describe it in a classroom. Of course when I’m teaching, I’m a bit more animated in front of the class with a 12′ wide whiteboard, where I take its large size to the full advantage. I’ll keep it toned down in this blog to shorten your reading time, provide some graphics, and get right to the point.


Some of the graphics in this blog are actual courseware slides which were modified from the Microsoft Official Curriculum MOC 6425C and MOC 6425B courseware, “Configuring and Troubleshooting Windows Server 2008 Active Directory Domain Services.” You can find additional information on this 5-Day, Instructor-Led course in the following link:


MOC 6425C Configuring and Troubleshooting Windows Server 2008 Active Directory Domain Services -
5 Day, Instructor-led, classroom or online.
http://www.microsoft.com/learning/en/us/Course.aspx?ID=6425C&Locale=en-us


There is also 20 hour, a self-paced online version of this course also available. Information on this version can be found in the link below. At the time of this writing, 12/31/2011, the cost is USD $319.00:
https://www.microsoftelearning.com/eLearning/offerDetail.aspx?offerPriceId=222031


The instructor led course costs much more. For pricing, please contact a Microsoft CPLS center (Certified Partner for Learning Solutions).


The terminology used in this blog includes resource access design practice terminology called IGDLA, or short for “Identities, Global groups, Domain local groups, and Access.”


However, the previous terminology was AGDLP, or short for “Add Accounts to Global Groups, then to Domain Local Groups, then apply Permissions to the Domain Local Group.”


By any other name, at the end of the day, the user gets the permissions applied to the Domain Local Group on the resource. IGDLA provides more of a general scope of application, then just defining specfically how AD groups work. IDGLA aligns with current industry standard practice terminology, which was the driving factor to change it.


 


Understanding what Groups are and what they are used for



Before implementing groups in your environment, it’s beneficial to understand how groups are used and which types of groups exist. It’s also important to understand group scope to help identify proper group type and usage in various scenarios. In addition, it’s important to define a group naming convention to easier “see” what the group type and intentions are just by looking at the name of the group, as well as to understand the group nesting feature and the benefits of using this approach.


Using groups makes it more efficient for the operating system to enumerate permissions on an ACL. Imagine if you have 300 user accounts on an ACL. The system must enumerate each and every user account, or rather the user account’s SID numbers, in the ACL. This will be preceived as a performance lag. Not only a performance hit, it’s difficult to keep track of.


When you use Groups, you add the group name to the resource. You also add the user account to the Group in Active Directory. So what happens is when the user logs on, the session ticket that gets assembled will have the user account SID in it, along with the Group SID. Therefore, when you access the resource, the system simply matches the user’s session ticket’s SID entries to the SID entries on the resource ACL. Much simple, easier to manage, and extremely efficient.


Keep in mind, some of the features may or may not exist in your Active Directory infrastructure, depending on what OS version your domain controllers are, or in a mixed NT4 environment. What is the oldest domain controller that still exists in the domain and/or forest, is also a factor. Such features as group nesting, may not exist if the AD domain and/or forest functional levels haven’t been updated to the latest levels. Using groups will also help to reduce the overall administrative overhead of handling user access, instead of simply adding a user account to a resource. What happens when that user leaves the company? Some institutions will keep the account but disable it. Other insitutions will delete the account. So what happens if you delete a user account that is still specified in an ACL? The user account in the ACL of a resource will remain but only as a SID number, and not the user account name, because it was deleted. This can become confusing to figure out who the account was, but at that point, it doesn’t matter because you know it was an account that was deleted. In that case, the only thing you can do is delete the SID entry in the ACL. Unless you were to reanimate the account whether performing an authoritative restore, using ADRestore.Net, or restoring an account from the AD Recycle Bin with Windows 2008 R2 or newer, but that is a different topic beyond the scope of this blog.


And what happens if you just use user accounts instead of groups? You might say I only have 20 users, so I’ll just do it by user account. Then after awhile, the company grows, more users are hired, you keep adding them to resources based on their user accounts, but one day you look at it and say, wow, we have over 200 users now, and we are having problems keeping track of who has access to what. If only I had started using groups in the beginning, and simply added or removed users from the groups as their roles or positions in the company changed, I would have had a better handle oh this mess, and it would be one less thing on my plate that I have to deal with now.




Role Groups


We can create role based groups to help day to day administration. Role groups such as based on their functions:


  • Sales
  • Marketing
  • Accountants
  • Managers
  • Accounting Managers
  • Sales Managers
  • etc



Group Naming Convention


Naming convention is important. I usually like to name my groups based on the group type, role and access. For example, I’ll create a Global Group (GG) for the accountants that just need Read access:
G_Accountants_Read


And for the accountants that need Full Control:
G_Accountants_FC


Of course, we usually don’t like to provide Full Control because besides Full Control allowing to change anything, it also allows the ability to change permissions as well as Take Ownership of a resource. In many cases, the “Modify” NTFS permission will work fine, and the users will not know the difference, as long as they see they can create, change, and delete items.


In summary, create Role based groups and properly name them to help easily identify and administer them.




Group Scope


There are four group scopes:


  • Local
  • Global
  • Domain Local
  • Universal


The characteristics that define each scope fall into these categories:


  • Replication. Where is the group defined, and to what systems is the group replicated?
  • Membership. What types of security principals can the group contain as members? Can the group include security principals from trusted domains?
  • Availability. Where can the group be used? Is the group available to add to another group? Is the group available to add to an ACL?
  • Trust availability. A trust allows a domain to refer to another domain for user authentication, to include security principals from the other domain as group members, and to assign permissions to security principals in the other domain.

The terminology used can be confusing. If Domain A trusts Domain B, Domain A is the trusting domain and Domain B is the trusted domain. Domain A accepts the credentials of users in Domain B. It forwards requests by Domain B users to authenticate to a domain controller in Domain B, because it trusts the identity store and authentication service of Domain B. Domain A can add Domain B’s security principals to groups and ACLs in Domain A.



 



 





Local Groups:


Local groups are truly local. They are created, defined on and only available to the specific computer they were created on. Local groups are created in the local Security Accounts Manager (SAM) database of a domain member computer, whether a workstations or a server.


Replication:


     Because a Local Group only exists on a specific machine, the group and its membership are not replicated to any other system and is only available for any sort of use only on that specific machine.


Membership:


A local group can include as members:


  • Any security principals from the domain—users, computers, global groups, or domain local groups.
  • Users, computers, and global groups from any domain in the forest.
  • Users, computers, and global groups from any trusted domain.
  • Universal groups defined in any domain in the forest.
  • Availability. A local group has only machine-wide scope. It can be used in ACLs on the local machine only. A local group cannot be a member of any other group.


Local Group Usage Best Practice:


In a workgroup, you can use local groups to manage security of resources on a system. In a domain, however, managing the local groups of individual machines becomes an administrative overhead, and is for the most part unnecessary. It’s not recommended creating custom local groups on domain members. There are very few scenarios in a domain environment that are addressed by using local groups.


In most cases, the Users and Administrators local groups are the only two local groups that you should really be concerned with managing in a domain environment. You can use the Restricted Groups GPO setting to easily manage these two groups across the forest.


Using Restricted Groups
http://www.windowsecurity.com/articles/Using-Restricted-Groups.html


Restricted groups are made for local group management:
http://www.frickelsoft.net/blog/?p=13


 




Domain local groups (DLGs):


DLGs are used primarily to manage permissions to resources, which means they mostly serve as rule groups. For example, the ACL_Sales Folders_Read group discussed earlier in the lesson would
be created as a domain local group.


Domain local groups have the following characteristics:


  • Replication. A domain local group is defined in the domain naming context. The group object and its membership (the member attribute) are replicated to every domain controller in the domain.
  • Membership. A domain local group can include as members:
  • Any security principals from the domain—users, computers, global groups, or other domain local groups.
  • Users, computers, and global groups from any domain in the forest.
  • Users, computers, and global groups from any trusted domain.
  • Universal groups defined in any domain in the forest.
  • Availability. A domain local group can be added to ACLs on any resource on any domain member. Additionally, a domain local group can be a member of other domain local groups, or even machine local groups.

The membership capabilities of a domain local group (the groups to which a domain local group can
belong) are identical to those of local groups, but the replication and availability of the domain local
group make it useful across the entire domain.


DLGs Best Practice:


Domain local groups are well suited for defining business management rules, such as resource access rules, because the group can be applied anywhere in the domain, and it can include members of any type within the domain, and members from trusted domains. For example, a domain local security group named ACL_Sales Folders_Read might be used to manage Read access to a collection of folders that contain sales information on one or more servers.


 




Global Groups


Global groups are used primarily to define collections of domain objects (users, other global groups, and computers), based on business roles, which means that they mostly serve as role groups.


Role groups, such as the Sales and Marketing groups, and roles of computers such as a Sales Laptops group, are usually created as global groups.


Global groups have the following characteristics:


  • Replication. A global group is defined in the domain naming context (the domain itself). The group object, including the member attribute, is replicated to all domain controllers only in the domain they were created in.
  • Membership. A global group can include as members only those users, computers, and other global groups in the same domain the global group was created in.
  • Availability. A global group is available for use by all domain members, and by all other domains in the forest and all trusting external domains. A global group can be a member of any domain local or universal group in the same domain or other domains in the forest. It can also be a member of any domain local group in a trusting domain. Global groups can be added to ACLs in the domain, in the forest, or in trusting domains.

Global groups have the most limited membership (only users, computers, and global groups from the same domain) but the broadest availability across the domain, the forest, and trusting domains.


Global Group Best Practice:


Global groups are well suited to defining roles, because roles are generally collections of objects from the same directory. For example, global security groups named Consultants and Sales might be used to define users who are consultants and sales people, respectively.


 



Universal Groups


Unlike Global and Domain local groups, the use of Universal Groups is not limited to role or rule type of groups; they can be used in both types of groups depending on the scenario.


Universal groups have the following characteristics:


  • Replication. A universal group is defined in a single domain in the forest but is replicated to the global catalog, which makes the universal group available to all domains, forest wide, and to trusting domains and forests.
  • Membership. A universal group can include as members users, global groups, and other universal groups from any domain in the forest.
  • Availability. A universal group can be a member of a universal group or domain local group anywhere in the forest. Additionally, a universal group can be used to manage resources, for example, to assign permissions, anywhere in the forest, as well as across trusts.

Universal groups are useful in multidomain forests. They allow you to define roles or to manage resources that span more than one domain.


Universal Group Limitations:


“Universal Groups cannot contain members (users or groups) outside the forest they are created in. This limitation would preclude users or groups that are members of domains trusted via External


Trusts from being added to Universal Groups.”
“Universal Groups from any domain in any forest can not be placed as members into Global Groups.”
“Domain Local Groups from any domain in any forest can not be placed as members into Universal Groups.”
“Universal Groups can not contain Global Groups from a mixed-mode domain in the same forest. “
http://networkadminkb.com/kb/Knowledge%20Base/Windows2003/Universal%20Group%20Limitations.aspx


Enable Universal Group Membership Caching in a Site:
“To reduce Global Catalago replication traffic, You can enable universal group membership caching.”
“In a branch site that has no global catalog server and in a forest that has multiple domains, you can use this procedure to enable Universal Group Membership Caching on a domain controller in the site so that a global catalog server does not have to be contacted across a wide area network (WAN) link for every initial user logon.”
http://technet.microsoft.com/en-us/library/cc816928%28WS.10%29.aspx


 


The best way to understand universal groups is through a short example


(For a bigger example, see the Group Nesting Strategy example towards the end of this blog)


Widgets, Inc has a forest with three domains: Americas, Asia, and Europe. Each domain has user accounts and a global group called, Regional Managers, which includes the managers of that region.


Keep in mind that global groups can contain only users from the same domain. Therefore due to this limiation, we need to look at using a Universal Group for this solution. We’ll create a universal group called, “Widgets Regional Managers,” or rather “U_Widgets Regional Managers” and the three Regional Managers groups are added as members.


The Widgets Regional Managers group therefore defines a role for the entire forest. As users are added to any one of the Regional Managers groups, they will, through group nesting, be members of the Widgets Regional Managers.


Widgets, Inc is planning to release a new product that requires collaboration across its regions. Resources related to the project are stored on file servers in each domain. To define who has the ability to modify files related to the new product, a universal group is created called “U_New Product_Modify.” That group is assigned the Allow Modify permission to the shared folders on each of the file servers in each of the domains. The Widgets Regional Managers group is made a member of the “U_New Product_Modify” group, as are various global groups and a handful of users from each of the regions.


Using universal groups can help you to represent and consolidate roles that span domains in a forest, and to define rules that can be applied across the forest.


 


 



Identifying and Creating a Group Nesting Strategy – IDGLA or AGDLP


Nesting is the process of adding one group to another group. This will allow you to help better manage and administer your environment based on business roles, functions, and management rules.


However, you can’t add any old group to any other old group. There are some rules to follow. The two Scope Summary charts above will help understand which groups can be members of other groups, depending on group scope or type.


The Best Practice for group nesting, known as IGDLA. IGDLA stands for Identities, Global groups, Domain local groups, and Access:

  •  Identities (user and computer accounts) are members of:
  • Global groups that represent business roles. Those role groups (global groups) are members of:
  • Domain Local groups that represent management rules—determining who has Read permission to a specific collection of folders, for example. These rule groups (domain local groups) are granted:
  • Access to resources. In the case of a shared folder, access is granted by adding the domain local group to the folder’s access control list (ACL), with a permission that provides the appropriate level of access.


As mentioned earlier, it was previously referred to as AGDLP, but changed to IDGLA because it defines more of a general scope of aplication, then just defining how AD groups work, which aligns with industry standards practice.


If the Domain Functional Level and Forest Functional Level is set to Windows 2000 or newer, AGDLP can be expanded to AGGUUDLDL, allowing you to nest Globals into other Global Groups, Global Groups into Universal Groups, Universal Groups into other Universal Groups, as well as Domain Local Groups into other Domain Local Groups.


The same applies to IDGLA expanded to IDGGUUDLDLA, or Identities, Global groups, Global Groups, Unicersal Groups, Universal Groups, Domain local groups, and Access. However, it’s not really referred to it as such, and is more or less a description of it’s expanded options, but more so because IGDLA refers to simply organizing identity resource access by role.


By any other name, the end results is the user gets the permissions applied to the Domain Local Group.




Summary:


AGGUDLP:


Recommended Best Practice for Active Directory Groups Nesting Strategy:


Add accounts to a Global Group, add the Global Group to a Universal Group, add the Universal Group to a Domain Local Group, apply permissions for the Domain Local Group to a resource. The accounts in the original Domain Local Group will have access to the resource with the permissions levels based on the permissions applied to the Domain Local Group.


AGGUUDLDLP:


Extended Optional Active Directory Groups Nesting Strategy:


Add accounts to a Global Group, optionally nest the Global Group into another Global Groups, etc, add the last nested Global Group to a Universal Group, optionally nest the Universal Group into another Universal Group, etc, add the last nested Universal Group to a Domain Local Group, optionally nest the Domain Local Group into another Domain Local Group, etc, apply permissions for the last nested Domain Local Group to a resource. The accounts in the original Global Group will have access to the resource based on the permisions applied to the Domain Local Group.


With a multi-domain forest, we’ll need Universal groups to fit the bill, which would be used to add Global Groups from multiple domains. That universal group can be added as a member of domain local groups in multiple domains. You can remember and refer to the nesting as IGUDLA.


 


If a Universal Group is available Forest Wide, then where is the Universal Group stored?


The Universal Group is stored in the domain of where it was created, but the Universal Group Memberships are stored in the Global Catalog and replicated Forest Wide.


 


 


Group Nesting Strategy Practice Scenario:


TechNet forum thread question: “can we add universal group into global group?”
http://social.technet.microsoft.com/Forums/en/winserverDS/thread/fa66b5c5-3ed3-4700-b479-e036577e110b


Basically, you need to follow the AGUDLP guideline (Add users to a global group, add the global group to a Universal, add the Universal to a Domain Local Group, add the Domain Local Group to the resource, then provide permissions for the Domain Local Group to access the resource).


This can be expanded to ADDUUDLDLP, which means you can nest Global groups into other Global Groups, nest Universal Groups into other Universal Groups, and nest Domain Local groups into other Domain Local Groups, but you can’t go backwards, meaning that you can’t add universals into a Global. Matter of fact, the system won’t even give you the option to add the groups trying it the other way.


 


.


Here’s an example of what I use in class when teaching group nesting:


  • Scenario: One forest, three domains.
  • Domain and Forest Levels are at the latest levels.
  • The Accountants in each domain need Full Control permissions to the accounting database in only their domain.
  • The Accountants in all domains in the forest need Read permissions to the accounting databases in the other domains.

How would you do this?


Solution:


  • In each domain, create two Domain Local Groups (DLG), one that you will assign Read permissions, and the other that you will assign Full Control permissions.
  • Add both DLG groups to the accounting database in each domain, and assign the appropriate permissions for each group.
  • In each domain, create a Global Accountants Group.
  • Add the users in each domain to their own domain’s Global Accountants Group.
  • Add the Global Accounting Group in each domain to their domain’s Domain Local Group that has been assigned Full Control to the database.
  • Create one Universal Accountants Group.
  • Add the Global Accountants Group from each domain to the Universal Accountants Group.
  • Add the Universal Accounting Group to the Domain Local Accountants Group in each domain, that has been given Read permissions to the accounting databases.

Here’s two versions of the diagram that should help to show the solution steps in the above bullet point.




Reference picture:
http://cid-0c7b9fd0852378b8.photos.live.com/self.aspx/Technet%20Forum%20Support/AD%20Groups/AD%20Groups%20Strategy.jpg


 


Reference Link to pic above:
https://public.blu.livefilestore.com/y1pe2i8ifuHij7srt59GRhupSS4CwgSe2OuOsUf23GQt2fNNcZFzlJGrM4VopdRoeBILusmw3CnVbaJKPfREWLPZw/AD%20Groups%20Strategy%20-%202.jpg?psid=1



.

Related Info and links:


Group scope: Active Directory
http://technet.microsoft.com/en-us/library/cc755692(WS.10).aspx


Active Directory Groups & Permissions Guideline – Good tutorial:
http://microsys.unity.ncsu.edu/documentation/ITD-Active-Directory-Environment/Groups-Permissions.php



 



I hope you’ve found this helpful.
Comments and suggestions are welcomed!


Ace Fekay