You'll notice that Microsoft hasn't provided the ACL editor with a horizontal scrolling bar, so you can't see an entire username if it's longer than the width of the box. To work around this limitation, you need to click Advanced to access the Access Control Settings window. In this window, you can enlarge the username field so that you can display longer names. You'll also discover that the ACL editor's default settings won't let you assign permissions on more than one object at a time. Therefore, you can't assign permissions to an organizational unit (OU) folder structure and propagate the permissions to all subfolders. Figure 1 shows a standard permissions set that lets you assign basic permissions to only the current object—not to subordinate objects. If you need to assign a wider range of permissions to a folder structure, you must click Advanced, then select View, Edit to access the Apply onto drop-down list. As Figure 2 shows, you must select This object and all child objects.
The ACL editor contains another anomaly: When you use the window in Figure 2 to remove a permission from a user who has Full Control (e.g., clear the Allow check box next to Delete User Objects), the system creates a horde of single-permission entries for the user and displays them in the Permission Entries list. Even two such special permissions assignments will fill up the Permission Entries list so that you can no longer find a specific permission assignment. The ACL editor's poor design has had a direct impact on our efforts to manage permissions in our growing OU structure. Because of this problem and other anomalies, we avoid complicated security editing of AD ACLs unless absolutely necessary.
OU Folder Structure
To work around the ACL editor, and to ease the process of delegating control to our division's administrative units (i.e., the local managers who formerly administered NT 4.0 domains), we created a top-level OU folder structure for each of our three administrative units, as Figure 3 shows. Notice that each OU folder includes a standard set of OUs to help administrators manage their objects (e.g., Computers, Groups, Users). For the top-level OUs, we decided not to use typical naming conventions but rather to use numbers so that the OU names aren't tied to the names of locations or departments. Using numbers also helps us identify objects in the domain because we include the administrative-unit number as a prefix in our names for every group, service account, share, computer, and printer object.
Management of all Group Pol-icy Objects (GPOs), administrative groups, and accounts takes place within the DCSP OU folder structure (Administrative Unit Central). We assigned the local IT departments (Administrative Unit 1, Administrative Unit 2) Full Control over their respective folders, in-cluding all subfolders. This permissions assignment gives every administrative group the necessary rights to create, manage, and delete any type of object within its OU folder structure. Assigning single permissions (rather than Full Control) to a structure as large as ours—even with the help of some proprietary tools—simply isn't an effective solution.
Group Policies
Why did we create a special folder for GPOs? Because GPOs introduced a new set of problems that affected our OU structure. By default, Win2K stores GPOs in AD—in domain-naming context at LDAP:// cn=Policies,cn=System,dc=domain (e.g., LDAP://cn=Policies,cn=System,dc=mycorp,dc=com for the Group Policy container in the mycorp.com domain)—and stores Group Policy files in the\%systemroot%\sysvol\domain\policies folder (e.g., C:\winnt\sysvol\domain\policies). GPOs aren't attached to OUs but rather reside in the file system and link to OUs. Remember that Win2K automatically replicates the \sysvol folder to every DC in a domain. Creating a large number of GPOs has a strong performance impact on every DC that resides in the same domain. A large number of GPOs will not only affect user logon time but will also increase the amount of replicated data. When you make changes to a GPO, the File Replication Service (FRS) replicates the entire file—not just the changes—to every DC in the domain.
Another problem that we identified involves GPO removal. If you delete a GPO link without deleting the GPO, the GPO remains in the \sysvol folder—and the FRS replicates it to every new DC. (You can see unlinked GPOs only on the All tab of the Add a Group Policy Object Link window.) If you don't check this list once in a while and clean it out, you can end up with hundreds of unused GPOs. At Siemens PG, we manage GPOs centrally, checking periodically for unused GPOs. You can also obtain a third-party product such as United Business Machines' (UBM's) Full Armor to manage your GPOs.
To prevent this unused-GPO clutter, we decided to deny local administrators the right to create GPOs (e.g., assigning specific desktop settings to users) unless they have an adequate reason to do so. We limited group membership of the Group Policy Creator Owners group to our DCSP administrators, who approve, create, manage, and delete GPOs within the GroupPolicies folder that you see in Figure 3. From this folder, local administrators can add a Group Policy link to an OU folder. DCSP administrators manage GPOs from the GroupPolicies folder's Properties dialog box, which shows every GPO available in the domain.
Single-DC Permissions
The domain's DCs presented another problem. We wanted to give local administrators rights to perform some maintenance tasks on the DCs in their group, but we didn't want to give them the same rights or access to DCs in other groups. Sensitive data varies according to location, and because we wanted to establish one domain for everybody, we needed to ensure that administrators couldn't interfere with one another. Our solution was to restrict access to DCs. Unfortunately, the permissions you grant using the Default Domain Controller Policy apply to every DC.
splurge987 January 31, 2008 (Article Rating: