Therefore, we decided to create—under the Domain Controllers folder that Figure 3 shows—an OU folder for each administrative group, then move the respective DCs out of the Domain Controllers OU and into the AU1 and AU2 sub-OUs. From these subfolders, we could link certain GPOs to certain sub-OUs. Now we could assign specific user rights to only the DCs in a certain administrative group. We gave administrators the rights to
- back up files and directories
- change the system time
- create a pagefile
- load and unload device drivers
- log on locally
- restore files and directories
- shut down the system
Other tasks, such as modifying system files or installing services on DCs, are prohibited for local administrators.
Remember that some groups or accounts must retain certain user rights (e.g., a backup service account must have the right to restore files and file folders) and others have inherited rights from a different GPO level (e.g., the domain level). You must manually add such accounts to your defined Group Policies. Table 2 shows a listing of default user rights on DCs. Remember to keep track of all your modifications. Some services (e.g., Microsoft Exchange Server) also require user rights on DCs.
DNS Server
In our AD environment, we wanted all computers to register dynamically; therefore, we decided to use AD-integrated DNS to automatically replicate all entries to every DC. AD matches DNS zones to AD domains, so our single large AD domain has one DNS zone for all computers. Because AD-integrated DNS is available only on DCs, every DC runs the DNS service so that local name resolution is available at every business location. The benefit of AD-integrated DNS is less maintenance effort for DNS replication.
We conducted several performance tests to determine whether AD-integrated DNS would be fast enough to handle as many as 20,000 entries in a single zone. Our results showed that such a load was feasible and that response times would remain fast.
However, a problem arose: How would local administrators handle static clients (such as UNIX servers or Web servers) that aren't running Win2K or that can't use dynamic DNS registration? The administrators would need to manually add these machines to the DNS zone, but the right that would let them do this would also let them accidentally delete an entry. You might think that the obvious solution is to give the administrators the Create All Child Objects permission in the MMC DNS snap-in. You would be incorrect. The DNS snap-in uses the DnsAdmins group as a built-in group; therefore, you must be a member of the DnsAdmins group to be able to open and use the DNS snap-in. If you try to grant a user who isn't a member of the DnsAdmins group access to the DNS snap-in, you'll fail.
We tried to restrict the DnsAdmins group to Read access to the DNS zone information and use other groups (e.g., Domain Admins) to handle Write access. Unfortunately, because the DNS snap-in uses DnsAdmins as a built-in group (i.e., with its unique built-in SID), members of the DnsAdmins group automatically get Full Control permissions on every DNS server's properties sheet. A member of the DnsAdmins group can change DNS property settings (e.g., set forwarders or enable monitoring) on any DC in the domain that runs DNS. Therefore, we couldn't accomplish this restriction. When we brought this problem to Microsoft's attention, we learned that this lack of management functionality is by design: Giving a user only Read permission to a DNS zone in the DNS snap-in is impossible.
However, because Win2K stores zone information in AD, you can use Lightweight Directory Access Protocol (LDAP) to grant permissions to the container and directly access the zone information. Win2K stores AD-integrated zone information in domain-naming context at LDAP://cn=MicrosoftDNS,cn=System,dc=domain.
We plan to develop an application that lets local administrators manage static client entries. Until then, only members of the DnsAdmins group can add or delete static client entries. Meanwhile, Microsoft expects to release a fix for this DNS delegation problem by the time you read this article. The fix won't be available in Win2K Service Pack 2 (SP2), but you can request it from Microsoft Product Support.
Plan and Test
With these tips and observations in mind, you should be able to more granularly plan permission delegation in your environment. Generally, the more specific the permissions you set in AD, the more difficult management of those permissions will be. Be careful not to drown in permission-delegation details, and be sure to clearly document every permission that you set. Don't lose sight of your larger AD goals.
At Siemens PG, we tried to keep our permissions as simple and straightforward as possible, and yet our environment is still extremely complex and difficult to manage. Our plan is to eventually implement a third-party permissions-management tool, such as FastLane Technologies' FastLane ActiveRoles, which should help us automate and record permissions assignment. Regardless of whether you implement a third-party tool, you must never underestimate the importance of planning and testing any AD permission strategy that you design for your company.
End of Article
splurge987 January 31, 2008 (Article Rating: