Active Directory Workshop
Few of us have the luxury of time or specialist equipment to really dive into the depths of Active Directory (AD), the directory service included in Windows 2000. The aim of this workshop is to provide some insightful knowledge without you getting your hands dirty.
Active Directory Workshop
Few of us have the luxury of time or specialist equipment to really dive into the depths of Active Directory (AD), the directory service included in Windows 2000. The aim of this workshop is to provide some insightful knowledge without you getting your hands dirty. Before you can start, though, a little theory is required as to what a directory service is all about and how you can benefit from using one.
In essence, a directory is little more than a repository for information - a database. But, unlike other databases, the information in a directory is specialised, relating primarily to the users of a network or applications and the resources available to them. A directory also has a number of services and utility programs associated with it - collectively referred to as the directory service - to manage the information held in the repository and provide users and client applications fast access to the data as and when requested. For example, the Microsoft directory service will typically be used to authenticate users when they log on to a network and to identify the shared servers, files and printers they're allowed to use.
Previously, this was all done in Windows NT using a flat, Registry-based file system referred to as SAM (Security Account Manager). AD improves on this with a hierarchical database that, like all directories, is server independent. Rather than logging on to several servers in turn, you only have to log on to the single, network-wide AD service to potentially access all the resources on the LAN.
Yes, NT domains can do that already, but, as anyone who administers a Windows network will tell you, NT domains are severely limited. This is especially true when it comes to handling large numbers of servers and their users. Even on quite small networks, you're likely to end up with lots of separate domains requiring complex one-way 'trust' relationships to enable users in one domain to access resources in another.
A directory service like AD can handle large networks used by millions of users, with the option of spreading the repository information about and holding it on several servers. This makes for a more robust and fault-tolerant system, plus the local directory copies improve performance on a large network. Keeping the copies updated can be a problem, but all directory services, including AD, offer built-in replication facilities to handle this for you.
Information in the directory can be extended and used by other applications. The latest version of Exchange Server uses AD to store email addresses and other information, while many e-business applications use the directory to distinguish between different types of customer and their preferences.
Lastly, directories support standards-based access to the information they hold. The most important of these is LDAP (Lightweight Directory Access Protocol), which is supported by AD and virtually all other directory products. As a result, any LDAP-enabled application should be able to access data managed by any LDAP-compatible directory service, including AD. Or at least that's the theory.
Installing Active Directory
The good news is that AD is included with all server versions of Windows 2000, and there are no special hardware requirements. That said, the primary domain controller (AD still refers to domains and domain controllers) will need plenty of memory and the main system volume has to be formatted with NTFS, if it isn't already. A significant amount of disk space is also required for the repository, especially on a large network.
Currently, a Microsoft Jet database is used to support the directory. This enables the repository to be indexed and for resources to be located quickly, but it does require a fair amount of room. The default folder for the database (%systemroot%/ntds), for instance, starts out at just over 40Mb, growing rapidly as objects are added and security rights defined. The log files are also stored here.
One other complication is that AD isn't loaded by default. Instead, you're prompted by the Configure Your Server Wizard to install it once the operating system is up and running. This starts when you first log on as the administrator and is used to configure a range of optional extras, including AD and the bundled DHCP and DNS servers.
You'll need the Windows 2000 install CD plus Service Packs, but the install Wizard does most of the hard work for you, which is just as well because the underlying technology is quite complex. Most of it's pretty dull, but one important consideration is a dependency on DNS. This allows AD to use familiar, Internet-style 'company.com' naming rather than the standard X.500 names used by other directories. A DNS server that supports dynamic updates is required. Fortunately, the Wizard checks to see if it can find one, prompting to install the bundled Windows 2000 implementation if it doesn't. It will also configure DNS with the domain names you decide to use, which saves having to set up the records manually.
You don't have to reload the operating system to promote a Windows 2000 server to a domain controller, which you do with NT. Moreover, existing NT domain servers can be integrated into AD without having to upgrade to Windows 2000. However, integration and migration from NT are far from simple procedures, putting them beyond the scope of this article, so for now we'll assume a new, Windows 2000-only installation. If you're desperate for migration information, the best place to seek help is via the Microsoft Web site and the Windows 2000 Resource Kit.
Management Console
As with most things to do with Windows 2000, once installed AD is managed using snap-ins to the MMC (Microsoft Management Console). The requisite snap-ins are loaded as part of the AD setup process - management of local users and groups are disabled by the Setup Wizard. The easiest way of accessing the new snap-ins is from the Start | Program | Administrative Tools menu, with three options as in Table 1.
Like all MMC snap-ins, you get the same familiar interface, with two panes displayed. On the left, the scope pane shows the directory tree and the objects it contains (see Root and branch for details), and this can be expanded, collapsed and displayed, just like folders and files in Windows Explorer. On the right is the separate results pane where selected objects and their properties are shown.
Clearly, the snap-in you're likely to be most interested in is 'Active Directory Users and Computers', as it's from here that users and their access rights to network resources are defined.
What you see depends on how the directory has been set up, but on the first domain controller a number of special system containers will have been created, the more important of which you'll find described in Table 2.
These are a good starting point, but in practice you'll want to create new containers to reflect your organisation and its users. Plus, you're likely to need to set up new users and user groups, and define the printers, shared files and other resources they need to access.
Populating the Directory
For this workshop, we created a domain called pcpro.local and set up three OU (Organisational Unit) container objects to logically group our users and manage their rights. One of these we called 'admin' (admin.pcpro.local) for users allowed to administer parts of the directory. We then created a sales.pcpro.local OU for - you guessed it - sales staff, and editorial.pcpro.local for editorial users.
Creating the OU containers was straightforward and just a matter of either clicking the new OU icon on the console toolbar, or selecting 'New...Organisational Unit' from the right mouse menu. Likewise, it was easy then to add new users within each OU. Existing accounts were simply dragged from the default Users container, while new accounts were defined directly in much the same way as on an ordinary NT domain network.
User groups are created in a similar manner, with the option of creating groups specific to the local domain, or with more global rights across the domain tree. You can also delegate the right to manage particular OUs to either individual users or, a group of users, simply by selecting the OU concerned and choosing 'Delegate Control...' from the right mouse menu. Another Wizard then steps you through the process of choosing the users or groups to which control will be given, followed by the rights to be delegated.
It's also easy to define shared file objects from the MMC snap-in, although the shares themselves need to be created first using the usual Windows tools. Shared printers can also have directory entries created for them, with the added advantage that the directory entries will be created automatically by the Add Printer Wizard in Windows 2000.
On our domain server, we created a number of shared folders and printer shares, both on the domain controller server and others. We then started the AD Users and Computers snap-in and added directory entries to point to all these resources. By putting them in particular OU containers, we were able to reflect the logical rather than physical structure of our network.
This may seem a bit unnecessary, as it's possible to use the shares whether directory entries have been set up for them or not. However, there are advantages to the directory pointers, albeit only for users of Windows 2000 and XP systems, as those with earlier versions of Windows can't make use of AD directly.
One big plus is that Windows 2000 and XP users are able to locate resources through the directory quicker and more easily than by browsing using NetBIOS. This is especially important where users are physically distant from the servers and printers concerned. Instead of having to traverse slow WAN links to find resources, all that's needed is a quick local directory search. Added to this, it's possible to search for printers and shares based on the various attributes assigned to them in the directory.
For instance, if you needed to print a particularly complex document, you could search for printers with lots of memory, list colour printers for presentation slides, the fastest printers and so on.
What the user sees
Despite some big differences in the underlying technology when AD is deployed, not much actually changes at the user end of the equation. When logging on to our AD domain using a Windows 2000 Professional PC, we're presented with the same logon screen as for an NT domain. We can also continue to browse the network as normal, to locate shares and printers - just as on any NT or peer-to-peer Windows network.
The most obvious change, though, is a new Directory icon in the My Network Places folder, through which we can navigate the directory to locate our shared files and printers, using domains, OUs and other container objects.
It may not sound like much of an advance, but the directory information is all located in one place, ready-indexed for fast retrieval. As we've already pointed out, it's quick and easy to find resources no matter where they're physically located on the network. But equally important is the fact that the directory can be configured to reflect the logical structure of an organisation rather than the layout of the network itself and its constituent servers, printers and other devices. That too can offer advantages, not least being able to locate and use resources without having to know the names of the servers or networks to which they're attached.
And there's more
There are other benefits to implementing Microsoft's AD, such as making it easier to lock down user desktops through the use of Windows 2000 group policies. These can be defined and stored in the directory, making it possible to control users and their desktops across the entire network, all from one place.
Security can be enhanced too, with facilities within AD to store and use X.509 digital certificates, again with centralised management and control across the entire network. It's important not to forget that other applications can make use of AD, to store and access information beyond the simple resource data covered here. It's not the only directory in town, but there are lots of companies using it, even to support large e-business applications reportedly handling millions of individual users.
However, that's not to say that AD is for everyone. If you're happy with NT domains, there may be little to be gained in moving up to AD, especially as there's often a lot of hassle involved unless you're already migrating or planning to migrate to Windows 2000. It's also a complex technology to get to grips with. In this workshop, we've concentrated on the basics of installing and using a single domain controller, but it's more complicated for larger networks where multiple domains and domain controllers are required. Bear in mind too that if access to shared network resources is your main goal, then AD is very much a Windows 2000- and XP-specific service. Windows NT and 9x users can't be authenticated by the Microsoft directory, neither can they use it to locate shared network resources, at least not without a lot of effort.
There have also been the usual bugs and problems reported with the software, although last year Microsoft claimed that some 75 per cent of its corporate customer base was either using AD or in the process of deploying it. A second generation of the directory service is on its way as part of the forthcoming Windows .NET release. That promises the usual enhancements to performance, scalability and functionality, and may ultimately win over the remaining 25 per cent yet to try the delights of the Microsoft directory.
Active Directory Workshop
Local Articles
Software
Home