Active Directory mysteries unraveled
a manager's perspective
Dan Tuten, PMP, MCSE
Program Manager, Georgia Dept of Revenue
In the 1980s, computer networks were few and far between. By the 1990s, computer network technology was expanding exponentially across all types of business. However, most of these networks started as un-planned, unstructured accumulations of computers and communications technology that entered business from the bottom up. New users, computers and servers were added as network technology expanded the ability of groups of people to better manage their productivity.
As is the tendency, when people see something helping their peers, people in the same business or organization and yet different departments wanted their own computer networks to improve their productivity. In most cases, each group would independently implement their network to increase the performance of their staff.
Unfortunately, in the rush to implement, many businesses often used competing technologies running on mixed platform environments based on the personal preferences of the groups implementing them. Further, many of these bottom-up networks did not communicate with each other and at the time that was OK, because they were not designed for intercommunications. However, in the longer term this meant that ideas and information in one part of an organization were not available to another part of the organization.
So we see that for a segment of an organization's staff, networks increased their productivity, but for the whole organization, the cost of delivering and integrating these services was growing far faster than the individual productivity gains. These problems became even more pronounced as the Internet factor forced many organizations to begin to take a big-picture look at their computer network technology. Larger networks, more complex networks, multi-platform networks caused Network Management operations to increase exponentially in the 90s.
This led to significant increases in the cost of managing, deploying and integration network technology. Suddenly, the productivity gains for the organization's staff were lost by the exponential cost increases of managing the ever expanding network infrastructure. One potential solution to this issue is the use Active Directory as a management tool. While there may be other potential solutions available in the marketplace, they are beyond the scope of this paper except as needed for comparison.
With Active Directory being one of the core components of Windows 200 Server and Windows Server 2003, it is important to review a history of those operating systems starting with a definition.
Active Directory Definitions
Active Directory is defined by its creator Microsoft as follows: Active Directory (AD) is a Directory Service with the ultimate purpose of storing information about users, resources, and other network entities, and to provide that information to anyone or anything that has access to the directory, according to access permissions. To help alleviate some of the mystery around Active Directory, let's reword some of this and break it into components as follows:
Active Directory is
- Object oriented database
- Store for information (Users, Computers, attributes, etc)
- Permissions based access and usage
- Only available in Windows 2000 Server and Windows Server 2003 families of products
Windows 2000 History
Many persons taking a look at Active Directory have the perspective that it is a recent system management platform, which is not entirely correct. Active Directory made its debut in conjunction with the rollout of Windows 2000, which is more than 5 years old on its own. While this may be very young considering competitors, such as UNIX and Novell's products, it is the middle child when considering alternatives such as LINUX and Apple's Directory Services delivered in its OS X series of products.
Many organizations around the world may have solid organizational infrastructures built on Microsoft's long time flagship domain management product, Windows NT 4. In comparing the two products they may feel that the latter product still needs to mature when in fact, Windows 2000 development began before Windows NT was even released to the public. In 1991 (Windows NT4 was released in 1993) Project Cairo was sponsored which would be a long term development to bring about Windows 2000 and its core technology of Active Directory. While the naming through the early releases and BETA initially portrayed the product as NT5, there are none of the NT4 kernels contained in the Windows 2000 product.
The long term development of Windows 2000 included multiple releases to the public. 1996 was the year of the preview which was built to run on Windows NT. Each following year brought us releases of NT5 BETA 1 and 2 in 1997 and 1998 respectively. 1999 gave us a name change to Windows 2000 and BETA 3 release. I personally know of several organizations that were running mission critical production environments on BETA 3 code due to its perceived superiority to NT4 for their organizations. To finish out the development cycle there were versions called Release Candidate 1 and 2 prior to the formal Windows 2000 launch in late 2000.
Windows 2003 Continues the History
When Windows NT4 was released to the public Microsoft began a series of service packs to continually update its core components. Over the course of the years during which it held the top slot for server sales with Microsoft, it underwent over 6 service packs and numerous updates at a rate of approximately 1 per year. Windows 2000 showed a similar propensity for needing to be updated at similar rates. Enter the Windows Server 2003 family and note a drastic change in updates required. Windows Server 2003 was released in spring of 2003 and just this spring (almost 2 years later) there is a service pack for its core components.
Windows Server 2003 is built on the core of Windows 2000 Server technology and as such has a complete development history of over 12 years from start to release. Although this may not be a glowing recommendation in some technical arenas, it has the best track record on not needing updates of any Microsoft product to date and has survived when a dominant directory service based infrastructure from Novell has been pushed into the background. Even Novell has moved away from their own products to embrace a distribution of LINUX as its new flagship line of products.
Whether you choose to implement the first version of ACTIVE DIRECTORY with Windows 2000 or gain the updates and advantages of Windows Server 2003, you will find a great many tools to help manage the network, maintain users, systems and servers and aid in keeping the total cost of ownership for the organization to a minimum.
Features and Benefits
Active Directory is one of the major features for the Windows 2000 Server family. Active Directory replaces the old Windows NT 4.0 Security Accounts Manager (SAM) database of users and groups with a Directory Service designed to act as a single, centralized repository of network- and computer- related objects such as users, groups, organizational units, computers, printers, and so on.
Active Directory is the newest competitor to Novell's NDS (Novell Directory Services), and it can hold millions of objects. (The older Windows NT 4.0 SAM database could contain only thousands of objects and was limited to computers, users, and groups.)
You can think of Active Directory, or any directory service for that matter, as a phone book of vast information that users can query and utilize. Users can also add and modify information stored in Active Directory providing that they have been granted the appropriate permissions to do so.
Active Directory was created to embrace current Internet standards. These include:
- TCP/IP - Transport Control Protocol/Internet Protocol.
- DHCP - Dynamic Host Configuration Protocol, used to assign addresses out to clients.
- DNS - Domain Name System.
- SNTP - Simple Network Time Protocol.
- LDAP - Lightweight Directory Access Protocol.
- LDIF - Lightweight Directory Access Protocol Interchange Format.
- Kerberos - For security and authentication.
- X.509 - Certificates for security and authentication.
Additional benefits of Active Directory include fault tolerance, scalability, and interoperability with Windows NT, Netware, UNIX and with the OS X (10.3 and later).
The logical organization of Active Directory defines how it is structured. The domain is the parent container. Organizational units (OU) can create different levels of authority in a hierarchical fashion. In terms of scalability, multiple domains can form a domain tree. Multiple domain trees, or different name spaces, combine to create a forest.
While it is not a perfect analogy in comparing the true power of Active Directory as a management tool for networks, in order to unravel this little part of the mystery, let's use an analogy of a library. The card catalogue is the domain that holds drawers called OUs which contain information about specific books. As the librarian, you can designate which assistant is responsible for maintaining each drawer. While the card catalogue doesn't contain any books itself, it is crucial to the smooth operation of the library as a whole. In a library, such as the library of congress, there would be multiple card catalogues to handle the huge complexity and amount of information. In our “library” the card catalogue is very special and shows which visitors can check out, read or even view the available books, thus showing that it not only contains specific information, but that it handles permissions about objects as well.
Maintaining our library analogy, Group Policy is the magician that uses the card catalogues to seek out which books to make fly, sends updates to books when a correction is made by the editor and other things that can only happen through magic. While this may seem a bit nonsensical, but the power of Group Policy can seem almost magical to the user that is unfamiliar with technology. The most usual uses of group policy are things likes forcing users to have a complex password, locking out their account when too many attempts have been made with bad passwords, forcing everyone's desktop background to be uniform and configuring automatic updates to point to an internal server instead of Microsoft.
This area of Active Directory that is just a bit too complex to unravel the mysteries behind it, however, project managers need to be aware of the general intent of group policies and a couple of important things to remember
Group Policies also follow a hierarchy in when they are applied. The basic premise is “Last One Wins”. The policies that can possibly take place on a system or user are applied in a specific sequence. First - any local policies in effect are applied. Second - any Site policies in effect are applied. Third – any domain policies in effect are applied. Lastly the OU policies in effect are applied (Parent first down through child to the lowest level in order). The easy way to remember this is LSDOU.
It is possible that multiple settings may be applied at various levels such as everyone having the same password at domain level, the same background at OU level, etc. When there is no conflict among the policies being set on a system or user, they all apply. When there are differences in the settings occur, remember the sequence and that the “Last one wins” unless…
Inheritance and Override
There always has to be an exception and these two elements provide for that need. Inheritance is the normal method of operations for the card catalogue. It means that all the drawers will be organized in the same way, unless a change has been authorized by the librarian. Through the “No Override” feature, the Active Directory designers built in the capability to force inheritance from parent to child through the sequence shown above so that an assistant only responsible for their card catalogue drawer couldn't decide to organize their cards according to the moon phase rather than the alphabet when nobody was looking.
Key Elements to the Project Plan
- Assemble a central planning team.
- Identify the vision and scope of the project.
- Perform risk management to ascertain the risks involved in migrating to AD.
- Document the current physical network.
- Analyze the current business practices to ascertain how information flows, and what users need in order to do their jobs.
- Plan and conduct analysis for project growth and reorganization.
- Plan for the Active Directory Migration
Central Planning Team, Vision and Scope
As project managers, many of us are very aware of the need for communication within a project plan. During an Active Directory implementation this can be extremely important as there may be significant changes for the users involved. An Active Directory implementation may change the way users systems look or respond and with insufficient communication, this will only cause additional support calls for the helpdesk. During the various Active Directory design and implementations that I have been a part, I have stressed communication early on through the use of a project team consisting of the groups noted in Figure 2. These groups are key to gaining the support from all stakeholders that even though change may be uncomfortable, in the end it will be to everyone's benefit.
In assembling the central planning team, communicate with the different departments within your organization. The central planning team will obtain approval from upper management, identify and consult with all systems and operations administrators, and gather information about the current network. Organizations may not have all of these areas or be organized differently. The key areas that MUST be in place are User education, Testing, and the development team for the effort.
You must identify the vision and scope of the project. A vision defines a clear direction. A scope encourages discussion, sets expectations, provides an initial assessment of risk, and provides a baseline of design and deployment. When it comes to user education, it is never too early. There have been great successes achieved in gaining user support through sending out information on the positive changes early in the planning stages to allow them time to mentally prepare for the coming project.
Requirements – Analysis, Risk, and Documentation
The Business Analyst (or the person acting in this role in smaller organizations) should have a good understanding of the capabilities of Active Directory or should conduct all interviews with a business savvy engineer that has these skills. It is important to ask the interview analysis questions with a view toward the possibilities of Active Directory.
Be sure to analyze the business needs. Observe how the company operates. Interview people in different positions. For example, managers and staff workers often have different views on the use of technology.
Part of conducting an organizational analysis is also risk management: taking a look at business practices and planning for growth and reorganization of the company. Performing risk management involves creating a document with a problem statement, risk assessment categories, and risk assessment for the organization. It helps to mitigate risk by using contingency plans.
A proactive risk management plan helps prevent risk and lessen its impact. The risk document helps to calculate probability, severity, and exposure, and lists ways to mitigate risks through contingency plans.
Documentation of the physical network is key to the plan as it will help to determine appropriate site boundaries in the overall structure.
Balance of Power
Within any Active Directory implementation, there is going to need to be a balance of power. Active Directory has the power to place great restrictions on the users in deference to security needs of the organization, but be careful! Heavy security restrictions come at the price of user productivity. A perfect example is the enforcement of password complexity at a specific Active Directory project. Users were forced to have passwords that were at least 10 characters and had to have a mixture of upper case, lower case and special characters. Guess what the greatest number of calls to the helpdesk were until this restriction was relaxed a bit? You guessed it, resetting passwords for users that couldn't remember their very complex password.
Planning and Design
Active Directory design is very much a one way street. While it is powerful and can greatly assist you in accomplishing your business and technical goals, a poor plan will lead to much frustration and the only option for some areas of Active Directory is to start from scratch.
There are a great number of elements to the design of Active Directory and should be undertaken by a person or outsourced to a firm that has the experience to take the myriad of factors into account. We will review a few of the more important business /project related elements to the design. The technical portions of the design are beyond the scope of this document.
K.I.S.S. (Keep It Simple Simon). More is not better, it is just more. A simple design provides more flexibility over the long run than does a complex one. The more complex an organization is the designers tend to make the AD design more complex, when the reverse is preferred. Keeping the design as simple as possible will greatly aid in administering the organization as a whole. Successful simplifying of a design has been gained through seeking out commonalities between departments, users, systems, etc.
Disregard the organizational chart structure. It does not need to be recreated in Active Directory. Users never see the structure of Active Directory anyway. Design the Active Directory structure with information technology in mind. The idea behind Active Directory is to make administration easier. The caution in this area is that since we do have delegation capabilities within Active Directory, it may be the proper political decision within the decision to maintain some of the organizational structure within the design. This will allow management of group policy and other elements on a department or other structure level, but again I must stress, if possible, simple is better in this design.
Build the design with group policy in mind. You may not wish to implement group policy immediately, but if you do not plan for it, you may have to do significant changes when you are ready to implement them.
The actual design is usually not very time consuming once all the factors are in place, so it is recommended that you build 2-3 potential models for decision by the development team based on all the factors. This will also force you to think through the impacts of the design from different perspectives. Doing this exercise should reap the benefit of having close to an ideal design to be implemented for the organization.
Include your users in the discussions. It is highly recommended that you have a group of users (and I don't mean supervisors of users) to talk through the design elements as they impact them. This will force the entire project team to understand the impacts of their decisions as well as assist in having a group of users that help evangelize the masses on the positive aspects soon to come.
Expect change. Although you may have been close to the ideal through careful planning and multiple models and having done all the other elements, it is, after all, a development effort and the final design will have changes that occur prior to or during implementation. If there are not, count yourself very fortunate.
Test. Test. Test. Make sure that you test everything. Test building the design on a scaled down version. Test the Group policies and the impact to users. Test the migration from the old system to the new. As you come across issues that impact the design, make the modification and test again. Having said this let me caution you of a potential trap. Some organizations have gone into paralysis in the testing phase over issues that are not critical enough to have stopped the project. This happens when the issues are not evaluated for impact with the total project in mind and are allowed to derail the progress. The project is to get Active Directory implemented and handed over for ongoing maintenance. The testing is merely a component of the overall plan.
One of the two primary ways to implement Active Directory is to do it in stages. This has the advantage of allowing the greatest flexibility in the design as you go. The servers can be put into place, the skeleton formed and gradually migrate the organization to the new infrastructure. This can be done by department, by site or by any other bite-size portion of the organization that makes sense. As you implement the design in a section, you can take lessons learned, modify the design if needed and move on to the next.
It is also important to note that an Active Directory migration will not usually happen in a vacuum. More often than not, the Active Directory design and implementation will be a part of a larger project plan such as a complete upgrade to new technology, migration from an older operating system, or move from mainframe based structure to client-server. The elements discussed in this paper apply regardless of the overall plan of which AD is a part, but should be applied in context of the larger project planning cycle.
One for All
Smaller organizations have the advantage of being able to do a single rollout all at once. This is considered an advantage primarily due to it having the lowest impact on user productivity. In an optimal scenario, Users go away from their normal work, attend training on the modified systems and return to work on the new. There is still an impact to users' productivity, but this is to be expected when there are changes to their systems.
Active Directory is a wonderful addition to the system administrator's toolbox. With the information imparted to the project manager with this paper, they can assist in getting it implemented successfully for the admin staff with the minimal negative impact to the organization.
Appendix A – Operating System Comparisons
The following table is based on Windows 2000 Active Directory, but can be applied to both versions.
|Database||Single writeable SAM||Multi-mastered ESE|
|Trusts||Intransitive One-way||Transitive Bi-directional|
|Group Nesting||Global into local||Free within each scope|
|Object hierarchy||NO||In OUs|
|Change DC||Only at install||Yes|
|Delegate Admin||Only at Domain||Domain, OU, Object, Attrib|
The following table is based on Windows 2000 Active Directory, but can be applied to both versions.
|Group types||One type||Security or distribution|
|Group scope||One||Global, Universal, Domain Local|
|Nesting||No||Free in each scope|
|Replication type||Multi-master||Multi-master w exceptions|
|Replication criteria||Time Syncing||Universal Sequence #s|
|Site||No (poor WAN replication)||Yes (better WAN replication)|
|Tree visible to users||Visible (Distracting)||Mostly invisible Ease of use|
Although not explicitly quoted, the following sources have provided the basis of the technical knowledge included in this paper.
Desai & Chellis, (2001), Implementing and Administering a Microsoft Windows 2000 Directory Services Infrastructure Study Guide, Alameda, CA: Sybex Publishing
King & Govanus, (2001), MCSE: Windows® 2000 Directory Services Design Study Guide, Alameda, CA: Sybex Publishing
Holme & Thomas, (2003), Upgrading your Certification to Microsoft Windows Server 2003 Self Paced Training Kit, Redmond, WA: Microsoft Press
© 2005, Dan Tuten
Originally published as a part of 2005 PMI Global Congress Proceedings – Edinburgh, Scotland