In part three of this four-part series, I’ll explain the differences among objects, object classes, and attributes. I will also cover Lightweight Directory Access Protocol (LDAP), on which the addressing scheme of Active Directory is based, and Active Directory Service Interface (ADSI), which allows the administrator to automate common administrative tasks, such as adding users and groups and setting permissions on network resources using Visual Basic or other programming tools.
It is easy to get confused by the relationships among object classes, attributes, and the objects themselves. Objects are created based on an object class. Attributes describe an object class. For example, there is an object class called Users. Fullname is an attribute of that class, and FBloggs is an object based on the object class, User.
When an object is created, it inherits all the attributes of its object class. Here’s where it gets really confusing: Object classes and attributes are also objects in Active Directory. Fortunately, most user interfaces hide this fact.
An object can be either a reference to something concrete or the actual information itself. For example, every bit of information about a user account is stored within Active Directory, but only a reference to a disk volume is stored in Active Directory. While the reference is not useful on its own, it is beneficial in locating the volume on the file server. When creating new object classes, carefully consider whether the object will store a reference to something external or whether all necessary information will be contained in the object’s attributes. While Active Directory is extremely convenient, it should not be used to store large amounts of information or information that changes constantly or is rarely used.
Whenever you add a user or a computer to Active Directory, you are creating an object. This process is often referred to as publishing, because it initiates a process of replicating the new information across all Active Directory servers in the domain.
Windows 2000 Server relies on Active Directory to store a great deal of useful information about users, groups, and machine accounts. This data is of particular interest to administrators because it will be the most commonly accessed part of Active Directory. The new user interface might not seem intuitive to administrators accustomed to previous versions of Windows NT, but, as with most things, the more you use it, the easier things will become.
User accounts are no longer managed using a dedicated utility (User Manager for Domains). Instead, administrators use the Active Directory Users and Computers MMC snap-in. The user accounts themselves have changed significantly as well. Windows NT 4.0 simply tracks the user name, full name, description, password, and a handful of other attributes regarding account information for each user. Windows 2000 Server takes advantage of Active Directory to extend these attributes. You can now use Active Directory to track a great deal of personal information about people, including phone number, address, manager’s name, and so on (although this additional information is optional).
Although similar to user groups in previous versions of Windows NT, Active Directory groups have some new features. The newest version of Microsoft Exchange allows groups to be used as e-mail distribution lists. To make this more useful, you can add e-mail accounts to the groups to allow distribution to users who are not members of the same Active Directory tree. You can also nest groups within each other. Doing so will greatly reduce the amount of time administrators spend managing users and groups.
In Active Directory, there are now three distinct types of user groups:
- Universal Groups will be the most commonly used type. They can contain users and other groups from anywhere in the forest and can be granted permissions in any domain, even in other forests if the relevant trust relationships exist. They are available only in native mode. An example of a universal group might be a virtual team. The memberships of such teams in a large company could be global, or forest-wide, with the team resources being similarly distributed. Universal groups could be used as a container in these circumstances to hold global groups from each subsidiary or department, with the team resources being protected by a single Access Control Entry (ACE) for the universal group.
- Global Groups are much the same as Windows NT global groups. They can contain only users and groups from the same domain. Global Groups are listed in the global catalog, but their membership list does not leave the domain.
- Domain Local Groups can be applied only to ACLs (access control lists) within the same domain but can contain users and groups from other domains, other trusted forests, and even trusted down-level domains. They are neither replicated outside the domain nor listed in the Global Catalog. Any of these types of groups can participate in domain security or merely function as a distribution list.
Windows 2000 Server provides many groups by default. These groups are called the built-in groups. Administrators can use these default groups for most purposes and can add their own groups as needed.
Systems that join a domain are automatically given a computer account in Active Directory. This is similar to adding a system to a Windows NT 4.0 domain. You can add systems to the domain even if they do not participate in domain security, however. For example, you can create a computer object for a UNIX system to help administrators track that system.
Lightweight Directory Access Protocol
The Lightweight Directory Access Protocol (LDAP) is a product of the Internet Engineering Task Force (IETF). It defines how clients and servers exchange information about a directory. Windows 2000 Server’s Active Directory uses LDAP versions 2 and 3.
You will need to understand the structure of distinguished names because you will be referring to them often in the course of administering Windows 2000. The distinguished name identifies each container from the very top down to the specific user object. A slash and an identifier separate each container. An example of a distinguished name is:
To simplify distinguished names, you can use relative distinguished names. The relative distinguished name of the previous example is cn=DBard, identifying the user name but not the context in which it resides. The context must be known already for the relative distinguished name to be an effective identifier.
Most tools do not display the distinguished name, however, but convert it to the form known as canonical name. For the above example, the canonical name would be:
User principal name
In Active Directory, each user account has a user principal name, or UPN, in the format<user>@<DNS-domain-name>. A UPN is a “user-friendly” name assigned by an administrator that is shorter and easier to remember than the LDAP distinguished name used by the system. The UPN is independent of the user object’s distinguished name, so a user object can be moved or renamed without affecting the user logon name. When logging on using a UPN, users no longer have to choose a domain from a list in the logon dialog box.
Users will rely on their user principal name to log on to their Windows 2000 systems. In other words, user principal names will replace the user names required by older Windows networks. Obviously, this helps the users by saving them the trouble of typing their distinguished names. It also benefits users because the user principal name will stay the same, even if administrators move or rename the underlying user account.
Active Directory Service Interface
Multiple directories in the organization pose complex challenges to users, administrators, and developers. 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?
Microsoft’s strategy for helping to solve these problems is the Active Directories Service Interface (ADSI). ADSI uses a set of Component Object Model (COM) programming interfaces that make it easier for customers and independent software offenders to build applications that register with, access, and manage multiple directories services with a single set of well-defined interfaces.
Administrators can write programs and scripts that use ADSI to read or write to legacy Windows NT 4.0 directories, NetWare NDS directories, NetWare 3 binderies, and LDAP directories such as Active Directory. Developers can even create applications that make use of directories at the customer’s site, without previous knowledge of the type of directory being used.
Using Visual Basic to gather a list of users, for example, is much simpler than in previous Windows operating systems. ADSI uses the Component Object Model, so almost any Windows development environment can immediately make use of the interface. Developers can now access Active Directory through the LDAP C API and through MAPI, although ADSI is the preferred interface.
One of the most familiar open programming APIs is open database connectivity (ODBC). ODBC provides open interfaces for relational databases, thus allowing developers to write applications and tools that will work with any database that supports ODBC. Because of the driving ODBC development of the community, every major relational database now supports ODBC. ADSI uses the equivalent of ODBC for directory services.
ADSI abstracts the capabilities of directory services from different network providers to present a single set of directory services interfaces for managing network resources. The standard ADSI objects are those found within multiple namespaces. The typical namespaces for ADSI are directory services for various network operating systems. Administrators and developers can use ADSI services to enumerate and manage the resources in a directory service, no matter which network environment contains the results.
ADSI makes it easier to perform common administrative tasks, such as adding new users, managing printers, and locating resources throughout the distributed computing environment. ADSI also assists developers in enabling the applications to connect with the central directory. Administrators and developers deal with a single set of directory service interfaces, regardless of the installed directory services.
The LDAP C API is defined in RFC 1823.
In part four, I’ll be concluding this series with a look at what administrators should consider when they’re planning to upgrade to Windows 2000.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.