ActiveXperts
Network Monitor

Product Overview

Built-in checks:

Download (.exe)

Brochure (.pdf)

Manual (.pdf)

Release Notes

Support

Knowledge Base

Forum

Contact Support

Purchase

Licensing

Pricing

Order now

Some quotes

Windows&.NET Magazine:
"Small,smart & very handy"

MonitorTools.com Review:
"Extremely easy to use,
great value for money!"

Windows Management

Introduction

Scripts Collection (1)

Scripts Collection (2)

WMI / ADSI / WSH

Windows 2000
Resource Kit

Miscellaneous

Download ActiveXperts Network Monitor 7.0 (6239 KB - .exe file)

Download Manual (653 KB - .pdf file)

ActiveXperts.com > ActiveXperts Network Monitor > Checks > ADSI Check

ADSI Check - Monitor Active Directory and other Directory Services

ActiveXperts Network Monitor includes a VBScript file called 'DirectoryService.vbs'. This script file includes functions for various ADSI operations.
ActiveXperts Network Monitor is designed to let operators write their own check routines and add them to the product. ActiveXperts has chosen VBScript as the scripting language to be used for this purpose because of its wide acceptance: VBScript is the most popular scripting language in Windows environments.

A VBScript function takes the following parameters:

File - UNC path of the VBScript file. The script should contain a function as specified in the Function name field. This function should return True (-1) in case of success, False (0) in case of an error, or (1) in case the result cannot be indicated( also called: 'Uncertain');
Function - The ADSI function name, for instance: CheckGroupMemberShip, or CheckAccountDisabled;
Parameter1 .. Parameter6 - Arguments to the function call; these arguments depend on the function you call. For instance, the 'CheckAccountDisabled' function requires two parameters: the Domain name and the Account name.
Advanced VBScript Settings - The ADSI function name, for instance: CheckGroupMemberShip, or CheckAccountDisabled;

Introduction to ADSI

It is common to find a variety of directories-many playing an administrative role-that are deployed within a single organization. These include network resource directories, such as an LDAP-based directory, Active Directory, Banyan StreetTalk, Microsoft Windows® operating system Directory Service, and Novell Directory Services, as well as application-specific directories, such as Lotus Notes, cc:Mail, or Microsoft Mail. Although a single directory for an entire organization is desirable, no product available today can fill this very large requirement.

Multiple directories in the organization pose complex challenges to users, administrators, and developers. These problems have limited wide-directory deployment. End users face multiple logons and a variety of interfaces to information across multiple directories. Administrators face the complexity of managing multiple directories. End users and administrators want application developers to use an existing administrative directory, but developers face a dilemma-which one should they use? Each directory offers unique application interfaces. Developers must choose a specific directory implementation or support multiple versions of their application. As a result, developers seldom use existing directory services.

Microsoft has a strategy for helping to solve these customer problems : the Active Directory Service Interfaces (ADSI). ADSI is a set of COM programming interfaces that make it easy for customers and independent software vendors (ISVs) to build applications that register with, access, and manage multiple directory services with a single set of well-defined interfaces.

One of the most familiar open programming APIs is Open Data Base Connectivity (ODBC). ODBC provides open interfaces for relational databases, thus allowing developers to write applications and tools that work with any database that supports ODBC. Because of the thriving ODBC development community, every major relational database now supports ODBC. ADSI is the equivalent of ODBC for directory services.

ADSI Objects

Active Directory Service Interfaces objects are COM objects that represent persistent objects in an underlying directory service. An Active Directory Service Interfaces object is manipulated using one or more COM interfaces. ADSI objects are divided into two groups: directory service leaf objects, and directory service container objects. A container object can contain other ADSI objects. A leaf object cannot contain ADSI objects. The division of an object type into a host and one or more dependent objects implements a logical grouping of properties and methods. This division does not necessarily reflect the structure of the underlying directory. The host and dependent object relationship should not be confused with the container and contents relationship-the former is a characteristic of ADSI, the latter a characteristic of the underlying directory.

ADSI Provider

An ADSI provider contains the implementation of ADSI objects and dependent objects for a particular name space. The figure below shows how clients are concerned only with getting and using interfaces on an object, and not with the details of where and how the software of an object is implemented.

Schema Management

ADSI provides predefined objects so that directory service manipulation can be uniform across name spaces. However, an ADSI object in any directory might have more functionality than that specified by ADSI. A directory might also contain objects that are not defined at all by ADSI. In addition, there are extensible directory services that allow their base schema to be modified and their objects to be arbitrarily extended by administrators and independent software vendors. Object extensions are handled by Schema Management ADSI objects. These objects are used to:

Browse the definitions of objects;
Extend the definitions of objects.

Schema management objects can be used to browse and modify the schema of a name space. These objects are:

Schema container object, which contains a given schema;
Class container object, which defines an object class;
Property object, which describes a property;
Syntax object, which describes a syntax that can be used in a property definition.

These objects are different from directory service objects like the User component, in that their properties are not subdivided into functional sets.
The schema container object is used to attach a set of object definitions to a part of a directory tree. Typically, each instance of a directory has its own schema. ADSI represents this by placing a schema container as a child of the directory root.

The picture above shows the typical layout. However, ADSI does not limit schema containers to this level of the tree. A complex directory might allow multiple schemas to exist in a directory instance. In that case, schema containers might be found in other parts of a tree. As shown in the picture below, there can only be one schema container in any given ADSI container.

The schema container itself is a tree that contains class, functional set, property, and syntax definitions. New classes and functional sets can be created in the container to expand the schema. Functional sets are defined separately from classes so that they can be used in multiple class definitions.

The class container object is used to define a class of objects that can be created in the directory. New classes can be derived from existing classes using the ADSI model.

The picture above illustrates how a class container object relates to other class objects, property objects, and syntax objects to create a definition of a class. A class object points to property objects, which point to the syntax that the property supports.

Caching

All ADSI objects provide two methods-GetInfo and SetInfo-to provide simple caching for properties. Operations that involve getting and setting properties occur in the cache.
A caller can obtain a property value from an ADSI object at any time after obtaining the object. The caller need not call GetInfo first. If the property has not been previously retrieved, the provider is responsible for retrieving and caching it to satisfy the request. Subsequent requests are satisfied from the cached value.
GetInfo is called to explicitly refresh the object's cached properties from the underlying directory. By calling GetInfo, the caller ensures that the property values are current as of the time of the GetInfo call. If the GetInfo method is executed after changes are made to the local object's cache but before the SetInfo method is executed, the changes are discarded. GetInfo allows the client to provide hints about which properties it uses so that the provider can optimize network access.
SetInfo is called to write an object back to the underlying directory. No changes are made to an object's properties within the directory until the SetInfo method is called.

Names

Objects that reside within a given name space are identified by a unique name. For example, files stored on a computer disk drive reside in the file system name space.

Directory service name spaces also identify the objects that they contain by unique names, which are usually based on the location in the directory where the object can be found. For example, in an Active Directory, a given object might have a name like this:
  CN=JSmith, OU=Sales, DC=ArcadiaBay, DC=Com

Different directory services use different forms for naming the objects that they contain. This makes dealing with different name spaces challenging, especially for developers, considering all of the different environments on which the code might be running. A goal of ADSI is to minimize the code's knowledge of an object's path so that programs can be name-space-portable. ADSI defines a naming convention that can uniquely identify an ADSI object in a heterogeneous environment. These names are called AdsPath strings. AdsPath consists of a provider's moniker (for example LDAP:, WinNT:)and the provider's specific path.

Examples of ADsPath strings are:

WinNT://REDMOND/jsmith, user see previous comment re: "WinNT"
    Identifies jsmith as a user in the Redmond Domain

WinNT://REDMOND/comp1, computer
    Identifies comp1 in the Redmond Domain

WinNT://REDMOND/comp1/alice
    Identifies alice as a local user on comp1 computer.

LDAP://OU=Sales, DC=ArcadiaBay, DC=COM
    Identifies an organizational unit in the Arcadia Domain

LDAP://exch01/O=Microsoft
    Identifies an exchange object on an exchange server

Introduction to Active Directory

WHAT IS ACTIVE DIRECTORY

Active Directory is a directory service. The term directory service refers to two things - a directory where information about users and resources is stored and a service or services that let you access and manipulate those resources. Active Directory is a way to manage all elements of your network, including computers, groups, users, domains, security policies, and any type of user-defined objects. It melds several NT services and tools that have functioned separately so far - User Manager for Domains, Server Manager, Domain Name Server - and provides additional functions beyond these services and tools.

Active Directory is built around Domain Name System (DNS) and lightweight directory access protocol (LDAP) - DNS because it is the standard on the Internet and is familiar, LDAP because most vendors support it. Active Directory clients use DNS and LDAP to locate and access any type of resource on the network. Because these are platform-independent protocols, Unix, Macintosh, and other clients can access resources in the same fashion as Windows clients.

The Microsoft Management Console (MMC) is used to implement and manage Active Directory. The goals of Active Directory are the same as those we identified in the discussion of domain models. The two most important are

Users should be able to access resources throughout the domain using a single logon.
Administrators should be able to centrally manage both users and resources.

Active Directory allows central control and decentralized administration of mixed NT 4.0 and 2000 Server domains. Clients can be 2000 Server workstations and servers, Windows 95, Windows 98, or any other system that has the Active Directory add-on installed.

Because Active Directory is a Microsoft product, most of this discussion focuses on 2000 Server’s implementation of Active Directory. Where applicable, we include information about how Unix can integrate with Active Directory.

FUNDAMENTALS OF ACTIVE DIRECTORY

In the world of Active Directory, clients and servers interact in the following manner:

If a client wants to access a service or a resource, it does so using the resource’s Active Directory name. To locate the resource, the client sends a standard DNS query to a dynamic DNS server by parsing the Active Directory name and sending the DNS part of the name as a query to the dynamic DNS server.
The dynamic DNS server provides the network address of the domain controller responsible for the name. This is similar to the way static DNS currently operates - it provides an IP address in response to a name query.
The client receives the domain controller’s address and uses it to make an LDAP query to the domain controller. The LDAP query finds the address of the system that has the resource or service that the client requires.
The domain controller responds with the requested information. The client accepts this information.
The client uses the protocols and standards that the resource or service requires and interacts with the server providing the resource.

Benefits of Using Active Directory in an Enterprise Environment

Active Directory is one of the main features that distinguishes 2000 Server from NT 4.0 and previous versions. This newest implementation of the directory services is a response to the often-stated, and possibly warranted, criticism that NT is not designed to be an enterprise-wide solution. In an enterprise environment, Active Directory provides the following benefits:

More fine-grained administration is possible. Instead of having many administrators with sweeping and widespread rights over all directories (as in User Manager for Domains), you may have administrators who have a great deal of authority over a particular directory or group of directories but few, if any, rights over other directories. Rights can be granted down to the attribute (object property) level.
By using the global catalog, you can query various attributes of objects. For example, a particular object - a user name - can be located by querying one of its attributes - say, last name.
Global groups and local groups have gone the way of the dodo bird (in a pure 2000 Server environment). Instead, you can create nested groups that can contain many levels of users with various individual rights and privileges.
You can create new object types. Standard object definitions include users, groups, computers, domains, organizational units, and security policies. Ten million objects per domain are allowed.
Trusts are, by default, transitive. If domain A trusts domain B and domain B trusts domain C, then domain A will trust domain C. However, as an administrator, you can deliberately not allow domain A to trust domain C or allow a one-way trust only.
Kerberos security is implemented for network authentication, which allows for greater security than the clear text or encrypted logons previously used.
Fault tolerance is greater. Each controller maintains a copy of the directory database and the replication topology is in a ring structure so that there are always two possible paths for replication.
Active Directory’s Class Store and Group Policy Editor (GPE) let users access and download applications to which they are entitled, regardless which machine they are sitting at. Active Directory’s Microsoft Installer (MSI) lets developers package applications for use with Active Directory.
A domain controller can be moved to another site or to another domain without having to reinstall 2000 Server.

Active Directory’s beauty is that it can scale up or down and functions equally well providing simple directory services or more complex levels of administration. Besides supporting LDAP, Active Directory supports HTTP.

Logical Domain Structure of Active Directory - Simple Objects

Active Directory is best understood from bottom to top. As an organization becomes larger and more complex, bottom-level units can be joined to make higher-level units. For example, domains can be joined in a hierarchical way to make domain trees, and domain trees can be joined with trusts to make domain forests. We look at the hierarchy of units (from bottom to top) in the following sections.

Simple objects include computers, groups, users, security policies, and user-defined objects. Objects have attributes, some of which are mandatory and some of which are optional. To view objects in 2000 Server Active Directory, click Start and select Programs, Administrative Tools, Directory Management.

Logical Domain Structure of Active Directory - Organizational Units

Organizational units (OUs) are a new object type within 2000 Server’s Active Directory. They are designed to reduce the number of domains in an organization. Ous are often used to replace domains and subdomains on systems migrating to Active Directory. Under NT 4.0, different departments in an organization are often structured as separate domains, but using Active Directory, these domains can and should be restructured as OUs, thereby flattening the domain structure.
OUs can also be nested, so that a section within a department can have its own OU within the department OU. Objects within OUs must be contained within one domain.

Logical Domain Structure of Active Directory - Domains

Domains group network objects and OUs into a unit with a security boundary. By default, security policies and settings don’t flow from one domain to another.

Logical Domain Structure of Active Directory - Domain Trees

Domain trees are a hierarchical way to group domains. All domains have, by default, a two-way trust arrangement with all other domains. The domains share a hierarchical naming structure with the child domain name appended to the parent name in the fully-qualified domain name.

Logical Domain Structure of Active Directory - Domain Forests

Domain forests are groups of domain trees. The domain trees within the domain forest don’t share a naming structure, but a two-way transitive trust is created among the root (top-level) domains in each domain tree. Because the domains within the domain trees are all joined with two-way trusts, in effect, resources become available to any user within the domain forest. Domain trees within the domain forest also share a global catalog.
The domain forest structure is particularly useful in this era of company mergers. If one company buys another company or if two companies decide to merge, an administrator doesn’t have to spend hours renaming and restructuring the domains within an organization. By typing DCPromo from the Run command on a 2000 Server and running the wizard, the administrator has the option of joining an existing domain to another domain to form a domain tree or joining an existing domain tree to another to form a domain forest. To see the domains, domain trees, and domain forests in the Active Directory namespace, click Start and select Programs, Administrative Tools, Domain Tree Management.

Physical Domain Structure

The logical domain structure and the physical domain structure don’t have to be the same. Active Directory lets you create sites to mirror the physical domain structure. Computers linked with high-speed, reliable network links can be grouped in one site, while computers linked with lower speed lines can be partitioned into separate sites.
Suppose that you have a department that contains several local subdepartments and several remote subdepartments connected with a slow link. A good logical partitioning would have the department as a domain and each subdepartment represented by an OU. The physical partitioning, however, would group the local domain and local OUs into one site and leave each remote subdepartment as its own separate site.

The physical domain structure is managed with the Active Directory Sites and Services Manager, which you access by clicking Programs, Administrative Tools.

Replication

Active Directory renders obsolete the notion of primary and backup domain controllers. With Active Directory, each controller has a copy of the directory and any controller can initiate and replicate changes. To avoid conflicts, each controller maintains a table of update sequence numbers (USNs) in its database. The tables identify the latest copy of the directory received from every other controller.

Replication can occur at several levels:

Within a domain
Within a site (intrasite)
Between sites

Replication within a domain is automatic and transparent to the administrator. USNs determine the most recent copy of the directory database, and timestamps are used only to break a tie.

You can configure intrasite replication by selecting the NTDS settings of a server (domain controller):

Right-click NTDS Settings, then select New NTDS Connection from the drop-down menu.
From the list of all the domain controllers within the site, select the one to which you wish to replicate, then click OK.
Name the connection in the next box - it’s a good idea to use a naming scheme that involves the name of the other domain controller - and click OK. The new connection appears in the right pane of the Active Directory Sites and Services Manager.
A default replication schedule is set automatically. To change the schedule, highlight the connector, and select Properties, Schedule to see a window.
To change the replication frequency for a time period, highlight the time period, then select one of the four options - None, Once per Hour, Twice per Hour, or Four Times per Hour. As an administrator, you may choose to replicate data between nonvolatile sites (sites where changes are infrequent) less often than the default of four times per hour. On the other hand, if changes on the site are frequent and bandwidth is plentiful, two to four times per hour may be appropriate. You may also stagger peak replication times for different connections - for example, making one connection replicate frequently between noon and 4:00 P.M. and another connection replicate frequently between 4:00 P.M. and 8:00 P.M. The possibilities are endless.

Policy Storage

Under 2000 Server, domain policy is no longer stored in the SAM, and local policy is no longer stored in the LSA. Instead, these policies are stored in Active Directory under Domain Policy Objects and Local Policy Objects, respectively. To see the policy objects for a domain, from the Active Directory Manager Advanced view select System, Policies. Domain Policy Objects store the following information:

Password policy - sets password policy for user accounts
Lockout policy - enables or disables a lockout policy for user accounts
Security descriptor for domain operations - specifies who can change Domain Policy property settings
Kerberos logon policy
Encrypting file system data recovery policy
Listing of the trusted Certificate Authorities

Local Policy Objects store the following information:

Auditing policy
Privilege policy or Administrative roles - specifies which privileges are associated with which accounts
Local roles - specifies which accounts receive domain SIDs in their token
User rights policy - sets local user and group rights

By default, all machines in a domain use the default local policy on the domain controller unless they have their own local policy.

Logon and Authentication

Three authentication protocols are supported in 2000 Server - Kerberos version 5, SSL/TLS (Public key authentication), and Windows NT Lan Manager. The three protocols are supported by the Security Support Provider Interface (SSPI) API.

Kerberos 5 is the primary protocol for secure authentication. It is installed by default as a service on 2000 Server domain controllers, and it is installed by default as a client on 2000 Server member servers and workstations. The advantages of Kerberos are many:

To log onto a remote server within a domain, a 2000 Server server doesn’t have to requery Kerberos. It can perform its own authentication procedure instead.
One server can authenticate to another server on behalf of a client. For example, a server located in one domain can send security credentials for a domain client to a server in another domain.
Kerberos 5 is used in many platforms, including some Unix platforms. 2000 Server’s version of Kerberos complies with RFCs 1510 and 1964.
Both client and server are authenticated during a Kerberos session.

Under 2000 Server, a domain logon using Kerberos takes place as follows:

C1, the client program, contacts the Local Security Authority Sub System (LSASS) using the winlogon sequence (Ctrl+Alt+Delete). (LSASS and the SSPI are integrated.)
Password and Identification (the session key) are sent from LSASS to the Kerberos authentication library.
The library requests a ticket-granting ticket (TGT) from the nearest Active Directory Key distribution center (KDC). The TGT is encrypted with the hashed password from step 2.
If the request is granted, a TGT is returned to the library. The library uses that ticket to obtain a ticket to the client workstation at which the user is sitting and then extracts SIDs from the ticket to pass back to the LSASS.
LSASS then creates the access token, which includes SIDs and privileges. All processes that the user executes use this access token as in NT 4.0 and earlier.
If the client wishes to access a network service, Client Runtime checks the ticket cache in the library for a ticket to that server. If found, the ticket is sent to the server. If not found, C1 sends the original TGT (obtained from the login process) back to the KDC and receives in return a new ticket. This ticket is appended with the session key and stored in the KDC for future use.

Local logon takes place using the older mechanism, MSV1_0, also known as NTLM.

Kerberos is not, by itself, a public key authenticator. Instead, it is a three-sided shared-secret authenticator. The three sides are the client (C1), the KDC, and the server (S1). Microsoft plans to expand Kerberos to allow public/private key encryption. Under this model, the client (user) may obtain a ticket only if it has an X.509 version 3 certificate stored in its own User Object within the Active Directory. The user requests a ticket by querying the Active Directory for a public key certificate (by using his or her private key). If Kerberos locates the public key certificate, the Kerberos service issues one ticket for the user, and that ticket is used to issue the initial ticket granting ticket (TGT) described above.

When the client wishes to access another server on the same domain, the server can verify the client ticket without accessing Kerberos. Kerberos gives the server encryption key to the new server, which the server can use to decrypt the ticket. When the client wishes to access another server outside the domain, the authenticating servers contact the Kerberos service on that domain on behalf of the client using the following steps:

Client requests access to a resource in another domain.
Kerberos service in the requesting domain issues a referral ticket for the new domain to the client.
The Kerberos client sends the ticket to the Kerberos service on the new domain.
The Kerberos service on the new domain issues a new ticket valid for the new domain but identifying the requesting domain.
If the original client is a non-Windows client hosting Kerberos version 5, it can be authenticated by a 2000 Server, but some values may be lost. If this happens, the Kerberos service still attempts to match the name on the ticket with an NT user account or a specialized account set up for this purpose.

For Internet connection and smart cards, the SSL/TLS protocol is used. Based on public key authentication, X.509 version 3 certificates are either given by a Certificate authority such as Verisign or issued by the network’s own certificate server.
For machines running NT 4.0 or earlier, Windows NT LAN Manager was the authentication protocol. It will continue to provide authentication to or from computers running these earlier releases as long as they are present in the network.

Access Rights - Delegation and Distribution

Under 2000 Server, Active Directory stores not only system policy information but also all security information related to the objects contained within Active Directory. The security information, which is contained within a property known as the security descriptor, includes

The object’s owner
Group memberships
Access Control List (ACL)

Within the ACL are Access Control Entries, each containing the security principal (which is a user, group, or computer), and the type of access allowed. The ACL can contain both ACEs that refer to the whole object and ACEs that refer only to the properties of the object. In this way, permissions and rights can be assigned on a more refined (even property-by-property) basis.

Under 2000 Server, child objects within the domain inherit access permissions from their parent objects unless otherwise configured. This inheritance can be both a blessing and a curse. Alistair G. Lowe-Norris makes a very important point regarding inheritance in his article - Managing Permissions for NT 5.0’s Active Directory - (Windows NT Magazine, July 1998). In the article, he explains that if you deny read access to a container object (let’s say an OU) for a particular group of users and accidentally leave the “Apply these permissions down the tree” box checked (the default), all objects in this OU aren’t visible to this group. To undo the damage, each OU must be examined to reinstate this permission - a daunting task if the OU contains many objects.
To see the rights and permissions for a particular object, open the Active Directory Service Manager within 2000 Server, select the object (let’s say a domain) from the tree in the left pane, then select Properties from the drop-down menu. In the Properties dialog box, switch to the Security tab. Highlight the group or user for which you wish to see permissions. Several permissions show up on this page; you can see the rest by clicking Advanced. To see further information, highlight the group or user on this page - let’s use ForeTell\Authenticated Users - then click View/Edit The Object tab displays permissions for the group or user on the object itself. The Properties tab displays permissions for the group or user on the properties of the object (and any child objects). If these permissions are changed, the changes are, by default, propagated down the tree (but within the domain). Like NTFS permissions and user rights under NT 4.0, permissions under Active Directory are cumulative, except for the Deny permission (like No access under NT 4.0), which overrides other permissions. If a user belongs to a group that has permission on a resource and the user is nested within a group that doesn’t have permission on the same resource, the user is denied access to that resource.

MIGRATING TO WINDOWS 2000 SERVER

Before the Migration

Preparing for 2000 Server is primarily the task of preparing for Active Directory.

Domain Flattening

One of the first suggestions is to flatten your organization - into one NT domain if possible. Many of the reasons for having more than one NT domain, such as the master domain/resource domain model, in which the resource domain trusts the master domain but the master domain trusts no other domains, disappears under 2000 Server. For example, instead of having two domains - a master and a resource domain - you could reconfigure the domains into OUs with exactly the same rights and permissions as those in your domain model.

Of course, flattening your organization domain structure during the period just before receiving 2000 Server is a little easier said than done. Recall from Chapters 3 and 4, that under NT 4.0 a PDC or BDC can’t be reconfigured as a PDC or BDC for another domain. NT must be completely reinstalled to make the change. Member servers and NT workstations can be transferred to a new domain, but even that is a headache if you have more than a few workstations (and fewer administrators than you need).

Standardizing on TCP/IP and DNS

As we mentioned before, Active Directory uses DNS as its locator service, and where there’s DNS, there must be TCP/IP. Ideally, TCP/IP should be your only protocol, but if that’s impossible, it should at least be the default. Your organization should aim to eliminate NetBIOS applications completely - another task that’s easier said than done. Fortunately, until the network has completely migrated to 2000 Server and Active Directory, it is still possible to support NetBIOS applications. Until your migration is complete, however, administrators must continue to use LMHOSTS and/or WINS to support those applications that use NetBIOS.

Object Identifier

Active Directory has an extensible schema. This means that as an administrator, with appropriate permissions, you may create new object classes and attributes specific to your organization. To do so, however, you need an Object Identifier (OID). An OID is equivalent in function to a CLSID (or GUID) for an ActiveX control. Each one must be unique, and therefore they must be issued by a standards organization - in the United States, it’s the American Nation Standards Institute (ANSI). Organizations receive (for a fee) a root OID that they then divide into branch IDs - a process similar to receiving a network number and subnet mask that a company uses to assign IP addresses.

PC Upgrades

Migrating to 2000 Server and Active Directory has a downside - more memory. To install 2000 Server on a server, Microsoft recommends a Pentium Pro with at least 128 MB of RAM and a 2 GB hard drive. The upside is that all workstations and servers don’t have to migrate immediately, but some features won’t be present until all computers are enabled for the Active Directory.

Migration

Each domain model has its own migration issues. Below we look at the most important ones for each model.

Single Domain

For many organizations, the single domain model is more than sufficient. If your network is currently configured as one NT domain, your job is basically complete. Once you receive 2000 Server, you may wish to subdivide your organization into OUs to provide more detailed control of your rights and permissions.

You can perform a single domain migration to 2000 Server and Active Directory (according to the Microsoft white paper Planning and Migrating to Active Directory) in the two ways:

Upgrade the PDC to 2000 Server first. Install Active Directory on this PDC, then install 2000 Server and Active Directory on at least one other domain controller (for fault tolerance). Upgrade other servers and workstations to 2000 Server and/or the Active Directory client software. To add an extra level of security, before migrating, synchronize one BDC with a PDC, then take the BDC off line. If problems occur during migration, you can bring the BDC back on line and promote it to an NT 4.0 PDC. You can then start again.
Take the PDC off line, bring it into a Lab and build the 2000 Server/ Active Directory network from there, adding workstations and servers as the configuration stabilizes. Until you tell the system that the migration to 2000 Server is complete, there is backward compatibility; NT 4.0 clients can continue to be added.

Master and Multiple-Master/Resource Domain

As we mentioned earlier, OUs can replace many of the functions of domains. Where possible, you should group the OUs into one domain for the following reasons:

Fewer domains make for a lighter administrative burden.
Querying is faster and more efficient. The global catalog can be used only for those attributes that are kept within the global catalog database. Therefore, if you are searching for an object located in another domain tree within the same domain forest and the attribute is not in the global catalog, it won’t be found.
Sometimes the reason for a multiple-master/resource domain arrangement is that the number of users within one NT 4.0 domain is limited to approximately 20,000 users. Active Directory, on the other hand, supports up to 10 million objects (which may be computers, users, groups, or OUs).

Microsoft’s white paper entitled Planning and Migrating to Active Directory contains a step-by-step approach to migrating from a master/resource model to a single domain with OUs. The following procedure is based on the section "Merging Second-Tier Domains into Master Domains."

Migrate the Master Domain to 2000 Server and install Active Directory on at least one PDC in this domain.
Create OUs based on the existing domain structure. The master domain will become one OU, while the resource domain will become another OU. Further divide these OUs if desired.
Upgrade resource domain PDCs to 2000 Server and Active Directory. Don’t move these PDCs from the resource domain yet.
Move member servers from the resource domains to OUs in the master domain. Local groups created on the member server move with the server. The administrator of the master domain can use both NetBIOS and Active Directory publishing to advertise a resource’s existence.
Move the resource domain local groups to the master domain. Normally, permissions are not preserved when domain local groups are moved to a new domain. However, Active Directory actually copies security principals that retain the old SID and append the new SID. When the logon service builds the access token, both SIDs are added to the token, thereby ensuring a link between the SID in the ACL and the new SID.
Move workstations on the resource domain to the master domain. If the workstations are to participate in Active Directory, they must first be upgraded to 2000 Server (if an NT workstation) or have special client software installed (if Windows 95/98).
Delete the resource domain either by turning off domain controllers in the resource domain or by moving them to the master domain. Domain controllers in 2000 Server, unlike those in NT 4.0, can be moved from one domain to another as long as both domains are Active Directory domains (which means that Active Directory is installed on at least one domain controller in each domain).

Single Domain

The complete trust model, in which a two-way trust is set up among all domains, is the most flexible but also the most difficult to administer. Everyone potentially has access to everything, and this access has advantages and disadvantages. It is up to you as the administrator to set the individual file and directory permissions so that highly confidential information (directors’ salaries, for example) can’t be accessed by all. Of course this is true with any network, but having the one-way trust can sometimes add an extra layer of protection above and beyond user rights and permissions.

Migrating a complete trust domain doesn’t differ greatly from migrating a master/resource domain. If possible, everything should be compiled into one domain or at the very least a domain tree. By pretending that one of the domains is the master domain and the rest are resource domains, the resource domains can be collapsed into the master domain in the same manner as outlined in the previous section.

If geography, network size, or company organization requires forming several domains, some of the domains could be labeled masters and the resource domains collapsed into the masters in the same fashion. Be aware that this procedure requires performing the migration many times. Two-way trusts are the default, but it’s possible to change those to one-way trusts. Of course, if company policy dictates that the domain structure remain as is, the same method could be used as is used for a single domain model - just many times.

Mixed Environments

It’s generally the case that the average enterprise networking environment consists of more than one operating system. It’s even more likely, as 2000 Server becomes available, that companies will choose to retain their NT 4.0 servers and workstations and integrate them gradually with the 2000 Server environment.

NT 4.0 and 2000 Server Mixed Environments

For purposes of discussion, we’ve classified Active Directory installations as pure and mixed. Depending on the classification, certain features will or won’t be present.

Pure 2000 Server/Active Directory environments - All domain controllers have 2000 Server and Active Directory installed. Workstations and clients may or may not be Active-Directory enabled. If they are, they will be able to participate fully in the Active Directory domain. If not, the controllers will appear as NT 4.0 controllers, and the data will appear as a flat store. Once all controllers have been upgraded, you must explicitly designate the network as a pure 2000 Server/Active Directory domain. From that point on, downlevel replication (NT 4.0 and below) ceases, and it’s impossible to add downlevel controllers. All controllers act as peers.
Mixed NT 4.0 and 2000 Server/Active Directory environments - The PDC must have 2000 Server and Active Directory installed. BDCs may have either NT 4.0 or 2000 Server installed. Clients may or may not be Active-Directory enabled. Unfortunately, the mixed NT 4.0/2000 Server environment doesn’t support two important features of Active Directory: multimaster replication and nesting of groups. Multimaster replication lets you change user account information from any domain controller because the controllers act as peers under 2000 Server. A mixed environment still has at least one PDC with one or more BDCs, and user account changes can be made from the PDC only. The group nesting feature lets administrators create smaller groups within larger groups to any level they wish. Furthermore, in 2000 Server, the notion of local groups and global groups is gone. In a mixed environment, however, this system persists.

ACTIVE DIRECTORY DESIGN OVERVIEW

The architecture of Active Directory integrates Windows 2000 networking and domain security with a native LDAP directory, framed in the DNS domain namespace and using DNS location services. Because Active Directory natively uses LDAP, it incorporates significant aspects of the X.500 models and general methodologies. However, the need to integrate support for NT domains and Microsoft's decision to leverage DNS as the fundamental namespace have led to some divergences from “classic X.500”—and an interesting finished product.

Yet before we get into detailed descriptions, let's take a look at an analogy between terms used in Active Directory and X.500. Active Directory is a networking-focused directory service, designed to manage distributed Windows 2000 networks. Active Directory runs as a discrete service within the Windows 2000 security subsystem, supplying a client/server set of directory services via a structured information model, and providing access to network resources in a logically unified namespace.

AD uses domain controllers (DCs) to provide DSA-like capability—handle client logon, queries, return results, and referrals to other DCs. The client-side software for AD is built in to Windows 2000 and available as an extension for Windows 95/98 clients.

AD leverages the X.500/LDAP data model with directory objects comprised of a series of properties. The AD schema, however, goes well beyond the base X.521 object set with its wide range of classes, attributes, and syntax.

The AD namespace uses DNS to define one or more Domain Trees—a tree of domains that comprise a contiguous DNS namespace. AD uses a forest to contain multiple disjoint (noncontiguous) domain trees.

A domain in AD is also a functional subdivision of the AD database with each partition stored on the DCsfor each domain. AD abstracts replication management to sites, which automatically performs local replication and allows configurable replication for local and remote DSAs. AD uses multi-master replication with flexible single- master operations for schema (and other) updates.

LDAP and Active Directory

Microsoft implements LDAP (version 3) as Active Directory's core directory protocol. Active Directory is constructed as a native LDAP directory, handling LDAP queries directly and without translation. LDAP provides a rich query capability for directory information access, supplying access to all directory functionality, including managing the schema and query scoping. Active Directory includes an LDAP-based change history interface, which can be used to link to and synchronize with other LDAP directories.

In their strategy white paper, “Comparing Microsoft Active Directory to Novell's NDS,” Microsoft describes Active Directory as an inherently scalable LDAP server product that can contain over a million objects in a single partition. (In other documentation, Microsoft describes testing the AD storage subsystem with 1.5 million objects.)

DNS and Active Directory

Active Directory integrates DNS at its core, using DNS for naming and location services. The use of the DNS structure for domain names is a significant change from the NetBIOS name structure used in previous versions of NT.

Domains in AD are structured as DNS domain names while retaining their NT domain security properties. The top of the domain tree can be (and commonly is) the internal or external organization name in the DNS namespace (for instance, mythical.org). Alternatively, for businesses without an assigned DNS name and who are not connected to the Internet, an arbitrary DNS name can be selected.

The integration of DNS allows Active Directory to merge with DNS-based networking environments. Active Directory is integrated with an RFC 2136-compliant version of Dynamic DNS (DDNS) to provide dynamic updating of DNS zone entries. Active Directory does not require that you run Windows 2000 DNS, although it is highly recommended. Using DDNS, Active Directory servers can do the following:

Dynamically publish SRV records containing information about their services, ports, and IP addresses;
Periodically check their DNS registrations to ensure correct IP address assignment;
Update the DNS records as servers and services become available or unavailable.

Active Directory adds multiple SRV records to the base DNS configuration, denoting various servers, services, protocols, and ports used in Active Directory operations. The SRV records are used by Active Directory clients to locate the Global Catalog and DCs for network logon and authentication.

DNS provides the core location services, and therefore, correct DNS configuration is essential to effective Active Directory network operations. DNS has the critical role of locating domain controllers and key services in the Active Directory namespace. Clients use DNS as the location service that connects them to the DC containing the needed directory information.

ACTIVE DIRECTORY MODELS

In their white paper called the “Active Directory Technical Summary,” Microsoft defines the architecture of Active Directory as subdivided into a number of primary components and several models. Although these models do not have the depth or focus of the X.500 models, they can nevertheless be useful in assessing Microsoft's design intent for Active Directory.

The Active Directory models are as follows:

Data model—Microsoft describes the Active Directory data model as deriving its origins from the data model referenced in the X.500 specifications. In Active Directory, the directory is an information datastore containing objects that represent network resources and users (and a wide range of information). Each of the objects in the Active Directory datastore is defined by the schema that specifies each object class, and the optional and mandatory attributes for that object class, its container class, and as well as permissible attribute syntax;
Security model—The Active Directory security model fully participates in the Windows 2000 security infrastructure and utilizes access control lists (ACLs) to protect directory objects, where user permissions to access objects are validated against the object's access control entries (ACEs) by the Windows 2000 access validation routines. Active Directory employs multiple security technologies and protocols, using Kerberos for authentication and transitive trusts, SSL/PCT for encryption, and SAM for authentication with down-level systems;
Administration model—The administration model implemented in Active Directory supports finely detailed delegation of administrative tasks. Active Directory allows the authorization of selected people to perform specific sets of actions on designated sets of objects or attributes within a specified subtree or organizational unit. The capability to specify ranges of actions that can be performed and to set the scope of the subtree in which the operation can be performed provides for delegation of appropriate network authority over the specified tasks;
Replication model—In their Windows 2000 SDK, Microsoft also defines a replication model. They define this model as “multi-master loose consistency with convergence,” where a directory will be comprised of a system of replicas, and changes made at any replica will be propagated to all others. The directory content will only be loosely consistent because the replicas will not necessarily be the same at any given point in time. Convergence occurs after all changes are propagated to all replicas, and the directory information is consistent between all replicas.

ACTIVE DIRECTORY OBJECTS AND SCHEMA

At a basic level, the Active Directory objects and properties are fairly consistent with X.500, but the approach is also somewhat different. Only two types of container objects are available in the primary management tool, for example—a container is either a domain (with all the related contingencies) or an OU.

Unlike X.500, Active Directory defines a substantial number of objects—more than 125 structural objects in the base schema alone. Although the range of objects may seem extensive, you are actually only presented with a handful of context-appropriate classes to select from when you create an object.
As just mentioned, AD supports only two administrator-created classes of container objects in the AD tree: domain and OU. The X.521 base container object classes Country, Locality, and Organization are not supported in the tree by Active Directory, which uses the domain component objects instead. There are many similarities between the domain object and the OU. They both provide containers for directory structure, administrative rights can be delegated at either level, and a group policy can be attached to either object. They differ significantly, however, in their structure and usage:

Domain—The domain object is one of the most critical in Active Directory, providing the basic tree structure, as well as security and partitioning boundaries. A domain object is created (from the domainDNS class) automatically when DCPromo is used to create a new domain. To guarantee the continuity of the DNS namespace, domain objects can only be created subordinate to other domain objects. Attributes for this class primarily consist of SAM information in addition to the basic properties assigned to all classes. In fact, the only attribute not from Top or one of the SAM classes is the dc attribute, which is used as the naming attribute of the class. The definitions of the two auxiliary SAM classes, SAMDomain and SAMDomainBase supply the properties necessary to support NT domain functionality;
OU—The Active Directory OU is similar to an X.500 OU in that it provides a container for objects without any inherent security or partitioning boundaries. OUs are used to subdivide the contents of a domain into smaller units for administrative purposes. An OU can be contained by either a domain or another OU.

From an overview perspective, the AD schema is similar to the schema defined in X.500. Although the class and attribute definition details vary, the underlying model is the same.

AD stores its schema as objects in a schema container subordinate to the configuration node. There is one schema, and therefore one schema container, per forest. The configuration partition (and, therefore, the AD schema) is replicated to every DC in the forest. The default DN of the schema container is as follows:

cn=schema,cn=configuration,dc=mythical,dc=org

By storing the schema in the directory, Active Directory allows applications and developers to easily access and modify schema information. This access to schema information provides necessary support for directory-enabled applications, and allows application to verify and extend the schema. AD also supports dynamic schema updates, allowing applications to use their schema extensions immediately.
Class definitions in Active Directory specify valid objects, the information used to create the object, and valid object relationships. Class definitions define the structure rules, as well as mandatory and optional attributes. Each class is derived from its parent object class (and, therefore, all objects are ultimately derived from top). Every object is created as an instance of its specified class.

Active Directory uses the following fields in the class definitions:

Class Type—The class type defines the type of object (structural, abstract, or auxiliary) and the designation as a container or not;
X.500 OID—This is the object identifier (assigned by industry organizations such as ANSI);
Category—This field specifies the LDAP name for the object class. AD LDAP agents and AD clients use the LDAP name to read or write the class;
Parent Class—Identifies the parent class definition from which this class inherits portions of its definition (like an X.500 superclass);
Auxiliary Class—Lists additional classes from which this class derives some portion of its definition;
Possible Superior—Lists the types of objects this object class can reside within;
Common Name—Identifies the attributes that will be used to name instances of this object class;
Mandatory Attributes—Contains a list of properties for which the object instance must have values;
Optional Attributes—Additional properties for which an instance of the object class may or may not have values.

It should be noted that the preceding list is what is viewable from the Active Directory Schema snap-in. The system uses other fields, but these are not visible in the schema browser. Other schema options control whether instances of a particular class are displayed for browsing. A default security template (ACL) can also be associated with each class.
Attribute definitions describe the properties of objects. Each attribute defines the specific sort of information it contains and can be single-valued or multi-valued.

Attributes can be added to the AD schema, but once added, they cannot be modified. Attributes that have been made part of the schema via extension can be removed so long as they are not currently being used in any object class definition. Attributes that are part of the standard AD schema cannot be removed from the schema.

The attribute definition in the AD schema consists of these fields:

Description—The descriptive text that explains the purpose of the attribute;
Common Name—The LDAP CN is the name by which the attribute is referenced in the class definition;
X.500 OID—The object identifier assigned to the attribute;
Syntax and Range—Identifies the syntax to be used for a particular attribute, and allows for entry of minimum/maximum range values.

The syntax definitions specify the format of the data to be used within the attribute and matching rules.

Syntax ID—Uniquely identifies the syntax type—the value designated in the attribute Syntax field of the attribute definition;
Syntax Name—Descriptive name of the syntax;
Syntax Flags—Contains matching rules to be used when comparing values using this syntax.

The schema is managed through the AD schema objects. Extending the schema creates new objects representing class or attribute definitions. Extensions to the Active Directory schema can be implemented in a variety of ways:

The Active Directory Schema MMC snap-in enables administrators to directly alter the schema;
The schema can be extended programmatically using ADSI interfaces, MAPI, or the LDAP C API;
Schema extensions can also be performed via LDIF files.

Active Directory doesn't currently allow deletions from the schema, but objects can be disabled. The following conditions apply when disabling components of the AD schema definitions:

Classes and attributes with certain access categories' values cannot be disabled. The access category indicates the type of rights required to access AD information;
Disabling an attribute definition requires that no class definitions are using the attribute. If a class definition includes the attribute, the class must be removed or disabled, before the attribute can be disabled;
Disabling a class definition prevents new instances of the object from being created, but it has no effect on current instances of the class.