AD Security

Introduction

Last month we covered Group Policies in some depth, showing how administrators can enforce corporate policy via the use of Group Policy Objects (GPO) in Active Directory (AD). This month, we continue with a similar theme exploring how Windows 2000 enforces security with and without the help of AD.

As everyone knows, under NT Server 4.0 the security boundary is the domain. When administrators wished to delegate administrative responsibility to other users in the organisation it required the creation of a new domain, since the administrator had total authority throughout a domain. If the corporate administrator thus needed to provide limited administrative responsibilities to the chief accountant and the sales manager, then new domains needed to be created for the sales and accounts departments, with appropriate rights granted for the two individuals. Once that had been done, each had administrative oversight for his or her own domain, but could not meddle in the affairs of other domains in the organisation.

Of course, the enterprise administrator also needed rights in these domains to ensure that central control was maintained, and this placed an additional burden on that administrator. Sometimes, however, the reason for setting up these new domains was to prevent the corporate administrator from having rights where he or she should not have them, allowing each department or segment of the organisation to have autonomous control of its own domain.

Given the physical limitations of the old domain structure it was also necessary for larger organisations to create multiple domains simply to handle the total number of objects required. This too introduced unwelcome management overhead, since it fell to the administrator to create and maintain the necessary trust relationships between domains to ensure that users throughout the organisation had access to the appropriate resources.

Active Directory now provides the store for all domain security policy and account information, providing replication and availability of account information to multiple Domain Controllers. It also supports a hierarchical name space for user, group, and machine account information, so that accounts can be grouped by Organisational Units (OU’s), rather than the flat domain account name space provided by earlier versions of NT Server.

AD supports a multi-level hierarchical tree of domains should organisations still wish to utilise domains to create trust boundaries. Management of trust relationships between domains is now greatly simplified, however, through automatic and transparent transitive trust throughout the domain tree. Most organisations will be able to dispense with multiple domains altogether, relying instead on the concept of sites and organisational units to partition their Active Directory tree both physically and logically.

Many NT-based organisations will be faced for the first time with the prospect of being able to support their entire organisation using a single domain. While this will cause little problem for green-field sites, those with existing complex domain implementations will find the move problematical. The effort involved in collapsing multiple domains into a single domain structure will pay dividends in the long run, however.

Once the domain structure has been sorted out, the administrator needs to plan the Organisational Unit and group strategy. Although groups and OU’s are totally separate entities they do have one common feature – users. To create a complete administrative solution, the group and OU structures therefore need to be synchronised to a certain extent, and this is one complication of Active Directory that should have been avoided.

The primary difference between organisational units within Active Directory and other directory services such as NDS is their use as security principals. An object is a security principal if it can be granted rights to other objects or resources.

NDS security principals, for instance, include users, groups, workstations, organisational units, organisational roles, and profiles. Any of these objects may be granted rights to other directory objects and corporate resources. For example, NDS organisational units can be granted rights to users, groups, and other OU’s .�

Assigning rights to an OU in NDS

NDS organisational units may also be granted rights to resources such as file servers, Web servers, dial-in devices, and printers. NDS users contained within the OU then automatically inherit the security rights granted to the parent organisational units. Thus, as users are moved from one department to another, the administrator does not need to worry about what rights need to be revoked and what new rights need to be granted. Instead, he simply drags the user from one OU to another in the NDS tree, and that user loses all the rights of the original OU, and automatically gains all the rights that apply to the new OU.

When a new user joins a company or is moved between departments, the user automatically inherits all directory and resource rights associated with any parent organisational units. The business benefit is time and cost savings, since administrators do not need to know anything about what resources are needed for the user’s position in the company. Network administrators can rely on NDS to calculate each user's rights based on their location in the directory, rather than having to define explicit rights for each user in the network – this is how a directory service should work.

Active Directory organisational units, on the other hand, are not security principals - AD security principals are still limited to users, groups and computers. Active Directory OU’s cannot be granted rights to other domain objects, or to any corporate resources such as file servers, Web servers, and printers. Using Active Directory, only users, groups and computers can be granted rights to other directory objects and corporate resources.

Since Active Directory OU’s are not security principals, NT servers cannot leverage their domain structure in the same way as NDS. When a user joins the company, the administrator must know what the user needs to accomplish in his or her job, then remember which groups provide the necessary directory and resource rights. Lastly, the administrator must add the user to the appropriate groups.

The reliance on groups is far too heavy in AD. Groups will always be needed for some things (they are still available in NDS too), but AD forces administrators to duplicate OU contents with groups simply in order to grant rights to directories and other network resources. In other words, the organisational unit with AD is used purely for delegating administrative rights, and nothing more. Later releases of the Beta code have made things slightly easier by providing an option when the administrator right clicks on an OU in the Users and Computers administration utility that says “Add members to a group”.�

Adding members of an OU to a group

This allows all objects contained within the OU to be quickly added to a group for subsequent security administration purposes. All it is really doing, however, is making it a little easier to duplicate information already painstakingly entered into the OU hierarchy, and it is further marred by the fact that the group has to be created in advance of this operation.

None of this is helped by the fact that groups are further complicated in Windows 2000 by the addition of a new group scope – Universal – to join the existing Global and Domain local groups.�

Creating a group - new group scopes and types

Two additional types – security and distribution – further increase the number of possible permutations, allowing administrators to create groups for security reasons (as before) or to be used as address lists for AD-aware applications. One of the nice things about groups in Windows 2000 is the fact that, at last, they can be nested one inside another – at least they can once a network has switched from mixed mode to native mode (i.e. running all Windows 2000 servers)

The true nature of AD “security” is revealed by the first menu option proffered when the administrator right clicks on an OU – “Delegate Control”.�

Delegating control of an OU – selecting tasks to delegate

Here the wizard walks the administrator through the task of delegating administrative responsibility for that particular OU to a user or group of users. Each user can be allocated full control or a subset of administrative privileges (such as reset passwords, create new users, and so on), and this allows numerous administrators to be granted autonomous control of their own resources on a per-OU basis rather than having to create new domains as with previous versions of NT. Administrative rights granted at higher levels of the tree can flow down to child OU’s automatically via the process of inheritance.

Unfortunately, whilst it is possible to look at the Security tab of an OU and check manually which groups and users have administrative control, there is no equivalent means of checking a user object to see which OU’s he or she has been granted control of.�

Verifying security trustees of a group in AD

This smacks of an ideal opportunity for some third party auditing software, since it is an area of potentially huge confusion for administrators.

Apart from the ability to delegate administrative control, the OU hierarchy of AD is there mainly as an aid to users when locating resources scattered around the corporate network. To make AD truly useful, however, Microsoft needs to work hard on creating new security principals that can be administered from within AD for future releases of Windows 2000.

At the very least, the OU itself should be made a security principal, allowing it to be used to grant access to other network resources such as servers and directories. It would also be nice to see the file system security brought into AD too, allowing administrators to apply security permissions to shares, volumes and directories without having to revert to using the NT Explorer as a separate operation. It remains to be seen how difficult this proves to be, and whether Microsoft will even listen to such criticism.

My prediction is that unless it does, NDS will quickly become the de facto directory service and security administration interface for both NetWare and NT environments, relegating AD to little more than a fancy hierarchical naming service for Windows 2000.�

Send mail to webmaster with questions or�
comments about this web site.
Copyright � 1991-2002 The NSS Group.
All rights reserved.