JETZT ONLINE BESTELLEN
Add to Cart
Active Directory
Designing, Deploying, and Running Active Directory

Fourth Edition Dezember 2008
ISBN 978-0-596-52059-5
858 Seiten
EUR45.00

Weitere Informationen zu diesem Buch

Inhaltsverzeichnis | Kolophon |


Inhaltsverzeichnis

	
Chapter 1: A Brief Introduction
Inhaltsvorschau
Active Directory (AD) is Microsoft’s network operating system (NOS), built on top of Windows 2000, Windows Server 2003, and now Windows Server 2008. It enables administrators to manage enterprise-wide information efficiently from a central repository that can be globally distributed. Once information about users and groups, computers and printers, and applications and services has been added to Active Directory, it can be made available for use throughout the entire enterprise to as many or as few people as you like. The structure of the information can match the structure of your organization, and your users can query Active Directory to find the location of a printer or the email address of a colleague. With Organizational Units, you can delegate control and management of the data however you see fit. If you are like most organizations, you may have a significant amount of data (e.g., thousands of employees or computers). It may seem intimidating if you are faced with importing all of this data into Active Directory and managing it, but fortunately, Microsoft has some very robust yet easy-to-use Application Programming Interfaces (APIs) to help facilitate programmatic data management.
This book is a comprehensive introduction to Active Directory with a broad scope. In Part I, we cover many of the basic concepts of Active Directory to give you a good grounding in some of the fundamentals that every administrator should understand. In Part II, we focus on various design issues and methodologies, to enable you to map your organization’s business requirements into your Active Directory infrastructure. Getting the design right the first time around is critical to a successful implementation, but it can be extremely difficult if you have no experience deploying Active Directory. In Part III, we cover in detailed management of Active Directory programmatically through scripts based on Active Directory Service Interface (ADSI), ActiveX Data Objects (ADO), Windows Management Instrumentation (WMI), the .NET Framework, and Windows PowerShell. No matter how good your design is, unless you can automate your environment, problems will creep in, causing decreased uniformity and reliability.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Evolution of the Microsoft NOS
Inhaltsvorschau
Network operating system, or “NOS,” is the term used to describe a networked environment in which various types of resources, such as user, group, and computer , are stored in a central repository that is controlled by administrators and to end users. Typically, a NOS environment is comprised of one or more servers that provide NOS services, such as authentication, authorization, and account manipulation, and multiple end users that access those services.
Microsoft’s first integrated NOS environment became available in 1990 with the release of Windows NT 3.0, which combined many features of the LAN Manager protocols and of the OS/2 operating system. The NT NOS slowly evolved over the next eight years until Active Directory was first released in beta form in 1997.
Under Windows NT, the “domain” concept was introduced, providing a way to group resources based on administrative and security boundaries. NT domains are flat structures limited to about 40,000 objects (users, groups, and computers). For large organizations, this limitation imposed superficial boundaries on the design of the domain structure. Often, domains were geographically limited as well because the replication of data between domain controllers (i.e., servers providing the NOS services to end users) performed poorly over high-latency or low-bandwidth links. Another significant problem with the NT NOS was delegation of administration, which typically tended to be an all-or-nothing matter at the domain level.
Microsoft was well aware of these limitations and needed to re-architect their NOS model into something that would be much more scalable and flexible. For that reason, they looked to LDAP-based directory services as a possible solution.
In general terms, a directory service is a repository of network, application, or NOS information that is useful to multiple applications or users. Under this definition, the Windows NT NOS is a type of directory service. In fact, there are many different types of directories, including Internet white pages, email systems, and even the Domain Name System (DNS). Although each of these systems has characteristics of a directory service, X.500 and the Lightweight Directory Access Protocol (LDAP) define the for how a true directory service is implemented and accessed.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Windows NT Versus Active Directory
Inhaltsvorschau
As we mentioned earlier, Windows NT and Active Directory both provide directory services to clients. Although both share some common concepts, such as Security Identifiers (SIDs) to identify security principals, they are very different from a feature, scalability, and functionality point of view. contains a comparison of features between Windows NT and Active Directory.
Table : A comparison between Windows NT and Active Directory
Windows NT
Active Directory
Single-master replication is used, from the Primary Domain Controller (PDC) master to the Backup Domain Controller (BDC) subordinates.
Multimaster replication is used between all domain controllers.
Domain is the smallest unit of partitioning.
Naming Contexts are the smallest units of partitioning.
System policies can be used locally on machines or set at the domain level.
Group policies can be managed centrally and used by clients throughout the forest based on domain, site, or Organizational Unit (OU) criteria.
Data cannot be stored hierarchically within a .
Data can be stored in a hierarchical manner using OUs.
Domain is the smallest unit of security delegation and administration.
A property of an object is the smallest unit of security delegation/.
Domain is a policy, replication, and security .
Domain is a policy and replication boundary. Forest is the security boundary.
NetBIOS and WINS are used for name resolution.
DNS is used for name resolution. WINS may be required for applications or legacy clients.
Object is the smallest unit of replication.
Attribute is the smallest unit of replication. In Windows Server 2003 Active Directory and above, some attributes replicate on a per-value basis (such as the member attribute of group objects).
Maximum recommended database size for the Security Accounts Manager (SAM) is 40 MB.
Recommended maximum database size for Active Directory is 16 TB.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Windows 2000 Versus Windows Server 2003
Inhaltsvorschau
Although the first version of Active Directory available with Windows 2000 was very stable and feature-rich, it still had room for improvement, primarily around manageability and performance. With Windows Server 2003, Microsoft has addressed many of these issues. To utilize these features, you have to upgrade your domain controllers to Windows Server 2003 and raise the domain and forest functional levels as necessary.
Windows 2000 Active Directory introduced us to the concept of mixed mode and native mode. This was a domain concept that indicated whether or not all domain controllers in a domain were Windows 2000 and could therefore use a new capability that wasn’t available in Windows NT. Switching from mixed mode to native mode was a purposeful configuration change made by the domain administrators.
Windows Server 2003 Active Directory further refined this by adding functional levels. It introduced both domain functional levels and forest functional levels. Like mixed mode and native mode, domain functional mode depends on the types of domain controllers in the forest. If you have all Windows Server 2003 domain controllers, you can switch Windows Server 2003 domain functional mode and gain access to many new functions. Microsoft also added new functions that could be used only if all domain controllers in the forest were upgraded to Windows Server 2003, so they added forest functional mode. When all DCs in the forest are upgraded, the enterprise administrators can increase the forest functional mode.
The difference between Windows 2000 Active Directory and Windows Server 2003 Active Directory is more evolutionary than revolutionary. While the decision to upgrade from Windows 2000 is a subjective one, based on your needs, Windows 2000 is in the extended support phase so you should definitely be considering migration to Windows Server 2008 if you are still running Windows 2000. On the whole, Microsoft added or updated more than 100 features within Active Directory during the Windows Server 2003 release, and we will now discuss some of the more significant ones.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Windows Server 2003 Versus Windows Server 2003 R2
Inhaltsvorschau
The release time frame for Windows Server 2008 was extended repeatedly, so Microsoft decided to release an interim update to Windows Server 2003—Windows Server 2003 R2. R2 includes Windows Server 2003 SP1 as well as a number of optional Active Directory add-on components. Some of these new optional components, such as Active Directory Application Mode (ADAM), are available via Web downloads, but Microsoft chose to package them on the R2 CD to make them available to a wider audience. In addition, some users question Microsoft’s commitment to software that is only available from its web site; making the components part of the Core OS dispels any doubts on Microsoft’s support position.
Service Pack 1 offers a considerable number of improvements for Windows Server 2003. As with Windows XP Service Pack 2, many of the changes are security-related, correcting issues in Internet Explorer and offering new firewall functionality, gives an overview of the Active Directory specific updates.
Table : Windows Server 2003 SP1 Active Directory enhancements
Feature
Description
Directory service backup
Special messages logged to the Directory Service event log if directory partitions are not backed up.
Additional replication security and fewer replication
Replication metadata for domain controllers removed from the domain is now removed. This enhances directory security and eliminates replication error messages related to the deleted domain controllers.
Install from Media improvements for installing DNS
New option to include application directory partitions in the backup media eliminates the requirement for network replication of DomainDNSZone and ForestDNSZones application directory partitions before the DNS Server is operational.
Updated tools
Newer versions of DcDiag, NTDSUtil, IADSTools.DLL, AdPrep, and other tools to aid in management, updates, and troubleshooting.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Windows Server 2003 R2 Versus Windows Server 2008
Inhaltsvorschau
Windows Server 2008 introduces substantial and, in some cases, complicated improvements to Active Directory. Perhaps the most important and well-known features are the introduction of Server Core and support for running Active Directory on Server Core along with the introduction of read-only domain controllers (RODCs). The differences between the fundamental Active Directory services in Windows Server 2003 R2 and Windows Server 2008 can again be considered evolutionary changes, as opposed to revolutionary. When evaluating your timeline to migrate to Windows Server 2008, consider the numerous new and improved features to aid your decision. Undoubtedly, one of the most compelling scenarios for upgrading to Windows Server 2008 Active Directory is for deployment into branch offices. A list of many of the key new features in Windows Server 2008 Active Directory are outlined in and will be discussed in detail throughout the remainder of this book.
Table : Windows Server 2008 Active Directory enhancements
Feature
Description
Read-only domain controllers (RODCs)
RODCs do not allow local writes and do not store passwords and other secrets by default. This feature adds a great deal of security to domain controllers in locations with questionable physical security.
Server Core support
Domain controllers can now run on a version of the Windows Server 2008 operating system that is substantially lighter and thus more secure.
Fine-grained password
Password policies can now be defined on a per user or group basis.
Administrative role
Users who are not domain administrators can be securely delegated administrative control of RODCs without providing access to Active Directory.
Read-only DNS
RODCs can host dynamic DNS zones and refer the updates to writeable domain controllers.
GlobalNames DNS zone
A new type of DNS zone which can help pave the way to migrating away from WINS.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
This chapter is a brief introduction to the origins of Active Directory and some of the new features available in Windows Server 2003, Window Server 2003 R2, and Windows Server 2008. The rest of the chapters in Part I cover the conceptual introduction to Active Directory and equip you with the skills necessary to gain the most from Parts II and III.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 2: Active Directory Fundamentals
Inhaltsvorschau
This chapter aims to bring you up to speed on the basic concepts and terminology used with Active Directory. It is important to understand each component of Active Directory before embarking on a design, or your design may leave out a critical element.
Data stored within Active Directory is presented to the user in a hierarchical fashion similar to the way data is stored in a filesystem. Each entry is referred to as an object. At the structural level, there are two types of objects: containers and non-containers, which are also known as leaf nodes. One or more containers branch off in a hierarchical fashion from a root container. Each container may contain leaf nodes or other containers. As the name implies, however, a leaf node may not contain any other objects.
Although the data in Active Directory is presented hierarchically, it is actually stored in flat database rows and columns. The Directory Information Tree (DIT) file is an Extensible Storage Engine (ESE) database file. This answers the question “Does Active Directory use JET or ESE Database technology?” ESE is a JET technology.
Consider the parent-child relationships of the containers and leaves in . The root of this tree has two children, Finance and Sales. Both of these are containers of other objects. Sales has two children of its own, Pre-Sales and Post-Sales. Only the Pre-Sales container is shown as containing additional child objects. The Pre-Sales container holds user, group, and computer objects as an example. Each of these child nodes is said to have the Pre-Sales container as its parent. represents what is known in Active Directory as a domain.
Figure : A hierarchy of objects
The most common type of container you will create in Active Directory is an organizational unit (OU), but there are others as well, such as the type called Container. Each of these has its place as we’ll show later, but the one that we will be using most frequently is the organizational unit.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
How Objects Are Stored and Identified
Inhaltsvorschau
Data stored within Active Directory is presented to the user in a hierarchical fashion similar to the way data is stored in a filesystem. Each entry is referred to as an object. At the structural level, there are two types of objects: containers and non-containers, which are also known as leaf nodes. One or more containers branch off in a hierarchical fashion from a root container. Each container may contain leaf nodes or other containers. As the name implies, however, a leaf node may not contain any other objects.
Although the data in Active Directory is presented hierarchically, it is actually stored in flat database rows and columns. The Directory Information Tree (DIT) file is an Extensible Storage Engine (ESE) database file. This answers the question “Does Active Directory use JET or ESE Database technology?” ESE is a JET technology.
Consider the parent-child relationships of the containers and leaves in . The root of this tree has two children, Finance and Sales. Both of these are containers of other objects. Sales has two children of its own, Pre-Sales and Post-Sales. Only the Pre-Sales container is shown as containing additional child objects. The Pre-Sales container holds user, group, and computer objects as an example. Each of these child nodes is said to have the Pre-Sales container as its parent. represents what is known in Active Directory as a domain.
Figure : A hierarchy of objects
The most common type of container you will create in Active Directory is an organizational unit (OU), but there are others as well, such as the type called Container. Each of these has its place as we’ll show later, but the one that we will be using most frequently is the organizational unit.
When you are potentially storing millions of objects in Active Directory, each object has to be uniquely locatable and identifiable. To that end, objects have a Globally Unique Identifier (GUID) assigned to them by the system at creation. This 128-bit number is the Microsoft implementation of the UUID concept from Digital Equipment Corporation. UUIDs/GUIDs are commonly misunderstood to be guaranteed to be unique. This is not the case; the number is just statistically improbable to be duplicated before the year 3400 AD. In the documentation for the GUID creation API function, Microsoft says, “To a very high degree of certainty, this function returns a unique value.” The object’s GUID stays with the object until it is deleted, regardless of whether it is renamed or moved within the Directory Information Tree (DIT).
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Building Blocks
Inhaltsvorschau
Now that we’ve shown how objects are structured and referenced, let’s look at the core concepts behind Active Directory.
Active Directory’s logical structure is built around the concept of domains. Domains were introduced in Windows NT 3.x and 4.0. However, in Active Directory, domains have been updated significantly from the flat and inflexible structure imposed by Windows NT. An Active Directory domain is made up of the following components:
  • An X.500-based hierarchical structure of containers and objects
  • A DNS domain name as a unique identifier
  • A security service, which authenticates and authorizes any access to resources via accounts in the domain or trusts with other domains
  • Policies that dictate how functionality is restricted for users or machines within that domain
A domain controller (DC) can be authoritative for one and only one domain. It is not possible to host multiple domains on a single DC. For example, Mycorp has already been allocated a DNS domain name for their company called mycorp.com, so they decide that the first Active Directory domain that they are going to build is to be named mycorp.com. However, this is only the first domain in a series that may need to be created, and mycorp.com is in fact the root of a domain tree.
The mycorp.com domain itself, ignoring its contents, is automatically created as the root node of a hierarchical structure called a domain tree. This is literally a series of domains connected together in a hierarchical fashion, all using a contiguous naming scheme. If Mycorp were to add domains called Europe, Asia, and Americas, then the names would be europe.mycorp.com, asia.mycorp.com, and americas.mycorp.com. Each domain tree is called by the name given to the root of the tree; hence, this domain tree is known as the mycorp.com tree, as illustrated in . You can see that in Mycorp’s setup we now have a contiguous set of domains that all fit into a neat tree. Even if we had only one domain, it would still be a domain tree, albeit with only one domain.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we’ve gone over the groundwork for some of the main internals of Active Directory. We covered such concepts as domains, trees, forests, Organizational Units, the Global Catalog, FSMOs, Windows 2000 domain modes, and forest and domain functional levels. We then delved into how groups work in Active Directory and what features are available under the various domain modes and functional levels.
With this information under our belts, let’s now take a look at how data is organized in Active Directory with Naming Contexts and Application Partitions.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 3: Naming Contexts and Application Partitions
Inhaltsvorschau
Due to the distributed nature of Active Directory, it is necessary to segregate data into partitions. If data partitions were not used, every domain controller would have to replicate all the data within a forest. Often it is advantageous to group data based on geographical or political requirements. Think of a domain as a big data partition, which is also referred to as a naming context (NC). Only domain controllers that are authoritative for a domain need to replicate all of the information within that domain. Information about other domains is not needed on those domain controllers. On the other hand, there is some Active Directory data that must be replicated to all domain controllers within a forest. There are three predefined naming contexts within Active :
  • A Domain Naming Context for each domain
  • The Configuration Naming Context for the forest
  • The Schema Naming Context for the forest
Each of these naming contexts represents a different type of Active Directory data. The Configuration NC holds data pertaining to the configuration of the forest (or of forest-wide applications), such as the objects representing naming contexts, LDAP policies, sites, subnets, Microsoft Exchange, and so forth. The Schema NC contains the set of object class and attribute definitions for the types of data that can be stored in Active Directory. Each domain in a forest also has a Domain NC, which contains data specific to the domain—for example, users, groups, computers, etc.
In Windows Server 2003 Active Directory, Microsoft extended the naming context concept by allowing user-defined partitions called application partitions. Application partitions can contain any type of object except for security principals. A major benefit of application partitions is that administrators can define which domain controllers replicate the data contained within these partitions. Application partitions are not restricted by domain boundaries, as is the case with Domain NCs; they can exist on any domain controller running Windows Server 2003 or later in a forest, regardless of the domain the DC hosts.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Domain Naming Context
Inhaltsvorschau
Each Active Directory domain has a Domain Naming Context, which contains domain-specific data. The root of this NC is represented by a domain’s distinguished name (DN) and is typically referred to as the NC head. For example, the mycorp.com domain’s DN would be dc=mycorp,dc=com. Each domain controller in the domain replicates a copy of the Domain NC.
contains a list of the default top-level containers found in a Domain NC. Note that to see all of these containers with the Active Directory Users and Computers (ADUC) snap-in, you must select View→Advanced Features from the menu. Alternatively, you can browse all of these containers with Ldp or the ADSI Edit tool available in the Windows Support Tools on any Windows Server 2003 or Windows 2000 CD. Windows Server 2008 includes ADSI Edit out of the box.
To start ADSI Edit, go to Start→Run→adsiedit.msc.
Table : Default top-level containers of a Domain NC
Description
cn=Builtin
Container for predefined built-in local security groups. Examples include Administrators, Domain Users, and Account Operators.
cn=Computers
Default container for computer objects representing member servers and workstations. You can change the default container used in Windows Server 2003 and newer with the redircmp.exe utility.
ou=Domain Controllers
Default organizational unit for computer objects representing domain controllers.
cn=ForeignSecurityPrincipals
Container for placeholder objects representing members of groups in the domain that are from a domain external to the forest.
cn=LostandFound
Container for orphaned objects. Orphaned objects are objects that were created in a container that was deleted from another domain controller within the same replication period.
cn=NTDS Quotas
Container to store quota objects, which are used to restrict the number of objects a security principal can create in a partition or container. This container is new in Windows Server 2003.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Configuration Naming Context
Inhaltsvorschau
The Configuration NC is the primary repository for configuration information for a forest and is replicated to every domain controller in the forest. Additionally, every writeable domain controller in the forest holds a writeable copy of the configuration NC. The root of the Configuration NC is found in the Configuration container, which is a sub-container of the forest root domain. For example, the mycorp.com forest would have a Configuration NC located at cn=configuration,dc=mycorp,dc=com.
contains a list of the default top-level containers found in the Configuration NC.
Table : Default top-level containers of the Configuration NC
Description
cn=DisplaySpecifiers
Container that holds display specifier objects, which define various display formats for the Active Directory MMC Snap-ins.
cn=Extended-Rights
Container for extended rights (controlAccessRight) objects.
cn=ForestUpdates
Contains objects that are used to represent the state of forest and domain functional level changes. This container is new in Windows Server 2003.
cn=LostandFoundConfig
Container for orphaned objects.
cn=NTDS Quotas
Container to store quota objects, which are used to restrict the number of objects that security principals can create in a partition or container. This container is new in Windows Server 2003.
cn=Partitions
Contains objects for each naming context, application partition, and external LDAP directory reference.
cn=Physical Locations
Contains location objects (physicalLocation), which can be associated with other objects to denote location of the object.
cn=Services
Store of configuration information about services such as FRS, Exchange, and Active Directory itself.
cn=Sites
Contains all of the site topology and replication objects. This includes site, subnet, siteLink, server, and nTDSConnection objects, to name a few.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Schema Naming Context
Inhaltsvorschau
The Schema NC contains objects representing the classes and attributes that Active Directory supports. The schema is defined on a forest-wide basis, so the Schema NC is replicated to every domain controller in the forest. Recall that the Schema NC is writeable only on the domain controller holding the schema master FSMO role. The root of the Schema NC can be found in the Schema container, which is a sub-container of the Configuration container. For example, in the mycorp.com forest, the Schema NC would be located at cn=schema,cn=configuration,dc=mycorp,dc=com.
Although the Schema container appears to be a child of the Configuration container, it is actually a separate naming context in its own right. shows how the Schema and Configuration NCs are segregated in the ADSI Edit tool.
Figure : ADSI Edit view of the Configuration and Schema naming contexts
You may be wondering why the schema isn’t just contained within the Configuration NC. As we discussed in , there is a Schema FSMO role that is the single master for updates to schema objects. The Schema FSMO role is necessary due to the highly sensitive nature of the schema. Schema modifications need to be processed prior to any updates that utilize the schema. The mechanism to most easily guarantee this with the replication model AD uses is to put the schema into its own partition so it can replicate separately prior to other changes.
Unlike the Domain and Configuration NCs, the Schema NC does not maintain a hierarchy of containers or organizational units. Instead, it is a single container that has classSchema, attributeSchema, and subSchema objects. The classSchema objects define the different types of classes and their associated attributes. The attributeSchema objects define all the attributes that are used as part of classSchema definitions. There is also a single subSchema instance that represents the abstract schema as defined in the LDAPv3 RFC (http://www.ietf.org/rfc/rfc2254.txt
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Application Partitions
Inhaltsvorschau
Application partitions are a feature introduced to Active Directory in Windows Server 2003. They enable administrators to create areas in Active Directory to store data on specific domain controllers they choose, rather than on every DC in a domain or forest. You can define which domain controllers hold a copy of each application partition, which is known as a replica. There is no limitation based on domain or site membership, which means that you can configure any domain controller running Windows Server 2003 or later within a forest to hold any application partition replica. The existing site topology will be used to automatically create the necessary connection objects to replicate among the servers that hold replicas of an application partition. Domain controllers will also register the necessary Service Location (SRV) records (explained in more detail in ), so that clients can use the DC locator process to find the optimal domain controller for an application partition, just as they would for a domain.
There are a few limitations to be aware of regarding application partitions:
  • Application partitions cannot contain security principals, which most notably includes user, inetOrgPerson, group, and computer objects. Any other type of object can be created in an application partition.
  • None of the objects contained in an application partition are replicated to the global catalog. Even if a domain controller that holds a replica of an application partition is also a global catalog server, the domain controller will not return any objects from the application partition during a global catalog search.
  • Objects in an application partition cannot be moved outside the partition. This is different from objects contained in domains, which can be moved between .
  • The Domain Naming FSMO must be on a Windows Server 2003 (or newer) domain controller to create an application partition. After the application partition has been created, you can move the Domain Naming FSMO back to a Windows 2000 domain controller (if necessary).
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we covered how objects are grouped at a high level into naming contexts and application partitions, which are used as replication boundaries. The Domain NC contains domain-specific data such as users, groups, and computers. The Configuration NC contains forest-wide configuration data such as the site topology objects and objects that represent naming contexts and application partitions. The Schema NC contains all the schema objects that define how data is structured and represented in Active Directory.
Application partitions were introduced in Windows Server 2003 Active Directory as a way for administrators to define their own groupings of objects and, subsequently, replication boundaries. Storage of DNS data for AD-integrated DNS zones is the classic example of when it makes sense to use application partitions, due to the increased control they give you over which domain controllers replicate the data. Dynamic objects are also new to Windows Server 2003 Active Directory. This feature allows you to create objects that have a TTL value; after the TTL expires, Active Directory automatically deletes the object.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 4: Active Directory Schema
Inhaltsvorschau
The schema is the blueprint for data storage in Active Directory. Each object in Active Directory is an instance of a class in the schema. A user object, for example, exists as an instance of the user class. Attributes define the pieces of information that a class, and thus an instance of that class, can hold. Syntaxes define the type of data that can be placed into an attribute. As an example, if an attribute is defined with a syntax of Boolean, it can store True or False as its value, or it can be null. A null value has an implementation-specific meaning; it could mean True or False depending on the application using the value.
Active Directory contains many attributes and classes in the default schema, some of which are based on standards and some of which Microsoft needed for its own use. Each release of Active Directory since Windows 2000 has included updates to the default schema. For background information on schema versions, see the sidebar ,” next. However, the Active Directory schema was designed to be extensible, so that administrators could add classes or attributes they deemed necessary. In fact, extending the schema is not a difficult task; it is often more difficult to design the changes that you would like to incorporate. Schema design issues are covered in , and in , we cover how to extend the schema programmatically. In this chapter, we’re concerned only with the fundamentals of the schema.
Table : Active Directory default schema versions
Schema version
Release
13
Windows 2000
30
Windows Server 2003
31
Windows Server 2003 R2
44
Windows Server 2008
The Schema Container is located in Active Directory under the Configuration Container. For example, the distinguished name of the Schema Container in the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Structure of the Schema
Inhaltsvorschau
The Schema Container is located in Active Directory under the Configuration Container. For example, the distinguished name of the Schema Container in the mycorp.com forest would be cn=schema,cn=Configuration,dc=mycorp,dc=com. You can view the contents of the container directly by pointing an Active Directory viewer such as ADSIEdit or LDP at it. You can also use the Active Directory Schema MMC snap-in, which splits the classes and attributes in separate containers for easy viewing, even though in reality all the schema objects are stored directly in the Schema Container.
The Active Directory Schema MMC snap-in is not fully enabled by default. In order to enable the schema management snap-in on a domain controller, you must first register the DLL which it depends on. To do that, run this command: regsvr32 schmmgmt.dll.
The schema itself is made up of two types of Active Directory objects: classes and attributes. In Active Directory, these are known respectively as classSchema (Class-Schema) and attributeSchema (Attribute-Schema) objects. The two distinct forms of the same names result from the fact that the cn (Common-Name) attribute of a class contains the hyphenated easy-to-read name of the class, and the lDAPDisplayName (LDAP-Display-Name) attribute of a class contains the concatenated string format that is used when querying Active Directory with LDAP or ADSI. In the schema, the lDAPDisplayName attribute of each object is normally made by capitalizing the first letter of each word of the Common-Name, and then removing the hyphens and concatenating all the words together. Finally, the first letter is made lowercase. This creates simple names like user, as well as the more unusual sAMAccountName and lDAPDisplayName. We’ll specify the more commonly used LDAP display name format from now on.
Whenever you need to create new types of objects in Active Directory, you must first create a classSchema object, defining the class of the object and the attributes it contains. Once the class is properly designed and added to the schema, you can then create objects in Active Directory that use the class. If the class you are adding will have custom attributes that are required to be populated when new instances of that class are created, you must define the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Attributes (attributeSchema Objects)
Inhaltsvorschau
Just as class information is stored in Active Directory as instances of the class called classSchema, attributes are represented by instances of the class called attributeSchema. As with all objects, the attributeSchema class has a number of attributes that can be set when specifying a new instance. The attributeSchema class inherits attributes from the class called top. However, most of the top attributes are not relevant here. All of the attributes of the attributeSchema class are documented in the Platforms SDK at http://msdn2.microsoft.com/en-us/library/ms680969(VS.85).aspx.
The userPrincipalName (UPN) attribute is used on user objects to provide a unique method of identifying each user across a forest. Users can log on to a workstation in any domain in the forest using the UPN if they so desire. The UPN attribute, in fact, accepts valid RFC 2822 (email) addresses, so the UPN for user tpood in the europe.mycorp.com domain could be tpood@mycorp.com or tpood@europe.mycorp.com, or even tpood@logon.local. In fact, any UPN suffix, such as @mycorp.com, can be used in a forest. The only requirement is that the UPN value for a user is unique across all users in a forest.
Active Directory does not enforce uniqueness of a UPN when it is set. If two different users in the same forest are assigned the same UPN, neither will be able to log on using the UPN. When duplicate UPNs are detected, domain controllers will log an event from source Key Distribution Center (KDC) with event ID 11. Many large organizations implement scripts or other tools to scan their directories on a regular basis to check for duplicate UPNs.
To dissect the attribute, we need to find out what values had been set for it. shows a subset of the values of attributes that have been set for the userPrincipalName attributeSchema instance.
Table : userPrincipalName’s attributes
Attribute lDAPDisplayName
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Attribute Properties
Inhaltsvorschau
There are several properties on attributes that have significant and varied impact on attribute use and functionality. Here we give a little more detailed information on a few of these attributes that you need to understand when modifying the schema.
Figure : The UPN attribute as viewed by the Active Directory Schema snap-in
The syntax of an attribute represents the kind of data it can hold; people with a programming background are probably more familiar with the term “data type.” Unlike attributes and classes, the supported syntaxes are not represented as objects in Active Directory. Instead, Microsoft has coded these syntaxes internally into Active Directory itself. Consequently, any new attributes you create in the schema must use one of the predefined syntaxes.
Whenever you create a new attribute, you must specify its syntax. To uniquely identify the syntax among the total set of 21 syntaxes, you must specify two pieces of information: the OID of the syntax and a so-called OM syntax. This pair of values must be set together and correctly correlate with . More than one syntax has the same OID, which may seem strange; and to uniquely distinguish between different syntaxes, you thus need a second identifier. This is the result of Microsoft requiring some syntaxes that X.500 did not provide. shows the 21 expanded syntaxes, including the name of the syntax with alternate names followed in parentheses.
Table : Syntax definitions
Syntax
OID
Description
Address
2.5.5.13
127
Used internally by the system.
Boolean
2.5.5.8
1
True or false.
Case-insensitive string
2.5.5.4
20
A string that does not differentiate between uppercase and .
Case-sensitive string
2.5.5.3
27
A string that differentiates between uppercase and
Distinguished name
2.5.5.1
127
The Fully Qualified Domain Name (FQDN) of an object in Active Directory.
DN-Binary
2.5.5.7
127
Octet string with binary value and DN. Format: B:<char count>:>:<object DN>.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Classes (classSchema Objects)
Inhaltsvorschau
Schema classes are defined as instances of the classSchema class. A complete listing of the attributes on the classSchema class is available from the Platform SDK at http://msdn2.microsoft.com/en-us/library/ms680982(VS.85).aspx.
Classes are special in that they can inherit from one another. For example, let’s say that we wanted to store two new types of objects in the schema, representing a marketing user and a finance user, respectively. These users both need all the attributes of the existing user class as a base. However, the finance user needs seven special attributes, while the marketing user needs three. The extra attributes required by both users do not match in any way. In this example, we can create a Marketing-User class, a class, and 10 distinctly new attributes. However, rather than having to specify that the Marketing-User and Finance-User classes have each of the attributes of the original user class individually, all we need to do is specify that the new classes inherit from the user class by setting the subClassOf attribute to user. When we do this, both of the new classes inherit every single attribute that the user class had. We can then add the extra attributes to each class and we have two new classes. This example is outlined in .
Figure : Marketing and Finance subclasses
You have another option when using Windows Server 2003 Forest Functional Mode or ADAM to resolve this issue. First, define the additional attributes and then create two auxiliary classes and assign the attributes to the classes. Then you can dynamically assign the auxiliary classes to users on ad hoc basis. This is far more flexible in that you can easily reconfigure individual users as necessary. If a user moves from Marketing to Finance, using special inherited classes would require deleting the user and recreating the user with the finance-user class. With dynamic auxiliary classes, you would simply clear the marketing attributes, remove the Marketing auxiliary class, and add the Finance auxiliary class and attributes.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we’ve shown you how the internal blueprint for all objects in Active Directory, known as the schema, was derived from the X.500 directory service. We explained the purpose of the OID numbering system and how it can be used as well as the various elements that must be unique in an Active Directory schema extension such as prefix names and link IDs.
We then detailed how an attribute and its syntax are structured in the schema as attributeSchema objects, using the userPrincipalName attribute as an example. We showed how attributes are added to classes by detailing how classes are stored in the schema as instances of classSchema objects. To make this clearer we dug into the details of the user class to see how it was constructed. Finally, we covered how auxiliary classes can be dynamically linked starting in Windows Server 2003 and why it is significant.
builds on what you’ve learned here to demonstrate how you can design and implement schema extensions.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 5: Site Topology and Replication
Inhaltsvorschau
This chapter introduces a major feature of Active Directory: multimaster replication. Active Directory was one of the first LDAP-based directories to offer multimaster replication. Most directories replicate data from a single master server to subordinate servers. This is how replication worked in Windows NT 4.0 for example. Obviously, there are several potential problems with a single-master replication scheme, including single point of failure for updates, geographic distance from master to clients performing the updates, and less efficient replication due to single originating location of updates. Active Directory replication addresses these issues, but with a price. To get the benefit of a multimaster replication, you must first create a site topology that describes the network and helps define how domain controllers should replicate with each other. In large environments, building and maintaining a site topology can be a significant amount of work.
This chapter looks at the basics of how sites and replication work in Active Directory. In , we’ll describe the physical infrastructure of a network layout using sites. We’ll also discuss in that chapter how the Knowledge Consistency Checker (KCC) sets up and manages the replication connections and details on how to effectively design and tailor sites, site links, and replication in Active Directory.
The Active Directory site topology is the map that describes the network connectivity, Active Directory Replication guidelines, and locations for resources as it relates to the Active Directory forest. The major components of this topology are sites, subnets, site links, site link bridges, and connection objects. These are all Active Directory objects that are maintained in the forest’s configuration container to allow the information to be locally available on all domain controllers so the DCs can properly communicate.
A subnet is a portion of the IP space of a network. Subnets are described by their IP network address combined with a subnet mask measured in bits. For instance, the subnet mask 255.255.255.0 is a 24-bit subnet mask. If you have a 24-bit mask for the 10.5.20.0 network, your subnet object would be described as 10.5.20.0/24. The subnet objects in Active Directory are a logical representation of the subnets in your environment; they may, but do not necessarily have to, reflect your actual physical subnet definitions. For example, you may have a building that has two 24-bit subnets of 10.5.20.0 and 10.5.21.0, which for the purposes of Active Directory could be included in a single AD subnet of 10.5.20.0/23, which specifies a 23-bit subnet mask. These examples all represent IP version 4 (IPv4) subnets. Windows Server 2008 introduces support for IP version 6 (IPv6) subnets and domain controllers in Active Directory. The same concepts for subnetting apply; however, the addresses and subnets are much larger. IPv4 uses 32-bit addressing whereas IPv6 uses 128-bit addressing.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Site Topology
Inhaltsvorschau
The Active Directory site topology is the map that describes the network connectivity, Active Directory Replication guidelines, and locations for resources as it relates to the Active Directory forest. The major components of this topology are sites, subnets, site links, site link bridges, and connection objects. These are all Active Directory objects that are maintained in the forest’s configuration container to allow the information to be locally available on all domain controllers so the DCs can properly communicate.
A subnet is a portion of the IP space of a network. Subnets are described by their IP network address combined with a subnet mask measured in bits. For instance, the subnet mask 255.255.255.0 is a 24-bit subnet mask. If you have a 24-bit mask for the 10.5.20.0 network, your subnet object would be described as 10.5.20.0/24. The subnet objects in Active Directory are a logical representation of the subnets in your environment; they may, but do not necessarily have to, reflect your actual physical subnet definitions. For example, you may have a building that has two 24-bit subnets of 10.5.20.0 and 10.5.21.0, which for the purposes of Active Directory could be included in a single AD subnet of 10.5.20.0/23, which specifies a 23-bit subnet mask. These examples all represent IP version 4 (IPv4) subnets. Windows Server 2008 introduces support for IP version 6 (IPv6) subnets and domain controllers in Active Directory. The same concepts for subnetting apply; however, the addresses and subnets are much larger. IPv4 uses 32-bit addressing whereas IPv6 uses 128-bit addressing.
You must define subnet information in the directory because the only key available for determining relative location on a network is the IP addresses of the machines. The subnets are, in turn, associated with sites. Without these definitions, there is no way for a machine to make an efficient determination of what distributed resources it should try to use. By default, no subnets are defined in Active Directory. For more information on defining subnets in Active Directory, see the sidebar ,” next.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
How Replication Works
Inhaltsvorschau
Microsoft has introduced a number of new terms for Active Directory replication, and most of them will be completely unfamiliar to anyone new to Active Directory. To properly design your replication topology, you should understand the basics of how replication works, but you also need to understand how replication works using these new terms, which are used throughout both Microsoft’s documentation and its tools. As you read the rest of this chapter, refer as needed back to the definitions of the terms that are presented. Do not be disappointed if it doesn’t all sink into your brain comfortably on your first or even fifth read of the material. Even experienced administrators have been known to debate how this all works, as well as what the proper terms are for the various structures and processes.
We will use the sample replication topology in for the discussion in this section.
Figure : Sample replication topology for “How Replication Works” discussion
Replication metadata is the data that governs the replication process. Active Directory replication enables data transfer between naming contexts on different domain controllers without ending up in a continuous replication loop or missing any data. To make this process work, each NC holds a number of pieces of information that specifically relate to replication within that particular NC. That means that the replication data for the Schema NC is held in the Schema NC and is separate from the replication data for the Configuration NC, which is held in the Configuration NC, and so forth. This is done this way because all replication is naming-context based. When a domain controller is pulling changes from another domain controller, it does so one naming context at a time in a serial fashion.
Although time isn’t used as the basis for replication in Active Directory, it is still incredibly important. All authentication between domain controllers for replication is Kerberos based, and Kerberos has a maximum time-skew requirement between hosts. In a default forest, if a domain controller deviates from the common time of all of the other domain controllers by more than five minutes, that domain controller will no longer be able to replicate with other domain controllers.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
We have now looked at the importance of the site topology in Active Directory and how that relates to your physical network. We have also considered the metadata that governs the replication process, how the system keeps track of changes to objects and properties automatically, how data is replicated among servers including propagation dampening, and how conflicts are resolved.
In , we take this knowledge further and show you how Active Directory manages and automatically generates the replication connections that exist both within and between sites. With that knowledge, we can move on to the design principles for sites and links in Active Directory.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 6: Active Directory and DNS
Inhaltsvorschau
One of the big advantages of Active Directory over its predecessor, Windows NT, is the reliance on the Domain Name System (DNS) as opposed to the Windows Internet Naming Service (WINS) for name resolution. DNS is the ubiquitous, standards-based naming service used on the Internet. WINS, on the other hand, never garnered industry support and has become a red-headed stepchild on many enterprise networks.
The good news is that with Active Directory, the dependencies on WINS have been eliminated, but the potentially bad news is that Active Directory has many dependencies on the DNS infrastructure. It is only potentially bad based on the flexibility of your DNS environment. Often, the groups that manage DNS and Active Directory within an organization are different, and getting the two teams to agree on implementation can be difficult due to political turf battles or technology clashes.
Although Active Directory doesn’t need WINS or, more accurately, NetBIOS Name Resolution, many other Microsoft technologies, including Exchange 2000/2003, do need it. Implementing Active Directory doesn’t necessarily guarantee that you won’t be running WINS anymore.
The intent of this chapter is to provide you with a good understanding of how Active Directory uses DNS and a description of some of the options for setting it up within your organization. We will briefly touch on some DNS basics, but will not go into much depth on how to configure and administer the Windows DNS server. For more information on those topics, we highly recommend DNS on Windows 2003 by Matt Larson, Cricket Liu, and Robbie Allen (O’Reilly).
DNS is a hierarchical name-resolution system. It is also the largest public directory service deployed. Virtually every company uses DNS for name-resolution services, including hostname to IP address, IP address to hostname, and hostname to alternate hostname (aliases). DNS is a well-documented standard that has been around since the early days of the Internet. The following RFCs cover some of the basics of DNS:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
DNS Fundamentals
Inhaltsvorschau
DNS is a hierarchical name-resolution system. It is also the largest public directory service deployed. Virtually every company uses DNS for name-resolution services, including hostname to IP address, IP address to hostname, and hostname to alternate hostname (aliases). DNS is a well-documented standard that has been around since the early days of the Internet. The following RFCs cover some of the basics of DNS:
  • RFC 1034, “Domain Names—Concepts and Facilities”
  • RFC 1035, “Domain Names—Implementation and Specification”
  • RFC 1912, “Common DNS Operational and Configuration Errors”
  • RFC 1995, “Incremental Zone Transfer in DNS”
  • RFC 1996, “A Mechanism for Prompt Notification of Zone Changes (DNS )”
  • RFC 2181, “Clarifications to the DNS Specification”
There are three important DNS concepts that every Active Directory administrator must understand:
  • Zones are delegated portions of the DNS namespace.
  • Resource records contain name resolution information.
  • Dynamic DNS allows clients to add and delete resource records dynamically.
A zone is a collection of hierarchical domain names, the root of which has been delegated to one or more name servers. For example, let’s say that the mycorp.com namespace was delegated to the name server ns1.mycorp.com. All domain names contained under mycorp.com that ns1.mycorp.com was authoritative for would be considered part of the mycorp.com zone.
A subset of the mycorp.com zone could be delegated to another server; for example, mycorp.com could delegate subdomain1.mycorp.com to the name server ns2.mycorp.com. At that point, subdomain1.mycorp.com becomes its own zone for which ns2.mycorp.com is authoritative.
A resource record is the unit of information in DNS. A zone is essentially a collection of resource records . There are various resource record types that define different types of name lookups. lists some of the more common resource record types.
Table : Commonly used resource record types
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
DC Locator
Inhaltsvorschau
One of the fundamental issues for clients in any environment is finding the most optimal domain controller (DC) to authenticate against. The process under Windows NT was not very efficient and could cause clients to authenticate to domain controllers in the least optimal location. With Active Directory, clients use DNS to locate domain controllers via the DC locator process. To illustrate at a high level how the DC locator process works, we will describe an example where a client has moved from one location to another and needs to find a DC for the domain it is a member of:
  1. A client previously located in Site A is moved to Site B.
  2. When the client initially boots up, it thinks it is still in Site A, so it retrieves from the cache the last DC it used, most likely from Site A, and proceeds to contact it.
  3. The DC in Site A receives the request, determines that the IP address is for Site B, and determines that the client should now be using a DC that services Site B. If the server does not service clients in Site B, it will return the client’s new site in the reply and tell the client that it isn’t the closest DC.
  4. The client will then perform a DNS lookup to find all DCs that service Site B.
  5. The client then contacts a DC servicing Site B. Three things can happen at this point:
    1. The DC servicing Site B can respond and authenticate the client.
    2. The DC might fail to respond (it could be down), at which point the client will attempt to use a different DC in Site B.
    3. All DCs servicing Site B fail to respond and the client then performs a DNS lookup to find all DCs that service the domain despite what sites they cover and uses any one of them to authenticate.
The two main things that are needed to support an efficient DC locator process are proper definition of the site topology in Active Directory and the presence of all the necessary Active Directory-related resource records in DNS. In the next section, we will describe the purpose of the resource records used in Active Directory.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Resource Records Used by Active Directory
Inhaltsvorschau
When you promote a domain controller into a domain, a file containing the necessary resource records for it to function correctly within Active Directory is generated in %SystemRoot%\System32\Config\netlogon.dns.
The contents of the file will look something like the following for a DC named moose.mycorp.com in the mycorp.com domain with IP address 10.1.1.1. We’ve reordered the file a bit to group records of similar purpose together (note that some lines may wrap due to their length):
mycorp.com. 600 IN A 10.1.1.1

ec4caf62-31b2-4773-bcce-7b1e31c04d25._msdcs.mycorp.com. 600 IN CNAME moose.mycorp.

com.

gc._msdcs.mycorp.com. 600 IN A 10.1.1.1

_gc._tcp.mycorp.com. 600 IN SRV 0 100 3268 moose.mycorp.com.

_gc._tcp.Default-First-Site-Name._sites.mycorp.com. 600 IN SRV 0 100 3268 moose.

mycorp.com.

_ldap._tcp.gc._msdcs.mycorp.com. 600 IN SRV 0 100 3268 moose.mycorp.com.

_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mycorp.com. 600 IN SRV 0 100

3268

moose.mycorp.com.

_kerberos._tcp.dc._msdcs.mycorp.com. 600 IN SRV 0 100 88 moose.mycorp.com.

_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mycorp.com. 600 IN SRV 0

100

88 moose.mycorp.com.

_kerberos._tcp.mycorp.com. 600 IN SRV 0 100 88 moose.mycorp.com.

_kerberos._tcp.Default-First-Site-Name._sites.mycorp.com. 600 IN SRV 0 100 88

moose.

mycorp.com.

_kerberos._udp.mycorp.com. 600 IN SRV 0 100 88 moose.mycorp.com.

_kpasswd._tcp.mycorp.com. 600 IN SRV 0 100 464 moose.mycorp.com.

_kpasswd._udp.mycorp.com. 600 IN SRV 0 100 464 moose.mycorp.com.

_ldap._tcp.mycorp.com. 600 IN SRV 0 100 389 moose.mycorp.com.

_ldap._tcp.Default-First-Site-Name._sites.mycorp.com. 600 IN SRV 0 100 389 moose.

mycorp.com.

_ldap._tcp.pdc._msdcs.mycorp.com. 600 IN SRV 0 100 389 moose.mycorp.com.

_ldap._tcp.97526bc9-adf7-4ec8-a096-0dbb34a17052.domains._msdcs.mycorp.com. 600 IN

SRV

0 100 389 moose.mycorp.com.

_ldap._tcp.dc._msdcs.mycorp.com. 600 IN SRV 0 100 389 moose.mycorp.com.

_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mycorp.com. 600 IN SRV 0 100

389

moose.mycorp.com.
Although it may look complicated, it isn’t. Let’s go through what these records actually mean, splitting the records up into sections for ease of understanding. To start with, the first record is for the domain itself:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Delegation Options
Inhaltsvorschau
Now that we’ve covered what Active Directory uses DNS for, we will review some of the options for setting up who is authoritative for the Active Directory-related zones. Ultimately, the decision boils down to whether you want to use your existing DNS servers or different servers, such as the domain controllers, to be authoritative for the zones. There are many factors that can affect this decision, including:
  • Political turf battles between the AD and DNS teams
  • Initial setup and configuration of the zones
  • Support and maintenance of the zones
  • Integration issues with existing administration software and practices
We will look at each of these factors as they apply to delegating the AD zones. Other slight variations of these options do exist, but we will discuss only the basic cases.
The first impulse of any cost-conscious organization should be to determine whether their existing DNS servers can be authoritative for the AD zones. That could entail manually populating all the necessary resource records required by each DC if the current DNS implementation doesn’t support dynamic updates. While this sounds fairly trivial at first glance, it becomes decidedly less trivial once you begin to explore the requirements.

Political factors

By utilizing the existing DNS servers for the AD DNS zones, the Active Directory administrators will likely not have the same level of control as they would if the zones were delegated and managed by them. Although it does limit the scope of control for a crucial service used by Active Directory, some AD administrators may find it a !

Initial setup and configuration

The initial population of the AD resource records can be burdensome depending on how you manage your resource records and how easy it will be for you to inject new ones. For example, domain controllers try to register their resource records via DDNS on a periodic basis. Many organizations do not allow just any client to make DDNS updates due to the potential security risks. For that reason, you’ll need to configure your existing DNS servers to allow the domain controllers to perform DDNS updates. DNS administrators will need to configure DDNS to only allow domain controllers to update certain zones in order to mitigate security risks of allowing domain controllers to update any DNS record in the server. This should not typically be a problem, but depending on how paranoid the DNS administrators are, it could be a point of .
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Active Directory Integrated DNS
Inhaltsvorschau
If you’ve decided to host your AD DNS zones on your domain controllers, you should strongly consider using AD-integrated zones. This section will explain some of the benefits of using AD-integrated DNS versus standard primary zones.
Figure : Forwarders configuration screen in the Windows Server 2003 DNS MMC snap-in
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Using Application Partitions for DNS
Inhaltsvorschau
Application partitions, as described in , are user-defined partitions that have a customized replication scope. Domain controllers that are configured to host replicas of an application partition will be the only servers that replicate the data contained within the partition. One of the benefits of application partitions is that they are not limited by domain boundaries. You can configure domain controllers in completely different domains to replicate an application partition, so long as they are in the same forest. It is for these reasons that application partitions make a lot of sense for storing AD-integrated DNS zones. No longer do you have to store DNS data within the domain context and replicate to every domain controller in the domain, even if only a handful are DNS servers. With application partitions, you can configure Active Directory to replicate only the DNS data between the domain controllers running the DNS service within a domain or forest.
When installing a new Windows Server 2003 Active Directory forest, the default DNS application partitions are created automatically. If you are upgrading from Windows 2000, you can manually create them by using the DNS MMC snap-in or the dnscmd.exe utility. There is one default application partition for each domain and . When configuring an AD-integrated zone in a Windows Server 2003 forest, you have several options for storing the DNS data. These options are listed in .
Table : Active Directory Integrated DNS zone storage options
Distinguished name
Replication scope
cn=System,DomainDN
Example: cn=System,dc=amer,dc=mycorp,dc=com
To all domain controllers in the domain. This is the only storage method available under Windows 2000.
dc=DomainDnsZones, DomainDN
Example: dc=DomainDnsZones,dc=amer, dc=mycorp,dc=com
To domain controllers in the domain that are also DNS servers.
dc=ForestDnsZones, ForestDN
Example: dc=ForestDnsZones,dc=mycorp,dc=com
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Aging and Scavenging
Inhaltsvorschau
One of the complexities of running a DNS infrastructure where clients can register their own records is that over time records will build up in your zones for clients that no longer exist, or perhaps have a new name. If you only have a small number of machines on your network, you could likely manage these records yourself through the MMC. On the other hand, if you have hundreds or even hundreds of thousands of machines participating in a single DNS zone, chances are you won’t be able to manage the lifecycle of these records on your own.
Fortunately, since Windows 2000, Microsoft DNS has included a feature called scavenging. Scavenging is a background process that you configure on a per-DNS-server basis to scan all of the records in a zone and remove the records that have not been refreshed in a certain time period. Clients that register themselves with dynamic DNS will automatically refresh their DNS registrations periodically. Windows DNS will store this timestamp as an attribute of the DNS record. By default, Microsoft DNS clients update and refresh their DNS registrations once every 24 hours.
One of the scavenging configuration options is the “no-refresh interval,” which defines how often the DNS server will accept the DNS registration refresh and update the DNS record. This functionality limits the amount of unnecessary replication for DNS record timestamp updates. For records that are manually created, the refresh timestamp is set to zero, which excludes the record from scavenging. You can also edit dynamically registered records to exclude them from scavenging.
Configuration of scavenging is a two step process:
  1. Enable scavenging for a specific DNS zone and define the refresh intervals for that zone (see ).
    If you right-click on the DNS server node in the DNS MMC, there is an option “Set Aging/Scavenging for All Zones…” that will allow you to configure these two values once for all of the DNS zones hosted on that particular DNS server.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
Active Directory relies heavily on DNS. In fact, Microsoft has shifted completely away from WINS for name resolution within the NOS in favor of standards-based DNS. The DC-locator process is a core DNS-based function used within Active Directory to help domain controllers and clients locate domain controllers that have certain properties, such as residing in a particular site or being a Global Catalog server or PDC emulator. Deciding how to manage the AD DNS zones can be a difficult decision, with each option having its own advantages and disadvantages. If you delegate the zones to domain controllers, AD-integrated zones can save a lot of time in maintenance and upkeep. In Windows Server 2003, you can use application partitions to replicate AD-integrated zones only to the domain controllers that are acting as DNS servers. This can greatly reduce replication traffic in some situations compared to Windows 2000 Active Directory, which replicated DNS data to every domain controller in a domain regardless of whether it was a DNS server.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 7: Read-Only Domain Controllers
Inhaltsvorschau
One of the most significant Active Directory features introduced in Windows Server 2008 was the Read-Only Domain Controller (RODC). Deploying domain controllers into untrusted locations has always been a substantial security risk for Active Directory deployments. The risk of a domain controller becoming physically compromised and having password hashes for that domain stolen or the risk of a database (ntds.dit) being modified offline and placed back on the network are both important risks to measure. The RODC brings the ability to mitigate both of these risks.
By default, RODCs do not store any passwords locally in their database. If a user authenticates to an RODC, the RODC will need to contact a writeable domain controller (sometimes called an RWDC) upstream in order to validate that user’s password. This, of course, also applies to other objects with passwords, such as computer and trust accounts. Through the use of Password Replication Policies, you can define what passwords are allowed to be cached locally on an RODC. You can also examine a real-time view of what passwords are currently cached on an RODC.
In order to ensure that an RODC cannot impact the integrity of an Active Directory forest, all replication to RODCs is one way. This means that if someone manages to make a change, Active Directory will not replicate that change to other Domain Controllers. shows the replication paths in a network with RODCs deployed.
Figure : RODC replication
Generally speaking, there are a couple of scenarios where we see RODCs being deployed. The first scenario is in the branch office. Branch offices are typically smaller facilities that are connected by a WAN link to a datacenter or other central site. These WAN links vary greatly in speed and reliability. The second key characteristic of the branch office is the inability for the physical security of a domain controller to be guaranteed. Often times server rooms in branch offices are merely closets or other repurposed spaces that have limited provisions for managing who has access to the space. The majority of our discussion about RODCs in this book will be focused on the branch office.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Prerequisites
Inhaltsvorschau
There are a few major prerequisites to deploying RODCs in to your Active Directory that you should take in to consideration before proceeding any further. The first is that your forest at a minimum be at the Windows Server 2003 forest-functional level. Next, you’ll need to have a writeable Windows Server 2008 domain controller in a site that your RODC is connected to, as determined by the Active Directory site-link topology.
Consider . If you have Bridge All Site Links enabled, RODCs can be more than one hop away from a Windows Server 2008 RWDC, and thus the RODC in Site A will be able to communicate with the Windows Server 2008 RWDC in Site C. If, however, you do not have bridge all site links enabled, you will either need to create a site-link bridge that includes site links A - B and B - C, or you will need to deploy a Windows Server 2008 RWDC in Site B.
Figure : Sample RODC deployment topology
In addition to these Active Directory requirements, you should investigate deploying the RODC compatibility pack to your clients. This package is available for download (and described in) Microsoft Knowledge Base article 944043 at http://support.microsoft.com/kb/944043. There are a number of compatibility issues and bugs with Windows XP and Windows Server 2003 clients and domain controllers that you are likely to encounter, and this package solves many of them. We will make reference to situations where this package may be required throughout this chapter when appropriate.
Throughout this chapter we will often reference situations where an RODC can specially request replication of a specific object. This functionality is known as ReplicateSingleObject or RSO. The replicate-single-object operation is initiated via a modification to the replicateSingleObject operational attribute of the RootDSE LDAP entry. For more information on this attribute, reference http://msdn.microsoft.com/en-us/library/cc200527.aspx.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Password Replication Policies
Inhaltsvorschau
As we discussed briefly, RODCs don’t cache passwords by default. This means that if an attacker were to get a copy of the Active Directory database from an RODC, they would not be able to compromise any passwords since there are none stored there. The downside of not storing any passwords is that the RODC will need to make a call to an RWDC, usually over the WAN, to authenticate a client. The value of the RODC diminishes when the WAN is down and clients cannot be authenticated even though there is a local domain controller.
The solution to this problem is the use of password replication policies (PRPs). Password replication policies allow you to define what user (and computer) passwords are cached locally on the RODC, as well as which passwords can never be cached. PRPs are defined through a series of four linked multivalued attributes on the RODC’s computer account in Active Directory. Those attributes are:
msDS-RevealOnDemandGroup
This is the list of principals that the RODC can cache the password for. This list is often referred to as the allowed list.
msDS-NeverRevealGroup
This is the list of principals that the RODC is never allowed to cache the password for. This list is often referred to as the denied list.
msDS-RevealedList
This is a list of principals whose passwords are currently cached on the RODC.
msDS-AuthenticatedAtDC
This is a list of principals who have authenticated to the RODC. This list is often referred to as the Auth-2 list.
In addition to these attributes, there are two new built-in groups that are added to Active Directory when you introduce the first RODC in the domain. These are the Allowed RODC Password Replication Group and the Denied RODC Password Replication Group. The allowed group is added to the msDS-RevealOnDemandGroup attribute by default, and the denied group is added to the msDS-NeverRevealGroup attribute by default. The allowed group has no members by default; however, the denied group has a number of members by default:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
The Client Logon Process
Inhaltsvorschau
So far we’ve discussed the caching of passwords on RODCs and how to control the caching, but we have not looked at how the RODC actually gets passwords from a writeable domain controller and caches them locally. In this section we’ll take a look not only at how passwords get cached locally, but also at the overall flow of communications between domain controllers and clients when an RODC is involved.
One key difference between RODCs and their writeable counterparts that you should keep in mind throughout this section (and that we will frequently point out) is that each RODC has its own krbtgt account. The krbtgt accounts are the credentials that are used by domain controllers to encrypt Kerberos messages, and if you have access to these credentials, you have an endless degree of power over the forest. Consequently, each RODC maintains a separate krbtgt account that is named in the format krbtgt_<number>, where <number> is a unique number. The RODC stores only the password for its personal krbtgt account locally. Writeable domain controllers, however, store the passwords for each krbtgt account in their databases.
In order to determine what krbtgt account is associated with a given RODC, you can inspect the msDS-KrbTgtLink attribute on an RODC’s computer account, or the msDS-krbTgtLinkBL attribute on the krbtgt account.
Let’s consider the situation depicted in as our baseline for the rest of this discussion. has four players:
RWDC01
This is our writeable domain controller in the datacenter.
RODC01
This is our read-only domain controller in the branch office.
User Brian
This is our user who will be logging on and accessing services.
Machine BrianPC
This is the workstation for user Brian.
Figure : Sample network topology
Let’s assume that the first step is for our machine, BrianPC, to authenticate to the domain. The following are the steps that will take place:
  1. First, BrianPC will contact RODC01 and provide a Kerberos authentication service request (a
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
RODCs and Write Requests
Inhaltsvorschau
RODCs have a great deal of special logic encoded in them to handle write requests they receive from clients. Perhaps the most obvious and common example of a write operation is a user or computer password change request. Other common examples are dynamic DNS registrations and updates to logon timestamp information.
The behavior of an RODC when a user changes their password varies depending on what mechanism the user is using to change their password (such as Kerberos or LDAP), and the operating system of the client. Let’s take the most common example of a user pressing Ctrl+Alt+Del on his workstation and selecting the change password option.
Clients running Windows Vista (and Windows Server 2008) will attempt to make the password change via Kerberos. When an RODC receives a Kerberos password change request, it will be forwarded to a writeable domain controller. The RODC will also immediately request that the RWDC replicate that user’s password to the RODC. The RWDC will then follow the normal process discussed earlier for replicating a password to an RODC.
On a client running Windows XP or earlier (and server operating systems running Windows Server 2003 or earlier), the client will contact a writeable domain controller directly and the RODC will have no knowledge of the password change. Next time the RODC replicates with a writeable domain controller, it will erase its local copy of that user’s password. The user authentication process discussed earlier will ensure the next time the user attempts to log on, and the RODC will again cache that user’s password if permissible.
If you have loaded the RODC hotfix package discussed earlier in this chapter, the client will contact an RODC to change its password and the RODC will chain that request to an RWDC. The password will still not be requested for immediate replication, however.
If the user account password change request is made via LDAP (such as for the Outlook Web Access change password webpage), the change will be made directly on a writeable domain controller. The RODC will have no knowledge of the password change, and next time the RODC replicates with a writeable domain controller, it will erase its local copy of that user’s password. The user authentication process discussed earlier will ensure the next time the user attempts to log on, and the RODC will again cache that user’s password if permissible.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
The W32Time Service
Inhaltsvorschau
As a rule, RODCs will synchronize time with writeable Windows Server 2008 domain controllers. In general, at no time will an RODC ever synchronize its time with another RODC.
When an RODC receives a request for time synchronization for a client, the manner in which the request is processed varies greatly depending upon whether or not the RODC has the client’s password cached. If the RODC has the client computer’s password cached locally, the RODC is able to process and sign the time-synchronization request as a standard writeable domain controller would. If, however, the RODC does not have the client’s password cached, then a writeable domain controller must be involved.
When the RODC receives a time-synchronization request it cannot process, there are a number of steps involved:
  1. The RODC forwards the request to a Windows Server 2008 writeable domain controller.
  2. The writeable domain controller then processes the request and signs it using the client computer’s password, and then returns the response to the RODC.
  3. The RODC in turn receives the response and forwards it to the client, who processes the response.
In order to handle the forwarding of requests and responses, the RODC maintains a local table of client time-service requests that it has forwarded. This table is known as the chaining table. The table contains three fields:
  • The client’s IP address (either IPv4 or IPv6)
  • The timestamp from the NTP request
  • The client’s RID
When an RODC receives a reply from the writeable domain controller, it searches the table for a matching request based on the RID and request timestamp. Once the RODC finds a match, the RODC forwards the response back to the source IP.
In the event the RODC is unable to find a match in the table, the RODC assumes that it originated the request. If the request is signed with the RODC’s computer account password, then the RODC updates its local clock as necessary. Otherwise, the RODC discards the response.
Any entry in the RODC’s chaining table has a maximum lifetime of up to four seconds by default, and any given client (as defined by the client’s IP address) can have a maximum of four entries in the chaining table at any given time. In total, the chaining table can contain a maximum of 128 entries by default. In the event either of these maximums is exceeded, new requests are simply discarded until the chaining table has additional room for them.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Application Compatibility
Inhaltsvorschau
Like any major change to your infrastructure, prior to large scale deployment of RODCs in your environment, you will need to perform significant testing in order to understand application behavior issues as they relate to RODCs.
Applications that attempt to write to Active Directory using LDAP will receive an LDAP referral from an RODC to a writeable domain controller. So long as the application is capable of chasing the referral, the write will succeed, and the next time the RODC replicates, that write will be reflected locally. In the event the WAN is down, the referral will fail. The application will need to be able to handle this situation.
You can disable an RODC’s ability to issue write referrals by setting the RODCMode registry value to 1. The RODCMode registry value is a REG_DWORD located at HKLM\System\CurrentControlSet\Services\NTDS\Parameters.
Another scenario where an application may fail is if it expects the results of a write to be immediately available on the local domain controller. One of the issues resolved by the RODC compatibility package is for a bug in the Windows print-spooler service. The print spooler publishes printers to Active Directory via LDAP (which would be referred to a writeable domain controller), and then immediately tries to read that published printer from the local domain controller. If the printer isn’t present on the local domain controller (which is the case with a local RODC), then the spooler service determines that publication of the printer failed.
If an application is using legacy RPC calls to make changes to Active Directory, those RPC calls will fail if they are targeted to an RODC. The application must explicitly target a writeable domain controller in order for the writes to succeed. The RODC will replicate the changes through normal replication.
If you have added attributes to the Filtered Attribute Set (FAS), applications will need to be aware that those attributes will not be available from Active Directory on an RODC. If an application requires access to an attribute in the FAS, the application will need to communicate with a writeable domain controller. For more information on the filtered attribute set, see . Keep in mind that the FAS cannot be enforced in a multidomain forest until your forest is at the Windows Server 2008 functional level. This is because an RODC that is also a global catalog may replicate one of the global catalog naming contexts from a Windows Server 2003 domain controller. Windows Server 2003 domain controllers are unaware of the FAS, and as such they will include filtered attributes when replicating with an RODC. Filtering occurs at the replication source, not at the RODC, so the RODC will process inbound replication for filtered attributes and store them in its database.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
RODC Placement Considerations
Inhaltsvorschau
When you place RODCs in your network, there are a few rules and considerations you should think about as you work on your design. The first rule to remember is that an RODC will never talk to another RODC.
If you’re thinking of placing multiple RODCs in a given site, this is a very important rule to remember. Think of a situation where you have a branch office with two RODCs for the same domain. Let’s call these RODCs RODC01 and RODC02. Let’s also assume we have a user Brian who works out of this site. On RODC01, Brian’s password is cached; however, on RODC02, Brian’s password is not cached. When the WAN becomes unavailable at this site and a writeable domain controller is unable to be contacted, Brian attempts to log on to his workstation. Brian’s workstation contacts RODC02, and because the WAN is unavailable and RODC02 does not have Brian’s password cached, logon fails. Brian’s workstation will not try to contact a different domain controller and will instead simply tell Brian his password is invalid. Having multiple RODCs in a site can provide redundancy where necessary, but it can also provide a great deal of unpredictability. If you are planning to deploy multiple RODCs to a site, we recommend you prepopulate each RODC’s password cache.
When you create a trust between a given set of domains, a special type of object called a trustedDomain is created in Active Directory to represent that trust. The trustedDomain object includes a password that is used for communicating with the remote domain in the trust. RODCs will never cache trust passwords, which means that any time a user who is in a site serviced by an RODC wishes to communicate with a resource in a trusted domain, the RODC must go to a writeable domain controller to get the necessary Kerberos tickets. This is true even when the resources the user wishes to access are in the same site as the user. If the WAN is down, the user will be unable to access those resources since a writeable domain controller for the user’s domain cannot be contacted.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
RODCs and Replication
Inhaltsvorschau
One improvement that should greatly help with scalability when you are deploying branch offices is an RODC’s ability to automatically load balance connections to bridgehead servers in the hub site without manual intervention. Each time the KCC executes on an RODC, the RODC will check and see if there are new potential replication bridgeheads in the hub site, and if necessary the RODC will automatically switch replication to a different bridgehead server for the purpose of load balancing replication connections.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Administrator Role Separation
Inhaltsvorschau
One often-sought-after feature for domain controllers is the ability to separate administration of the domain controller hardware platform and operating system from administration of the Active Directory service. On a writeable domain controller, this is simply impossible since anyone who is an administrator on the domain controller can make changes that could elevate their privileges across the forest and lead to compromise of the forest. RODCs introduce the ability to delegate administrative control of the operating system to a third party, and we highly recommend that you do this as a best practice even if you are administering RODCs out of an Active Directory management team!
By delegating administrative rights to the RODC operating system to a group other than the Domain Admins group, you remove the need to ever log in to an RODC as a domain administrator. Keep in mind the paradigm of an RODC being compromised by default when you consider this recommendation. If you log in to a compromised RODC with an account with domain admin rights, you could be giving away your domain admin password, or perhaps the OS has been modified to run a login script under your domain administrator login that makes compromising changes to the directory via an RWDC.
You can configure a multitude of different local roles on an RODC; however, we expect the most common local role you will configure is the Administrators role. The list of available roles includes:
  • Administrators
  • Users
  • Guests
  • Remote Desktop Users
  • Network Configuration Operators
  • Performance Monitor Users
  • Performance Log Users
  • Distributed COM Users
  • IIS_IUSRS
  • Cryptographic Operators
  • Event Log Readers
  • Certificate Service DCOM Access
  • Incoming Forest Trust Builders
  • Terminal Server License Servers
  • Pre-Windows 2000 Compatible Access
  • Windows Authorization Access Group
  • Server Operators
  • Replicator
  • Account Operators
  • Backup Operators
  • Print Operators
In order to configure the local Administrators role on an RODC, you can use either ntdsutil or the Active Directory Users and Computers (ADUC) tool. ADUC limits you to configuring the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
This chapter has focused exclusively on the deployment of the read-only domain controller (RODC) into your environment. RODCs are a major feature in Windows Server 2008 Active Directory and are likely to play a key part in the Active Directory deployments of many organizations. RODCs mitigate key security risks around Active Directory with regard to domain controllers that are in physically insecure locations such as branch offices.
Over the course of this chapter, we took a look at changes in behavior between RODCs and their writeable counterparts. We explored the client logon process in depth and also discussed how RODCs handle write operations and time synchronization. We took a look at application compatibility testing requirements and known issues as well as important points to keep in mind when deploying RODCs within your Active Directory topology. We concluded our discussion with a look at the new administrative role separation functionality that RODCs enable, and stressed the importance of never logging in to an RODC with an account that has domain-level administrative privileges.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 8: Group Policy Primer
Inhaltsvorschau
Group Policy is a large topic that deserves a book in itself (and there are several of those) to be properly covered. We will discuss group policy as it applies specifically to the design and administration of an Active Directory in this book, but not Group Policy as it applies to the actual settings and operations on an Active Directory client.
The goal of policy-based administration is for an administrator to define the environment for users and computers once by defining policies, and then to rely on the system to enforce those policies. This chapter is an introduction to the Group Policy and how to manage it. covers how to begin designing Group Policy and the OU structures in support of Group Policy.
The scope and functionality of Active Directory group policies encompasses a number of key points:
  • They can be targeted to individual computers and users, sites, domains, and Organizational Units.
  • They can apply to users, computers, or groups of either.
  • They can set values and automatically unset them in specified situations.
  • They can do far more than just a desktop lockdown.
With group policies, an administrator can define a large number of detailed settings to be enforced on users throughout the organization and be confident that the system will take care of things. Let’s take an example from Leicester University. Administrators wanted the Systems Administrator toolset to be available on workstations they worked from. While they could install these tools on their own PCs, they also wanted the tools to follow them around the network and be available from any PC that they chose to log on from. However, they didn’t want to leave these tools installed on that PC when they logged off. Prior to Active Directory, the administrators would have had to arrive at a client, log on, install the toolset, do whatever was required at a client, uninstall the toolset, and finally log off. This would be a considerable chore when working with a large number of machines. Active Directory group policies can be used to specify that the toolset is to be automatically installed on any client that an administrator logs on to. That way, an administrator could go straight to the Start menu and find the tools available. When the group policy goes out of scope, the same group policy would uninstall the toolset from the machine.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Capabilities of GPOs
Inhaltsvorschau
GPOs can be edited using the Group Policy Management Editor (GPME), formerly the Group Policy Object Editor (GPME), which is an MMC snap-in. The GPME is limited to managing a single GPO at a time and cannot be used to link a GPO. For this reason, Microsoft developed the Group Policy Management Console (GPMC) MMC snap-in, which was released around the same time as Windows Server 2003 as a web download from http://www.microsoft.com/downloads/details.aspx?FamilyId=0A6D4C24-8CBD-4B35-9272-DD3CBFC81887. The Group Policy Management Console was bundled with Windows starting with Windows Server 2003 R2 and is available on Windows Vista SP1 as a feature of the Remote Server Administration Tools (RSAT) download.
The GPMC provides a single interface to manage all aspects of GPOs, including editing (through the GPME), viewing the resultant set of policies (RSOP), and linking to domains, sites, and OUs. In general, the GPMC is a vastly superior interface to managing group policies via the Active Directory Users and Computers (ADUC) MMC snap-in. We will utilize the GPMC through all of the examples in this book.
There are three different policy areas that a GPO supports. These areas include registry settings, security settings, and software installation. Most registry settings in a GPO have three states: enabled, disabled, and unconfigured. By default, all settings in a GPO are unconfigured. Any unconfigured settings are ignored during application, so the GPO comes into play only when settings have actually been configured. In some cases, the setting needs no other parameters, while in other cases, a host of information must be entered to configure the setting; it all depends on what the setting itself does.
Enabling and disabling most settings is fairly straightforward. However, due to Microsoft’s choice for the names of certain settings for GPOs, you actually can have the choice of enabling or disabling options with names such as “Disable Access to This Option.” By default, this setting isn’t in use, but you can disable the disable option (i.e., enable the option) or enable the disable option (i.e., disable the option). Be careful and make sure you know which way the setting is applied before you actually widely deploy the GPO.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
How Group Policies Work
Inhaltsvorschau
The remainder of this chapter takes an in-depth look at Group Policy Objects, focusing on two areas:
  • How GPOs work in Active Directory
  • How to manage GPOs with the Group Policy Object Editor and Group Policy Management Console
Group policies are very simple to understand, but their usage can be quite complex. Each GPO can consist of two parts: one that applies to a computer (such as a startup script or a change to the system portion of the registry) and one that applies to a user (such as a logoff script or a change to the user portion of the registry). You can use GPOs that contain only computer policies, only user policies, or a mixture of the two.
Any GPO is initially created as a standalone object in Active Directory. Each object can then be linked one or more times to three different container types: Sites, Domains, and Organizational Units. GPOs for domains and Organizational Units are held in the domain relating to their application, but creating a GPO for a site stores that GPO in the forest root domain by default; administrators can change this if they wish.
You cannot link group policies to containers. Users and computers that are stored in a container will apply policies linked to the domain or their site, however.
In the normal state of affairs, an administrator would customarily browse to a Site, Domain, or Organizational Unit in GPMC, and then create a GPO and link it to that object. At this point, it appears that you have created a GPO at that location in the tree rather than what really happened, which was that the system created the GPO as a standalone object in the Policies container and then immediately linked it to that .
To apply a GPO to a set of users or computers, you simply create a GPO in Active Directory and then link it to a Site, Domain, or Organizational Unit. Then, by default, the user portion of the GPO will apply to all users in the tree, and the computer portion of the GPO will apply to all computers in the tree.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Managing Group Policies
Inhaltsvorschau
The Microsoft tools available to manage GPOs under Windows 2000 were pretty limited, consisting of the Group Policy Object Editor (formerly Group Policy Editor) and built-in support in the Active Directory Users and Computers and Active Directory Sites and Services snap-ins. While these tools could get the job done, they did not provide any support for viewing the Resultant Set of Policy (RSoP), viewing how GPOs had been applied throughout a domain, or backing up or restoring GPOs.
Directly after the release of Windows Server 2003, Microsoft released the Group Policy Management Console (GPMC) as a separate web download. The GPMC is a much-needed addition to Microsoft’s GPO management tools and provides nearly every GPO management function that an organization might need, including scripting support.
The other new feature available in the Windows Server 2003 Active Directory administrative tools and in GPMC is support for viewing the RSoP for a given computer based on certain criteria. RSoP allows administrators to determine what settings will be applied to a user and can aid in troubleshooting GPO problems. RSoP will be described in more detail in the section on debugging group policies.
The Windows Server 2008 version of the Active Directory administrative tools no longer includes RSoP. You must instead use the GPMC.
The GPMC is a one-stop shop for all your GPO management needs. You can browse a forest and see where GPOs are applied; you can create and link GPOs; you can import and export, backup and restore, delegate control, and view RSoP reports, all from the GPMC. Not only does the GPMC have a bunch of new functionality not available in any of the previous standard tools, it also integrates the existing tools—such as the GPME for editing GPOs.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Troubleshooting Group Policy
Inhaltsvorschau
If, at any point, you need to debug group policies, there are couple of available options. The first is new as of Windows Server 2003 and is called the Resultant Set of Policy, which some people may be familiar with if you’ve used tools like Full Armor’s Fazam 2000. The Resultant Set of Policy (RSoP) allows you to specify certain user, computer, group, and GPO criteria to determine what GPOs will be applied. Another option is to enable some extra logging that can help point out GPO processing problems.
The Group Policy Results Wizard is a frontend for the Resultant Set of Policy (RSoP) tool. RSoP is a very powerful tool that will identify what GPO settings have been applied to a user or computer. Before RSoP, administrators were left to do their own estimates as to what GPOs took precedence and what settings were actually applied to users and computers. RSoP removes much of the guesswork with an easy-to-use wizard interface.
Figure : Group Policy Results Wizard target selection
Figure : Target-user selection
To start the Group Policy Results wizard, open the GPMC, and right click the Group Policy Results folder and launch the “Group Policy Results Wizard.” shows the initial screen where you will be prompted to select a target machine to run the RSoP session on.
The next screen, as shown in , allows you to optionally specify what user to run the RSoP session in the context of. If you only need computer settings, you can skip this step. The wizard will only display users who have logged on to the target machine successfully in the past.
Once you finish the wizard, the GPMC will create a report similar to the one shown in . This report is divided into three sections:
  • The summary view gives a high-level overview of which policies were applied, filters that were executed, and so forth.
  • The settings view allows you to view every setting that was applied and the GPO this setting originated from.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
One of the big selling points of Active Directory has always been group policy, and in Windows Server 2008 Active Directory, Microsoft greatly extended the functionality and management of GPOs. In this chapter, we covered the details of how group policies are stored in Active Directory, how GPOs are processed by clients, the GPO precedence order, the effect of inheritance, and the role ACLs play.
With Windows Server 2003, Microsoft introduced several new tools to help manage and troubleshoot GPOs. Perhaps the most important is the Group Policy Management Console (GPMC), which is a one-stop shop for all your GPO needs. With the GPMC, you can perform virtually any function you need to do from a single interface, as opposed to using three or four separate tools as was necessary with the Windows 2000 tools. Another benefit of the GPMC is that it installs several COM objects that allow you to script many of your GPO management functions.
There are a number of troubleshooting and diagnostic tools available for discerning what happened when things go wrong that we introduced in this chapter as well.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 9: Fine-Grained Password Policies
Inhaltsvorschau
Undoubtedly, one of the most exciting new features in Windows Server 2008 Active Directory is the introduction of a feature called fine-grained password policies (FGPPs). Prior to FGPPs, domain account policies (password and lockout policies, specifically) could only be set on a per-domain basis. If you had a requirement to have separate password-complexity requirements for two sets of users, you could either deploy a third-party password filter or deploy a second domain. Fine-grained password policies solve both of these issues within a single domain and are immediately available once your domain is running at Windows Server 2008 domain functional level.
Fine-grained password policies you create are represented by Password Setting Objects (PSOs) within Active Directory. PSOs are standard Active Directory objects and are stored under the System container in the domain partition.
Fine-grained password policies functionality is new to Windows Server 2008 and, as such, Windows Server 2003 and earlier versions of Windows domain controllers are not capable of enforcing the functionality. FGPPs become available once the domain has been promoted to Windows Server 2008 Domain Functional Level. While you can create and manage PSOs before your domain is running at the Windows 2008 Domain Functional Level, the policies will have no effect on users.
Unfortunately, Microsoft did not include a dedicated toolset to manage Password Setting Objects in Windows Server 2008. In order to manage PSOs with the out-of-the-box toolset, you’ll need to use ADSI Edit or an LDIF file. ADSI Edit was enhanced in Windows Server 2008, so at least you will not need to convert values to the special underlying formats required by Active Directory to create the PSOs. An alternative to the built-in tools is a freely available tool called PSOMgr. PSOMgr is a command-line interface designed specifically for managing PSOs. You can get PSOMgr at http://www.joeware.net/freetools/tools/PSOMgr/. Since PSOMgr is so much easier to use, we will use it throughout this chapter.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Understanding Password Setting Objects
Inhaltsvorschau
Fine-grained password policies you create are represented by Password Setting Objects (PSOs) within Active Directory. PSOs are standard Active Directory objects and are stored under the System container in the domain partition.
Fine-grained password policies functionality is new to Windows Server 2008 and, as such, Windows Server 2003 and earlier versions of Windows domain controllers are not capable of enforcing the functionality. FGPPs become available once the domain has been promoted to Windows Server 2008 Domain Functional Level. While you can create and manage PSOs before your domain is running at the Windows 2008 Domain Functional Level, the policies will have no effect on users.
Unfortunately, Microsoft did not include a dedicated toolset to manage Password Setting Objects in Windows Server 2008. In order to manage PSOs with the out-of-the-box toolset, you’ll need to use ADSI Edit or an LDIF file. ADSI Edit was enhanced in Windows Server 2008, so at least you will not need to convert values to the special underlying formats required by Active Directory to create the PSOs. An alternative to the built-in tools is a freely available tool called PSOMgr. PSOMgr is a command-line interface designed specifically for managing PSOs. You can get PSOMgr at http://www.joeware.net/freetools/tools/PSOMgr/. Since PSOMgr is so much easier to use, we will use it throughout this chapter.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Scenarios for Fine-Grained Password Policies
Inhaltsvorschau
Nearly all of the settings that you could historically only define in the Default Domain Policy for the entire domain can be configured with Password Setting Objects. The exceptions to this rule are the Kerberos settings that must still be defined on a per-domain basis via Group Policy.
If you are using one or more custom password filters in your domain, you can continue to utilize these filters in addition to fine-grained password policies.
Each of the settings in question is stored as an attribute of the msds-PasswordSettings schema class that was added with the Windows Server 2008 schema extensions. These attributes are outlined in .
Table : Mandatory Password Setting Object attributes
Attribute
Description
cn
The name of the PSO
msDS-PasswordSettingsPrecedence
The order of precedence of the PSO in the event multiple PSOs apply to a user
msDS-PasswordReversibleEncryptionEnabled
Toggles storing the password with reversible encryption
msDS-PasswordHistoryLength
The number of previous passwords stored in Active Directory
msDS-PasswordComplexityEnabled
Toggles password complexity checking
msDS-MinimumPasswordLength
The minimum length of the password
msDS-MinimumPasswordAge
The minimum interval before the password can be reset
msDS-MaximumPasswordAge
The maximum age of the password before it must be reset
msDS-LockoutThreshold
The number of failed login attempts necessary to trigger a lockout
msDS-LockoutDuration
The number of minutes to lock the account out
msDS-LockoutObservationWindow
The time window during which the lockout threshold is
When you define your strategy for using password setting objects, you will need to determine the number of separate PSOs you will require to implement your strategy, as well as the relevant values for each PSO. All of the settings for a given user will come from a single PSO as the settings from multiple PSOs are not merged. This may mean that you will need to duplicate some common settings across multiple PSOs.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Creating Password Setting Objects
Inhaltsvorschau
Now that we’ve discussed the basics of password setting objects, we’ll go ahead and provision a PSO in the domain in order to walk through the process.
Password Setting Objects are stored in the Password Settings Container under the System container at the root of your domain as shown in . You will need to select View→Advanced Features in Active Directory Users and Computers in order to view the contents of the System container.
Figure : Password Settings Objects
One useful feature of PSOMgr is its ability to get you started with a copy of your domain password policy (as defined via Group Policy), as well as some common PSO templates. For the sake of simplicity, we’ll be working with the common PSO templates PSOMgr creates throughout most of this chapter. In order to create these PSOs, you’ll need to run this command: PSOMgr /quickstart /forreal. In any case where PSOMgr is going to make changes to your environment, you must specify the /forreal switch as a confirmation. If you don’t do this, PSOMgr will simply print out the changes it would make in the event you specify /forreal. shows the results of running the /quickstart option.
While the quick-start examples PSOMgr makes are excellent, chances are you may want to define one or more PSOs with custom settings. In this section, we’re going to walk through creating a PSO with the settings defined in both with the GUI and with PSOMgr.
Table : Custom PSO settings
Setting
Value
ADSI Edit formatted value
Name
CustomPSO1
CustomPSO1
Precedence
11
11
Reversible Encryption Enabled
No
FALSE
Password History Length
10 passwords
10
Password Complexity Enabled
Yes
TRUE
Minimum Password Length
8 characters
8
Minimum Password Age
1 day
1:00:00:00
Maximum Password Age
90 days
90:00:00:00
Account Lockout Threshold
15 failed logons
15
Account Lockout Window
30 minutes
00:00:30:00
Account Lockout Observation Window
30 minutes
00:00:30:00

Creating a PSO with ADSI edit

In order to create a PSO with the GUI, we’ll need to use ADSI Edit. While you can use Windows Server 2003 and earlier versions of ADSI Edit, the logic to make entering some of the values in a PSO (specifically the durations) significantly less painful is only available in the Windows Server 2008 version of ADSI Edit. You can launch ADSI Edit by going to Start→Run→adsiedit.msc. When you launch ADSI Edit for the first time, you’ll need to connect to a partition. In our case we want to connect to the Domain NC for the domain we’re currently logged in to. To do this, go to Action→Connect To. The Connection Settings dialog, shown in , gives you the option to specify a domain and/or server to connect to.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Managing Password Settings Objects
Inhaltsvorschau
As noted earlier, Microsoft doesn’t have a comprehensive tool for managing PSOs, so we’re forced to go to a few different places to get the information we need. If you’re comfortable with the command line, PSOMgr will do all of the tasks in this section. In some cases, we can use Active Directory Users and Computers (ADUC) or ADSI Edit to manage PSOs, though. This section focuses on managing existing PSOs and the application of them to users.
There are a few strategies for managing which PSO applies to your user population, and you’ll have to decide on which strategy works best based on your organization. The first strategy is to define a global security group for each PSO and apply the PSO to that group. You can, in turn, place users (or nest additional global groups) in the group. The second strategy is to apply PSOs directly to users or existing groups. Of course, the third strateogy here is to mix application to groups and users where necessary.

Applying PSOs to groups

Applying your PSOs primarily to groups is likely to be the most scalable strategy for many organizations. The strategy here is that you create a global group for each PSO and place the users who the PSO will apply to in this group. While you can reuse existing global security groups, we recommend that you create new groups dedicated just to application of PSOs. This ensures that you will not affect users inadvertently by adding or removing them from a group that controls PSOs or resource access.
It is important to remember that only global security groups are applicable for applying a PSO to a user. While you can link a PSO to a universal or domain local group, it will not actually be considered for application to the user in the resultant PSO calculation.
If multiple PSOs apply to a user by virtue of being a member of multiple groups linked to different PSOs, the PSO with the lowest precedence will win and in the case of multiple PSOs with the same precedence, the PSO with the smallest GUID will win.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Delegating Management of PSOs
Inhaltsvorschau
One of the decisions you will likely need to make when planning your implementation of fine-grained password policies is who will manage the PSOs. It is likely that this will fall into the hands of a few different groups or tools depending on the organization. One possibility is that the Active Directory team will manage the PSOs in which case this section is somewhat irrelevant. Another possibility is that the PSOs will be controlled by an information security team. A third is that PSOs will be managed indirectly by an identity management/provisioning system.
In the event that the Active Directory team owns PSOs end-to-end, you likely will not need to perform any delegation of security rights to accomplish the management of PSOs. In the event a separate team such as an information security group controls PSOs, you will need to delegate the necessary rights. In this case, it is likely there will be three ways you can handle the delegation:
Delegate access to only application groups
In this scenario you would strictly employ a design of applying password policies based on security groups with no exceptions. The information security group would be delegated access to these groups and be responsible for managing the membership of the groups. When a new PSO is deemed necessary, they will need to engage the Active Directory team to create it. This model creates a system of checks and balances to ensure that growth in the number of PSOs is managed. This model would also require that the Active Directory team be engaged to modify the settings on a PSO.
Delegate access to modify PSOs and application groups
In this case you would delegate access to modify existing PSOs and also to manage the membership of application groups. The information security group would be able to modify the specific settings on a PSO and control where the PSO is applied. If you feel that you will often need to implement exceptions where PSOs are linked directly to users, this model will enable this to be done independent of the Active Directory team. While chances are that the frequency of changes to PSO settings should be rare, this model also mitigates the need to engage the Active Directory team for those changes. The system of checks and balances for creating new PSOs still exists here.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
Fine-grained password policies are an important and long-awaited new feature in Windows Server 2008. FGPPs allow administrators to define Password Settings Objects and apply different password and account lockout policies to different sets of users in the domain. PSOs can be applied either to global security groups that users are members of, or directly to users.
Managing PSOs is possible either with the ADSI Edit GUI or with the free PSOMgr command-line tool. The PSOMgr tool offers a number of enhanced features that any administrator who is planning to deploy FGPPs should at least investigate.
Due to the manner in which PSOs are implemented in Active Directory, you will need to consider the management and delegation model of those PSOs as it applies to your organization. Applying PSOs to groups provides flexibility in delegating this .
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 10: Designing the Namespace
Inhaltsvorschau
The emphasis of this chapter is on reducing the number of domains that you require for Active Directory while gaining administrative control over sections of the Active Directory domain namespace using Organizational Units. The purpose of this chapter is to help you create a domain namespace design. That includes all the domains you will need, the forest and domain-tree hierarchies, and the contents of those domains in terms of Organizational Units and even groups.
When designing a forest, remember that there are often multiple good answers to forest design for any given company. There is no “best” design for all situations. Microsoft has provided great flexibility in what can be done, which can turn around and bite you with indecision on how you should implement. It isn’t unusual for two engineers to have two very different designs for the same company that are both good for completely different reasons. Simply document all recommended designs and let the decision makers decide together which one will be the best for long-term operations. Overall, the best solutions are usually the simplest solutions. In most cases, you will want to choose single-forest designs over multiforest designs, single-tree designs over multitree designs, and single-domain designs over multidomain designs. The design example shown here is simply that: an example. The company in question could have designed their Active Directory infrastructure in a number of ways, and this is one of them.
There are a number of restrictions that you have to be aware of when beginning your Active Directory design. We will introduce you to them in context as we go along, but here are some important ones:
  • The forest, not the domain, is the security boundary for Active Directory. Anyone with high-level access rights on any writeable domain controller in any domain can negatively impact or take control of any other DC or domain in the forest.
  • Under Windows 2000, you cannot rename a domain once it has been created. Fortunately, with Windows Server 2003, this limitation has been removed given specific caveats, although the rename process is tedious. You can even rename forest root domains once you’ve reached the Windows Server 2003 forest functional level. If you are running Exchange, however, there are additional considerations and limitations for domain renames. In general, domain renames are not a recommended endeavor, so you should aim to never need to perform one.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
The Complexities of a Design
Inhaltsvorschau
Active Directory is a complex service, and designing for it isn’t easy. Take a look at a fictitious global company called PetroCorp, depicted in .
Figure : The sites and servers of a company called PetroCorp
Here you can see a huge network of sites linked with various network connections across wide area networks. A variety of domains seems to exist for othercorp.com and petrocorp.com, and as each one of those square boxes represents a single domain controller, you can see that some of the servers will need to replicate data across those WAN links. petrocorp.com, for example, seems to need to replicate to all the major sites, since it has domain controllers (DCs) in each of those sites.
Take a look at , which shows a much more complex hierarchy.
It’s possible to see the users and computers in all the Organizational Units in this view, and the structure seems to be set up so that Group Policy Objects (represented by trapezoids) can be applied to various portions of the tree. The following is a discussion of the principles and processes that will help you create complicated designs like these to mirror the complexities in your own organization.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Where to Start
Inhaltsvorschau
Before you sit down to make your design, you will need to obtain some important pieces of information. At a minimum, you will need:
  • A copy of your organizational structure, since this is effectively the document that explains how your organization’s business units fit together in the hierarchy.
  • A copy of the geographical layout of your company. This includes the large-scale picture in continents and countries and also the individual states, counties, or areas in which you have business units.
  • A copy of the network diagram(s), indicating the speeds of connection between the various sites.
  • A copy of any diagrams and information on any systems that will need to interface to Active Directory, such as existing X.500 and LDAP directories, so that you can take them into account.
Once you’ve gathered the information, you can sit down and plan your design.
Figure : A complex domain tree showing GPOs
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Overview of the Design Process
Inhaltsvorschau
The namespace design process takes place in two stages:
Design of the domain namespace
During the first stage, you deal with the namespace design itself. That means calculating the number of domains you need, designing the forest and tree structure, and defining the naming scheme for workstations, servers, and the network as a whole.
Design of the internal domain structure
During the second stage, you need to concentrate on the internal structure of each domain that you have previously noted. Here you also need to use your business model as a template for the internal structure and then move on to consider how administration and other rights will be delegated. The internal structure can also be modified depending on how you intend to use Group Policy Objects; this will be covered in .
When you are finished with your design, you can implement it by setting up a test forest in a lab environment. This will enable you to get a better feel for how the design actually works and whether there is anything you have failed to consider. We can’t stress enough the importance of a test environment.
When working on the budget for your production forest, include time, money, and resources for the test environment as well. This up-front expenditure will likely save you considerable back-end mistakes and uncertainty on a continual basis.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Domain Namespace Design
Inhaltsvorschau
The first stage in your design is to work out the domain, domain tree, and forest configuration of your network. The best way to do this is to make a first pass at designing the domains and then structure them together into a single tree or a series of trees. Before we start, however, let’s take a look at our objectives for this part of the design.
There are two objectives for the design of the domain namespace:
  • Designing Active Directory to represent the structure of your business
  • Minimizing the number of domains by making much more use of the more flexible Organizational Units

Represent the structure of your business

When designing your Active Directory, you should aim to make it both match the structure of your business, and also be managed by whatever management model your IT organization operates under. Typically, organizations fall into one of three or four common models for managing their IT infrastructure:
Centralized administration
In this model, your entire IT infrastructure is centrally managed by one team.
Decentralized administration
In this model, your IT infrastructure is typically managed either locally at each location or on an organizational basis, perhaps by department or division. It is difficult to deploy a common Active Directory forest in this model as standards are often lax or nonexistent and Active Directory doesn’t lend particularly well to being administered by a large group from an infrastructure (e.g., domain controllers and forest-level configuration) perspective.
Hybrid centralized/decentralized administration
In a large organization this is likely to be the most common model. Certain components of the Active Directory are managed centrally, such as the domain controllers and enterprise-wide configuration, while other components such as objects stored in OUs are managed by distributed IT staff.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Design of the Internal Domain Structure
Inhaltsvorschau
Having designed the domain namespace, you can now concentrate on the internals of each domain. The design process itself is the same for each domain, but the order is mostly up to you. The first domain that you should design is the forest root domain. After that, iterate through the tree, designing subdomains within that first tree. Once the tree is finished, go on to the next tree and start at the root as before.
In a tree with three subdomains called Finance, Sales, and Marketing under the root, you could either design the entire tree below Finance, then the entire tree below Sales, and so on, or you could design the three tier-two domains first, then do all the subdomains immediately below these three, and so on.
When designing the internals of a domain, you need to consider both the hierarchical structure of Organizational Units and the users and groups that will reside within those Organizational Units. Let’s look at each of those in turn.
When we refer to a hierarchy, a tree, or the directory tree, we mean the hierarchical Organizational Unit structure within a domain. We are not referring to the hierarchy of domain trees in a forest.
Earlier, when we discussed how to design domains, we spoke of how to minimize the number of domains you have. The idea is to represent most of your requirements for a hierarchical set of administrative permissions using Organizational Units instead.
Organizational Units are the best way to structure your data because of their flexibility. They can be renamed and easily moved around within and between domains and placed at any point in the hierarchy without affecting their contents. These two facts make them very easy for administrators to manage.
There are four main reasons to structure your data in an effective hierarchy:
To represent your business model to ease management
Partitioning your data into an Organizational Unit structure that you will instantly recognize makes managing it much more comfortable than with every user and computer in one Organizational Unit.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Other Design Considerations
Inhaltsvorschau
In many cases, you may need to revise your namespace designs a number of times. Certainly GPOs will make a difference as to how you structure your users and computer objects, so we do not assume that one pass through a design process will be enough.
Once you have a basic design, there is nothing stopping you from putting that design to one side and working on identifying a perfect design for your Active Directory network, one that you would like to implement in your organization, ignoring all Active Directory-imposed design constraints. You then can work out how difficult it will be to move to that perfect design from the practical one that you worked out using the preceding steps. You can look at the feasibility of the move from one to the other and then rationalize and adjust your final design to take into account the factors you have listed. You can then use this as an iteration tool so that your final design is much closer to the perfection you are aiming for.
Apart from GPOs, which we cover in Chapters and , there are other aspects of Active Directory design that we have not and will not be covering. For example, you are quite likely to want printers advertised in Active Directory so that they can be accessed easily using a simple search of Active Directory (which the Add Printer wizard now uses as the default option). The Distributed File System (DFS) that allows you to organize disjointed and distributed shares into a single contiguous hierarchy is a fine example of this. When you reference a share held by the DFS, the DFS uses the Active Directory site topology to automatically redirect your request to the closest share replica. There is also the matter of designing your own objects and attributes that you want to include. However, there are two points that you should consider:
  • As a general rule, Active Directory should hold only static or relatively static data. At the very least, the lifetime of the data has to be greater than the time to replicate to all DCs throughout the organization. When considering which objects to add, don’t consider adding objects with very short life spans. Dynamic data—that is, data with a relatively short lifespan—is more suited for storage in an application partition or an ADAM instance. Windows Server 2003 introduces the ability to host data with a short lifespan through the use of dynamic objects.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Design Examples
Inhaltsvorschau
Having covered the design of the namespace, some real-world example designs are in order. We have created three fictitious companies that will serve as good models for demonstrations of the design process. We will also use these three companies in the following chapters. The companies themselves are not fully detailed here, although there is enough information to enable you to make a reasonable attempt at a namespace design. In the chapters that follow, we will expand the relevant information on each company as required for that part of the design.
We used a number of criteria to create these companies:
  • The companies were set up to represent various organizations and structures.
  • While each corporation has a large number of users and machines, the design principles will scale down to smaller organizations well.
  • In these example corporations, we are not interested in how many servers each company has or where those servers are. These facts come into play in the next chapter on sites. We are interested in users, groups, machines, domains, and the business and administration models that are used.
TwoSiteCorp is an organization that employs 50,000 people using 50,000 desktop computers. The organization spans two sites connected with a 128 KB dedicated link. The London site has 40,000 clients and 40,000 employees, while the new expansion at the Leicester site has 10,000 clients and 10,000 employees. TwoSiteCorp’s business model is based on a structure in which users are members of one of three divisions: U.K. Private Sector, U.K. Public Sector, and Foreign. No division is based entirely at one site. Various other minor divisions exist beneath these as required for the management structure. Administration is handled centrally from the major London site by a team of dedicated systems administrators.

Step 1: Set the number of domains

While TwoSiteCorp’s 128 KB link between its two physical locations is slow for site purposes, there is no need to split the two sites into two domains. No particular part of the organization has a unique policy requirement, because the administrators decided that they will implement one set of policies for all users. Finally, the sites already have two Windows NT domains installed. However, management has no desire to maintain either, so both will be rationalized into one domain. Thus, TwoSiteCorp will end up with one domain.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Designing for the Real World
Inhaltsvorschau
It’s very easy to get bogged down in the early stages of the namespace design without actually progressing much further. The stumbling block seems to be that it feels conceptually wrong to have only one domain, yet administrators can’t put their finger on what the problem is. If you follow the guidelines in the initial steps of the namespace design, you quite possibly could end up with one domain to start with.
This is partly a conceptual problem: a set of domains with individual objects managed by different teams can feel more secure and complete than a set of Organizational Units in a single domain containing individual objects managed by different teams. It’s also partly an organizational problem and, possibly, a political problem. Putting in an Active Directory environment is a significant undertaking for an organization and shouldn’t be taken lightly. This change is likely to impact everyone across the company, assuming you’re deploying across the enterprise. Changes at that level are likely to require ratification by a person or group who may not be directly involved on a day-to-day basis with the team proposing the change. So, you have to present a business case that explains the benefits of moving to Active Directory.
Following our advice in this chapter and Microsoft’s official guidelines from the whitepapers, TechNet, or the Resource Kit will lead most companies to a single domain for their namespace design. It is your network, and you can do what you want. More domains give you better control over replication traffic but may mean more expense in terms of hardware and administrative overhead. If you do decide to have multiple domains but have users in certain locations that need to log on to more than one domain, you need DCs for each domain that the users need in that location. This can be expensive. We’ll come back to this again later, but let’s start by considering the number of domains you need.
If the algorithm we use to help you determine the number of domains gives you too small a figure in your opinion, here’s how you can raise it:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we presented seven steps toward effective namespace design:
  1. Decide on the number of domains.
  2. Design and name the tree structure.
  3. Design the workstation- and server-naming scheme.
  4. Design the hierarchy of Organizational Units.
  5. Design the users and groups.
  6. Design the Global Catalog.
  7. Design the application partition structure.
Following these seven steps allows you to solve the two main objectives of this chapter:
  • Come up with an Active Directory namespace design to represent the structure of your business.
  • Minimize the number of domains by making much more use of the more flexible Organizational Units.
Although we’ve shown you how to start to design your Active Directory, there is still a long way to go. Designing the namespace of domains, trees, and forests and the internal Organizational Unit hierarchy according to the guidelines given here means that you should have a structural template that represents your business model within the preceding restrictions. Hopefully this design makes sense in terms of your organization and will be simpler to manage.
The rest of the design still needs to be completed. You need to look at the low-level network links between sites and how they will affect your replication decisions. You then need to tackle the subject of how to revise the initial namespace design based on Group Policy Objects, security delegation and auditing, schema changes, and so on. Next we’ll move on to designing the physical site topology that the DCs use when communicating with one another.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 11: Creating a Site Topology
Inhaltsvorschau
As we mentioned in , there are two aspects to replication:
  • How data gets replicated around an existing network of links between domain controllers
  • How the Knowledge Consistency Checker generates and maintains the replication links between domain controllers, both intrasite and intersite
We covered the former in , and we’ll cover the latter here, leading to an explanation of how to properly design a representation of your organization’s network infrastructure within Active Directory.
Two distinct types of replication connections exist with Active Directory sites: intrasite (within sites) and intersite (between sites). An Active Directory service known as the Knowledge Consistency Checker (KCC) is responsible for automatically generating the replication connections between intrasite DCs. The KCC will create intersite connections automatically for you as well, but only when an administrator has specified that two sites should be connected via a site link. Every aspect of the KCC and the connection objects that are created is configurable, so you can manipulate what has been automatically created and what will be automatically created via manipulation of the various options.
Note that there is a large distinction between the KCC (the process that runs every 15 minutes and creates the replication topology) and the replication process itself. The KCC is not involved in the regular work of replicating the actual data in any way. Intrasite replication along the connections created by the KCC uses a notification process to announce that changes have occurred—each domain controller is responsible for notifying its replication partners of changes. If no changes occur at all within a six-hour period, the replication process is kicked off automatically just to make sure that nothing was missed. Intersite replication, on the other hand, does not use a notification process by default. Instead, intersite replication relies on a schedule to transfer updates, using compression to reduce the total traffic size.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Intrasite and Intersite Topologies
Inhaltsvorschau
Two distinct types of replication connections exist with Active Directory sites: intrasite (within sites) and intersite (between sites). An Active Directory service known as the Knowledge Consistency Checker (KCC) is responsible for automatically generating the replication connections between intrasite DCs. The KCC will create intersite connections automatically for you as well, but only when an administrator has specified that two sites should be connected via a site link. Every aspect of the KCC and the connection objects that are created is configurable, so you can manipulate what has been automatically created and what will be automatically created via manipulation of the various options.
Note that there is a large distinction between the KCC (the process that runs every 15 minutes and creates the replication topology) and the replication process itself. The KCC is not involved in the regular work of replicating the actual data in any way. Intrasite replication along the connections created by the KCC uses a notification process to announce that changes have occurred—each domain controller is responsible for notifying its replication partners of changes. If no changes occur at all within a six-hour period, the replication process is kicked off automatically just to make sure that nothing was missed. Intersite replication, on the other hand, does not use a notification process by default. Instead, intersite replication relies on a schedule to transfer updates, using compression to reduce the total traffic size.
The KCC and the topologies it generates were dramatically improved in Windows Server 2003 Active Directory. With Windows 2000 Active Directory, when there were more than 200 sites with domain controllers, it could take the KCC longer than 15 minutes to complete and would also drive up CPU utilization. Since the KCC runs every 15 minutes, it could get backlogged as a result or not finish at all. Typically when faced with this situation, administrators had to disable the KCC and manually create connection objects. With Windows Server 2003, Microsoft has stated that the new limit is closer to 5,000 sites when running a forest at the Windows Server 2003 forest functional level, which is a vast improvement. In fact, the KCC was largely rewritten in Windows Server 2003 and became much more scalable and efficient.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Designing Sites and Links for Replication
Inhaltsvorschau
There is only one really important point that is the overriding factor when designing a replication strategy for your network: how much traffic and over what period will you be replicating across the network? However, replication isn’t the only reason for creating sites. Sites also need to exist to group sets of machines together for ease of locating data, finding the nearest DC to authenticate with, finding the nearest DFS share mount point, or routing email in Exchange 2007 organizations.
Before you sit down to design your site and WAN topology, you need to obtain the map of your existing network infrastructure. This map should contain all physical locations where your company has computers, along with every link between those . The speed and reliability of each link should be noted.
If you have an existing IP infrastructure, write down all the subnets that correspond to the sites you have noted.
From the network diagram, you need to draw your site structure and name each site, using a one-to-one mapping from the network diagram as your starting point. If you have 50 physical WAN locations, you have 50 sites. If only 30 of these will be used for Active Directory, you may not see a need to include the entire set of sites in Active Directory. If you do include the entire set, however, it is much easier to visualize your entire network and add clients or servers to those locations later.
When drawing Active Directory topologies, sites normally are represented by ovals.
Remember that a site is a well-connected set of subnets (“well-connected” tends to mean about 10 Mbps LAN speed). A site does not have to have a domain controller in it; it can be composed entirely of clients. If you have two buildings (or an entire campus) that is connected over 10/100 Mbps links, your entire location is a single site.
This is not a hard-and-fast rule. By the normal rules, two locations connected over a 2 Mbps link represent two distinct sites. You can, however, group networks together into single sites if you want to. You have to appreciate that there will be more replication than if you had created two sites and a site link, because DCs in both physical locations will maintain the intrasite replication ring topology. If you had created two sites and a site link, only two bridgehead servers would replicate with each other.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Examples
Inhaltsvorschau
Having considered the 6 steps, let’s take another brief look at the three examples from the previous chapter and see what they will need in terms of sites.
TwoSiteCorp has two locations split by a 128 Kbps link. This means creation of two sites separated by a single site link, with DCs for domain authentication in each site. The site link cost is not an issue, as only one route exists between the two sites; whether the link cost is set to 1 or 500, you get the same result. Here the only issue is scheduling the replication, which depends on the existing traffic levels of the link. For a slow link like this one, it is best to schedule replication during the least busy times. If replication has to take place all the time, as changes need to be propagated rapidly, it may be time to consider increasing the capacity of the link.
RetailCorp has a large, centralized retail organization with 600 shops connected via 64 Kbps links to a large centralized 10/100 Mbps interconnected headquarters in London. In this situation, you have one site for HQ and 600 sites for the stores. RetailCorp also uses a DC in each store. They then have to create 600 high-cost site links, each with the same cost. RetailCorp decides this is one very good reason to use ADSI (discussed in Part III) and writes a script to automate the creation of the site link objects in the configuration. The only aspect of the site links that is important here is the schedule. Can central HQ cope with all of the servers replicating intersite at the same time? Does the replication have to be staggered? The decision is made that all data has to be replicated during the times that the stores are closed; for stores that do not close, data is replicated during the least busy times. There is no need to worry about site link bridges or site link transitiveness as all links go through the central hub, and no stores need to intercommunicate. The administrators decide to let the KCC pick the bridgehead servers automatically.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Additional Resources
Inhaltsvorschau
Microsoft has produced an outstanding guide for customers setting up a branch office deployment. A branch office deployment is a deployment with a large number of WAN sites that need to host local copies of Active Directory. One example of a branch office deployment is a large retail outlet that has a central office and hundreds of retail outlets that are all tied together into the same forest. If you have to deploy this kind of infrastructure, you absolutely need to review the Windows Server 2003 Active Directory Branch Office Guide; you can find it on the Microsoft web site at http://www.microsoft.com/downloads/details.aspx?FamilyId=9353A4F6-A8A8-40BB-9FA7-3A95C9540112.
Bridgehead load balancing is an area that Microsoft greatly improved in Windows Server 2003. Although Windows Server 2003 will better distribute the replication load across multiple domain controllers, the new load-balancing algorithm will only work with new connections that are established; so, when you add a new domain controller, it will be underutilized for replication connections. Windows 2000, on the other hand, will not spread the load at all, which can create a topology that results in overloaded bridgehead servers in hub sites. Microsoft produced a tool to help with both of these issues. The tool is called the Active Directory Load Balancer (ADLB) and will look at the connection objects for a specified site and evenly spread those connections across all of the DCs in the site that can be used as bridgeheads. ADLB is part of the Windows Server 2003 Resource Kit Tools and is available for download from http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
Based on this chapter, you should have a good understanding of how to go about designing the site topology for your Active Directory deployment and also how to determine if a domain controller is necessary in any given site. Site topologies are leveraged by Active Directory for replication and also by various other applications such as DFS and Exchange Server 2007. Clients also rely on the site topology to locate a domain controller for authentication.
The Knowledge Consistency Checker (KCC) is the process that runs automatically on each domain controller to generate the underlying replication connections. Intersite replication connections are generated on one domain controller in a site that is designated the Intersite Topology Generate (ISTG) for that site.
Planning your site topology requires a good understanding of the underlying network as you apply it to your requirements for sites, site links, and site link bridges. Sites represent disparate network locations that you want to segregate replication and traffic between. Site links represent the connectivity between sites, and site link bridges provide the KCC with hints about transitivity between site links for generating the necessary connections for replication to occur.
The next chapter deals with how to update your designs to reflect your requirements for Group Policy Objects in your organization.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 12: Designing Organization-Wide
Inhaltsvorschau
This chapter takes an in-depth look at Group Policy Objects (GPOs), focusing on how to structure your Active Directory effectively using Organizational Units and groups so that you can make the best use of the GPOs required in your organization.
In , we described the design of the Active Directory Organizational Unit hierarchy. We also explained that other items have a bearing on that design. You see, there are two key design issues that affect the structure of your Organizational Units: permissions delegation and GPO placement. If you decide that your Active Directory is to be managed centrally rather than in a distributed fashion and that you will employ only a few GPOs that will be implemented mostly domain-wide (rather than many GPOs on many Organizational Units), your Organizational Unit structure can be almost any way that you want it to be. It shouldn’t make much difference whether you have 400 branches coming off the root or one container with every item inside it. However, if permissions over specific objects do need to be delegated to specific sets of administrators, it will make more sense to structure your domain Organizational Units in a manner that facilitates that administration. This doesn’t have to be the case, but it makes it much easier to use Organizational Units.
For example, if we have 1,000 users and 10 managers who each manage 100 users, we could put the 1,000 users in one Organizational Unit and give the 10 administrators permission to modify only their 100 users. This is a slow and daft way to run systems administration. It would be better to create 10 Organizational Units and put 100 users in each, giving each administrator permissions over his particular Organizational Unit. This makes much more sense, as the administrator can be changed very easily, it is easier to report on access, and so on. Sense and reducing management overhead are the overriding keys here. Either solution is feasible; one is just easier to implement and maintain.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Using GPOs to Help Design the Organizational Unit Structure
Inhaltsvorschau
In , we described the design of the Active Directory Organizational Unit hierarchy. We also explained that other items have a bearing on that design. You see, there are two key design issues that affect the structure of your Organizational Units: permissions delegation and GPO placement. If you decide that your Active Directory is to be managed centrally rather than in a distributed fashion and that you will employ only a few GPOs that will be implemented mostly domain-wide (rather than many GPOs on many Organizational Units), your Organizational Unit structure can be almost any way that you want it to be. It shouldn’t make much difference whether you have 400 branches coming off the root or one container with every item inside it. However, if permissions over specific objects do need to be delegated to specific sets of administrators, it will make more sense to structure your domain Organizational Units in a manner that facilitates that administration. This doesn’t have to be the case, but it makes it much easier to use Organizational Units.
For example, if we have 1,000 users and 10 managers who each manage 100 users, we could put the 1,000 users in one Organizational Unit and give the 10 administrators permission to modify only their 100 users. This is a slow and daft way to run systems administration. It would be better to create 10 Organizational Units and put 100 users in each, giving each administrator permissions over his particular Organizational Unit. This makes much more sense, as the administrator can be changed very easily, it is easier to report on access, and so on. Sense and reducing management overhead are the overriding keys here. Either solution is feasible; one is just easier to implement and maintain.
Permissions delegation is covered in more detail in .
The same fundamental facts apply to GPOs. If you are going to need to apply multiple policies to multiple sets of users, it makes more sense and will be easier to manage if you set up multiple Organizational Units. However, this isn’t always possible, for example, if the Organizational Unit structure that you have as an ideal conflicts with the one that you will need for permissions delegation, which again conflicts with the one you would like for GPO structuring.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
One of the big selling points of Active Directory has always been group policy, and in Windows Server 2003 Active Directory, Microsoft extended the functionality and management of GPOs greatly. In this chapter, we expanded on the information presented in to cover strategies for designing your Group Policy deployment.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 13: Active Directory Security: Permissions and Auditing
Inhaltsvorschau
Permissions can be set in Active Directory in much the same way they are set for files. Although you may not care that everyone in the tree can read all your users’ phone numbers, you may want to store more sensitive information and restrict that access. Reading is not the only problem, of course. You also have create, modify, and delete privileges to worry about, and the last thing you need is a disgruntled or clever employee finding a way to delete all the users in an Organizational Unit.
None of this should be new to system managers who already deal with Windows NT Access Control Lists and Access Masks, Novell eDirectory Trustee Lists and Inherited Rights Masks, and Unix access permissions in file masks. In fact, Microsoft has carried the NT terminology from file permissions forward to Active Directory, so if you already know these terms, you’re well ahead. If you are not familiar with them, don’t worry. Terminology in permissions can seem confusing at first, so we’ll go through it all in detail.
Managing the permissions in Active Directory doesn’t have to be a headache. You can design sensible permissions schemes using guidelines on inheritance and complexity that will allow you to have a much easier time as a systems administrator. The GUI that Microsoft provides is fairly good for simple tasks but more cumbersome for complex multiple permissions. In Windows Server 2003, the GUI was enhanced to provide an “effective permissions” option that lets you determine the effective permissions a user or group has on the container or object. Also, Active Directory permissions are supported by ADSI, which opens up a whole raft of opportunities for you to use scripts to track problems and manipulate access simply and effectively. Finally, the DSACLS utility allows administrators to manage permissions from a command line if you prefer an alternative to the GUI.
Yet permissions are only half the story. If you allow a user to modify details of every user in a specific branch below a certain organizational unit, you can monitor the creations, deletions, and changes to objects and properties within that branch using auditing entries. In fact, you can monitor any aspect of modification to Active Directory using auditing. The system keeps track of logging the auditing events, and you can then periodically check them or use a script or third-party tool to alert you quickly to any problems.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Permission Basics
Inhaltsvorschau
shows the basics. Each object stores a value called a Security Descriptor, or SD, in the nTSecurityDescriptor attribute. This attribute holds all the information describing the security for that object. Included with the information are a flag indicating whether or not the security descriptor is protected against inheritance, as well as two important collections called Access Control Lists, or ACLs, that hold the relevant .
Figure : Active Directory security architecture
The first ACL, called the System ACL or SACL, defines the permission events that will trigger both success and failure audit messages. The second, called the Discretionary ACL or DACL, defines the permissions that users have to the object, its properties, and its children. Each of the two ACLs holds a collection of Access Control Entries (ACEs) that correspond to individual audit or permission entries.
Audit and permission ACEs can apply to the object as a whole or to the individual properties of the object. This allows an administrator to control all aspects of access and auditing. Audit ACES are discussed further in , but we will briefly document some of the information in the following section so that other permission topics discussed later in this chapter are more readily understood.
Each permission ACE is made up of several pieces of information:
Trustee
SID of the user or group to which the ACE applies, such as the SID for the group Mycorp\Domain Admins.
ACE Type
Determines whether the ACE is a Grant or a Deny.
Object Type
schemaIDGUID for the attribute or object class that the ACE applies to. Alternatively, the rightsGuid for the property set, validated write, or extended right that the ACE applies to such as the member attribute, Personal Information property set, Change Password extended right, or user objects. For delete or create child objects permissions, the objectType should be configured to the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Using the GUI to Examine Permissions
Inhaltsvorschau
To access the permissions for any object, select the Active Directory Users and Computers MMC and right-click on it. Choose Properties from the drop-down menu and select the Security tab of the properties window that is displayed.
To make the Security tab visible, you need to select View→Advanced Features. If you reopen the properties window of the object to which you wish to assign permissions, you should see a Security tab.
The window in is your first point of contact for permissions. The top area contains a complete list of all groups and users who have permissions to the object whose properties we are looking at. The Permissions section below this list displays which general permissions are allowed and denied for the highlighted user or group. The general permissions listed are only those deemed to be the most likely to be set on a regular basis. Each general permission is only an umbrella term representing a set of actual implemented permissions hidden underneath the item. Consequently, the general permission called Read translates to specific permissions like Read All Properties and List Contents, as we will show later. Below the Permissions section are three important parts of this window:
Advanced button
The Advanced button allows you to delve further into the object, so that permissions can be set using a more fine-grained approach.
Text display area
The second part of this area of the window is used to display a message, such as that shown in . The text shows that the permissions for the current object are more complex than can be displayed here. Consequently, we would have to press the Advanced button to see them.
Inheritance checkbox (Windows 2000 only; not shown in )
The “Allow inheritable permissions from parent to propagate to this object” option protects or blocks the object from inheriting Access Control Entries from its parent. When you clear the checkbox on the security properties or Access Control Settings windows mentioned later, the system pops up a Yes/No/Cancel dialog box that asks if you want to convert your inherited entries to normal entries. If you click Cancel, the operation aborts. Clicking No removes all inherited entries and protects the object or branch. Clicking Yes converts the current inherited entries to standard entries and protects the object from any new inherited permissions to the parent or higher branch. All normal permission entries for the object are unchanged by whatever choice you make. We will cover this in more detail later in the book. For Windows Server 2003 and newer, this checkbox is located on the Advanced screen. Clicking the Advanced button actually displays the same users and groups again, but in slightly more detail. shows this window, known as the Advanced Security Settings for the object.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Using the GUI to Examine Auditing
Inhaltsvorschau
Examining auditing entries is almost identical to viewing permissions entries. If you go back to the screen shown in and click on the Auditing tab, a screen similar to that in is displayed.
This window shows the list of Auditing Entries (AEs) that have been defined on the object. This object has one AE, and it’s not very helpful viewing it from here since the detail is too limited. So just as you would do with permissions, you can click the Edit button (or View/Edit with Windows 2000), drill down, and view the individual AE itself.
Figure : Advanced Settings window showing auditing entries
shows the successful and failed items that are being audited. The items are grayed out because this entry is inherited from further up the tree, i.e., it is not defined directly on this object but instead further up the hierarchy.
shows an example auditing entry window for successful and failed auditing of properties. Here you are auditing only property writes.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Designing Permission Schemes
Inhaltsvorschau
Having worked through many designs for different domain structures, we have come up with a series of rules or guidelines you can follow to structure the design process effectively. The idea is that if you design your permissions schemes using these rules, you will be more likely to create a design with global scope and minimum effort.
This list is not exhaustive. We are sure you will be able to think of others beyond these. If, however, these rules spark your creative juices and help you design more effectively, they will have done their job.
The rules are:
  1. Whenever possible, assign object permissions to groups of users rather than individual users.
  2. Design group permissions so that you have a minimum of duplication.
  3. Manage permissions globally whenever possible.
  4. Allow inheritance: do not protect sections of the tree from inheritance.
  5. Keep a log of every unusual change that you have made to the tree, especially when you have protected sections of it from inheritance or applied special rights to certain users.
Let’s look at these rules in more detail.
Figure : Auditing entry for an object

Rule 1: Apply permissions to groups whenever possible

By default, you should use groups to manage your user permissions. At its simplest, this rule makes sense whenever you have more than one user for whom you wish to set certain permissions.
Some things need to be made very clear about how groups are different between NT and Active Directory:
  • Active Directory supports the concept of two types of group: security and distribution. A distribution group is simply a group that is not Windows Security-. A security-enabled group is a group that is used in calculating access rights to objects. The SID from security groups a user is a member of will be added to the user’s security token when they authenticate. Distribution groups are most often used for mailing lists; however, they can be used for other basic “group” tasks as well, such as instant messaging lists or even security for LDAP-based applications not using Windows security.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Designing Auditing Schemes
Inhaltsvorschau
Designing auditing schemes, in contrast to permissions, is a relatively easy process. Imagine the circumstances in which you may need to check what is happening in Active Directory, and then set things up accordingly.
You must remember that every Active Directory event that is audited causes the system to incur extra processing. Having auditing turned on all the time at the root for every modification by anyone is a great way to get all DCs to really slow down if a lot of Active Directory access occurs on those DCs.
That point bears repeating. Auditing changes to any object in the domain Naming Context (NC) will propagate domain-wide and cause logging to the security event log on every DC that services the Domain NC. Auditing changes to the Configuration NC or Schema NC will cause all DCs in a forest to begin auditing to their security event logs. You must have tools in place to retrieve logs from multiple DCs if you wish to see every security event that occurs. After all, if you have 100 DCs and are logging Configuration NC changes, then because changes can occur on any DC, you need to amalgamate 100 security event logs to gather a complete picture.
Here are a few examples where designing auditing schemes could come in handy:
  • Someone complains that user details are being set to silly values by someone else as a joke.
  • You notice that new objects you weren’t expecting have been created or deleted in a container.
  • The Active Directory hierarchy has changed and you weren’t informed.
  • You suspect a security problem.
Although the preceding reasons are all great reasons for enabling auditing, they are better reasons for removing native update access rights to the directory and pushing updates through some sort of provisioning system such as Microsoft’s Identity Lifecycle Manager tool (ILM, formerly known as MIIS), Quest’s Active Roles Directory Management tool, or even home-grown web-based tools. With these kinds of tools, you can implement good solid features sorely missing from Active Directory, such as the :
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Real-World Examples
Inhaltsvorschau
It now seems appropriate to put what we have laid out earlier into practice. We will use a series of tasks that could crop up during your everyday work as an administrator. The solutions we propose probably are not the only solutions to the problems. That is often the case with Active Directory; there are many ways of solving the same problem.
In this example, an Organizational Unit called Hardware Support Staff contains the user accounts of an in-house team of people whose job is to repair and fix broken computers within your organization. Whenever a user has a fault, he rings the central faults hotline to request a support engineer. An engineer is assigned the job, which is added to the end of her existing list of faults to deal with. The user is informed about which engineer will be calling and approximately when she will arrive. As with all jobs of this sort, some take longer than others, and users have discovered how to find the mobile or pager number of the engineer they have been assigned and have taken to calling her to get an arrival-time update rather than ringing the central desk. Management has decided that they want to restrict who can ring the pager or mobile, but they do not want to stop giving out the engineer’s name as they feel it is part of the friendly service. Consequently, they have asked you to find a way of hiding the pager and mobile numbers in Active Directory from all users who should not have access.
The solution that we will use is to remove the default ability of every user to see the pager and mobile properties of the Engineer objects by default. The first thing we need to find out is how the permissions are currently granted to the users. We look at the ACL on a user object and we do not see either attribute listed specifically. We do however see an inherited Read Property (RP) access for the entire object granted to the Pre-Windows 2000 Compatible Access group. We also see explicit RP access for several Property Sets granted to Authenticated Users.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
Security is always important, and when access to your organization’s network is concerned, it’s paramount. We hope this chapter has given you an understanding of how permission to access can be allowed or denied to entire domains or individual properties of a single object. Auditing is also part of security, and having mechanisms already designed—so that they can be constantly working or dropped in when required—is the best way to keep track of such a system.
Assigning permission and auditing entries to an object appears to be a simple subject on the surface. However, once you start delving into the art of setting permissions and auditing entries, it quickly becomes obvious how much there is to consider. Global design is the necessary first step.
Although expanding your tree later by adding extra containers is rarely a problem, in a large tree it makes sense to have some overall guidelines or rules that allow you to impose a sense of structure on the whole process of design and redesign. Ideally, the golden rules and tables that we created should allow you to plan and implement sensible permissions schemes, which was the goal of the chapter.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 14: Designing and Implementing Schema Extensions
Inhaltsvorschau
For Active Directory to hold any object, such as a user, it needs to know what the attributes and characteristics of that object are. In other words, it needs a blueprint for that object. The Active Directory schema is the blueprint for all classes, attributes, and syntaxes that can potentially be stored in Active Directory.
The following considerations should be kept in mind when you contemplate extending your schema:
  • Microsoft designed Active Directory to hold the most common objects and attributes you would require. Because they could never anticipate every class of object or every specific attribute that a company would need, Active Directory was designed to be extensible. After all, if these objects and properties are going to be in everyday use, the design shouldn’t be taken lightly. Administrators need to be aware of the importance of the schema and how to extend it. Extending the schema is a useful and simple solution to a variety of problems, and not being aware of this potential means that you will have a hard time identifying it as a solution to problems you might encounter.
  • Designing schema extensions is very important, in part because any new class or attribute that you create in the schema is a permanent addition. Under Windows Server 2003, you can disable or redefine schema extensions, but you can never remove them completely.
  • Although it is easy to extend Active Directory, it’s surprising how many companies are reluctant to implement schema extensions due to concerns over the impact to Active Directory. One of the biggest impediments in Windows 2000 was that anytime the partial attribute set was extended (i.e., an attribute added to the Global Catalog), a full resync had to be done for all Global Catalog servers. Fortunately, Microsoft resolved this in Windows Server 2003, and a full resync is no longer performed.
This chapter takes you through the process of extending the schema, from the initial design of the changes through the implementation, and discusses how to avoid the pitfalls that can crop up. We then talk about analyzing the choices available and seeing whether you can obtain the required design result some other way. We obviously cover how to implement schema changes from first principles, but before that we identify the steps in designing or modifying a class or attribute. Finally, we cover some pitfalls to be aware of when administering the schema.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Nominating Responsible People in Your Organization
Inhaltsvorschau
If you don’t already have a central person or group of people responsible for the Object Identifier (OID) namespace for your organization, you need to form such a group. This OID Managers group is responsible for obtaining an OID namespace, designing a structure for the namespace that makes sense to your organization, managing that namespace by maintaining a diagram of the structure and a list of the allocated OIDs, and issuing appropriate OIDs for new classes from that structure as required. Whenever a new class or attribute is to be added to your organization’s schema, the OID Managers provide a unique OID for that new addition. This is then logged by the OID Managers with a set of details about the reason for the request and the type of schema extension that it is to be used for. All these details need to be defined by the OID Managers group.
The Schema Managers, by comparison, are responsible for designing and creating proper classes in the schema for a forest as well as for handling schema extensions required by third party applications. They are responsible for actually making changes to the schema via requests from within the organization, and for ensuring that redundant objects doing the same thing are not created, that inheritance is used to best effect, that the appropriate objects are indexed, and that the partial attribute set contains the right attributes.
If you are designing code that will modify some other organization’s schema, the documentation accompanying that code should make it explicitly clear exactly which classes and attributes are being created and why. The documentation also should explain that the code needs to be run with the privilege of a member of the Schema Admins group, since some organizations may have an Active Directory in which the Schema Admins group is empty most of the time.
A better solution to programmatically processing schema changes is to supply organizations with the LDIF files for the schema modifications. This allows the organizations to review the actual changes and incorporate them into a batch update process with other schema modifications, which allows for easier testing and production implementation. Some large organizations have extensive schema change control procedures that require LDIF format files describing all changes. Failure to supply the required LDIF file results in the update being rejected.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Thinking of Changing the Schema
Inhaltsvorschau
Before you start thinking of changing the schema, you need to consider not just the namespace, but also the data your Active Directory will hold. After all, if you know your data, you can decide what changes you want to make and whom those changes might impact.
No matter how you migrated to Active Directory, at some point you’ll need to determine exactly what data you will add or migrate for the objects you create. Will you use the physicalDeliveryOfficeName attribute of the user object? What about the telephonePager attribute? Do you want to merge the internal staff office location list and telephone database during the migration? What if you really need to know what languages each of your staff speaks or qualifications they hold? What about their shoe size, their shirt size, number of children, and whether they like animals? The point is that some of these already exist in the Active Directory schema and some don’t. At some point, you need to design the actual data that you want to include. This is an important decision, since not all data should necessarily be added to Active Directory. While it may be nice to have shoe size in the directory, it may not make much business sense. You need to ask, “Is this data needed on all domain controllers for a given domain or all global catalogs in the forest?” It is possible that an application partition, Active Directory Lightweight Directory Services (AD LDS), or even a SQL Server database may be a better store for this information. Keep in mind that every piece of data that gets added to the directory needs to be replicated. This has significant impact on network traffic, storage needs, and the time required to build new domain controllers.
Let’s consider MyUnixCorp, a large fictional organization that for many years has run perfectly well on a large mainframe system. The system is unusual in that the login process has been completely replaced in-house with a two-tier password system. A file called
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Creating Schema Extensions
Inhaltsvorschau
There are three ways to modify the schema: through the Active Directory Schema MMC, using LDIF files, or programmatically using ADSI or LDAP. We will not cover the use of the Active Directory Schema MMC very heavily here since it is fairly straightforward to use, although we will cover its use in managing the Schema Master FSMO role. Typically, you should not use the Active Directory Schema MMC to extend the schema and instead use LDIF files or ADSI. Most vendors provide LDIF files, which contain the schema extensions that you can run at your leisure. We cover extending the schema with ADSI in .
The Schema Manager MMC is not available from the Administrative Tools menu like the other Active Directory snap-ins. To use it, you need to first register the Dynamic Link Library (DLL) file for the MMC snap-in by typing the following command at the command prompt:
regsvr32.exe schmmgmt.dll
You can then start the Active Directory Schema console by creating a custom MMC and adding the Active Directory Schema snap-in to it. To create a console, go to the Run menu from the Start button, type mmc.exe, and click OK. Then in the empty MMC, go to File→Add/Remove Snap-in…. From here, you can click the Add button and select Active Directory Schema as the item. If you then click the Add button, followed by Close, and then the OK button, that will give you an MMC hosting the Schema Manager snap-in for you to use and later save as required.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
Carefully designing the changes that you make to the Active Directory schema cannot be stressed highly enough for large corporations or application developers. Selecting a team of Schema Managers and OID Managers and creating documentation to accompany and justify changes will smooth that process. Whether you are a small company or a large multinational, creating sensible structures should mean that you rarely make mistakes and almost never have to make objects defunct.
Hopefully we have shown you not only the perils and pitfalls of modifying the schema, but also why the schema is necessary and how it underpins the entire Active Directory. While you should be cautious when modifying Active Directory, a sensible administrator should have as little to fear from the Active Directory schema as he does from the Windows Registry.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 15: Backup, Recovery, and Maintenance
Inhaltsvorschau
A very important though often overlooked aspect of maintaining Active Directory is having a solid disaster recovery plan in place. While the reported incidents of corruption of Active Directory have been minimal, it has happened and is something you should be prepared for regardless of how unlikely it is to occur. Restoring accidentally deleted objects is much more likely to happen than complete corruption, and thus you should be equally prepared for this as well. Do you have a plan in place for what to do if a domain controller that has a FSMO role suddenly goes offline, and you are unable to bring it back? All the scenarios we’ve just described typically happen under times of duress. That is, clients are complaining or an application is no longer working correctly and people aren’t happy. It is during times like this that you don’t want to have to scramble to find a solution. Having well-documented and tested procedures to handle these issues is critical.
In this chapter, we will look at how to prepare for failures by backing up Active Directory. We will then describe how you can recover all or portions of your Active Directory from backup. We will then cover how to recover from FSMO failures. Finally, we will look at other preventive maintenance operations you can do to ensure the health of Active Directory.
Backing up Active Directory is a straightforward operation. It can be done using the NT Backup utility provided with Windows 2000 and 2003, the Windows Server Backup utility provided with Windows Server 2008, or with a third-party backup package such as Veritas NetBackup. Fortunately, you can back up Active Directory while it is online, so you do not have to worry about taking outages just to perform backups like you do with some other systems.
To back up Active Directory, you have to back up the System State of one or more domain controllers within each domain in the forest. If you want to be able to restore any domain controller in the forest, you’ll need to back up every domain controller. On a Windows 2000 or Windows Server 2003 domain controller, the System State contains the following:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Backing Up Active Directory
Inhaltsvorschau
Backing up Active Directory is a straightforward operation. It can be done using the NT Backup utility provided with Windows 2000 and 2003, the Windows Server Backup utility provided with Windows Server 2008, or with a third-party backup package such as Veritas NetBackup. Fortunately, you can back up Active Directory while it is online, so you do not have to worry about taking outages just to perform backups like you do with some other systems.
To back up Active Directory, you have to back up the System State of one or more domain controllers within each domain in the forest. If you want to be able to restore any domain controller in the forest, you’ll need to back up every domain controller. On a Windows 2000 or Windows Server 2003 domain controller, the System State contains the following:
Active Directory
This includes the files in the NTDS folder that contains the Active Directory (ntds.dit), the checkpoint file (edb.chk), transaction log files (edb*.log), and reserved transaction logs (res1.log and res2.log).
Boot Files
The files necessary for the machine to boot up.
COM+ Class Registration Database
The database for registered COM components.
Registry
The contents of the registry.
SYSVOL
This is the SYSVOL share that contains all of the file-based GPO information as well as the NETLOGON share, which typically contain user logon and logoff scripts.
Certificate Services
This applies only to DCs that are running Certificate Services.
Although most backup packages allow you to perform incremental or differential backups, with Active Directory you can only perform full backups of the system state.
Windows Server 2008 domain controller system-state backups include practically every operating system file in addition to the components listed previously. Consequentially, you will notice a substantial increase in the size of system-state backups on Windows Server 2008.
The user that performs the backup must be a member of the Backup Operators group or have Domain Admins equivalent privileges.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Restoring a Domain Controller
Inhaltsvorschau
One of the benefits of Active Directory is built-in redundancy. When you lose a single domain controller, the impact can and generally should be insignificant. With many services, such as DHCP, the architecture dictates a dependency on a specific server. When that server becomes unavailable, clients are impacted. Over the years, failover or redundancy has been built into most of these services, including DHCP. With Active Directory, the architecture is built around redundancy. Clients are not dependent on a single DC; they can failover to another DC seamlessly if a failure occurs.
When a failure does occur, you should ask yourself several questions to assess the impact:
Is the domain controller the only one for the domain?
This is the worst-case scenario. The redundancy in Active Directory applies only if you have more than one domain controller in a domain. If there is only one, you have a single point of failure. You could irrevocably lose the domain unless you can get that domain controller back online or restore it from backup.
Does the domain controller own a FSMO role?
The five FSMO roles outlined in play an important part in Active Directory. FSMO roles are not redundant, so if a FSMO role owner becomes unavailable, you may need to seize the FSMO role on another domain controller. Check out the FSMO recovery section later in this chapter for more information.
Is the domain controller a Global Catalog server?
The Global Catalog is a function that any domain controller can perform if enabled. But if you have only one Global Catalog server in a site and it becomes unavailable, it can impact users’ ability to log in. As long as clients can access a Global Catalog, even if it isn’t in the most optimal location, they will be able to log in. If a site without a Global Catalog for some reason loses connectivity with the rest of the network, it would impact users’ ability to log in. With Windows Server 2003 and newer, you can enable universal group caching on a per-site basis to limit this potential issue, but only if the user is not using a
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Restoring Active Directory
Inhaltsvorschau
No one ever wants to be in a position where you have to restore Active Directory, but nevertheless you should prepare for it. Restoring Active Directory comes in a few different flavors, which we’ll cover now.
A non-authoritative restore is a restore where you simply bring a domain controller back to a known good state using a backup. You then let replication resync the contents of the latest changes in Active Directory since the backup. The restore-from-backup method we described earlier to handle DC failures is an example of a non-authoritative restore. The only difference between that scenario and the one we’ll describe here is that previously we assumed that the failed server you rebuilt or replaced was not a domain controller yet. There may be some circumstances when you want to perform a similar restore, but the server is already configured as a domain controller. One example might be if some changes were made on a particular domain controller that you wanted to take back. If you were able to disconnect the domain controller from the network in time before it replicated, you could perform a non-authoritative restore to get it back to a known state before the changes were made. This would effectively nullify the changes as long as they didn’t replicate to another server.
You cannot restore “null” values from a backup. If you erroneously populate a series of attributes on a domain controller that were not previously populated and then perform a restore, those attributes will not become null once again. This is because Active Directory does not store null values in the database, and thus it is impossible to recover them because they’re not there.
A non-authoritative restore simply restores Active Directory without marking any of the data as authoritative. This means that any changes that have happened since the backup will replicate to the restored server. Also, any changes that were made on the server that had not replicated will be lost.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Working with Snapshots
Inhaltsvorschau
One of the new features for Active Directory in Windows Server 2008 is the notion of snapshots. With snapshots, you can make a point in time copy of the Active Directory database. This feature uses the Volume Shadow Copy (VSS) service to create the snapshot. Once you have created a snapshot, you can mount it using the dsamain command-line utility and browse it like the live Active Directory database using ldp or Active Directory Users and Computers.
The benefits of this new capability are endless, but some ideas include:
  • Looking at permissions or other settings prior to modification in case you need to rollback
  • Exporting objects or values that were inadvertently modified and then importing them back to your production directory
  • Determining which backup to perform a restore from
  • Restoring a complete object with a third-party tool
A free third-party tool for restoring objects from a snapshot is available at http://www.one-identity.net/tools/snapshot/.
Creating the snapshot is a straight forward process using the ntdsutil command-line utility:
C:\>ntdsutil

ntdsutil: snapshot

snapshot: activate instance ntds

Active instance set to "ntds".

snapshot: create

Creating snapshot...

Snapshot set {e73b71cd-7e2b-40ee-8871-69575f4b1e66} generated successfully.
Once you have created a snapshot, you can mount it and make it available to LDAP clients. Mounting the snapshot consists of either specifying the GUID generated in the previous step or selecting the snapshot from a list. In this example, we select the snapshot from a list:
snapshot: list all

 1: 2008/06/30:22:44 {e73b71cd-7e2b-40ee-8871-69575f4b1e66}

 2:   C: {c8bc59c0-f20b-4bac-a12a-ab6eab737f0c}



snapshot: mount 1

Snapshot {c8bc59c0-f20b-4bac-a12a-ab6eab737f0c} mounted as

C:\$SNAP_200806302244_VOLUMEC$\
Once the snapshot has been mounted in the filesystem, you can use the dsamain utility to mount the snapshot version of the Active Directory and make it accessible via LDAP. Dsamain requires that you provide the path to the database to mount as well as a port number to listen on. If you only specify the LDAP port, dsamain will automatically use the subsequent three ports for LDAPS, Global Catalog, and Global Catalog SSL. Thus if you specify port 10389, ports 10390, 10392, and 10393 will also be used. The command to mount the database in this scenario is:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
FSMO Recovery
Inhaltsvorschau
The FSMO roles were described in . These roles are considered special in Active Directory because they are hosted on a single domain controller within a forest or domain. The architecture of Active Directory is highly redundant, except for FSMO roles. It is for this reason that you need to have a plan on how to handle FSMO failures.
While it would be a really nice feature if domain controllers could detect that they are being shut down and gracefully transfer any FSMO roles to other domain controllers, this isn’t reality. Without having the graceful FSMO role transfer, you have to perform manual transfers. Manually transferring a role is pretty straightforward. You bring up the appropriate Active Directory snap-in, bring up the FSMO property page, select a new role owner, and perform the transfer. Here is a list of the FSMO roles and the corresponding snap-in that can be used to transfer it to another domain controller:
  • Schema Master: Active Directory Schema
  • Domain Naming Master: Active Directory Domains and Trusts
  • RID Master: Active Directory Users and Computers
  • PDC Emulator: Active Directory Users and Computers
  • Infrastructure Master: Active Directory Users and Computers
You can use the command-line tool NETDOM to query all FSMOs for a given domain with a single command:
netdom query fsmo /domain:domainname
When a FSMO role owner goes down and cannot be brought back online, you no longer can transfer the role; you instead have to “seize” it. Windows Server 2008 domain controllers will automatically seize the roles held by a domain controller when you perform a metadata cleanup. If you wish to specify exactly where the roles are seized to, you must still perform this task by hand, though. Unfortunately, you cannot seize FSMO roles using the Active Directory snap-ins as you can to transfer them. To seize a FSMO role, you will need to use the ntdsutil utility. We will now walk through the ntdsutil commands that are used to seize a FSMO role. Note that due to the width of the output, some of the text wraps to the following line.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Restartable Directory Service
Inhaltsvorschau
Windows Server 2008 introduces the ability to start and stop Active Directory like a normal Windows service. This allows you to perform most offline operations without restarting the domain controller. While Active Directory is stopped, it will not respond to logon requests. If the domain controller is hosting Active Directory Integrated DNS zones, it will also not respond to queries for these zones. While the Active Directory service is stopped, you can perform all of the offline tasks outlined in this chapter with the exception of restoring a backup. Restoring still requires that you boot into Directory Services Restore Mode.
Once you have stopped the Active Directory service, you can log in to the domain controller with domain credentials if another domain controller is available to service the request. If another domain controller is not available to service the request, then you will not be able to log in. If you want to continue to have the option of using the Directory Services Restore Mode Password, you must modify a registry value. This configuration change is outlined in the sidebar, ,” next.
Table : DSRMAdminLogonBehavior values
Value
Description
0
You can only log on to the domain controller with a domain account, which requires that another domain controller be available to service the request.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
DIT Maintenance
Inhaltsvorschau
Using the ntdsutil utility, you can check the integrity and semantics of the Active Directory database and reclaim whitespace, which can dramatically reduce the size of the DIT. Also, just as you should rotate the password for the Administrator accounts in the forest, you should also change the DS Restore Mode Administrator password as well. You may even need to do this more frequently depending on whether you have people who leave your team and should no longer know the password.
Unfortunately, to accomplish all these tasks (with the exception of changing the DS Restore Mode Administrator password) on Windows Server 2003 and earlier domain controllers, you have to boot the domain controller into DS Restore Mode. That means you will have to have schedule downtime for the machine. Also, to use DS Restore Mode, you need console access, either through being physically at the machine or with out-of-band access, such as with an HP Integrated Lights Out (iLO) connection. There is one other option: using Terminal Services. You can modify the boot.ini file on the domain controller to automatically start up in DS Restore Mode. You can then use a Terminal Services connection to log in to the machine. For more information, check out MS Knowledge Base article 256588 at http://support.microsoft.com/kb/256588.
The majority of the offline maintenance tasks discussed in this section can be performed without rebooting Windows Server 2008 domain controllers into DS Restore Mode as discussed earlier in the section .” However, if you need to set a Windows Server 2008 domain controller to automatically boot into DS Restore Mode, you’ll need to use the bcdedit command-line utility to reconfigure the domain controller’s boot settings. This is a three step process:
  1. bcdedit /copy {current} /d "DC-DS Restore Mode"
    The tool will output a GUID response similar to this: The entry was successfully copied to {49fa7976-5065-11dd-ae21-000c291a8e6c}.
  2. bcdedit /set {49fa7976-5065-11dd-ae21-000c291a8e6c}
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we reviewed all the elements necessary to develop a disaster recovery plan. We covered how to back up Active Directory and some of the gotchas related to the tombstone lifetime and password-change cycles. We then discussed the various options for restoring Active Directory, including restore by replication, authoritative restores, and nonauthoritative restores. We discussed the FSMO transfer process and what is needed to seize FSMO roles. Finally, we delved into some of the maintenance tasks that can be done with the Active Directory DIT files.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 16: Upgrading to Windows Server 2003
Inhaltsvorschau
The first version of Active Directory with Windows 2000 was surprisingly stable and robust. That said, since Active Directory is such a complex and broad technology, there was still much room for improvement. There were some issues with scalability, such as the infamous 5,000-member soft limit with groups or the 300-site soft limit, which may have imposed artificial limitations on how you implemented Active Directory. Both of these issues were resolved in Windows Server 2003. The default security setup with Windows 2000 Active Directory out-of-the-box was not as secure as it should have been. Signed LDAP traffic and other security enhancements have since been added into service packs, but they are provided by default as of Windows Server 2003. Finally, manageability was another area that needed work in Active Directory. Windows Server 2003 added numerous command-line utilities along with some significant improvements to the administrative snap-ins.
We have highlighted a few key areas where Active Directory was improved in Windows Server 2003, and we’ll describe more new features in the next section. If you already have a Windows 2000 Active Directory infrastructure deployed, your next big decision will be when to upgrade. At the time of publication, chances are you should be thinking of when to upgrade to Windows Server 2008 rather than Windows Server 2003. We still recommend you read the chapters on upgrading to Windows Server 2003 and R2 prior to reading about upgrading to Windows Server 2008 as these chapters build upon each other. Fortunately, the transition to Windows Server 2003 (and 2008) is evolutionary, not revolutionary as with the migration from Windows NT to Active Directory. In fact, Microsoft’s goal was to make the move to Windows Server 2003 as seamless as possible, and for the most part they have accomplished this. You can introduce Windows Server 2003 domain controllers at any rate you wish into your existing Active Directory environment; they are fully compatible with Windows 2000 domain .
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
New Features in Windows Server 2003
Inhaltsvorschau
While the release of Windows Server 2003 is viewed as evolutionary, there are quite a few new features that make the upgrade attractive.
By “feature,” we mean new functionality that is not just a modification of the way it worked in Windows 2000. In this sense, a feature is something you have to use or implement explicitly. Functionality differences with Windows 2000 are covered in the next section.
We suggest you carefully review each of these features and rate them according to the following categories:
  • You would use the feature immediately.
  • You would use the feature eventually.
  • You would never use the feature or it is not important.
Rating each feature will help you determine how much you could benefit from the upgrade. The following is the list of new features, in alphabetic order:
Application partitions
You can create partitions that can replicate to any domain controller in the forest.
Concurrent LDAP binds
Concurrent LDAP binds do not generate a Kerberos ticket and security token and are therefore much faster than a simple LDAP bind.
Cross-forest trust
This is a transitive trust that allows all the domains in two different forests to trust each other via a single trust defined between two forest root domains. This requires Windows Server 2003 Forest Functional Level.
Domain controller rename
The rename procedure for domain controllers requires a single reboot.
Domain rename
Domains can now be renamed, but not without significant impact to the user base (e.g., all member computers must be rebooted twice). For more information, check out the following whitepaper: http://technet.microsoft.com/en-us/windowsserver/bb405948.aspx. This requires Windows Server 2003 Forest Functional Level.
Dynamic auxiliary classes
There is now support for the standards-based implementation of dynamic auxiliary classes. Under Windows 2000, auxiliary classes are considered “static” because they are statically linked to structural classes in the schema. With dynamic auxiliary classes, you can link one when creating an object (or add after the creation) without it being defined in the schema as an auxiliary class for the object’s objectClass. This requires Windows Server 2003 Forest Functional Level.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Differences with Windows 2000
Inhaltsvorschau
Even though Active Directory was scalable enough to meet the needs of most organizations, there were some improvements to be made after several years of real-world deployment experience. Many of the functionality differences with Windows 2000 are the direct result of feedback from AD administrators.
As with the new features, we suggest you carefully review each of the differences and rate them according to the following categories:
  • It would positively affect my environment to a large degree.
  • It would positively affect my environment to a small degree.
  • It would negatively affect my environment.
The vast majority of differences are actually improvements that translate into something positive for you, but in some situations, such as with the security-related changes, the impact may cause you additional work initially.
Account lockout enhancements
Several bugs have been fixed that erroneously caused user lockouts in Windows 2000.
Changes with Pre-Windows 2000 Compatible Access
To enhance security, the Everyone security principal no longer means all unauthenticated and authenticated users. It instead represents only authenticated users. To grant the equivalent of anonymous access in Windows Server 2003, the Anonymous Logon account should be added to the Pre-Windows 2000 Compatible Access group.
Distributed Link Tracking (DLT) service disabled by default
The DLT service can be the source of thousands if not millions of linkTrackOMTEntry objects that are nestled within the System container of a domain. By default, the DLT service is disabled on Windows Server 2003 domain controllers.
Faster global catalog removal
With Windows 2000, whenever you disabled the global catalog on a domain controller, the global catalog removal process could only remove 500 objects every 15 minutes. This has been changed so that the process is much quicker.
Improved event log messages
There are several new event log messages that will aid in troubleshooting replication, DNS, FRS, etc.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Functional Levels Explained
Inhaltsvorschau
Now that you are sufficiently excited about the new features with Active Directory and improvements since Windows 2000, we will cover how you can actually enable these features in Windows Server 2003. If you’ve already deployed Windows 2000 Active Directory, you are most certainly familiar with the domain mode concept. With Windows 2000 Active Directory, you had mixed and native-mode domains. Domain mode simply dictated what operating systems were allowed to run on the domain controllers and nothing more. New features were enabled with the move to native mode, including universal security groups and enhanced group nesting to name a couple. Think of functional levels like domain modes, but taken a step further.
Windows Server 2003 functional levels are very similar to Windows 2000 domain modes from the standpoint that they dictate what operating systems can run on domain controllers, and they can only be increased or raised and never reversed. One common misunderstanding with domain modes, which hopefully will not be carried over to functional levels, is that they have virtually no impact on clients and what operating systems your clients run. For example, you can have Windows 9x clients in mixed or native-mode Windows 2000 domains and also in domains that are at the Windows 2000 or Windows Server 2003 domain functional level.
For information about which operating systems domain controllers can run at the various functional levels, check out .
An important difference with functional levels is that they apply both to domains and at the forest level. The reason for this is that some features of Windows Server 2003 Active Directory require either that all the domain controllers in a domain are running Windows Server 2003 or that all the domain controllers in the entire forest are running Windows Server 2003.
To illustrate why this is necessary, let’s look at two examples. First, let’s look at the new “last logon timestamp attribute” feature. With this feature, a new attribute called
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Preparing for ADPrep
Inhaltsvorschau
Before you can start enabling functional levels, you have to go through the process of upgrading your existing infrastructure to Windows Server 2003. The first step before you can promote your first Windows Server 2003 domain controller is to prepare the forest with the ADPrep utility.
If you’ve installed Exchange 2000 or newer into your Active Directory forest, you are undoubtedly familiar with the Exchange setup.exe /forestprep and /domainprep switches. These switches are run independently from the Exchange server install to allow Active Directory administrators to take care of the AD-related tasks necessary to support Exchange. The Exchange /forestprep command extends the schema and adds some objects in the Configuration Naming Context. The Exchange /domainprep command adds objects within the Domain Naming Context of the domain it is being run on and sets some ACLs. The ADPrep command follows the same logic and performs similar tasks to prepare for the upgrade to Windows Server 2003.
Microsoft recommends that you have at least Windows 2000 Service Pack (SP) 2 installed on your domain controllers before running ADPrep. There are a number of fixes that you should ensure you have if you are still running SP2. More details on these are available at http://support.microsoft.com/kb/331161.
While the minimum is SP2, we recommend that you have SP3 at a minimum on your Windows 2000 domain controllers.
The ADPrep command can be found in the \i386 directory on the Windows Server 2003 CD. The ADPrep command depends on several files in that directory, so it cannot simply be copied out and put on a floppy or CD by itself. To run the ForestPrep, you would execute the following:
X:\i386\adprep /forestprep
where X: is a CD drive or mapped drive to a network share containing the Windows Server 2003 CD. Similarly, to run DomainPrep, you would execute the following:
X:\i386\adprep /domainprep
Finally, you would execute the following command:
X:\i386\adprep /domainprep /gpprep
You can view detailed output of the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Upgrade Process
Inhaltsvorschau
The upgrade process to Windows Server 2003 should be straightforward for most deployments. No forest restructuring is required, no user profile or workstation changes are necessary assuming you are running the latest service pack and hotfixes, and there should be no need for political turf battles over namespace usage and ownership like there might have been with your initial Active Directory deployment.
We are going to outline five high-level steps that you should follow to upgrade to Windows Server 2003. They include performing an inventory of your domain controllers and clients to determine if there will be any compatibility showstoppers. You are then ready to do a trial run and perform extensive testing to see what impact the upgrade may have on functionality. Next, you have to prepare your forest and domains with ADPrep, which we’ve already discussed in some depth. Finally, you’ll upgrade your domain controllers to Windows Server 2003. In the Post-Upgrade Tasks section of this chapter, we will describe what to do after you’ve upgraded your domain controllers as far as monitoring, raising functional levels, and taking advantage of new features goes.
Prior to running your adprep process, fully read and understand Microsoft Knowledge Base Article 555040 at http://support.microsoft.com/kb/555040. It details all of the known issues with the adprep process. Also review KB article 309628 at http://support.microsoft.com/kb/309628, which details the operations adprep performs.
A good first step before you start the upgrade process is to do a complete inventory of all the hardware and software that is on your domain controllers. You’ll then want to contact your vendors to determine whether they’ve already done compatibility testing and can verify support for Windows Server 2003. The last thing you want to do is start the upgrade process and find out halfway through that a critical monitoring application or backup software that runs on your domain controllers does not work correctly. Much of this testing can be done in your own labs, but it is always good to check with the vendors and get their seal of approval. After all, if a problem does arise, you’ll want to make sure they are supporting the new platform and won’t push back on you.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Post-Upgrade Tasks
Inhaltsvorschau
After you’ve upgraded one or more of your domain controllers to Windows Server 2003, you need to do some additional tasks to fully complete the migration. First and foremost, you need to monitor the domain controllers every step of the way and especially after they have been upgraded. You are setting yourself up for failure if you are not adequately monitoring Active Directory.
The criticality of monitoring cannot be overstated. If you are not monitoring, how can you determine whether something broke during the upgrade? Here are several things you should check after you upgrade your first domain controller in a domain, any FSMO role owner, and after all DCs have been upgraded:
Responds to all services
Query LDAP, Kerberos, the global catalog (if applicable), and DNS (if applicable) and be sure authentication and login requests are being processed. The dcdiag command can run many of these tests.
Processor and memory utilization
Trend processor and memory utilization for some period before you do the upgrade so you can compare to the numbers after the upgrade.
DIT growth
The growth of the DIT should not be significant. If you performed an in-place upgrade of Windows 2000 domain controllers, you may in fact want to do an offline defrag after the upgrade to reclaim any space due to single-instance store of ACLs.
Event logs
This is a no-brainer, but you should always check the event logs to see whether any errors are being logged.
DC resource records registered
Ensure that all of the SRV, CNAME, and A records for the domain controllers are registered. The dcdiag command can perform these checks.
Replication is working
Run repadmin /showreps and repadmin /replsum and watch for anything out of the ordinary.
Group policies are being applied
You may want to add a new setting to an existing GPO or create a new GPO and see if the settings apply on a client that should be receiving it.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we covered the new features in Windows Server 2003 and some of the differences with Windows 2000, most of which were instigated by real-world deployment issues. We then went over how you can enable new features with the use of functional levels and why they are necessary. Next we discussed the aDPrep process and how that must be done before the first Windows Server 2003 domain controller can be promoted. Once you have your forest and domains prepared, you can start the upgrade process. We described some of the important issues to be aware of when upgrading, and finally what to do after you’ve completed the upgrade.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 17: Upgrading to Windows Server 2003 R2
Inhaltsvorschau
Windows Server 2003 has been available to the public since March 2003. Since its release, Microsoft has also released several feature packs that add additional functionality to the base operating system, and there has also been a substantial update in the form of Service Pack 1. Because the release dates for Windows Server 2008 were pushed further and further out, as well as for a number of other reasons, Microsoft decided to release a new version of Windows Server 2003 called R2. This is the gold version of Windows Server 2003 with Service Pack 1, and it includes the previously released to web (RTW) feature packs, as well as some new feature packs that were not previously released.
Windows Server 2003 Service Pack 1 should not be considered an optional update; however, R2 can certainly be considered optional. Service Pack 1 for Windows Server 2003 is comparable to Service Pack 2 for XP in terms of the amount of security changes implemented across the OS. There are also a few additions to the Active Directory Services that this chapter will focus on. If you have already installed Service Pack 1 and do not want or need any of the feature packs on the R2 CD, then you will not need to install R2, though you should still consider running the R2 ADPrep to upgrade the schema to the latest Microsoft schema revision.
Before you can introduce Windows Server 2003 R2 domain controllers, you must prepare the forest with the ADPrep utility, which is like the ADPrep utility needed to upgrade Windows 2000 forests to Windows Server 2003 forests. ADPrep primes the forest for new platform interoperability features available in R2. This schema update is one of the reasons that R2 is a “new” server release instead of simply a rollup or Service Pack.
Before diving into the process to upgrade to Windows Server 2003 R2, the discussion will focus on some of the new Active Directory features included in R2, as well as Service Pack 1, and some of the functionality differences with the original Windows Server 2003 release to manufacturing (RTM) edition. Based on this information, you should be able to prioritize the importance of how quickly or even
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
New Active Directory Features in Windows Server 2003 Service Pack 1
Inhaltsvorschau
On January 15, 2002, Bill Gates, Chief Software Architect for Microsoft, sent the now-famous Trustworthy Computing email memo to all Microsoft employees disclosing the new Microsoft direction. It outlined a direction toward security and a trusted computing base. As the first major project out of the gate after this milestone event, Windows Server 2003 was a valiant step in the right direction, but the momentum and technical acumen wasn’t fully built up by the time of its release.
Microsoft truly started to hit its security stride with the release of Windows XP Service Pack 2 in August 2004. Then in March 2005, Windows Server 2003 Service Pack 1 was released as the comparable service pack for the server OS. As you may well expect, both service packs are packed full of security fixes, new technology, and coding techniques to help counter unknown future security holes. For this reason, these service packs should not be considered optional updates.
On top of the security fixes and other non-AD related hotfixes, there are quite a few new Active Directory features and updates that make Service Pack 1 attractive to any Active Directory administrator. We list the Active Directory specific SP1 updates and features in this section. If upgrading from Windows 2000 to Windows Server 2003 SP1, you should also refer to for benefits gained when upgrading from Windows 2000 to Windows Server 2003.
By “feature,” we mean new functionality that is not just a modification of the way it worked in Windows Server 2003.
We suggest you carefully review each of these features and rate them according to the following categories:
  • I would use the feature immediately.
  • I would use the feature eventually.
  • I would never use the feature or it is not important.
Rating each feature will help you determine how much you could benefit from the upgrade. The following is the list of new features, in alphabetical order:
Confidential attributes
Ability to mark attributes as confidential so they cannot be read without additional permissions granted. By default, any attribute marked “confidential” can only be read by administrators; however, this can be delegated.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Differences with Windows Server 2003
Inhaltsvorschau
As with the new features, we suggest you carefully review each of the differences and rate them according to the following categories:
  • It would positively affect my environment to a large degree.
  • It would positively affect my environment to a small degree.
  • It would negatively affect my environment.
The vast majority of differences are actually improvements that translate into something positive for you, but in some situations, such as with the security-related changes, the impact may initially cause you additional work:
Additional replication security and fewer replication errors
Replication metadata is now removed for domain controllers that are removed from the domain. This enhances directory security and eliminates replication error messages related to the deleted domain controllers.
Install from Media improvements for installing DNS Servers
New option to include application directory partitions in the backup media eliminates requirement for network replication of DomainDNSZone and ForestDNSZones application directory partitions before the DNS Server is operational.
Updated tools
Newer versions of DcDiag, NTDSUtil, AdPrep, and other tools to aid in management, updates, and troubleshooting.
Extended storage of deleted objects
Tombstone lifetime on new forests increased from 60 to 180 days. Existing forests are not modified.
SID History attribute retained on object deletion
The SID History attribute has been added to the default list of attributes retained on an object tombstone. When the object is undeleted, the attribute will be restored along with the object.
Operations master health and status reporting
Operations that require a FSMO domain controller that cannot be performed will generate Directory Service event log messages.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
New Active Directory Features in Windows Server 2003 R2
Inhaltsvorschau
Windows Server 2003 R2 includes all of the aforementioned Service Pack 1 upgrades, as well as some additional feature packs. There are only a few features in R2 that are specific to Active Directory; these are listed below.
We suggest you carefully review each of these features and rate them according to the following categories:
  • I would use the feature immediately.
  • I would use the feature eventually.
  • I would never use the feature or it is not important.
Rating each feature will help you determine how much you could benefit from the upgrade. The following is the list of new features, in alphabetical order:
Active Directory Application Mode (AD/AM or ADAM)
Standalone LDAP service that is Active Directory with the NOS-specific components and requirements stripped out. This feature does not require your domain controllers or your schema to be updated to R2; you can just upgrade the standalone or member server on which you want to run R2 ADAM.
Active Directory Federated Services (ADFS)
Standards-based technology that enables distributed identification, authentication, and authorization across organizational and platform boundaries. This feature does not require your domain controllers or your schema to be updated to R2; you can just upgrade the standalone or member server on which you want to run ADFS.
Identity Management for UNIX (IMU or IdMU)/Subsystem for UNIX Applications (SUA)
Manage user accounts and passwords on Windows and Unix via NIS. Automatically synchronize passwords between Windows and Unix.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Preparing for ADPrep
Inhaltsvorschau
Before you can install your first R2 domain controller, you have to go through the process of upgrading your existing schema to Windows Server 2003 R2 with the ADPrep utility. If you’ve upgraded from Windows 2000 to Windows Server 2003 AD, you are undoubtedly familiar with the adprep.exe /forestprep switch. If not, please review . This switch is run independently from the domain controller promotion to allow Active Directory administrators to take care of the AD-related tasks necessary to support Windows Server 2003 R2 Active Directory. The R2 ForestPrep process the schema to include the objects and attributes necessary for the R2 Feature Packs, primarily the Unix interoperability functions.
Unlike the Windows 2000 to Windows Server 2003 upgrade, you do not have to run adprep.exe /domainprep or adprep.exe /domainprep /gpprep for the Windows Server 2003 to Windows Server 2003 R2 Upgrade, as there are no domain-level changes that need to be implemented.
If you are upgrading from Windows 2000 to Windows Server 2003 R2, however, you do need to run adprep.exe /domainprep and adprep.exe /domainprep /gpprep. See for details; the process is the same as it is under the initial version of Windows Server 2003.
Windows Server 2003 Service Pack 1 is required to load R2.
The ADPrep command can be found in the \CMPNENTS\R2\ADPREP directory on Windows Server 2003 R2 disk 2. The ADPrep command depends on several files that reside in that directory, so it cannot simply be copied out and put on a floppy or CD by itself. To run the ForestPrep, you would execute the following:
X:\CMPNENTS\R2\ADPREP\adprep /forestprep
where X: is a CD drive or mapped drive to a network share containing the Windows Server 2003 R2 CD.
Windows Server 2003 R2 comes with two CDs. The version of ADPrep specific to R2 is on CD2. If you are upgrading from Windows 2000 to Windows Server 2003 R2, you only need to run ADPrep from CD2. The version of ADPrep on CD1 does not contain any of the R2 changes.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Service Pack 1 Upgrade Process
Inhaltsvorschau
The upgrade process to Windows Server 2003 Service Pack 1 is similar to any service pack upgrade—test, test, test, test, and test some more before introducing changes to production. You need to test all aspects of your business requirements and management tools against a domain with domain controllers that have been upgraded. This upgrade will not require you to make any Active Directory changes. However, there are non-Active Directory-related changes, specifically security changes, in SP1 that could impact your line of business applications and management capabilities.
One non-AD-related change in Windows Server 2003 Service Pack 1 that has caused a significant number of issues in managing domains and servers is a change to the Discretionary Access Control List (DACL) of the Service Control (SC) Manager. This change locks down the ability to remotely enumerate installed services to administrators. Previously, an administrator could delegate to a non-administrator the ability to stop and start services. This delegation will break under SP1 if the tool used to manage the services enumerates the services on the remote server. You must either re-open the DACL access on the SC Manager using the Support Tool SC.EXE or use a tool that doesn’t enumerate the services prior to managing the delegated service.
The Service Pack 1 installation files can be downloaded directly from the Microsoft Website; see Microsoft Knowledge Base Article 889101 at http://support.microsoft.com/kb/889101 for the Service Pack release notes and the download location.
Once you have determined through testing that loading Service Pack 1 on your domain controllers will create no obvious dangers to your business or your ability to manage your environment, you should back up any systems to be upgraded. Make sure that the backup includes the system state to capture Active Directory and SYSVOL information, and then deploy the Service Pack into production. Don’t forget to verify that your Line of Business apps, monitoring, and management software are all working properly after the upgrade.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
R2 Upgrade Process
Inhaltsvorschau
The R2 upgrade process is quite simple, and because there is no change in the function of the operating system, there is no real concern of possible issues with the exception of the schema update processed in the ForestPrep. Even if there are issues during the schema update, they are not usually terribly difficult to overcome, especially with the schema defunct capability in Windows Server 2003 Active Directory. The ForestPrep only has to be run once, so after that is completed, the rest of the R2 rollout should be quite smooth.
During the beta of R2, there were cases reporting failures during the ForestPrep process due to preexisting schema attributes colliding with the new attributes in various ways. All of these cases were corrected by defuncting and/or redefining the old attributes causing the collisions.
As we outlined earlier, before you can promote the first Windows Server 2003 R2 domain controller into your forest, you have to run the ForestPrep procedure. Log in to the Schema FSMO role holder and run ADPrep /forestprep. When the process has successfully completed, you will be greeted with a heartening success message:
The command has completed successfully.

ADPrep successfully updated the forest-wide information.
If you run into errors, messages will be provided that should give an indication of the problem. Assuming your prerequisites are in order, any errors will be concerning pre-existing schema definitions. If you have been particular about your schema updates, it is unlikely you will encounter issues.
Now comes the easy part, really. The installation of R2 will copy a few files to the server and add some menu items to the Add/Remove Windows Components of the Add or Remove Programs dialog. These additional menu picks will allow you to later install the various feature packs as needed. The Active Directory-specific feature packs, ADAM, ADFS, and IMU, are available under the Active Directory Services pack.
That’s it, all done, nothing else to do for the upgrade. The hard part was the SP1 upgrade and ForestPrep procedure mentioned previously.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we covered the new Active Directory features in Windows Server 2003 SP1 and Windows Server 2003 R2. Further, we mentioned that while Windows Server 2003 Service Pack 1 is an important, if not critical, upgrade, R2 is optional and should only be done if you need one or more of the feature packs included in the release. Next, we discussed the processes involved with upgrading from a Windows Server 2003 Active Directory and domain controllers to Windows Server SP1 and then R2. Finally, we discussed the ForestPrep process and how that must be completed prior to introduction of the first R2 domain controller.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 18: Upgrading to Windows Server 2008
Inhaltsvorschau
The process for upgrading to Windows Server 2008 from Windows 2000 or Windows 2003 Active Directory is relatively straightforward. If you’ve completed the upgrade from Windows 2000 to Windows Server 2003, you should have all the skills necessary to embark upon upgrading to Windows Server 2008. If not, we recommend that you review the previous two chapters on upgrading to Windows Server 2003 as we will not be rehashing the content already covered there.
The goal of this chapter is to provide an at a glance overview of the new Active Directory features you will be able to leverage as you begin and complete your migration to Windows Server 2008. We will also discuss the upgrade process with specific attention to the additional steps necessary to deploy new Windows Server 2008 features.
While the release of Windows Server 2008 is viewed as evolutionary, there are quite a few new features that make the upgrade attractive.
By “feature,” we mean new functionality that is not just a modification of the way it worked in Windows Server 2003. In this sense, a feature is something you have to use or implement explicitly. Functionality differences with Windows Server 2003 are covered in the next section.
We suggest you carefully review each of these features and rate them according to the following categories:
  • I would use the feature immediately.
  • I would use the feature eventually.
  • I would never use the feature or it is not important.
Rating each feature will help you determine how much you could benefit from the upgrade. The following is the list of new features, in alphabetic order:
Administrative role separation
Users who are not domain administrators can be securely delegated administrative control of RODCs without providing access to the writeable Active Directory (e.g., they cannot modify anything but the RODC).
ADMX repository
Upgraded Group Policy template files can be stored once per domain in the Sysvol, thus greatly reducing the size of the Sysvol for many organizations.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
New Features in Windows Server 2008
Inhaltsvorschau
While the release of Windows Server 2008 is viewed as evolutionary, there are quite a few new features that make the upgrade attractive.
By “feature,” we mean new functionality that is not just a modification of the way it worked in Windows Server 2003. In this sense, a feature is something you have to use or implement explicitly. Functionality differences with Windows Server 2003 are covered in the next section.
We suggest you carefully review each of these features and rate them according to the following categories:
  • I would use the feature immediately.
  • I would use the feature eventually.
  • I would never use the feature or it is not important.
Rating each feature will help you determine how much you could benefit from the upgrade. The following is the list of new features, in alphabetic order:
Administrative role separation
Users who are not domain administrators can be securely delegated administrative control of RODCs without providing access to the writeable Active Directory (e.g., they cannot modify anything but the RODC).
ADMX repository
Upgraded Group Policy template files can be stored once per domain in the Sysvol, thus greatly reducing the size of the Sysvol for many organizations.
Database snapshots
Point-in-time snapshots of the Active Directory database can be taken as a basis for disaster recovery and other object restore and comparison operations.
DNS Server features
Support for new locator options, automatic configuration during install, background zone loading, and multicast DNS support.
DFS-R Sysvol replication
Sysvol can now be replicated with the new DFS-R replication engine, which is much more reliable and scalable when compared to NTFRS.
Fine-Grained Password Policies
Password policies can now be defined on a per-user basis.
GlobalNames DNS zone
A new type of DNS zone that can help pave the way to migrating away from WINS by resolving unqualified hostnames.
Group Policy Preferences
A product Microsoft purchased from Desktop Standard, Group Policy Preferences allow you to control numerous settings and Windows features that were previously only accessible via scripts.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Differences with Windows Server 2003
Inhaltsvorschau
Even though Active Directory was scalable enough to meet the needs of most organizations, there were some improvements to be made after several years of real-world deployment experience. Many of the functionality differences with Windows Server 2003 are the direct result of feedback from AD administrators.
As with the new features, we suggest you carefully review each of the differences and rate them according to the following categories:
  • It would positively affect my environment to a large degree.
  • It would positively affect my environment to a small degree.
  • It would negatively affect my environment.
The vast majority of differences are actually improvements that translate into something positive for you, but in some situations, such as with the security-related changes, the impact may cause you additional work initially:
Active Directory user interface enhancements
The core Active Directory GUI tools have been improved so that they can connect to mounted snapshots as well as AD LDS instances, in addition to various cosmetic features and enhancements. In addition, the attribute editor allows editing of any object attribute in the GUI, and Active Directory Sites and Services supports searching for servers.
Auditing and logging infrastructure enhancements
Auditing of Active Directory access and changes as well as various other actions have been updated substantially.
Delegated DCPromo
Domain controller promotion can be broken up into a two-step process allowing delegation of the physical hands-on portion of dcpromo to users other than domain administrators such as local site support technicians.
Domain DFS scalability enhancements
Domain-based DFS roots can host more than 5,000 links and can also leverage Access Based Enumeration.
DNS user interface enhancements
Various usability enhancements to the MMC such as storing conditional forwarders in Active Directory.
ESE single bit error correction
The JET database engine that Active Directory uses is now capable of detecting single bit errors and correcting them, and thus reducing incidences of database failure due to corruption.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Preparing for ADPrep
Inhaltsvorschau
Before you can install your first Windows Server 2008 domain controller, you have to go through the process of upgrading your existing schema to Windows Server 2008 with the ADPrep utility. If you’ve upgraded from Windows 2000 to Windows Server 2003 AD, you are undoubtedly familiar with the adprep.exe /forestprep switch. If not, please review . This switch is run independently from the domain controller promotion to allow Active Directory administrators to take care of the AD-related tasks necessary to support Windows Server 2008 Active Directory. The Windows Server 2008 process extends the schema to include the objects and attributes necessary for the new Windows Server 2008 features.
You will need to run adprep.exe /domainprep in each domain you plan to deploy Windows Server 2008 domain controllers to. See for details; the process is the same as it is under the initial version of Windows Server 2003. If you are upgrading from Windows 2000, you will also need to run adprep.exe /domainprep /gpprep in each domain you plan to deploy Windows Server 2008 domain controllers to.
If you intend to deploy read only domain controllers (RODCs) in your environment, you will need to run adprep /rodcprep once per forest.
The ADPrep command can be found in the \SOURCES\ADPREP directory on Windows Server 2008 DVD. The ADPrep command depends on several files that reside in that directory, so it cannot simply be copied out and put on a floppy or CD by itself. To run the ForestPrep, you would execute the following:
X:\SOURCES\ADPREP\adprep /forestprep
where X: is a DVD drive or mapped drive to a network share containing the Windows Server 2008 DVD.
You can view detailed output of the ADPrep command by looking at the log files in the %SystemRoot%\system32\debug\adprep\logs directory. Each time ADPrep is executed, a new folder with the current date is generated that contains files with information concerning the actions taken during that particular invocation of ADPrep. The folders are named based on the time and date
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Windows Server 2008 Upgrade Process
Inhaltsvorschau
As with any major upgrade, the first step when beginning your Windows Server 2008 upgrade is to test the upgrade in a representative lab environment. Your lab should model applications that connect to Active Directory, as well as clients. If you are planning to deploy RODCs, you will need to pay particular attention to how applications interact with RODCs.
Once you have completed your testing, you will need to perform the forestprep, , and optionally rodcprep processes outlined earlier in this chapter. Then you can begin deploying Windows Server 2008 domain controllers. While it is supported to simply upgrade an existing domain controller in place to Windows Server 2008, we recommend that you always perform clean installations.
Once you have upgraded all of the domain controllers in a domain to Windows Server 2008, you can upgrade the domain to the Windows Server 2008 functional level to begin taking advantage of new Windows Server 2008 Active Directory features. Once all of the domains are at the Windows Server 2008 functional level, you can upgrade the forest functional level as well.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we covered the new features in Windows Server 2008 and some of the differences with Windows Server 2003. We then went over how you can enable new features with the use of functional levels and why they are necessary. Next we discussed the aDPrep process and how that must be done before the first Windows Server 2008 domain controller can be promoted. Once you have your forest and domains prepared, you can start the upgrade process. We described some of the important issues to be aware of when upgrading, and finally what to do after you’ve completed the upgrade.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 19: Integrating Microsoft Exchange
Inhaltsvorschau
Microsoft Exchange has been the driving reason behind many companies move to Active Directory. Starting with Exchange 2000, Exchange requires an Active Directory infrastructure, and the dependencies it places on Active Directory are not small. In fact, the Exchange schema extensions roughly double the size of the default Active Directory schema. There are also restrictions on the location of your domain controllers relative to the Exchange servers. For these reasons and the critical nature of email, calendar, and collaboration services, all of which Exchange can provide, it is clear that Exchange can be one of the most significant applications you integrate into Active Directory.
In this chapter, we will briefly touch on some of the important issues regarding the integration of Exchange with Active Directory. We’ll also cover how to prepare the forest for Exchange and describe some of the changes this causes.
Here are a few key points to note about Active Directory, Exchange Server 2000, Exchange Server 2003, and Exchange Server 2007:
  • Exchange 2000 can run only on Windows 2000.
  • Exchange Server 2003 can run on Windows 2000 (with reduced functionality) and Windows Server 2003.
  • Exchange Server 2007 SP1 can run Windows Server 2003 or Windows Server 2008.
  • Exchange 2000 can run in a Windows Server 2003 or Windows 2000 Active Directory forest.
    If you are running Exchange 2000 in a forest that is running at the Windows Server 2003 forest functional level, you must review Knowledge Base article 831809 at http://support.microsoft.com/kb/831809.
  • Exchange 2000 SP3 servers cannot exist in an Active Directory site that also contains Windows Server 2008 domain controllers unless you hardcode DSAccess to ignore these domain controllers.
  • Exchange Server 2003 can run in a Windows Server 2003 or Windows 2000 Active Directory forest.
    Be sure to review Microsoft Knowledge Base article 903291 at http://support.microsoft.com/kb/903291 before upgrading a forest to Windows Server 2003 functional level.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
A Quick Word about Exchange/AD Interaction
Inhaltsvorschau
Here are a few key points to note about Active Directory, Exchange Server 2000, Exchange Server 2003, and Exchange Server 2007:
  • Exchange 2000 can run only on Windows 2000.
  • Exchange Server 2003 can run on Windows 2000 (with reduced functionality) and Windows Server 2003.
  • Exchange Server 2007 SP1 can run Windows Server 2003 or Windows Server 2008.
  • Exchange 2000 can run in a Windows Server 2003 or Windows 2000 Active Directory forest.
    If you are running Exchange 2000 in a forest that is running at the Windows Server 2003 forest functional level, you must review Knowledge Base article 831809 at http://support.microsoft.com/kb/831809.
  • Exchange 2000 SP3 servers cannot exist in an Active Directory site that also contains Windows Server 2008 domain controllers unless you hardcode DSAccess to ignore these domain controllers.
  • Exchange Server 2003 can run in a Windows Server 2003 or Windows 2000 Active Directory forest.
    Be sure to review Microsoft Knowledge Base article 903291 at http://support.microsoft.com/kb/903291 before upgrading a forest to Windows Server 2003 functional level.
  • Exchange Server 2003 SP2 (and newer) can run in a Windows Server 2008 Active Directory forest.
    For more information on Windows Server 2008 and Exchange, visit http://msexchangeteam.com/archive/2007/08/16/446709.aspx.
  • Exchange Server 2007 can run in a Windows Server 2003 or Windows Server 2008 Active Directory forest.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Preparing Active Directory for Exchange
Inhaltsvorschau
Before you can install the first Exchange server in Active Directory, you have to prepare your forest and domains. The Exchange 2000 and 2003 setup programs provided two options called /forestprep and /domainprep that perform various tasks such as extending the schema, creating groups, creating containers for Exchange, and setting on those containers. Exchange Server 2007 has revamped this process significantly and now requires a series of setup commands:
  • /PrepareLegacyExchangePermissions
  • /PrepareSchema
  • /PrepareAd
  • /PrepareDomain
Due to the extent of changes caused by running these commands and the elevated privileges required to do so, it is imperative that Active Directory administrators have a thorough understanding of what the commands do.
Exchange Server 2007 is available in 32-bit and 64-bit versions. While it is not supported to run the 32-bit version of Exchange 2007 in production, you can use the 32-bit version for testing, management, and for preparing your Active Directory.
In order to run the Exchange 2007 setup tool, you will need to load Windows PowerShell. On Windows Server 2008, PowerShell is a feature that you can install using Server Manager. Alternatively, you can run ServerManagerCmd -i PowerShell from a command prompt to install PowerShell. On Windows Server 2003, you will need to download PowerShell from Microsoft’s website. Reference http://support.microsoft.com/kb/926139 for download links and installation instructions.
On Windows Server 2008, you must also install the Remote Server Administration Tools (RSAT) for Active Directory Domain Services. You can either install these tools via the Add Features Wizard in Server Manager, or by running ServerManagerCmd -i RSAT-ADDS from a command prompt. This feature includes the ldifde utility that Exchange setup uses to extend the Active Directory schema.
In our experience, a server reboot may be necessary after installing the RSAT-ADDS feature.
The machine on which you are running setup from must be a member of an Active Directory site. More specifically, the machine’s IP address must match a valid subnet definition in Active Directory that is associated with an Active Directory site.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Mail-Enabling Objects
Inhaltsvorschau
In order for an object such as a user or group to be able to receive mail, you must mailbox-enable or mail-enable the object. This process sets all of the necessary attributes on the object so that Exchange knows how to handle mail for that object. In order to carry out this process, you’ll need to either use the Exchange Management Console GUI or the PowerShell cmdlets that ship with Exchange 2007. If you’re running Exchange 2003 or Exchange 2000, you’ll need to use the wizards that are integrated with Active Directory Users and Computers.
The Exchange Management Console (EMC) is a complete replacement for the duo of Exchange System Manager and Active Directory Users and Computers, which were used in versions of Exchange previous to Exchange 2007. The EMC is a frontend to Windows PowerShell, and anytime you run a wizard that executes a PowerShell command, the GUI will actually tell you the PowerShell command that was just run. In this section, we will walk through mailbox-enabling an existing user with the EMC as well as mail-enabling a group.

Mailbox-enabling a user

The EMC is capable of either modifying existing user objects or creating new ones and mailbox-enabling them at the same time. Managing end-user mailboxes is accomplished in the Mailbox pane under Recipient Configuration in the console. You can either right click and select New Mailbox, or use the Action Pane.
shows the choices presented when you run the New Mailbox wizard. We will only discuss creating a user mailbox and briefly a linked mailbox. For more information on the various types of mailboxes and recipients, visit http://technet.microsoft.com/en-us/library/bb201680(EXCHG.80).aspx.
Figure : New Mailbox wizard
shows the screen that you can elect to create mailboxes for existing users or to create new users. You can add to the list as many existing users as you want to create mailboxes for; however, you can only select one set of settings for all of these users (such as mailbox database and policy settings).
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
The importance of Exchange in the enterprise is ever increasing. Exchange has steadily eaten away at the messaging market to the point where it is currently the market leader. In fact, the initial driving force behind the move to Active Directory for many organizations is the need to deploy Exchange. Integrating Exchange into Active Directory is no small feat due to its heavy reliance on AD.
Exchange setup has a number of steps that are necessary to prepare Active Directory to support Exchange, and all of these steps will need to be performed by an Active Directory administrator who has elevated access to the directory. The Exchange Management Console (EMC) and Exchange Management Shell (EMS) are a completely new management experience in Exchange 2007 and provide an end-to-end environment for managing both the Exchange infrastructure as well as objects in the directory that are mail-enabled.
Exchange may be the most significant application you’ll integrate with Active Directory. Knowing this, as an Active Directory administrator you should come to the table with a basic understanding of Exchange, and we covered the principles of Exchange we think you’ll find most useful in this chapter.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 20: Active Directory Lightweight Directory Service (a.k.a. ADAM)
Inhaltsvorschau
Shortly after Microsoft released Windows 2000 Active Directory, developers and started asking for a standalone Microsoft LDAP service that was similar to Active Directory, but didn’t have the baggage of Active Directory such as DNS requirements, the FRS requirements, Group Policy, and other domain pieces like Kerberos and the legacy SAM stuff—basically, something light and easy to set up and play with, and then tear back down as required. While you can do this with Active Directory, there tends to be additional clean-up and configuration required, and things unrelated to the LDAP functionality can get confused and cause it all to malfunction.
In November 2003, shortly after Windows Server 2003 Active Directory was released, Microsoft released Active Directory Application Mode (ADAM) V1.0 to the web (RTW). This was the product that the developers and administrators had been asking for: Active Directory Lite. ADAM allows developers and administrators to play with Active Directory on Windows XP (in the case of ADAM V1.0) or Windows Server 2003 and newer servers without promoting the local host to a full domain controller. The only DNS requirement is resolution of the hostname. There is no FRS, no Kerberos, no group policy, and no extra domain stuff. In fact, ADAM runs nicely as a regular Windows application that can leverage any Windows Domain authentication or local machine authentication that is available, as well as offering up its own authentication that is completely application specific. It is just as happy in a domain as it is on a standalone machine.
Over the last couple of years, companies large and small (including Microsoft) have been building and deploying ADAM-based applications. Due to the fact that ADAM was released after the security push and didn’t have any legacy requirement baggage other than being programmatically compatible with Active Directory, it is, by default, considerably more locked down. Where Active Directory followed the “on or enabled or open by default” mentality, ADAM followed the new “off/disabled/closed by default” approach. From a security standpoint, this is great. Another huge benefit is that many experienced Active Directory administrators and developers will be able to get familiar with ADAM quickly, which will benefit administration, management, monitoring, and application development since ADAM is so similar to Active Directory.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
ADAM Terms
Inhaltsvorschau
There are several terms used throughout this chapter; here are some simple definitions to help understand the concepts:
Instance
An instance is a single installation of ADAM on a server. Each server can have multiple instances of ADAM installed; they would all be independently managed and use different LDAP and LDAPS ports.
Configuration set
A collection of ADAM instances that replicate with each other and share a common schema and configuration container. Application partitions can be shared amongst the instances that make up the configuration set as well.
Replica
An instance of ADAM that is part of a configuration set and replicates with other ADAM instances.
Partition/naming context
Unique namespace named after the root DN. ADAM will have at least two partitions per instance: the configuration and schema partitions. ADAM can also have multiple application partitions.
Application partition
Type of partition that contains application data. ADAM can have multiple application partitions per instance.
Configuration partition
Type of partition that contains configuration data for the instance or configuration set.
Schema partition
Type of partition that contains the class and attribute mappings.
Bindable object
An object instantiated from an objectClass that has msDS-BindableObject listed as a static auxiliary class in the schema definition for the objectClass. The most common bindable object is the user class. Objects of this type are authenticated by ADAM directly.
Bindable proxy object
An object instantiated from an objectClass that has msDS-BindProxy listed as a static auxiliary class in the schema definition for the objectClass. The most common Bindable proxy object is the userProxy class. Objects of this type are authenticated by ADAM by proxying the authentication request to Windows.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Differences Between AD and ADAM V1.0
Inhaltsvorschau
ADAM and AD are quite similar, but obviously there are differences or else there would be nothing to talk about. This section isn’t intended to be a comprehensive listing of all differences, but rather an attempt to catch the major changes and popular “gotchas.”
The most obvious difference is that ADAM is set up to run as a standalone application service; it isn’t part of the system-level service NETLOGON. This means that instead of the LDAP functions being handled by the LSASS.EXE process, they instead run from the DSAMAIN.EXE process. The not-so-obvious upshot of this is that ADAM can be stopped or started on demand without having to reboot the machine. It also means ADAM can be updated as needed, again without rebooting the machine. Anytime you had to go anywhere near the LDAP functionality of a domain controller, you were pretty much guaranteed a reboot and had concerns of it restarting properly and users being impacted. All of these concerns are dramatically reduced now because Active Directory in Application Mode is just an application.
In addition to the benefit of stopping and starting on command, the new service implementation allows you to set up multiple instances of ADAM on a single machine, each under a different service. So instead of having a single Active Directory instance on a machine responding to requests on port 389, you can have multiple ADAM on a machine listening on various ports, with each instance having an entirely different schema.
Another difference is that with ADAM you can actually control what ports the LDAP Service is listening on. Active Directory seemed to have some registry entries you could change to specify what ports it listened on. Unfortunately, it was just a dirty trick: the ports were really hardcoded in the binaries so that you could modify them in the registry, but it didn’t do anything. This is silly because the DNS SRV records have a field describing what port the service is listening on, but it just wasn’t used by the DC Locator functions.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
ADAM R2 Updates
Inhaltsvorschau
There were several changes in the ADAM R2 release. Unless otherwise noted, these changes apply both to ADAM R2 and the Service Pack 1 release for RTW ADAM V1.0. Most of these changes are directly related to feedback from administrators and developers who took the time to post in the various Active Directory newsgroups or submit requests to Microsoft. The Microsoft Directory Services group is very responsive to feedback; if you have suggestions for improvement or have found issues, be sure to document the ideas and post them in the Active Directory newsgroups.
ADAM now allows you to create user and userProxy objects in the configuration partition. These users can then be added to any group in any partition. So, you could add the user to the configuration partition’s administrators group, which is nested in the administrators group of all application partitions. The change allows an ADAM user to administrate an ADAM instance instead of having the requirement to use a Windows user. To enable this new capability, set:
ADAMAllowADAMSecurityPrincipalsInConfigPartition=1
in the msDS-Other-Settings attribute of the Directory Service object to enable this new capability.
Password change requests to bindable proxy objects (such as userProxy) are now chained directly to Windows. Previously Windows user passwords needed to be managed within Windows, and any requests sent to ADAM returned an error. No configuration changes are required to enable this.
ADAM gets the VLV searching capability available in Windows Server 2003 Active Directory. VLV allows you to display a subset of the result set without returning every entry. No configuration changes are required to enable this.
Although there isn’t anything you have to enable to get VLV to work with ADAM, it is likely that you will want to make some changes to better support it. By default, VLV is not efficient when used against an ADAM directory. Also, due to how VLV is implemented in ADAM, you can actually have LDAP query failures if too many objects match the query filter. See the upcoming section ” for more .
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Active Directory Lightweight Directory Services Updates
Inhaltsvorschau
Windows Server 2008 brings an updated version of ADAM that has been renamed to AD LDS. AD LDS is now available as a role under Windows Server 2008. Many of the new Active Directory features in Windows Server 2008 are also available under AD LDS.
The major Active Directory GUI tools, including the Active Directory Schema MMC and Active Directory Sites and Services, are now capable of connecting to AD LDS instances. You can now manage AD LDS replication the same way as you manage Active Directory replication.
In order to connect to an AD LDS instance with the GUI tools, you’ll need to right-click and select Change Domain Controller, and then enter the name and port number of the AD LDS instance (e.g., to connect to an AD LDS instance running on port 389 on server k8devlds01.brianlab.local, you would specify k8devlds01.brianlab.local:389).
AD LDS instances can be hosted on Server Core installations of Windows Server 2008.
You can install AD LDS replicas from media now (IFM) similar to Active Directory. In order to see the IFM step in the AD LDS setup wizard, you will need to run it from the command line. To do this, run %windir%\ADAM\adaminstall.exe /adv. For more information on Install from Media, see .
You can now create snapshots of AD LDS instances and mount them in the same way as with Active Directory domains. For more information about snapshots, see .
AD LDS supports the enhanced directory modification auditing that was introduced to Active Directory in Windows Server 2008. This functionality allows you to log changes to attribute values as well as their previous values. For more information about auditing, see .
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
AD LDS Installation
Inhaltsvorschau
A Windows Server 2008 server does not automatically load AD LDS. In order to use it, you must first install it. Fortunately, the installation routine is a rather trivial process that you can complete in short order. Microsoft also delivers on the promise of reduced reboots in that you will not need to reboot after installing AD LDS.
The AD LDS installation is broken up into two main pieces: installation of the base components and installation of new instances. The base component installation only needs to occur once per server while new instance installations will occur every time you want to install a new instance or replica of an existing instance.
Base component installation is as simple as opening up Server Manager, selecting Roles, clicking Add Roles, checking the Active Directory Lightweight Directory Services checkbox, and hitting Next a couple of times.
Now that you have the component installation completed, you will probably want to actually install a new instance of ADAM. This process is also quite simple, though not as trivial as the component install. When you install a new instance, you need to have answers to the questions listed in .
Table : New instance installation questions
Question
Description
Example
Unique instance or replica? ()
Do you want to replicate the configuration and schema with an existing instance, or do you want a completely new instance?
Unique instance
Instance name? ()
This value is appended to the string “ADAM_” to specify the ADAM service name running this instance and listed in the Add/Remove Programs dialog.
AddressBook
LDAP port number? ()
The TCP port you should listen on for standard LDAP requests.
389
SSL port number? ()
The TCP port you should listen on for SSL-based Secure LDAP (LDAPS) requests.
636
Create application directory partition? ()
Select whether you would like to have the instance creation process create an application partition. This is recommended when you first set up ADAM.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Tools
Inhaltsvorschau
ADAM introduces several new tools and other updated tools that should be familiar to most Active Directory administrators. It is worth loading ADAM just to get these tools. shows all of the tools included with ADAM. All tools are located in the %windir%\ADAM directory.
Table : ADAM tools
Filename
New
Description
ADAM-adsiedit.msc
Yes
View/modify AD and ADAM objects.
ADAM-schmmgmt.dll
Yes
View/Modify ADAM schema objects. This tool will only work on ADAM not AD.
adaminstall.exe
Yes
ADAM instance installer.
adamsync.exe
Yes
Synchronize data from Active Directory to ADAM.
adamuninstall.exe
Yes
ADAM instance remover.
ADSchemaAnalyzer.exe
Yes
Schema comparison to assist with schema differencing/synchronization. Works with AD and ADAM.
csvde.exe
No
CSV directory object import/export. Works with AD and ADAM.
dsacls.exe
No
View/Modify AD and ADAM object ACLs.
dsdbutil.exe
Yes
ADAM instance database management tool.
dsdiag.exe
Yes
Directory diagnosis to assist in directory troubleshooting. Compare with Active Directory DCDiag tool.
dsmgmt.exe
Yes
ADAM instance configuration management tool.
ldifde.exe
No
LDIF directory object import/export. Works with AD and ADAM.
ldp.exe
No
GUI LDAP query tool. Works with AD and ADAM. Great new ACL editor.
repadmin.exe
No
AD and ADAM replication management tool plus much more.
The ADAM-ADSIEDIT GUI tool is similar to ADSIEDIT for Active Directory with some slight upgrades to support ADAM. The primary difference is in data entry forms that allow modification of group membership to insert Windows or ADAM Security principals, as well as the ability to connect to ADAM instances.
The ADAM Schema Management GUI tool is similar to the Schema Management tool for Active Directory with some slight upgrades to support ADAM. The primary difference is in connection dialog and lack of Default Security tab to update the defaultSD attribute for the object. This generally isn’t much of an issue as there aren’t any classes in the base ADAM schema that have any ACEs defined in their
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
ADAM Schema
Inhaltsvorschau
As mentioned previously, the initial ADAM schema is a small subset of the Active Directory schema. The ability to extend the schema is the same as in Active Directory, so you can fully expand the schema to be the same as the AD Schema. Because of this, ADAM is a great place to test schema modifications that you want to make in Active Directory. The fact that the extensions work the same and you can quickly destroy and recreate ADAM instances means that you can quickly test new extensions, changing the definitions until you get exactly what you want. You can even have multiple instances on the same computer running at the same time, each with a different version of the schema so you can easily compare and contrast them. For details on working with the schema, AD and ADAM, see Chapters and .
ADAM supports an additional type of index that is not currently supported by Active Directory. The index is a subtree container index and was specifically added to better support VLV operations. Microsoft first introduced this change for ADAM V1.0 as the hotfix for Microsoft Knowledge Base Article 832474 and was only available upon request. The hotfix is now included with ADAM SP1 and newer for everyone’s benefit.
Creating this index allows any VLV operations using a particular attribute as the sort key to be handled in a significantly more efficient manner. It can also prevent a common failure that causes a VLV query to terminate with a “Critical extension unavailable” error in larger directories. By default, when a VLV query is processed, the directory executes the query and stores the result set in a special internal table called the temp table so it can be sorted. This table can vary in size, but can be no larger than the value specified in the MaxTempTableSize setting of the Default Query Policy. The value for that setting, by default, is only 10,000 records. If the query result set exceeds the size of the current temp table, you will get the Critical extension unavailable error instead of the results. Enabling the subtree container index allows ADAM to avoid using the temp table, which significantly increases performance and avoids the issue of exceeding the temp table size.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Using ADAM
Inhaltsvorschau
Now that you have an overview of what ADAM is, some of the differences, and how to install it, you are probably sitting there with an empty ADAM wondering, “What next?” This section will walk you through some common simple tasks, including creating an application partition and populating it with some data. These examples assume you have installed an ADAM instance with the MS-User.LDF and MS-UserProxy.LDF files. All of the examples will use LDIF files and ldifde.exe for making the updates because it is available with every server and requires no scripting knowledge. If you are familiar with scripting or other LDAP applications, they could be used as well.
If you prefer command-line tools over GUI based tools, point your web browser at http://www.joeware.net and download the ADMOD and ADFIND freeware utilities. These command-line tools are specifically optimized to work with Active Directory and ADAM and have several built-in capabilities that take advantage of special features that aren’t available through ADSI.
Generally, the first thing you need to do with ADAM to add data to it is to create an application partition to house that data. If you had an application partition created during the instance install, then you don’t have to worry about this step unless you would like to create an additional application partition within the same instance.
ADAM will allow you to use any container class as an application partition root. If you want the application partition root to be a container, domainDNS, organizationalUnit, c, o, or even a user, you can easily set it up. You only have to specify three pieces of data to create an application partition: the distinguished name (DN), the objectClass, and instanceType. The instanceType attribute must always be 5, so that just leaves you with two attributes you have to figure out: the DN and objectClass.
The distinguished name is the full qualified name for the root of the partition. This is the value you will use any time you want to access the application partition. The
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
ADAM is an extremely exciting product that is certainly going to find heavy use for both Microsoft and other applications in the enterprise environment. The flexibility it offers allows an Active Directory administrator to say “We can do that” more often now in order to support line of business applications and other functions that they would have never allowed near their domain-based Active Directory. Knowledge and understanding of AD LDS will become more and more important to all Active Directory administrators going forward as more and more applications start to leverage it.
In this chapter, basic AD LDS concepts, as well as some more advanced concepts, were discussed and explored. Next, differences between AD LDS and Active Directory as well as updates in the Windows Server 2008, Windows Server 2003 R2 and Windows Server 2003 SP1 versions of AD LDS/ADAM were discussed. A complete walkthrough of the installation of the core components of AD LDS was provided, as well as walkthroughs for the installations of a standard unique instance and a replica instance with screenshots and tables illustrating decision points. Readers were also introduced to the new and updated tools that ship with AD LDS. Finally, many ldifde.exe examples showing most aspects of creating and deleting objects and partitions were provided and discussed to help a new AD LDS administrator quickly get up and running with a new AD LDS instance.
The management tools for AD LDS are sparse at the moment, but expect a great number of currently existing and all new tools to become available as it becomes more and more widely accepted. Look to AD LDS to give a hint as to possible future modifications and strategic direction of Active Directory.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 21: Scripting with ADSI
Inhaltsvorschau
This chapter covers the basics of ADSI and VBScript so that even inexperienced programmers and system administrators can understand how to write useful Active scripts. In , we show you how to use ADO to search Active Directory and retrieve sets of records according to the search conditions that you impose. Other chapters take this knowledge and extend it so that you can manipulate other aspects of Active Directory, such as permissions and auditing () and modifying the schema (). In , we make an introduction to the .NET Framework and programming Active Directory with it. In , we apply the .NET Framework skills to build a web application using ASP.NET to manage Active Directory objects. Finally, in we discuss using PowerShell to manage Active Directory. covers basic PowerShell constructs.
First, let’s take a look at some of the underlying technologies that you’ll use when developing scripts.
ActiveX, the base component of a number of these technologies, enables software components to interact with one another in a networked environment, regardless of the language in which they were created. Think of ActiveX as the method developers use to specify objects that the rest of us then create and access with our scripts in whatever language we choose. Microsoft currently provides a number of hosts that run scripts to manipulate ActiveX objects including the Internet Information Server (IIS) web server, the Internet Explorer (IE) web browser, and the Windows Scripting Host (WSH). IIS allows scripts called from HTML pages to run on the host server, and IE runs scripts called from HTML pages on the client. WSH allows scripts to run directly or remotely on a host from a command-line or GUI interface. WSH is an integral part of the Windows operating system.
WSH is an important technology for a number of reasons:
  • You need no other software to start scripting.
  • The development environment for WSH has no special requirements to build or compile programs; your favorite text editor will do.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
What Are All These Buzzwords?
Inhaltsvorschau
First, let’s take a look at some of the underlying technologies that you’ll use when developing scripts.
ActiveX, the base component of a number of these technologies, enables software components to interact with one another in a networked environment, regardless of the language in which they were created. Think of ActiveX as the method developers use to specify objects that the rest of us then create and access with our scripts in whatever language we choose. Microsoft currently provides a number of hosts that run scripts to manipulate ActiveX objects including the Internet Information Server (IIS) web server, the Internet Explorer (IE) web browser, and the Windows Scripting Host (WSH). IIS allows scripts called from HTML pages to run on the host server, and IE runs scripts called from HTML pages on the client. WSH allows scripts to run directly or remotely on a host from a command-line or GUI interface. WSH is an integral part of the Windows operating system.
WSH is an important technology for a number of reasons:
  • You need no other software to start scripting.
  • The development environment for WSH has no special requirements to build or compile programs; your favorite text editor will do.
  • You can execute any WSH script with a VBS, JS, or WSF extension just by double-clicking it.
  • You can actually execute scripts from the command line, directing window output to that command line. This is possible because WSH has two interpreters, one called wscript.exe, which interprets scripts in the GUI Windows environment, and one called cscript.exe, which interprets scripts in the command-line environment of a cmd.exe session. By default, if you double-click a script called myscript.vbs, the system passes that script to wscript.exe, just as if you had manually typed wscript.exe myscript.vbs. The default interpreter can be changed globally or on a per-script basis along with other settings.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
ADSI
Inhaltsvorschau
Before you can start writing scripts that use ADSI, you first need to understand the basic COM concept of interfaces and the ADSI concepts of namespaces, programmatic identifiers (ProgIDs), and ADsPath.
A COM interface defines the properties associated with an item, how to access those properties, and how to access specific functionality of the item, more commonly referred to as an object. For example, WSH has a number of objects that represent files, shortcuts, network access, and so on. ADSI provides a specification for interfaces that each directory service provider must implement to maintain uniformity. Each ADSI interface normally supports methods that can be called to perform a specific action, and properties (or property methods) to retrieve information about the object.
A method is a procedure or function that is defined on an object and interacts with the object. An interface to access Active Directory group objects would have Add and Remove methods, so that members could be added or removed from a group. Methods are normally represented as Interface::MethodName when referenced, and this is the form we adopt in this book. Objects also have properties that are retrieved using the IADs::Get or IADs::GetEx methods, and set or replaced using the IADs::Put or IADs::PutEx methods.
Each ADSI object supports an IADs interface that provides six basic pieces of information about that object:
Name
Relative name for the object (RDN in the case of Active Directory)
ADsPath
Unique identifier for object
GUID
128-bit Globally Unique Identifier of object
Class
Objectclass of the object
Schema
ADsPath to the objectclass of the object
Parent
ADsPath to the parent object
If you wanted to retrieve the objectGUID property of an object, you would use the :
strGUID = objX.Get("objectGUID")
You can see that we are calling the IADs::Get method on the object called objX; the dot (.) indicates the invocation of a property or method. The IADs::Get method takes as its one parameter the property to retrieve, which in this case is the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Simple Manipulation of ADSI Objects
Inhaltsvorschau
Let’s now take a look at simple manipulation of Active Directory objects using ADSI. We are using Active Directory as the primary target for these scripts, but the underlying concepts are the same for any supported ADSI namespace and automation language. All the scripts use GetObject to instantiate objects and are assuming you are logged in already with an account that has administrative privileges over the objects manipulated. If you aren’t, you need to use IADsOpenDSObject::OpenDSObject as shown earlier in the chapter.
The easiest way to show how to manipulate objects with ADSI is through a series of real-world examples, the sort of simple tasks that form the building blocks of everyday scripting. To that end, imagine that you want to perform the following tasks on the mycorp.com Active Directory forest:
  1. Create an Organizational Unit called Sales.
  2. Create two users in the Sales OU.
  3. Iterate through the Sales OU and delete each user.
  4. Delete the Organizational Unit.
This list of tasks is a great introduction to how ADSI works because we will reference some of the major interfaces using these examples.
The creation process for the Sales Organizational Unit is the same as for any object. First you need to get a pointer to the container in which you want to create the object. You do that using the following code:
Set objContainer = GetObject("LDAP://dc=mycorp,dc=com")
Because we are creating a container of other objects, rather than a leaf object, you can use the IADsContainer interface methods and properties. The IADsContainer::Create method is used to create a container object, as shown in the following code:
Set objSalesOU = objContainer.Create("organizationalUnit", "ou=Sales")
Here we pass two arguments to IADsContainer::Create: the objectclass of the class of object you wish to create and the Relative Distinguished Name (RDN) of the object itself. We use the ou= prefix because the type of object is an Organizational Unit. Most other objects use the cn=
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
Hopefully, you now understand the basics of ADSI enough to be useful. It’s a very robust API that allows you to interface to all aspects of Active Directory as well as Windows NT, Windows 2000, and Windows Server 2003 servers. Even though the majority of this chapter covers Microsoft operating systems, the code does use the LDAP namespace and is portable to many other directory services. One of ADSI’s biggest strengths is its ability to communicate with a variety of directory services using either LDAP or a provider-specific namespace.
In the next chapter, we will cover the IADs interface in more depth along with a discussion of the Property Cache. A chapter covering ADO will follow and should give you all the necessary tools to query and manipulate Active Directory.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 22: IADs and the Property Cache
Inhaltsvorschau
Each object in a directory has a series of attributes, or properties, that uniquely define it. Although properties can vary from object to object, ADSI supports the manipulation of a core set of six properties common to all objects using the IADs interface. These properties are common to all objects because IADs is the most basic interface in ADSI.
The IADs properties are as follows:
Class
The object’s schema class
GUID
The object’s Globally Unique ID (GUID)
Name
The object’s name
ADsPath
The ADsPath to the object in the current namespace
Parent
The ADsPath to the object’s parent
Schema
The ADsPath to the object’s schema class
Each of these properties has a corresponding property method in the IADs interface. You can use the property method, which has the same name as the property, to access that property’s value. contains code to display the six IADs properties for a user object.
Example . Using the explicit property methods to display the six IADs properties
Option Explicit



Dim objUser 'An ADSI User object

Dim str     'A text string



' User object using the LDAP namespace

Set objUser = GetObject("LDAP://cn=Administrator,cn=Users,dc=mycorp,dc=com")

str = str & "Name: " & objUser.Name & vbCrLf

str = str & "GUID: " & objUser.GUID & vbCrLf

str = str & "Class: " & objUser.Class & vbCrLf

str = str & "ADsPath: " & objUser.ADsPath & vbCrLf

str = str & "Parent: " & objUser.Parent & vbCrLf

str = str & "Schema: " & objUser.Schema & vbCrLf & vbCrLf



WScript.Echo str



Set objUser = Nothing
To begin, we declare two variables (str and objUser), invoke the GetObject method to create a reference to the user object, and assign it to objUser. We then set the str variable to the string "Name:" and apply the IADs::Name property method (i.e., objUser.Name) to retrieve the Name property’s value (i.e., Administrator). The carriage-return line-feed constant (vbCrLf) specifies to move to the start of a new line. At this point, str represents the string "Name: Administrator".
In the next line, we use the IADs::GUID property method (objUser.GUID
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
The IADs Properties
Inhaltsvorschau
The IADs properties are as follows:
Class
The object’s schema class
GUID
The object’s Globally Unique ID (GUID)
Name
The object’s name
ADsPath
The ADsPath to the object in the current namespace
Parent
The ADsPath to the object’s parent
Schema
The ADsPath to the object’s schema class
Each of these properties has a corresponding property method in the IADs interface. You can use the property method, which has the same name as the property, to access that property’s value. contains code to display the six IADs properties for a user object.
Example . Using the explicit property methods to display the six IADs properties
Option Explicit



Dim objUser 'An ADSI User object

Dim str     'A text string



' User object using the LDAP namespace

Set objUser = GetObject("LDAP://cn=Administrator,cn=Users,dc=mycorp,dc=com")

str = str & "Name: " & objUser.Name & vbCrLf

str = str & "GUID: " & objUser.GUID & vbCrLf

str = str & "Class: " & objUser.Class & vbCrLf

str = str & "ADsPath: " & objUser.ADsPath & vbCrLf

str = str & "Parent: " & objUser.Parent & vbCrLf

str = str & "Schema: " & objUser.Schema & vbCrLf & vbCrLf



WScript.Echo str



Set objUser = Nothing
To begin, we declare two variables (str and objUser), invoke the GetObject method to create a reference to the user object, and assign it to objUser. We then set the str variable to the string "Name:" and apply the IADs::Name property method (i.e., objUser.Name) to retrieve the Name property’s value (i.e., Administrator). The carriage-return line-feed constant (vbCrLf) specifies to move to the start of a new line. At this point, str represents the string "Name: Administrator".
In the next line, we use the IADs::GUID property method (objUser.GUID) to retrieve the GUID property’s value (i.e., {D83F1060-1E71-11CF-B1F3-02608C9E7553}). We are appending the GUID to previous value set in str so the new str represents the Name property value and the GUID property value.
While you can use property methods to access most of an object’s properties, you can also use the IADs interface’s IADs::Get and
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Manipulating the Property Cache
Inhaltsvorschau
There will be times when you need to write a script that queries all the values that have been set in the underlying directory for a particular object. For example, you may need to write a script that queries all the property values that have been set for a particular user.
Discovering the set property values for an object can be a long, tedious job. Fortunately, ADSI provides a quick method. If someone has set a value for a property, it must be in that object’s property cache. So all you need to do is walk through the property cache, displaying and optionally modifying each item as you go.
In this section, we’ll describe the property cache mechanics and show you how to write scripts that use several ADSI methods and properties to add individual values, add a set of values, walk through the property cache, and write modifications to the cache and to the directory. Although these examples access the Lightweight Directory Access Protocol (LDAP) namespace, you can just as easily substitute the WinNT namespace in any of the scripts and run them against Windows NT servers.
Details of the property cache interfaces can be found in the MSDN Library at: http://msdn.microsoft.com/en-us/library/aa772166(VS.85).aspx.
Every object has properties. When you perform an explicit IADs::GetInfo call (or an implicit IADs::GetInfo call using IADs::Get) on an object that you previously bound to, the OS loads all the properties for that specific object into that object’s property cache (with the exception of constructed attributes). Consider the property cache a simple list of properties. The PropertyList object represents this list. You can use several IADsPropertyList methods to navigate through the list and access items. For example, you can navigate the list and access each item, every nth item, or one particular item based on its name.
Each item in the property list is a property entry represented by the PropertyEntry object. You use the IADsPropertyEntry interface to access property entries. A property entry can have one or more property values. To access values in a property entry, you use the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Checking for Errors in VBScript
Inhaltsvorschau
It is worthwhile to look at error handling in a little more detail now. Normally errors that occur in a script are termed fatal errors. This means that execution of the script terminates whenever an error occurs. When this happens, a dialog box opens and gives you the unique number and description of the error. While this is useful, sometimes you may like to set errors to be nonfatal, so that execution continues after the error. To do this, you include the following line in your code:
On Error Resume Next
Once you have done this, any line with an error is ignored. This can cause confusion, as can be seen from the following code. Note the missing P in LDAP:
Option Explicit

On Error Resume Next

Dim objGroup

Set objGroup = GetObject("LDAP://cn=Managers,ou=Sales,dc=mycorp,dc=com")

objGroup.GetInfo

WScript.Echo objGroup.Description

objGroup.Description = "My new group description goes here"

objGroup.GetInfo

WScript.Echo objGroup.Description
This script fails to execute any of the lines after the On Error Resume Next statement, as the first LDAP call into the objGroup variable failed. However, it will not terminate as usual with an error after the GetObject line, due to the On Error statement. To get around this, you should add a couple lines to do error checking. is a good example of error checking in a different script.
Example . Error checking in VBScript
On Error Resume Next



'**********************************************************************

'Clear errors

'**********************************************************************

Err.Clear



'**********************************************************************

'Get a pointer to the Administrator account

'**********************************************************************

Set objUser = GetObject ("LDAP://cn=Administrator,cn=Users,dc=mycorp,dc=com")

If Err.Number = &H80005000 Then

  WScript.Echo "Bad ADSI path!" & vbCrLf & "Err. Number: " _

    & vbTab & CStr(Hex(Err.Number)) & vbCrLf & "Err. Descr.: " _

    & vbTab & Err.Description

  WScript.Quit

End If



'**********************************************************************

'Explicitly call GetInfo for completeness

'**********************************************************************

objUser.GetInfo



'**********************************************************************

'Clear any previous errors

'**********************************************************************

Err.Clear



'**********************************************************************

'Try and get a pointer to the "moose" attribute of the user (which

'doesn't exist)

'**********************************************************************

x = objUser.Get("moose")



'**********************************************************************

'Check for property does not exist error

'**********************************************************************

If Err.Number = &H8000500D Then

  WScript.Echo "No such property!" & vbCrLf & "Err. Number: " _

    & vbTab & CStr(Hex(Err.Number)) & vbCrLf & "Err. Descr.: " _

    & vbTab & Err.Description

End If
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
Over the last two chapters, we’ve covered the interfaces, methods, and property methods that allow you to use access and manipulate generic objects in Active Directory. These interfaces include:
  • IADs
  • IADsContainer (covered more fully later)
  • IADsPropertyList
  • IADsPropertyEntry
  • IADsPropertyValue
We’ve also looked at how to supply credentials to authenticate with alternate credentials using the ADsOpenDSObject interface as well as how to work with the error handling capabilities of VBScript.
In the next chapter, we cover how to search Active Directory using a database query interface called ADO.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 23: Using ADO for Searching
Inhaltsvorschau
Microsoft’s ADO technology lets you conduct database searches and retrieve the results through a flexible interface called record sets. ADO also lets you update information in a database directly or with stored procedures. Since Microsoft created an ADO database provider for ADSI (the ADSI OLE DB provider), you can also use ADO’s database query technology to query Active Directory. However, the ADSI OLE DB provider is currently read-only, so many of the useful ADO methods for updating data aren’t available. You can use ADO only for searching and retrieving objects, but despite the read-only limitation, using ADO is still a boon. It is significantly faster to search Active Directory using ADO than it is to use ADSI to enumerate each object recursively down a branch. Even using IADsContainer::Filter is slow in comparison. So if you need to search Active Directory rapidly for attributes that match certain criteria, ADO is exactly what you should use. The ADO object model consists of nine objects (Command, Connection, Error, Field, Parameter, Property, Record, Recordset, and Streams) and four collection objects (Errors, Fields, Parameters, and Properties). However, some of these objects aren’t useful if you’re using the ADSI OLE DB provider, as they are more often used for accessing full-fledged database services. For example, the Parameter object lets you pass parameters to stored procedures, but this object is of little use because the ADSI provider doesn’t support stored procedures.
The objects that are appropriate to ADSI in a read-only environment are the Command, Connection, Error, Field, Property, and Recordset objects. We use them to show you how to perform complex searches. For a full description of the ADO object model and the available functions, check out the following in the MSDN Library at: http://msdn.microsoft.com/en-us/library/ms675532(VS.85).aspx.
One point to note: ADO is written to work with all types of databases , so there are a number of ways to do exactly the same thing. We will attempt to cover examples of each different way as they crop up so that you will be able to choose the method that suits you best or that you are familiar with.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
The First Search
Inhaltsvorschau
The easiest way to explain basic searching using ADO is with an example. Here we’ll build an ADO query to search and display the distinguished names of all users in Active Directory. You can create a simple script to do this search in six steps.
For this script, you need to define one constant and three variables . The constant is adStateOpen, which we set to 1. If you’re using VBScript, you use this constant later to determine whether you made a successful connection to the database. The two main variables are objConn (an ADO Connection object that lets you connect to the AD ) and objRS (an ADO Recordset object that holds the retrieved resultset). The third variable holds the output of the resultset, as shown in the following example:
Option Explicit

Const adStateOpen = 1

Dim objConn    'ADO Connection object

Dim objRS      'ADO Recordset object
The Option Explicit statement at the beginning of the script is optional, but we recommend that you include it. This statement forces the script to declare variables, so you can quickly spot errors.
To perform an ADO query, you need to establish an ADO connection, which is completely separate from any ADSI connections you opened with IADsOpenDSObject::OpenDSObject. Before you can establish this connection, you must create an ADO Connection object to use. This object can be created the same way you create a filesystem object: use the CreateObject method, with "ADODB.Connection" as a parameter. You use the ADODB prefix to create all ADO objects, and Connection is the top-level object in the ADO object model:
Set objConn = CreateObject("ADODB.Connection")
Just as you use different programmatic identifiers (ProgIDs) (e.g., WinNT:, LDAP:) to tell ADSI which directory to access, you use different OLE DB providers to tell ADO which query syntax to use. An OLE DB provider implements OLE DB interfaces so that different applications can use the same uniform process to access data. The ADSI OLE DB connector supports two forms of syntax: the SQL dialect and the LDAP dialect. Although you can use the SQL dialect to query the ADSI namespace, most scriptwriters use the LDAP dialect because Active Directory is an LDAP Directory. However, the default for the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Understanding Search Filters
Inhaltsvorschau
When you use the LDAP dialect with the ADSI OLE DB provider to conduct a search, you must use an LDAP search filter to specify your search criteria. In a simple case, (objectclass=user) would be used to select every object with the user objectClass under the search base. You can in fact use a filter to match the presence of a value (or not) for any attribute of an object. This enables you to create powerful searches with complex criteria. For example, you can search for any group object that has a certain user as a member and that has a description matching a certain substring.
Filters must follow the format specified in RFC 2254, The String Representation of LDAP Search Filters. You can download RFC 2254 from http://www.ietf.org/rfc/rfc2254.txt.
Although filters let you conduct powerful searches, working with them can seem complex because of the format used, known as prefix notation. To make it easier to understand, we have divided the discussion of filters into two parts: items within a filter and items connecting filters.
Within a filter, you can have three types of items:
Operators
A filter can include one of three operators . The equal-to (=) operator checks for exact equivalence. An example is (name=janet). The greater-than-or-equal-to (>=) and less-than-or-equal-to (<=) operators check for compliance with a range. Examples are (size>=5) and (size<=20).
The equal-to operator can be modified to specify a bitwise comparison. The format of the filter is attribute:matching_rule_oid:=value. The two matching rule OIDs are 1.2.840.113556.1.4.803 for a bitwise AND match and 1.2.840.113556.1.4.804 for a bitwise OR match. For example, the filter (userAccountControl: 1.2.840.113556.1.4.803:=2) searches for objects that have bit 1 (value 2) enabled, which means they are marked as disabled.
Attributes
You can include attributes in filters when you want to determine whether an attribute exists. You simply specify the attribute, followed by the = operator and an asterisk (
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Optimizing Searches
Inhaltsvorschau
When you are searching Active Directory using LDAP filters, there are some important guidelines to follow that can help reduce load on the domain controllers, increase the performance of your scripts and applications, and reduce the amount of traffic generated on the network. It is also important to socialize these concepts with others as much as possible. It takes only a couple of badly written search filters in a heavily used application to severely impact the performance of your domain controllers!
Understanding how to write efficient search criteria is the first important step to optimizing searches. By understanding a few key points, you can greatly improve the performance of your searches. It is also important to reuse data retrieved from searches or connections to Active Directory as much as possible. Microsoft has provided a paper on creating more efficient Active Directory Enabled applications. This paper has a lot of detailed information concerning efficient queries. You can find the paper at the URL: http://msdn.microsoft.com/en-us/library/ms808539.aspx.
The following list describes several key points to remember about searching:
  • Use at least one indexed attribute per search. Certain attributes are marked as “indexed” in Active Directory, which allows for fast pattern matching. They are typically single-valued and unique, which means searches using indexed attributes can determine which objects match them very quickly. If you don’t use indexed attributes, the database equivalent of a full table scan must be done to determine the matches.
  • Use objectCategory or a combination of objectClass and objectCategory in every search. The problem with using only objectClass is that it is not indexed in a default Active Directory installation prior to Windows Server 2008. objectCategory, on the other hand, is indexed by default and much more efficient to use. See the next section for more information.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Advanced Search Function: SearchAD
Inhaltsvorschau
We will now take many of the concepts from this chapter and apply them in a useful example called SearchAD. SearchAD can be included in any VBScript and used immediately as is.
SearchAD takes five parameters and returns a Boolean indicating whether it succeeded or failed in the search. You should recognize most of these parameters:
  • The base distinguished name to start the search from
  • A valid ADO criteria string
  • The depth that you wish to search, represented by one of the exact strings Base, OneLevel, or SubTree
  • The comma-separated list of attributes that is to be returned
  • A variable that will hold the returned results of the search in an array
The last parameter does not have any values when passed in, but if SearchAD is successful, the array contains the resultset.
Here is an example use of SearchAD:
bolIsSuccess = SearchAD("LDAP://ou=Finance,dc=mycorp,dc=com", _

  "(cn=a*)", "Base", "cn,description", arrSearchResults)
You can also use it as part of an If…Then condition:
If SearchAD("LDAP://dc=mycorp,dc=com", "(description=moose)", "SubTree", _

  "ADsPath,cn,description", arrSearchResults) Then

  'success code using arrSearchResults

Else

  'failure code

End If
The array that is returned is a two-dimensional array of attributes that match the criteria. If there were 12 results returned for the preceding query, this is how you access the results:
arrSearchResults(0,0) 'ADsPath of first result

arrSearchResults(0,1) 'CN of first result

arrSearchResults(0,2) 'Description of first result

arrSearchResults(1,0) 'ADsPath of second result

arrSearchResults(1,1) 'CN of second result

arrSearchResults(1,2) 'Description of second result

arrSearchResults(2,0) 'ADsPath of third result

arrSearchResults(2,1) 'CN of third result

arrSearchResults(2,2) 'Description of third result

arrSearchResults(3,0) 'ADsPath of fourth result

arrSearchResults(3,1) 'CN of fourth result

arrSearchResults(3,2) 'Description of fourth result

.

.

.

arrSearchResults(11,0) 'ADsPath of 11th result

arrSearchResults(11,1) 'CN of 11th result

arrSearchResults(11,2) 'Description of 11th result
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we reviewed the basics of ADO, which provides a robust search interface for Active Directory. While originally intended for databases, ADO was adapted to Active Directory to allow queries based on LDAP search filters. Several techniques for optimizing searches in Active Directory were reviewed, including a discussion of using objectClass versus objectCategory. We ended the chapter by covering a fully functional SearchAD procedure that can be used as-is in any VBScript to easily search Active Directory based on specified criteria. SearchAD hides all the underlying ADO logic, including connection setup, query execution, and recordset manipulation.
After providing a good background for ADSI and ADO in the last three chapters, we are now ready to move to more practical applications. The next several chapters show some of the capabilities these interfaces provide and a lot of sample code to get you started.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 24: Users and Groups
Inhaltsvorschau
In this chapter, we will show you how to automate the creation and manipulation of user and group accounts. Although tools to create user and group accounts already exist (e.g., the Windows 2000 Resource Kit’s Addusers utility), ADSI’s versatility lets you quickly write a script that creates 1,000 fully featured user or group accounts based on whatever business logic you require. You can also create command-line utilities or web-based interfaces using the techniques shown in this chapter to perform such functions as unlocking locked-out user accounts or adding users to groups.
You can quickly create a user account with minimal attributes with ADSI. The following code shows how to create a user on a local computer and in an Active Directory domain:
Option Explicit

Dim objDomain, objUser



'Creating a local user on a computer or member server

'Valid for Windows NT/2000/2003/2008

Set objComputer = GetObject("WinNT://MYCOMPUTER,Computer")

Set objUser = objComputer.Create("user","vlaunders")

objUser.SetInfo



'Creating a user in Active Directory

Set objDomain = GetObject("LDAP://cn=Users,dc=mycorp,dc=com")

Set objUser = objDomain.Create("user", "cn=vlaunders")

objUser.Put "sAMAccountName", "vlaunders"

objUser.Put "userPrincipalName", "vlaunders@mycorp.com"

objUser.SetInfo
The code is composed of two sections. The first section uses the WinNT provider to create a user account on a local computer that could be a member server or part of a workgroup. The second section uses the LDAP provider to create a user account in an Active Directory domain.
When you create users in an Active Directory domain, you need to be aware of two important User object attributes: sAMAccountName and userPrincipalName. The User object has several mandatory attributes. The system sets many of these mandatory attributes, except for one, sAMAccountName, which allows Active Directory-based clients to interact with older clients and NT domains. You must set the sAMAccountName attribute before you call IADs::SetInfo or the creation will fail. The
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Creating a Simple User Account
Inhaltsvorschau
You can quickly create a user account with minimal attributes with ADSI. The following code shows how to create a user on a local computer and in an Active Directory domain:
Option Explicit

Dim objDomain, objUser



'Creating a local user on a computer or member server

'Valid for Windows NT/2000/2003/2008

Set objComputer = GetObject("WinNT://MYCOMPUTER,Computer")

Set objUser = objComputer.Create("user","vlaunders")

objUser.SetInfo



'Creating a user in Active Directory

Set objDomain = GetObject("LDAP://cn=Users,dc=mycorp,dc=com")

Set objUser = objDomain.Create("user", "cn=vlaunders")

objUser.Put "sAMAccountName", "vlaunders"

objUser.Put "userPrincipalName", "vlaunders@mycorp.com"

objUser.SetInfo
The code is composed of two sections. The first section uses the WinNT provider to create a user account on a local computer that could be a member server or part of a workgroup. The second section uses the LDAP provider to create a user account in an Active Directory domain.
When you create users in an Active Directory domain, you need to be aware of two important User object attributes: sAMAccountName and userPrincipalName. The User object has several mandatory attributes. The system sets many of these mandatory attributes, except for one, sAMAccountName, which allows Active Directory-based clients to interact with older clients and NT domains. You must set the sAMAccountName attribute before you call IADs::SetInfo or the creation will fail. The userPrincipalName attribute isn’t mandatory, but it is recommend so users can log on using an email-style address, as defined in RFC 2822, Internet Message Format at http://www.ietf.org/rfc/rfc2822.txt.
Windows Server 2003 Active Directory changed the mandatory requirement of sAMAccountName being populated during object creation. If you do not specify it, you will get a randomly generated sAMAccountName such as $KJK000-H4GJL6AQOV1I.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Creating a Full-Featured User Account
Inhaltsvorschau
Creating user accounts as we’ve done previously is fine for an introduction, but typically you’ll need to set many more attributes to make them usable in your environment. The approaches you use to create fully featured users in the NT and Active Directory environments differ slightly; Active Directory offers considerably more properties than NT, such as the office and home addresses of users, as well as lists of email addresses and pager, fax, and phone numbers.
You can manipulate User objects with a special interface called IADsUser. IADsUser’s methods and property methods let you directly set many of the User object’s property values. Tables , , and contain the methods, read-write property methods, and read-only property methods, respectively, for the IADsUser interface. The corresponding Active Directory attribute is included in parentheses for the property methods that can be set with the LDAP provider.
Table : IADsUser methods
Method
Description
IADsUser::ChangePassword
Changes the existing password.
IADsUser::SetPassword
Sets a new password without needing the old one.
IADsUser::Groups
Gets a list of groups of which the user is a member. You can use the IADsMembers interface to iterate through the list.
Table : IADsUser read-write property methods
Property method
Available with WinNT or LDAP?
IADsUser::AccountDisabled
WinNT, LDAP (userAccountControl mask).
IADsUser::AccountExpirationDate
WinNT, LDAP (accountExpires).
IADsUser::Department
LDAP (department).
IADsUser::Description
WinNT, LDAP (description).
IADsUser::Division
LDAP (division).
IADsUser::EmailAddress
LDAP (mail).
IADsUser::EmployeeID
LDAP (employeeID).
IADsUser::FaxNumber
LDAP (facsimileTelephoneNumber).
IADsUser::FirstName
LDAP (givenName).
IADsUser::FullName
WinNT, LDAP (displayName).
IADsUser::GraceLoginsAllowed
Neither.
IADsUser::GraceLoginsRemaining
Neither.
IADsUser::HomeDirectory
WinNT, LDAP (homeDirectory).
IADsUser::HomePage
LDAP (wWWHomePage).
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Creating Many User Accounts
Inhaltsvorschau
User-specific scripts work well if you have to create only a few user accounts. If you need to create many user accounts at one time, or if you create new accounts often, using a script with an input file is more efficient. The input file includes the user data so that you can use the script to create any user account. For example, the output shown below represents the users-to-create.txt input file that provides the user data for the universal script in . Although this input file includes only four data sets, you can include as many data sets as you want. You include a data set for each user account that you want to create:
vlaunders:12/09/01:The description:Victoria Launders:onebanana

aglowenorris:08/07/00:Another user:Alistair Lowe-Norris:twobanana

kbemowski:03/03/03:A third user:Karen Bemowski:threebanana

jkellett:08/09/99:A fourth user:Jenneth Kellett:four
Example . Creating many user accounts using a script with an input file
Option Explicit



Const ForReading = 1



Dim objDomain, objUser, fso, tsInputFile, strLine, arrInput

Dim fldUserHomedir, wshShell



Set objDomain = GetObject("LDAP://cn=Users,dc=mycorp,dc=com")

Set fso = CreateObject("Scripting.FileSystemObject")



'**********************************************************************

'Open the text file as a text stream for reading.

'Don't create a file if users-to-create.txt doesn't exist

'**********************************************************************

Set tsInputFile = fso.OpenTextFile("c:\users-to-create.txt", ForReading, False)



'**********************************************************************

'Execute the lines inside the loop, as long as you're not at the end

'of the file

'**********************************************************************

While Not tsInputFile.AtEndOfStream



  '**********************************************************************

  'Read a line, and use the Split function to split the data set into

  'its separate parts

  '**********************************************************************

  strLine = tsInputFile.ReadLine

  arrInput = Split(strLine, ":")



  Set objUser = objDomain.Create("user","cn=" & arrInput(0))

  objUser.Put "sAMAccountName", arrInput(0)

  objUser.Put "userPrincipalName", arrInput(0) & "@mycorp.com"



  '**********************************************************************

  'Write the newly created object out from the property cache

  'Read all the properties for the object, including

  'the ones set by the system on creation

  '**********************************************************************

  objUser.SetInfo

  objUser.GetInfo



  '**********************************************************************

  'Set the password

  '**********************************************************************

  objUser.SetPassword arrInput(4)



  '**********************************************************************

  'Set the properties

  '**********************************************************************

  objUser.AccountDisabled = False

  objUser.AccountExpirationDate = arrInput(1)

  objUser.Description = arrInput(2)

  objUser.LoginScript = "\\MYDOMAIN\DFS\Loginscripts\" & arrInput(0) & ".vbs"

  objUser.Profile = "\\MYDOMAIN\DFS\Users\" & arrInput(0) & "\profile"

  objUser.PasswordRequired = True

  objUser.DisplayName = arrInput(3)



  '**********************************************************************

  'Set the drive that you'll map to

  '**********************************************************************

  objUser.HomeDirectory = "\\MYDOMAIN\DFS\Users\" & arrInput(0)

  objUser.Put "homeDrive", "Z:"

  objUser.SetInfo



  '**********************************************************************

  'Create the home directory

  '**********************************************************************

  If Not fso.FolderExists("\\MYDOMAIN\DFS\Users\" & arrInput(0)) Then

    Set fldUserHomedir = fso.CreateFolder("\\MYDOMAIN\DFS\Users\" & arrInput(0))

  End If



  '**********************************************************************

  'Set full rights for the user to the home directory

  '**********************************************************************

  Set wshShell = WScript.CreateObject("Wscript.Shell")

  wshShell.Run "cacls \\MYDOMAIN\DFS\Users\" & arrInput(0) _

    & " /e /g " & arrInput(0) & ":F", 1, True



  '**********************************************************************

  'Stop referencing this user

  '**********************************************************************

  Set objUser = Nothing

Wend



'Close the file

tsInputFile.Close
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Modifying Many User Accounts
Inhaltsvorschau
Once you have created the user accounts in a domain, you will more than likely need to modify them at some point. The modifications may consist only of changing individual properties of a user, such as the description or name fields. In these cases, you can perform the change manually or write a command-line script as shown in the next section. In some situations, you will need to make a large number of changes to your user accounts, as would be the case if you changed the name of a login script and wanted to point all users to the new script.
In most cases with Active Directory domains, you will want to use ADO to find objects, as explained in . So for our next example, let’s say that we want to change the login script for all users in the domain that have a department attribute equal to “Sales.” shows how this can be done using ADO.
Example . Modifying the login script for all users in Sales
Option Explicit

On Error Resume Next

Dim objConn, objComm, objRS, objUser

Dim strBase, strFilter, strAttrs, strScope

'**********************************************************************

'Set the ADO search criteria

'**********************************************************************

strBase   = "<LDAP://dc=mycorp,dc=com>;"

strFilter = "(&(objectclass=user)(objectcategory=person)(department=Sales));"

strAttrs  = "ADsPath;"

strScope  = "Subtree"



set objConn = CreateObject("ADODB.Connection")

objConn.Provider = "ADsDSOObject"

objConn.Open

'**********************************************************************

'Need to enable Paging in case there are more than 1000 objects returned

'**********************************************************************

Set objComm = CreateObject("ADODB.Command")

Set objComm.ActiveConnection = objConn

objComm.CommandText = strBase & strFilter & strAttrs & strScope

objComm.Properties("Page Size") = 1000

Set objRS = objComm.Execute()

While not objRS.EOF

  Set objUser = GetObject( objRS.Fields.Item("ADsPath").Value )

  objUser.LoginScript = "login-sales.vbs"

  objUser.SetInfo

  if Err.Number <> 0 Then

     Wscript.Echo objUser.Name & " error occurred"

     Err.Clear

  Else

     Wscript.Echo objUser.Name & " modified"

  End if

  Set objUser = Nothing

  objRS.MoveNext

Wend
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Account Unlocker Utility
Inhaltsvorschau
Imagine that you need a utility that quickly enables and unlocks an NT or Active user account. The account was locked because the password was entered incorrectly too many times in succession. Writing a user-specific script is inefficient if you have many users. Using an input file to pass in the needed user data to a script also is inefficient. You’d have to create the input file just before running the script, because you can’t predict whose account you need to unlock. The best approach is to use -line arguments to pass in the user data as you need it. uses this approach to enable and unlock an Active Directory user account. If you have a mixed NT and Active Directory network, you can even combine these two utilities into one script.
Example . Account unlocker utility for Active Directory using the LDAP provider
'**********************************************************************

'How to unlock and enable a Active Directory user via arguments

' to this script

' Parameters should be <domain> <username>, where domain specifies

' a fully qualified AD domain like dc=mycorp,dc=com

'**********************************************************************

Option Explicit



Dim wshArgs, objUser, strOutput, arrSearchResults



On Error Resume Next



'**********************************************************************

'Get the arguments

'**********************************************************************

Set wshArgs = Wscript.Arguments



'**********************************************************************

'If no arguments passed in, then quit

'**********************************************************************

If wshArgs.Count = 0 Then

  WScript.Echo "ERROR: No arguments passed in." & vbCrLf & vbCrLf _

    & "Please use AD-UNLOCK <domain> <username>" & vbCrLf & vbCrLf

  WScript.Quit

End If



'**********************************************************************

'Error checking of the arguments could go here if we wanted to

'**********************************************************************



'**********************************************************************

'Use SearchAD function from the end of  to scan the entire

'Active Directory for this user and return the ADsPath. If the search

'failed for whatever reason, then quit

'**********************************************************************

If Not SearchAD("LDAP://" & wshArgs(0), _

  "(&(objectcategory=person)(objectClass=user)(sAMAccountName=" _

     & wshArgs(1) & "))", "SubTree", "ADsPath", arrSearchResults) Then



  WScript.Echo "ERROR: No users found." & vbCrLf & vbCrLf

  WScript.Quit

Else

  '**********************************************************************

  'Attempt to bind to the first ADsPath specified in the array

  '(as there should be only one)

  '**********************************************************************

  Set objUser = GetObject(arrSearchResults(0,0))

  If Err Then

    Wscript.Echo "Error: Could not bind to the following user: " & vbCrLf _

      & vbCrLf & arrSearchResults(0,0) & vbCrLf & vbCrLf

    WScript.Quit

  Else

    strOutput = "Connected to user " & arrSearchResults(0,0) & vbCrLf

  End If



  '**********************************************************************

  'Attempt to enable the user (but don't quit if you fail)

  '**********************************************************************

  Err.Clear

  objUser.AccountDisabled = False

  objUser.SetInfo

  If Err Then

    strOutput = strOutput & vbTab & "Error: Could not enable the user." & vbCrLf

  Else

    strOutput = strOutput & vbTab & "User enabled." & vbCrLf

  End If



  '**********************************************************************

  'Attempt to unlock the user

  '**********************************************************************

  Err.Clear

  objUser.IsAccountLocked = False

  objUser.SetInfo

  If Err Then

    strOutput = strOutput & vbTab & "Error: Could not unlock the user." & vbCrLf

  Else

    strOutput = strOutput & vbTab & "User unlocked." & vbCrLf

  End If



  WScript.Echo strOutput

End If
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Creating a Group
Inhaltsvorschau
Now we will move on to creating groups. Creating a group is very similar to creating a user. You use the same IADsContainer::Create method:
Set objGroup = objSalesOU.Create("group", "cn=Managers")

objGroup.Put "sAMAccountName", "Managers"

objGroup.SetInfo
This code assumes we already have a pointer to an OU in the objSalesOU variable. The IADs::Put method is used to set the sAMAccountName, a mandatory attribute in Windows 2000 Active Directory with no default value, just like with users.
The IADsGroup interface that operates on group objects supports four methods and one property that are specific to the group object, as listed in .
Table : The IADsGroup interface
IADsGroup methods and properties
Action
Add
Adds users to the group as members
Remove
Removes user members from the group
IsMember
Tests to see if a user is a member of a group
Members
Returns a list of all the members of the group
Description
Returns the text describing the group
In , we show how to create a group with both the WinNT and LDAP providers.
Example . Creating a group with both the WinNT and LDAP providers
Option Explicit



Dim objDomain, objGroup, objComputer



'Creating a group in a Windows NT domain

Set objDomain = GetObject("WinNT://MYDOMAIN")

Set objGroup = objDomain.Create("group","MyGroup")

objGroup.SetInfo



'Creating a local group on a computer or member server

'Valid for Windows NT, Windows 200x

Set objComputer = GetObject("WinNT://MYCOMPUTER")

Set objGroup = objComputer.Create("group","My Group")

objGroup.SetInfo



'Creating a group in Active Directory

Set objDomain = GetObject("LDAP://cn=Users,dc=mycorp,dc=com")

Set objGroup = objDomain.Create("group","cn=My Group")

objGroup.Put "sAMAccountName", "MyGroup"

objGroup.SetInfo
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Adding Members to a Group
Inhaltsvorschau
Adding objects as members of a group can be done with IADsGroup::Add, a simple method that takes the DN of the object to be added:
objGroup.Add("LDAP://cn=Sue Peace,cn=Users,dc=mycorp,dc=com")

objGroup.Add("LDAP://cn=Keith Cooper,cn=Users,dc=mycorp,dc=com")
Groups can contain virtually any other type of object as a member, including users, computers, and other groups.
In , we described the need to add many user groups as members of several permission groups. contains the code necessary to implement this functionality. It scans for all groups prefixed with USER_ and DRUP_. It then adds all the USER groups to each DRUP group, except for the group where the suffix matches. In other words, all USER_ groups except USER_Finance are added to DRUP_Finance. This was why the names were set up this way.
Example . Adding many user groups as members of several permission groups
'**************************************************************************

'Search the entire AD for all groups starting USER_ and return the cn

'and AdsPath variables in the following structure

'

'  arrUSERGroup(index,0) = cn attributes

'  arrUSERGroup(index,1) = ADsPath attribute

'

'where index goes from 0 to (the maximum number of results returned -1)

'**************************************************************************

If (SearchAD("LDAP://dc=mycorp,dc=com", _

       "(&(objectCategory=group)(cn=USER_*))", _

           "SubTree", "cn,ADsPath", arrUSERGroup)) Then



  '**************************************************************************

  'As above but for DRUP_ groups

  '**************************************************************************

  If (SearchAD("LDAP://dc=mycorp,dc=com", _

      "(&(objectCategory=group)(cn=DRUP_*))", _

              "SubTree", "cn,ADsPath", arrDRUPGroup)) Then



    '***********************************************************************

    'Set up an index to allow us to iterate through the USER_ groups. The

    'Ubound function here counts the maximum number of rows returned

    '***********************************************************************

    arrUSERGroupsUb = Ubound(arrUSERGroups)

    For intUSERGroupIndex = 0 To arrUSERGroupsUb

      '***********************************************************************

      'As above but for DRUP_ groups

      '***********************************************************************

      arrDRUPGroupsUb = Ubound(arrDRUPGroups)

      For intDRUPGroupIndex = 0 To arrDRUPGroupsUb

        '***********************************************************************

        'Extract the portion of the name that corresponds to all letters after

        'the "USER_" or "DRUP_" parts (i.e., five  letters)

        '***********************************************************************

        txtUSERGroupSuffixName = Right(arrUSERGroup(intUSERGroupIndex,0), _

          Len(arrUSERGroup(intUSERGroupIndex,0))-5)

        txtDRUPGroupSuffixName = Right(arrDRUPGroup(intDRUPGroupIndex,0), _

          Len(arrDRUPGroup(intDRUPGroupIndex,0))-5)

        '***********************************************************************

        'If the two extracted strings are not the same, then add the USER group

        'to the DRUP group

        '***********************************************************************

        If Not txtUSERGroupSuffixName = txtDRUPGroupSuffixName Then

          Set objDRUPGroup = GetObject(arrDRUPGroup(intDRUPGroupIndex,1))

          If NOT objDRUPGroup.IsMember(arrUSERGroup(intUSERGROUPIndex,1)) Then

           objDRUPGroup.Add(arrUSERGroup(intUSERGroupIndex,1))

           objDRUPGroup.SetInfo

          End If

        End If

      Next

    Next

  End If

End If
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Evaluating Group Membership
Inhaltsvorschau
The IADsGroup::IsMember method takes one argument, the DN of the object to check, just as Add and Remove do. It returns a Boolean, i.e., true or false. That allows you to use it in an If … Then statement like this:
Set objGroup = GetObject("LDAP://cn=Managers,ou=Sales," _

  & "dc=mycorp,dc=com")

If objGroup.IsMember("LDAP://cn=Vicky Launders,ou=Sales," _

  & "dc=mycorp,dc=com") Then

    WScript.Echo "Is a Member!"

Else

    WScript.Echo "Is NOT a Member!"

End If
To get a list of members in a group, the IADsGroup::Members method can be used. The IADsGroup::Members function is different from the other IADsGroup methods we have shown so far, since it returns a pointer to an IADsMembers object. shows the two methods IADsMembers support.
Table : The IADsMembers interface
Action
Count
The number of items in the container. If there is a filter set, only the number of items that match the filter are returned.
Filter
A filter, consisting of an array of object class strings, that can restrict the number of objects returned during enumeration of the container.
There are a number of ways of enumerating the members of a group. The For Each … In … Next loop is the most common. This is how it works:
Set objGroup = GetObject("LDAP://cn=Managers,ou=Sales," _

  & "dc=mycorp,dc=com")

WScript.Echo "Number of members of the group: " & objGroup.Members.Count

For Each objMember In objGroup.Members

  WScript.Echo objMember.Name

Next
This script displays the number of members and then prints each member’s name. As the For loop executes, objMember ends up holding an IADs object representing each member of the group.
Another useful feature of IADsMembers is the Filter method. It can be used to filter certain object classes during enumeration just like you can with containers. To view only the members of a group that are users, you would modify the previous example to do the following:
objMembers = objGroup.Members

objMembers.Filter = Array("User")

For Each objMember In objMembers

  WScript.Echo objMember.Name

Next
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we looked at how to create and manipulate properties of user and group objects in Active Directory and the Windows NT SAM. We used this knowledge to show how to write a script to create thousands of users easily from a set of data in a file or from a database. We then showed how to create simple tools, such as an account unlocker, that you can use in your day-to-day management of Active Directory. Next we showed how to create groups and modify group members. Finally, we reviewed how to determine group membership and iterate through all the members of a group.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 25: Permissions and Auditing
Inhaltsvorschau
Security descriptors (SDs), access control lists (ACLs), and access control entries (ACEs) have been used for files and directories on NTFS filesystems for years. The same concepts apply to securing Active Directory objects as well. While the information in this chapter is focused on Active Directory, the principles of creating a SD that contains a discretionary access control list (DACL) and system access control list (SACL) can map over to NTFS files and directories.
ADSI provides four main interfaces we can use:
IADsAccessControlEntry
Manipulates individual ACEs that represent access or audit permissions for specific users or groups to objects and properties in Active Directory
IADsAccessControlList
Manages collections of ACEs for an object
IADsSecurityDescriptor
Manages the different sets of ACLs to an object
IADsSecurityUtility
Gets, sets, and retrieves security descriptors for an object
All of the ADSI security interfaces can be found in the MSDN Library at http://msdn.microsoft.com/en-us/library/aa746481.aspx.
If you haven’t read in its entirety, you may find this chapter a little confusing.
Microsoft has a habit of calling a shovel a ground insertion earth management device (GIEMD for short); that is, they like to give names that are not always intuitive to the average person. The contents of the five properties of the ACE object are not all immediately obvious from the names. In addition, as Microsoft uses the ACE for system audit and permissions entries, a number of values that can go into the properties make sense only in a particular context. To complicate matters further, one property (AceFlags) is a catchall area that currently serves as the location for two completely different sets of information.
Creating an ACE is a simple matter, getting it right is a lot more difficult. To set up an ACE, you need the following basic pieces of information:
AccessMask
What permissions you want to set
AceType
Whether you are setting allow/deny permissions or auditing for an object or
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
How to Create an ACE Using ADSI
Inhaltsvorschau
Microsoft has a habit of calling a shovel a ground insertion earth management device (GIEMD for short); that is, they like to give names that are not always intuitive to the average person. The contents of the five properties of the ACE object are not all immediately obvious from the names. In addition, as Microsoft uses the ACE for system audit and permissions entries, a number of values that can go into the properties make sense only in a particular context. To complicate matters further, one property (AceFlags) is a catchall area that currently serves as the location for two completely different sets of information.
Creating an ACE is a simple matter, getting it right is a lot more difficult. To set up an ACE, you need the following basic pieces of information:
AccessMask
What permissions you want to set
AceType
Whether you are setting allow/deny permissions or auditing for an object or
Trustee
Who to apply the permissions to
AceFlags
What inheritance options you want and, if it is an audit entry, whether you are monitoring successes or failures
Flags
Determines whether or not the object type is inherited or not
ObjectType
Indicates what type of ADSI object the permission is for
InheritedObjectType
What the ACE applies to if not just the entire object
We will now go through several examples to show you what the seven properties of an ACE will contain based on certain security settings. Let’s start with the simple example: giving a user full control permissions to an Organizational Unit. That means the information in gets stored as an ACE on the SD of the Organizational Unit itself.
Table : Contents of the ACE properties when giving a user full control permissions to an Organizational Unit
Name of the property
Value to be stored
Trustee
Names the user who is to have the permission.
AccessMask
Gives full control (i.e., give every permission).
AceType
This is an allow permission.
AceFlags
The permission applies to this object. Child objects inherit this ACE.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
A Simple ADSI Example
Inhaltsvorschau
All of the seven ACE properties are set using property methods of the same names as those in an ADSI interface called IADsAccessControlEntry. The ACEs that are created using this are then modified using IADsAccessControlList and IADsSecurityDescriptor.
Let’s go through an example now so you can see how it all fits together. shows a section of VBScript code that creates an ACE that allows ANewGroup full access to the myOU organizational unit and all its children.
Example . A simple ADSI example
Option Explicit



'Declare constants

Const FULL_CONTROL = -1

Const ADS_ACETYPE_ACCESS_ALLOWED = 0

Const ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT = 2



'Declare variables

Dim objObject    'Any object

Dim objSecDesc   'SecurityDescriptor

Dim objDACL      'AccessControlList

Dim objNewACE    'AccessControlEntry



'Create the new ACE and populate it

Set objNewACE = CreateObject("AccessControlEntry")

objNewACE.Trustee = "AMER\ANewGroup"

objNewACE.AccessMask = FULL_CONTROL

objNewACE.AceType = ADS_ACETYPE_ACCESS_ALLOWED

objNewACE.AceFlags = ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT



'Add the new ACE to the object and write it to the AD

Set objObject = GetObject("LDAP://ou=myOU,dc=amer,dc=mycorp,dc=com")



'Use IADs::Get to retrieve the SD for the object

Set objSecDesc = objObject.Get("ntSecurityDescriptor")



'Use IADsSecurityDescriptor:: DiscretionaryAcl to retrieve the existing DACL

Set objDACL = objSecDesc.DiscretionaryAcl



'Use IADsAccessControlList::AddACE to add an ACE to an existing DACL

objDACL.AddAce objNewACE



'Use IADsSecurityDescriptor:: DiscretionaryAcl to put back the modified DACL

objSecDesc.DiscretionaryAcl = objDACL



'Use IADs::Put to replace the SD for the object

objObject.Put "ntSecurityDescriptor", Array(objSecDesc)



'Write out the property cache using IADs::SetInfo

objObject.SetInfo
A common error seen by script writers writing their own ACL manipulation scripts is the dreaded “The security ID structure is invalid” error, or error –2147023559. The number one cause of this error is a trustee that cannot be resolved to a SID.
First we create the new ACE. This requires use of a
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
A Complex ADSI Example
Inhaltsvorschau
is an example of a real-life problem that gets asked nearly every week in the Microsoft newsgroups: how to delegate the ability to unlock an account, reset a password, and set the flag that the account must change password on the next logon.
Example . Delegating unlock, password reset, and must change password flag
Option Explicit



'Modify these to change your trustee and target for the ACL mod

Const TRUSTEE="AMER\PasswordAdmin"

Const OBJPATH="ou=myOU,dc=amer,dc=mycorp,dc=com"



'Attribute, Class, Control Access Right constants

Const ATTRIB_LOCKOUTTIME_GUID = "{28630EBF-41D5-11D1-A9C1-0000F80367C1}"

Const ATTRIB_PWDLASTSET_GUID = "{BF967A0A-0DE6-11D0-A285-00AA003049E2}"

Const CLASS_USER_GUID = "{BF967ABA-0DE6-11D0-A285-00AA003049E2}"

Const CAR_RESETPWD_GUID = "{00299570-246D-11D0-A768-00AA006E0529}"



'AccessMask constants

Const ADS_RIGHT_GENERIC_READ = &H80000000

Const ADS_RIGHT_GENERIC_WRITE = &H40000000

Const ADS_RIGHT_GENERIC_EXECUTE = &H20000000

Const ADS_RIGHT_GENERIC_ALL = &H10000000

Const ADS_RIGHT_ACCESS_SYSTEM_SECURITY = &H1000000

Const ADS_RIGHT_SYNCHRONIZE = &H100000

Const ADS_RIGHT_WRITE_OWNER = &H80000

Const ADS_RIGHT_WRITE_DAC = &H40000

Const ADS_RIGHT_READ_CONTROL = &H20000

Const ADS_RIGHT_DELETE = &H10000

Const ADS_RIGHT_DS_CONTROL_ACCESS = &H100

Const ADS_RIGHT_DS_LIST_OBJECT = &H80

Const ADS_RIGHT_DS_DELETE_TREE = &H40

Const ADS_RIGHT_DS_WRITE_PROP = &H20

Const ADS_RIGHT_DS_READ_PROP = &H10

Const ADS_RIGHT_DS_SELF = &H8

Const ADS_RIGHT_ACTRL_DS_LIST = &H4

Const ADS_RIGHT_DS_DELETE_CHILD = &H2

Const ADS_RIGHT_DS_CREATE_CHILD = &H1

Const FULL_CONTROL = -1



'AceType constants

Const ADS_ACETYPE_SYSTEM_AUDIT_OBJECT = &H7

Const ADS_ACETYPE_ACCESS_DENIED_OBJECT = &H6

Const ADS_ACETYPE_ACCESS_ALLOWED_OBJECT = &H5

Const ADS_ACETYPE_SYSTEM_AUDIT = &H2

Const ADS_ACETYPE_ACCESS_DENIED = &H1

Const ADS_ACETYPE_ACCESS_ALLOWED = &H0



'AceFlags constants

Const ADS_ACEFLAG_FAILED_ACCESS = &H80

Const ADS_ACEFLAG_SUCCESSFUL_ACCESS = &H40

Const ADS_ACEFLAG_VALID_INHERIT_FLAGS = &H1F

Const ADS_ACEFLAG_INHERITED_ACE = &H10

Const ADS_ACEFLAG_INHERIT_ONLY_ACE = &H8

Const ADS_ACEFLAG_NO_PROPAGATE_INHERIT_ACE = &H4

Const ADS_ACEFLAG_INHERIT_ACE = &H2



'Flags constants

Const ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT = &H2

Const ADS_FLAG_OBJECT_TYPE_PRESENT = &H1



'Declare variables

Dim objObject    'Any object

Dim objSecDesc   'SecurityDescriptor

Dim objDACL      'AccessControlList

Dim objNewACE_1  'AccessControlEntry

Dim objNewACE_2  'AccessControlEntry

Dim objNewACE_3  'AccessControlEntry



'Create new ACE, Unlock User Objects

Set objNewACE_1 = CreateObject("AccessControlEntry")

objNewACE_1.Trustee = TRUSTEE

objNewACE_1.AccessMask = ADS_RIGHT_DS_WRITE_PROP or ADS_RIGHT_DS_READ_PROP

objNewACE_1.AceType = ADS_ACETYPE_ACCESS_ALLOWED_OBJECT

objNewACE_1.AceFlags = ADS_ACEFLAG_INHERIT_ONLY_ACE _

                                                 or ADS_ACEFLAG_INHERIT_ACE

objNewACE_1.Flags= ADS_FLAG_OBJECT_TYPE_PRESENT _

                                  or ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT

objNewACE_1.ObjectType= ATTRIB_LOCKOUTTIME_GUID

objNewACE_1.InheritedObjectType = CLASS_USER_GUID



'Create new ACE, Set/Clear Must change password on next logon

Set objNewACE_2 = CreateObject("AccessControlEntry")

objNewACE_2.Trustee = TRUSTEE

objNewACE_2.AccessMask = ADS_RIGHT_DS_WRITE_PROP or ADS_RIGHT_DS_READ_PROP

objNewACE_2.AceType = ADS_ACETYPE_ACCESS_ALLOWED_OBJECT

objNewACE_2.AceFlags = ADS_ACEFLAG_INHERIT_ONLY_ACE _

                                                 or ADS_ACEFLAG_INHERIT_ACE

objNewACE_2.Flags= ADS_FLAG_OBJECT_TYPE_PRESENT _

                                  or ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT

objNewACE_2.ObjectType= ATTRIB_PWDLASTSET_GUID

objNewACE_2.InheritedObjectType = CLASS_USER_GUID



'Create new ACE, Reset Password

Set objNewACE_3 = CreateObject("AccessControlEntry")

objNewACE_3.Trustee = TRUSTEE

objNewACE_3.AccessMask = ADS_RIGHT_DS_CONTROL_ACCESS

objNewACE_3.AceType = ADS_ACETYPE_ACCESS_ALLOWED_OBJECT

objNewACE_3.AceFlags = ADS_ACEFLAG_INHERIT_ONLY_ACE _

                                                 or ADS_ACEFLAG_INHERIT_ACE

objNewACE_3.Flags= ADS_FLAG_OBJECT_TYPE_PRESENT _

                                  or ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT

objNewACE_3.ObjectType= CAR_RESETPWD_GUID

objNewACE_3.InheritedObjectType = CLASS_USER_GUID



'Add the new ACE to the object and write it to the AD

Set objObject = GetObject("LDAP://" & OBJPATH)



'Use IADs::Get to retrieve the SD for the object

Set objSecDesc = objObject.Get("ntSecurityDescriptor")



'Use IADsSecurityDescriptor:: DiscretionaryAcl to retrieve the existing DACL

Set objDACL = objSecDesc.DiscretionaryAcl



'Use IADsAccessControlList::AddACE to add ACEs to an existing DACL

objDACL.AddAce objNewACE_1    ' Add Unlock

objDACL.AddAce objNewACE_2    ' Add Set/Clear must change password

objDACL.AddAce objNewACE_3    ' Add Reset password



'Use IADsSecurityDescriptor:: DiscretionaryAcl to put back the modified DACL

objSecDesc.DiscretionaryAcl = objDACL



'Use IADs::Put to replace the SD for the object

objObject.Put "ntSecurityDescriptor", Array(objSecDesc)



'Write out the property cache using IADs::SetInfo

objObject.SetInfo
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Creating Security Descriptors
Inhaltsvorschau
If you are creating an object from scratch and you don’t want it to receive the default DACL and SACL that would normally be applied to objects created, you can write your own DACL and SACL for an object. As you would expect, there are a number of properties associated with security descriptors and ACLs that you need to set. SDs and ACLs can be manipulated with the IADsAccessControlList interface (see ) and the IADsSecurityDescriptor interface (see ). We’ll go through these briefly now and then move on to some more examples.
Table : IADsAccessControlList methods and properties
IADsAccessControlList methods and properties
Action
AddAce method
Adds an ACE to an ACL
RemoveAce method
Removes an ACE from an ACL
CopyAccessList method
Copies the current ACL
AclRevision property
Shows the revision of the ACL (always set to 4; see later text)
AceCount property
Indicates the number of ACEs in the ACL
Table : IADsSecurityDescriptor methods and properties
Action
CopySecurityDescriptor method
A copy of an existing SD.
Revision property
The revision of the SD (always set to 4, as noted earlier).
Control property
A set of flags indicating various aspects of the SD (see later text). Generally, you will not need to set this property; instead, you can set the properties listed in this table.
Owner property
The SID of the owner. If this field is null, no owner is set.
OwnerDefaulted property
A Boolean value indicating whether the owner is derived by the default mechanism when created (i.e., assembled out of all the inherited ACEs passed down by its parents) rather than explicitly set by the person or application that created the SD in the first place.
Group property
The SID of the object’s primary group, if appropriate. If this field is null, no primary group exists.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Listing the Security Descriptor of an Object
Inhaltsvorschau
A good example of a useful real-world task is when you are curious to see what ACEs have been set on an object, such as a domain or Organizational Unit. is a piece of code that can be used as the basis for checking through an Active Directory forest looking for irregularities or that can be used to help you build the proper values for your own delegation script. The code is fairly simple but very long, due to the fact that it has to check every constant for both the SACL and DACL of each object.
Example . Examining the security descriptor of an object
Option Explicit



'Declare the variables

Dim objObject, objRootDSE, objSchema, objExtRights, objEnum, objSD

Dim objDACL, objSACL, objACE

Dim SchemaGuids, CARGuids, SDCtlD, AccMaskD, ACEFlagsD, FlagsD

Dim strDC, strSchemaPath, strConfigPath, strGUID, strLDAPPath



'AccessMask constants

Const FULL_CONTROL                     = -1

Const FULL_CONTROL2                    = &HF01FF



Const ADS_RIGHT_GENERIC_READ           = &H80000000

Const ADS_RIGHT_GENERIC_WRITE          = &H40000000

Const ADS_RIGHT_GENERIC_EXECUTE        = &H20000000

Const ADS_RIGHT_GENERIC_ALL            = &H10000000

Const ADS_RIGHT_ACCESS_SYSTEM_SECURITY = &H1000000

Const ADS_RIGHT_SYNCHRONIZE            = &H100000

Const ADS_RIGHT_WRITE_OWNER            = &H80000

Const ADS_RIGHT_WRITE_DAC              = &H40000

Const ADS_RIGHT_READ_CONTROL           = &H20000

Const ADS_RIGHT_DELETE                 = &H10000

Const ADS_RIGHT_DS_CONTROL_ACCESS      = &H100

Const ADS_RIGHT_DS_LIST_OBJECT         = &H80

Const ADS_RIGHT_DS_DELETE_TREE         = &H40

Const ADS_RIGHT_DS_WRITE_PROP          = &H20

Const ADS_RIGHT_DS_READ_PROP           = &H10

Const ADS_RIGHT_DS_SELF                = &H8

Const ADS_RIGHT_ACTRL_DS_LIST          = &H4

Const ADS_RIGHT_DS_DELETE_CHILD        = &H2

Const ADS_RIGHT_DS_CREATE_CHILD        = &H1



'AccessMask Dictionary for Flag enumeration

Set AccMaskD = CreateObject("Scripting.Dictionary")

AccMaskD.Add FULL_CONTROL, "FULL_CONTROL"

AccMaskD.Add FULL_CONTROL2, "FULL_CONTROL2"

AccMaskD.Add ADS_RIGHT_GENERIC_READ, "ADS_RIGHT_GENERIC_READ"

AccMaskD.Add ADS_RIGHT_GENERIC_WRITE, "ADS_RIGHT_GENERIC_WRITE"

AccMaskD.Add ADS_RIGHT_GENERIC_EXECUTE, "ADS_RIGHT_GENERIC_EXECUTE"

AccMaskD.Add ADS_RIGHT_GENERIC_ALL, "ADS_RIGHT_GENERIC_ALL"

AccMaskD.Add ADS_RIGHT_ACCESS_SYSTEM_SECURITY, "ADS_RIGHT_ACCESS_SYSTEM_SECURITY"

AccMaskD.Add ADS_RIGHT_SYNCHRONIZE, "ADS_RIGHT_SYNCHRONIZE"

AccMaskD.Add ADS_RIGHT_WRITE_OWNER, "ADS_RIGHT_WRITE_OWNER"

AccMaskD.Add ADS_RIGHT_WRITE_DAC, "ADS_RIGHT_WRITE_DAC"

AccMaskD.Add ADS_RIGHT_READ_CONTROL, "ADS_RIGHT_READ_CONTROL"

AccMaskD.Add ADS_RIGHT_DELETE, "ADS_RIGHT_DELETE"

AccMaskD.Add ADS_RIGHT_DS_CONTROL_ACCESS, "ADS_RIGHT_DS_CONTROL_ACCESS"

AccMaskD.Add ADS_RIGHT_DS_LIST_OBJECT, "ADS_RIGHT_DS_LIST_OBJECT"

AccMaskD.Add ADS_RIGHT_DS_DELETE_TREE, "ADS_RIGHT_DS_DELETE_TREE"

AccMaskD.Add ADS_RIGHT_DS_WRITE_PROP, "ADS_RIGHT_DS_WRITE_PROP"

AccMaskD.Add ADS_RIGHT_DS_READ_PROP, "ADS_RIGHT_DS_READ_PROP"

AccMaskD.Add ADS_RIGHT_DS_SELF, "ADS_RIGHT_DS_SELF"

AccMaskD.Add ADS_RIGHT_ACTRL_DS_LIST, "ADS_RIGHT_ACTRL_DS_LIST"

AccMaskD.Add ADS_RIGHT_DS_DELETE_CHILD, "ADS_RIGHT_DS_DELETE_CHILD"

AccMaskD.Add ADS_RIGHT_DS_CREATE_CHILD, "ADS_RIGHT_DS_CREATE_CHILD"



'AceType constants

Const ADS_ACETYPE_SYSTEM_AUDIT_OBJECT   = &H7

Const ADS_ACETYPE_ACCESS_DENIED_OBJECT  = &H6

Const ADS_ACETYPE_ACCESS_ALLOWED_OBJECT = &H5



Const ADS_ACETYPE_SYSTEM_AUDIT          = &H2

Const ADS_ACETYPE_ACCESS_DENIED         = &H1

Const ADS_ACETYPE_ACCESS_ALLOWED        = &H0



'AceFlags constants

Const ADS_ACEFLAG_FAILED_ACCESS            = &H80

Const ADS_ACEFLAG_SUCCESSFUL_ACCESS        = &H40

Const ADS_ACEFLAG_VALID_INHERIT_FLAGS      = &H1F

Const ADS_ACEFLAG_INHERITED_ACE            = &H10

Const ADS_ACEFLAG_INHERIT_ONLY_ACE         = &H8

Const ADS_ACEFLAG_NO_PROPAGATE_INHERIT_ACE = &H4

Const ADS_ACEFLAG_INHERIT_ACE              = &H2



'AceFlags Dictionary for Flag enumeration

Set ACEFlagsD = CreateObject("Scripting.Dictionary")

ACEFlagsD.Add ADS_ACEFLAG_FAILED_ACCESS, "ADS_ACEFLAG_FAILED_ACCESS"

ACEFlagsD.Add ADS_ACEFLAG_SUCCESSFUL_ACCESS, "ADS_ACEFLAG_SUCCESSFUL_ACCESS"

ACEFlagsD.Add ADS_ACEFLAG_VALID_INHERIT_FLAGS, "ADS_ACEFLAG_VALID_INHERIT_FLAGS"

ACEFlagsD.Add ADS_ACEFLAG_INHERITED_ACE, "ADS_ACEFLAG_INHERITED_ACE"

ACEFlagsD.Add ADS_ACEFLAG_INHERIT_ONLY_ACE, "ADS_ACEFLAG_INHERIT_ONLY_ACE"

ACEFlagsD.Add ADS_ACEFLAG_NO_PROPAGATE_INHERIT_ACE, _

                                       "ADS_ACEFLAG_NO_PROPAGATE_INHERIT_ACE"

ACEFlagsD.Add ADS_ACEFLAG_INHERIT_ACE, "ADS_ACEFLAG_INHERIT_ACE"





'Security Descriptor constants

Const ADS_SD_CONTROL_SE_SACL_PROTECTED        = &H2000

Const ADS_SD_CONTROL_SE_DACL_PROTECTED        = &H1000

Const ADS_SD_CONTROL_SE_DACL_AUTO_INHERITED   = &H400

Const ADS_SD_CONTROL_SE_SACL_AUTO_INHERITED   = &H800

Const ADS_SD_CONTROL_SE_SACL_AUTO_INHERIT_REQ = &H200

Const ADS_SD_CONTROL_SE_DACL_AUTO_INHERIT_REQ = &H100

Const ADS_SD_CONTROL_SE_SACL_DEFAULTED        = &H20

Const ADS_SD_CONTROL_SE_SACL_PRESENT          = &H10

Const ADS_SD_CONTROL_SE_DACL_DEFAULTED        = &H8

Const ADS_SD_CONTROL_SE_DACL_PRESENT          = &H4

Const ADS_SD_CONTROL_SE_GROUP_DEFAULTED       = &H2

Const ADS_SD_CONTROL_SE_OWNER_DEFAULTED       = &H1



'Security Descriptor Dictionary for Flag enumeration

Set SDCtlD = CreateObject("Scripting.Dictionary")

SDCtlD.Add ADS_SD_CONTROL_SE_SACL_PROTECTED, "ADS_SD_CONTROL_SE_SACL_PROTECTED"

SDCtlD.Add ADS_SD_CONTROL_SE_DACL_PROTECTED, "ADS_SD_CONTROL_SE_DACL_PROTECTED"

SDCtlD.Add ADS_SD_CONTROL_SE_SACL_AUTO_INHERITED, _

                                        "ADS_SD_CONTROL_SE_SACL_AUTO_INHERITED"



SDCtlD.Add ADS_SD_CONTROL_SE_DACL_AUTO_INHERITED, _

                                        "ADS_SD_CONTROL_SE_DACL_AUTO_INHERITED"

SDCtlD.Add ADS_SD_CONTROL_SE_SACL_AUTO_INHERIT_REQ, _

                                      "ADS_SD_CONTROL_SE_SACL_AUTO_INHERIT_REQ"

SDCtlD.Add ADS_SD_CONTROL_SE_DACL_AUTO_INHERIT_REQ, _

                                      "ADS_SD_CONTROL_SE_DACL_AUTO_INHERIT_REQ"

SDCtlD.Add ADS_SD_CONTROL_SE_SACL_DEFAULTED, "ADS_SD_CONTROL_SE_SACL_DEFAULTED"

SDCtlD.Add ADS_SD_CONTROL_SE_SACL_PRESENT, "ADS_SD_CONTROL_SE_SACL_PRESENT"

SDCtlD.Add ADS_SD_CONTROL_SE_DACL_DEFAULTED, "ADS_SD_CONTROL_SE_DACL_DEFAULTED"

SDCtlD.Add ADS_SD_CONTROL_SE_DACL_PRESENT, "ADS_SD_CONTROL_SE_DACL_PRESENT"

SDCtlD.Add ADS_SD_CONTROL_SE_GROUP_DEFAULTED, "ADS_SD_CONTROL_SE_GROUP_DEFAULTED"

SDCtlD.Add ADS_SD_CONTROL_SE_OWNER_DEFAULTED, "ADS_SD_CONTROL_SE_OWNER_DEFAULTED"



'Flags constants

Const ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT = &H2

Const ADS_FLAG_OBJECT_TYPE_PRESENT           = &H1



'Flags Dictionary for Flag enumeration

Set FlagsD = CreateObject("Scripting.Dictionary")

FlagsD.Add ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT, _

                               "ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT"

FlagsD.Add ADS_FLAG_OBJECT_TYPE_PRESENT, "ADS_FLAG_OBJECT_TYPE_PRESENT"



' Misc Constants

Const ADS_SECURITY_INFO_SACL   = &H8

Const ADS_SECURITY_INFO_DACL   = &H4

Const ADS_SECURITY_INFO_GROUP  = &H2

Const ADS_SECURITY_INFO_OWNER  = &H1

Const ADS_OPTION_SECURITY_MASK = &H3         ' Security mask for options

Const ADS_OPTION_SERVERNAME = 0

Const E_ADS_PROPERTY_NOT_FOUND = &H8000500D  ' Property not found in cache



'Main Script Logic Begin

'Retrieve parameter, display usage if necessary

If (WScript.Arguments.Count <> 1) Then

  Out "Usage: sdlist ADsPath"

  Out "   Ex: sdlist LDAP://dc=mycorp,dc=com"

  WScript.Quit

End If

strLDAPPath=WScript.Arguments.item(0)



'Bind to object

Out "Opening object - " & strLDAPPath

Set objObject = GetObject(strLDAPPath)

strDC = objObject.GetOption(ADS_OPTION_SERVERNAME)

Out "Using domain controller: " & strDC



'Connect to RootDSE, retrieve Schema/Config NCs

Out "Opening RootDSE"

Set objRootDSE = GetObject("LDAP://" & strDC & "/RootDSE")

strSchemaPath = objRootDSE.Get("schemaNamingContext")

strConfigPath = objRootDSE.Get("configurationNamingContext")



'Connect to schema and retrieve schemaIDGUIDs of attributes and classes

'  schemaIDGUID attribute is an octet string

'Build dictionary object to hold values

Out "Opening Schema"

Set objSchema = GetObject("LDAP://" & strSchemaPath)

Out "Retrieving classes and attributes"

objSchema.Filter=Array("attributeSchema","classSchema")

Set SchemaGuids = CreateObject("Scripting.Dictionary")

For Each objEnum In objSchema

  strGUID=GuidToStr(objEnum.schemaIDGUID)

  SchemaGuids.add UCase(strGUID),objEnum.lDAPDisplayName

Next



'Connect to extended-rights container and retrieve rightsGuids of CA objects

'  rightsGuid is a unicode string

'Build dictionary object to hold values

'  handle validated writes special, MS duplicated a rightsGuid

Out "Opening Extended-Rights container"

Set objExtRights = GetObject("LDAP://cn=extended-rights," & strConfigPath)

Out "Retrieving Property Sets, Extended Rights, and Validated Rights"

objExtRights.Filter=Array("controlAccessRight")

Set CARGuids = CreateObject("Scripting.Dictionary")

For Each objEnum In objExtRights

  strGUID="{" & objEnum.rightsGuid & "}"

  if objEnum.validAccesses = 8 then strGUID = "VWRITE - " & strGUID

  CARGuids.add UCase(strGUID),objEnum.displayName

Next



'Retrieve Security Descriptor

'  Need to check if the property not found in cache error was thrown as it

'  indicates person running script has insufficient rights



On Error Resume Next

Set objSD = objObject.Get("nTSecurityDescriptor")

If Err = E_ADS_PROPERTY_NOT_FOUND Then

  Out ""

  Out "You do not have access to the DACL..."

  WScript.Quit

End If

On Error Goto 0



'Write out the SDs general information

Out ""

Out "=================================================================="

Out "Security Descriptor"

Out "  SD revision is : " & objSD.Revision

Out "  SD Owner is    : " & objSD.Owner

Out "  SD Group is    : " & objSD.Group

Out "  Control Flags " & HexStr(objSD.Control)

DisplayFlags GetFlagStrs(objSD.Control,SDCtlD),"      "

Out "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"



'Write out the DACL general information

Set objDACL = objSD.DiscretionaryAcl

Out "Discretionary ACL"

Out "  DACL revision : " & objDACL.AclRevision

Out "  DACL ACE Count: " & objDACL.AceCount

Out "------------------------------------------------------------------"



'Loop through ACEs

EnumACEs(objDACL)

Out "------------------------------------------------------------------"

Out "------------------------------------------------------------------"



'Retrieve SACL

'   The SACL requires enhanced permissions to retrieve. Because of this

'   and how the Security Interface works, the script disconnects from the

'   the object and reconnects and attempts to set the options to retrieve

'   the SACL. If it fails, throw an error.

Set objObject = Nothing

Set objObject = GetObject(strLDAPPath)

objObject.SetOption ADS_OPTION_SECURITY_MASK, ADS_SECURITY_INFO_OWNER _

                                           Or ADS_SECURITY_INFO_GROUP _

                                           Or ADS_SECURITY_INFO_DACL _

                                           Or ADS_SECURITY_INFO_SACL



On Error Resume Next

Set objSD = objObject.Get("nTSecurityDescriptor")

If Err = E_ADS_PROPERTY_NOT_FOUND Then

  Out ""

  Out "You do not have access to the SACL..."

  WScript.Quit

End If

On Error Goto 0



'Write out the SACL general information

Set objSACL = objSD.SystemAcl

Out "System ACL"

Out "  SACL revision : " & objSACL.AclRevision

Out "  SACL ACE Count: " & objSACL.AceCount

Out "------------------------------------------------------------------"



'Loop through ACEs

EnumACEs(objSACL)

Out "------------------------------------------------------------------"



'Main Script Logic End

'Subroutines



'Output Routine, change this routine to redirect output

Sub Out(str)

  WScript.Echo str

End Sub



'Convert a binary GUID to a string GUID

'   Convert GUID octet string to Hex characters then arrange in proper order

'   and add brackets {}

Function GuidToStr(Guid)

  Dim i, str

  str = " "

  For i = 1 To Lenb(Guid)

    str = str & Right("0" & Hex(Ascb(Midb(Guid, i, 1))), 2)

  Next



  GuidToStr = "{"

  For i = 1 to 4

    GuidToStr = GuidToStr & Mid(str,10-(i*2),2)

  Next

  GuidToStr = GuidToStr & "-"

  For i = 1 to 2

    GuidToStr = GuidToStr & Mid(str,14-(i*2),2)

  Next

  GuidToStr = GuidToStr & "-"

  For i = 1 to 2

    GuidToStr = GuidToStr & Mid(str,18-(i*2),2)

  Next

  GuidToStr = GuidToStr & "-"

  For i = 1 to 2

    GuidToStr = GuidToStr & Mid(str,16+(i*2),2)

  Next

  GuidToStr = GuidToStr & "-"

  For i = 1 to 6

    GuidToStr = GuidToStr & Mid(str,20+(i*2),2)

  Next

  GuidToStr = GuidToStr & "}"

End Function



'Convert integer to Hexidecimal string for output - format (0xnnnn)

Function HexStr(val)

  HexStr = "(0x" & Hex(val) & ")"

End Function



'Get list of Flag strings for given bit flag value and Dictionary

'  Loops through the keys of a dictionary object and executes a bitwise-AND

'  against value and each key. If there is a match, adds key's matching item

Function GetFlagStrs(val,ByRef dict)

  Dim keys, keycnt, i, ar(), flgcnt

  flgcnt=0

  keys = dict.Keys

  keycnt = UBound(keys)

  For i = 0 To keycnt

    If ((val and keys(i)) = keys(i)) Then

      Redim Preserve ar(flgcnt)

      ar(flgcnt) = dict(keys(i)) & "  " & HexStr(keys(i))

      flgcnt = flgcnt + 1

    End If

  Next

  GetFlagStrs=ar

End Function



'Loop through Array and display strings with fill padding

Sub DisplayFlags(ar,fill)

  Dim str

  For Each str In ar

    Out fill & str

  Next

End Sub



'Convert ACETYPE value to string

'   ACETYPE is NOT a bitflag attribute.

Function AceTypeToStr(acetype)

  Select Case acetype

    Case ADS_ACETYPE_SYSTEM_AUDIT_OBJECT

      AceTypeToStr = "ADS_ACETYPE_SYSTEM_AUDIT_OBJECT"

    Case ADS_ACETYPE_ACCESS_DENIED_OBJECT

      AceTypeToStr = "ADS_ACETYPE_ACCESS_DENIED_OBJECT"

    Case ADS_ACETYPE_ACCESS_ALLOWED_OBJECT

      AceTypeToStr = "ADS_ACETYPE_ACCESS_ALLOWED_OBJECT"

    Case ADS_ACETYPE_SYSTEM_AUDIT

      AceTypeToStr = "ADS_ACETYPE_SYSTEM_AUDIT"

    Case ADS_ACETYPE_ACCESS_DENIED

      AceTypeToStr = "ADS_ACETYPE_ACCESS_DENIED"

    Case ADS_ACETYPE_ACCESS_ALLOWED

      AceTypeToStr = "ADS_ACETYPE_ACCESS_ALLOWED"

    Case Else

      AceTypeToStr = "Unknown"

  End Select

  AceTypeToStr = AceTypeToStr & " " & HexStr(acetype)

End Function



'Resolves a GUID to a schema objects or a Control Access Right object

Function GuidToObj(guid, access)

  Dim str

  guid = UCase(guid)

  If (guid <> "") Then

    If (SchemaGuids.Exists(guid)) Then

      str = SchemaGuids(guid)

    End If

    If (str = "") Then

      If (access and ADS_RIGHT_DS_SELF) Then

        guid = "VWRITE - " & guid

      End If

      If (CARGuids.Exists(guid)) Then

        str = CARGuids(guid)

      End If

    End If

    If (str = "") Then str = "_ _UNKNOWN_ _"

    GuidToObj = str & " (" & guid & ")"



  Else

    GuidToObj = "_ _NONE_ _"

  End If

End Function



'Loop through ACES from ACL and display information about each ACE

Sub EnumACEs(ByRef objACL)

  dim intACECount

  intACECount = 1

  For Each objACE In objACL

    Out "  ACE #" & intACECount

    Out "     Trustee               : " & objACE.Trustee

    Out "     AceType               : " & AceTypeToStr(objACE.AceType)

    Out "     AceFlags " & HexStr(objACE.AceFlags)

    DisplayFlags GetFlagStrs(objACE.AceFlags,ACEFlagsD), "        "

    Out "     Access Mask Flags " & HexStr(objACE.AccessMask)

    DisplayFlags GetFlagStrs(objACE.AccessMask,AccMaskD), "        "

    Out "     Flags " & HexStr(objACE.Flags)

    DisplayFlags GetFlagStrs(objACE.Flags,FlagsD), "        "

    Out "     Object Type           : " _

                & GuidToObj(objACE.ObjectType,objACE.AccessMask)

    Out "     Inherited Object Type : " _

       & GuidToObj(objACE.InheritedObjectType,objACE.AccessMask)

    Out ""

    intAceCount = intACECount + 1

  Next

End Sub
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
This chapter took a detailed look at the four main interfaces that you can use to manipulate and iterate over permissions and auditing entries for objects and attributes in your organization:
  • IADsAccessControlEntry
  • IADsAccessControlList
  • IADsSecurityDescriptor
  • IADsSecurityUtility
You should now have the tools in your programming belt necessary to modify the permissions in Active Directory as needed.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 26: Extending the Schema and the Active Directory Snap-ins
Inhaltsvorschau
This chapter takes a look at two different areas: programmatically extending the schema and customizing the functionality of the Active Directory administrative MMC snap-ins. Although these topics may seem very different, they share the common thread of storing and presenting information beyond what Active Directory is configured to do by default. They are also related because you will often want to include new schema extensions in the Active Directory snap-ins.
In the first half of the chapter, we take a look at how you can manipulate the schema to include new attributes and classes. In the second half, we describe how to modify the various components of the Active Directory Users and Computers (ADUC) snap-in to include customized display names and menus. While we will focus on ADUC, the techniques presented in this chapter can be used to modify any of the Active Directory administrative snap-ins.
We’ve shown you how the schema works in and how to design extensions in . Now let’s take a look at how to query and manipulate the schema using ADSI.
In addition to being able to query and update schema objects as you can any other type of object with the IADs interface, there are two main schema-specific interfaces available: IADsClass and IADsProperty. Each of these interfaces has a variety of useful methods and property methods to allow you to set mandatory properties for classes, optional properties for classes, maximum values for attributes, and so on.
First, let’s compare accessing and modifying the schema by directly using the attributes we are interested in versus using the IADsClass and IADsProperty methods. This first code section uses attributes directly:
objAttribute.Put "isSingleValued", False

objAttribute.Put "attributeId", "1.3.6.1.4.1.999999.1.1.28"

arrMustContain = objSchemaClass.Get("mustContain")

arrMayContain = objSchemaClass.Get("mayContain")
Now we will use the ADSI schema interfaces to do the same thing:
objAttribute.MultiValued = True

objAttribute.OID = "1.3.6.1.4.1.999999.1.1.28"

arrMustContain = objSchemaClass.MandatoryProperties

arrMayContain = objSchemaClass.OptionalProperties
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Modifying the Schema with ADSI
Inhaltsvorschau
We’ve shown you how the schema works in and how to design extensions in . Now let’s take a look at how to query and manipulate the schema using ADSI.
In addition to being able to query and update schema objects as you can any other type of object with the IADs interface, there are two main schema-specific interfaces available: IADsClass and IADsProperty. Each of these interfaces has a variety of useful methods and property methods to allow you to set mandatory properties for classes, optional properties for classes, maximum values for attributes, and so on.
First, let’s compare accessing and modifying the schema by directly using the attributes we are interested in versus using the IADsClass and IADsProperty methods. This first code section uses attributes directly:
objAttribute.Put "isSingleValued", False

objAttribute.Put "attributeId", "1.3.6.1.4.1.999999.1.1.28"

arrMustContain = objSchemaClass.Get("mustContain")

arrMayContain = objSchemaClass.Get("mayContain")
Now we will use the ADSI schema interfaces to do the same thing:
objAttribute.MultiValued = True

objAttribute.OID = "1.3.6.1.4.1.999999.1.1.28"

arrMustContain = objSchemaClass.MandatoryProperties

arrMayContain = objSchemaClass.OptionalProperties
This makes use of IADsClass::Manda-toryProperties, IADsProperty::MultiValued, IADsProperty::OID, and IADsClass::OptionalProperties. As you can see, it’s not hard to convert the code. However, we feel that including code that directly modifies the properties themselves gives you some idea of what you are actually changing and helps you to refer back to the definitions presented in .
More details on these three interfaces can be found in the MSDN Library at http://msdn.microsoft.com/en-us/library/aa746465(VS.85).aspx.
We will create an example attribute called Mycorp-LanguagesSpoken. It is to be a multivalued, indexed attribute that can hold an array of case-sensitive strings of between 1 and 50 characters. The name is prefixed with Mycorp, so it is obvious that
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Customizing the Active Directory Administrative Snap-ins
Inhaltsvorschau
In many cases, you may want to modify Active Directory Users and Computers (ADUC) to display additional attributes, perhaps even ones you’ve created. Continuing the schema extension example from the beginning of the chapter, let’s say that you decide you want the myCorp-LanguagesSpoken attribute to be displayed in ADUC so others can view the languages a user speaks. Fortunately, the Active Directory snap-ins are largely customizable by modifying one or more attributes in Active Directory. You can also extend the functionality of a snap-in using WSH, VB, or any other COM-based .
The rest of the chapter is devoted to reviewing the components behind the Active Directory administrative snap-ins and how you can modify them to meet your needs. These components include:
Display Specifiers
Objects in Active Directory that contain localized user interface information
Property Pages
Tabbed dialog box that displays information
Context Menus
Menu displayed after right-clicking an object (e.g., user)
Icons
Image displayed when viewing a particular class
Display Names
User-friendly names displayed for attributes and classes (e.g., Last Name)
Creation Wizard
Wizard interface used to create an object
Display specifiers are objects stored in Active Directory that contain information on how to display and manage objects for a specific object class through the Active Directory snap-ins. These display specifiers are held in the Configuration Naming Context under the DisplaySpecifiers container. Within the DisplaySpecifiers container, there is a container for each supported locale, in a path similar to this:
LDAP://cn=409,cn=DisplaySpecifiers,cn=Configuration,dc=mycorp,dc=com
The preceding container contains the display specifiers for the U.S./English locale of 409. If you wanted to create or manage display specifiers for a different locale, you just create a new container with the relevant hexadecimal code for the locale and populate it with the relevant display specifier objects. For example, 409 in hex represents 1,033 in decimal, and 1,033 is the U.S./English locale. If we created 809 (2,057 in decimal), we would get the U.K./English locale, and if we created 40C (1,036 in decimal), we would get the French locale. The currently installed locale values can be found in the registry at
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we covered how to query and manipulate the Active Directory Schema, including how to locate and transfer the Schema FSMO. The schema cache and its importance was also briefly touched on, along with information on how to determine which attributes of an object are in the GC and how to add an attribute to the GC if necessary.
The second part of the chapter focused on how to customize the Active Directory MMC snap-ins by modifying displaySpecifier objects. We described how to manipulate each of the major snap-in components, including property pages, context menus, icons, display names and the object creation wizard.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 27: Scripting with WMI
Inhaltsvorschau
The Windows Management Instrumentation (WMI) API was developed by Microsoft in 1998 in response to the ever-growing need for developers and system administrators to have a common, scriptable API to manage the components of the Windows operating systems. Before WMI, if you wanted to manage some component of the operating system, you had to resort to using one of the component-specific Win32 APIs, such as the Registry API or Event Log API. Each API typically had its own implementation quirks and required way too much work to do simple tasks. The other big problem with the Win32 APIs was that Microsoft’s scripting languages such as VBScript could not use them. This really limited how much an inexperienced programmer or system administrator could do to programmatically manage systems. WMI changes all this by providing a single API that can be used to query and manage the Event Log, the Registry, processes, the filesystem, or any other operating system component.
You may be wondering at this point: this is a book on Active Directory, so why do I need to care about a system management API? Even if your sole job in life is to manage Active Directory, WMI can benefit you in at least two ways. First, Active Directory runs on top of Windows Server. These servers need to be managed (i.e., Event Log settings configured, Registry modified, applications installed, etc.) and monitored (i.e., filesystem space, services running, etc.). You can choose to do all of those tasks manually, or you can use WMI to automate them. For each task you automate, the total cost of ownership to support Active Directory is reduced, and you help ensure your servers stay consistent. In the Windows Server 2003 release, there are several new WMI hooks into Active Directory to monitor things such as trusts and replication.
In this chapter, we will give a brief introduction to the concepts and terminology behind WMI and then delve into several sample scripts showing how to make use of it. We will cover some system-specific tasks, such as managing services, the Event Log, and the Registry, which should give you a good grounding in some of the fundamentals of WMI. In the second half of the chapter, we will review how WMI can be used to access and monitor Active Directory.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Origins of WMI
Inhaltsvorschau
There have been several industry initiatives over the years to develop a model for managing systems and devices that would be robust enough to meet the needs of most vendors. Several protocols and frameworks have been developed to address the problem. The Simple Network Management Protocol (SNMP) is probably the most notable, but is pretty simple in its implementation and does not provide many features most vendors need for a single management framework.
The Distributed Management Task Force (DMTF) was created in the early 1990s to address the management framework problem. They developed the Web-Based Enterprise Management (WBEM) standard, which attempts to unify the management frameworks utilizing web technologies. As part of the WBEM standard, they also created the Common Information Model (CIM) , which is the language used for describing management data in an object-oriented way. The WBEM/CIM standards have garnered a lot of industry support in recent years and provide the basis for WMI.
For more information on WBEM/CIM, check out the DMTF website: http://www.dmtf.org.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
WMI Architecture
Inhaltsvorschau
The WMI architecture is composed of two primary layers: the CIM infrastructure, which includes the CIMOM and CIM Repository, and the WMI providers. Although the concepts Microsoft uses are very similar to the WBEM/CIM standards, they did not implement one very important component: the use of web technologies for the transport mechanism. Instead of using HTTP to transport messages between the WMI infrastructure and clients, Microsoft uses COM and DCOM, two Microsoft-specific technologies. This limits the use of WMI to only Microsoft platforms.
That being said, the capabilities to manage Microsoft-based platforms with WMI are nearly unlimited. More and more vendors are utilizing WMI not only to manage components of the Microsoft OS, but also to manage their own applications. Microsoft has also become heavily invested in WMI by providing WMI providers for nearly all of its major applications, including Active Directory, Exchange 2000 and Exchange 2003, and DNS.
The CIM Repository is the primary warehouse for management data. It contains the static data that does not change very frequently, such as memory or disk size. The CIMOM or CIM Object Manager handles requests from clients, retrieves data from the CIM Repository, and returns it to the client. The CIMOM also provides an event service, so that clients can register for events and be notified dynamically when they occur. For dynamic data, such as performance monitor counters, the CIMOM will interact directly with a WMI provider instead of retrieving the data directly from the CIM Repository. The CIM Repository cannot store all possible data that is needed by the various WMI providers. The storage requirements would be significant, not to mention that a lot of the data would become out-of-date almost immediately after it was stored.
The WMI providers contain much of the intelligence behind WMI. Typically a provider will be implemented for each individual managed component, such as the Event Log or Active Directory Trusts. Each provider is responsible for interacting with its managed component and can perform certain functions implemented by methods on classes representing that component. Also, as described earlier, some providers interact with the CIMOM to provide dynamic data that cannot be held in the CIM Repository.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Getting Started with WMI Scripting
Inhaltsvorschau
Once you have a basic understanding of the WMI architecture, scripting with WMI is easy. In fact, once you understand how to reference, enumerate, and query objects of a particular class with WMI, it is straightforward to adapt the code to work with any managed component.
To reference objects in WMI, you use a UNC-style path name. An example of how to reference the C: drive on a computer called dc1 looks like the following:
\\dc1\root\CIMv2:Win32_LogicalDisk.DeviceID="C:"
The format should be easy to follow. The first part of the path (\\dc1\) is a reference to the computer on which the object resides. To reference the computer on which the script is running, you can use a “.” for the computer name. The second part (root\CIMv2) is the namespace the object resides in. The third part (Win32_LogicalDisk) is the class of the object to reference. The fourth part is the key/value pairs representing the object. Generically, the path can be shown as follows:
\\ComputerName\NameSpace:ClassName.KeyName="KeyValue"[,KeyName2="KeyValue2"...]
Now that we know how to reference WMI objects, let’s go ahead and instantiate an object using VBScript’s GetObject function. For GetObject to understand that we are referencing WMI objects, we have to include one additional piece of information: the moniker. Just as we’ve been using the LDAP: and WinNT: progIDs to reference Active Directory and SAM-based objects in ADSI, we need to use the winmgmts: moniker when we are dealing with WMI objects:
Set objDisk = GetObject("winmgmts:\\dc1\root\CIMv2:Win32_LogicalDisk.DeviceID='C:'")
Note that if you want to reference the C: logical drive on the local computer, you can leave off the computer name and namespace path. The GetObject call would then look like this:
Set objDisk = GetObject("winmgmts:Win32_LogicalDisk.DeviceID='C:'")
We have left out the namespace path to show that a script can use a default namespace. root\CIMv2 is the default namespace; however, this is configurable, and it is not advised to assume this will be the default on any systems you do not directly control. Also, when accessing a provider that uses any other namespace or when referencing a remote object, you need to include the namespace path.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
WMI Tools
Inhaltsvorschau
There are several tools available to query and browse WMI information. These tools can be very useful in situations in which you want to access WMI information, but do not want to write a script to do it.
The WMI command-line tool (WMIC) is a powerful tool that can expose virtually any WMI information you want to access. It is available in Windows XP and Windows Server 2003 (and higher). Unfortunately, WMIC does not run on Windows 2000, but it can still be used to query WMI on a Windows 2000 machine.
WMIC maps certain WMI classes to “aliases.” Aliases are used as shorthand so that you only need to type “logicaldisk” instead of “Win32_LogicalDisk.” An easy way to get started with WMIC is to type the alias name of the class you are interested in. A list of all the objects that match that alias/class will be listed.
wmic:root\cli>logicaldisk list brief

DeviceID  DriveType  FreeSpace    ProviderName  Size         VolumeName

A:        2

C:        3          1540900864                 4296498688   W2K

D:        3          15499956224                15568003072

Z:        5          0                          576038912    NR1EFRE_EN
Most aliases have a list brief subcommand that will display a subset of the properties for each object. You can run similar queries for services, CPUs, processes, and so on. For a complete list of the aliases, type alias at the WMIC prompt.
The creators of WMIC didn’t stop with simple lists. You can also utilize WQL to do more complex queries. This next example displays all logical disks with a drivetype of 3 (local hard drive):
wmic:root\cli>logicaldisk where (drivetype = '3') list brief

DeviceID  DriveType  FreeSpace    ProviderName  Size         VolumeName

C:        3          1540806144                 4296498688   W2K

D:        3          15499956224                15568003072
We have barely touched the surface of the capabilities of WMIC. You can invoke actions, such as creating or killing a process or service, and modify WMI data through WMIC as well. For more information, check out the Support WebCast “WMIC: A New Approach to Managing Windows Infrastructure from a Command Line,” available at
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Manipulating Services
Inhaltsvorschau
Querying services is simple to do with WMI. The Win32_Service class is the WMI representation of a service. The Win32_Service class contains a lot of property methods that provide information about the service; the most useful ones have been listed in .
Table : Useful Win32_Service properties
Property
Description
AcceptPause
Returns a Boolean indicating whether the service can be paused.
AcceptStop
Returns a Boolean indicating whether the service can be stopped.
Description
Description of the service.
DisplayName
Display name of the service.
Name
Unique string identifier for the service.
PathName
Fully qualified path to the service executable.
Started
Boolean indicating whether the service has been started.
StartMode
String specifying the start mode of the service. Will be one of Automatic, Manual, or Disabled.
StartName
Account under which the service runs.
State
Current state of the service. Will be one of Stopped, Start Pending, Stop Pending, Running, Continue Pending, Pause Pending, Paused, or Unknown.
The following script retrieves all the running services on a machine. All we need to do is use a WQL query that finds all Win32_Service objects that have a state of “Running”:
Option Explicit

Dim strComputer, objWMI, objServices, objService

strComputer = "."



Set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set objServices = objWMI.ExecQuery _

      ("SELECT * FROM Win32_Service WHERE State = 'Running'")

For Each objService In objServices

   WScript.Echo objService.DisplayName

   WScript.Echo " Name: " & objService.Name

   WScript.Echo " PathName: " & objService.PathName

   WScript.Echo " Started: " & objService.Started

   WScript.Echo " StartMode: " & objService.StartMode

   WScript.Echo " StartName: " & objService.StartName

   WScript.Echo " State: " & objService.State

   WScript.Echo ""

Next

WScript.Echo "The script has completed successfully."
Before you can start to manipulate the status of a service, you have to be able to find any dependent services. A dependent service requires the parent service to be running while it is running. If you try to stop the parent service without first stopping all dependent services, you will get an error. The following example shows how to find all dependent services for the IIS Admin service:
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Querying the Event Logs
Inhaltsvorschau
The Event Logs are typically a system administrator’s first line of inquiry when trying to troubleshoot problems. Because they are so important, it is also important to see how we can make use of them with WMI. The two major components that we need to be concerned with are the Event Logs themselves and the events contained within each Event Log. We will first focus on properties of Event Logs.
The Win32_NTEventLogFile class represents an Event Log. contains several Win32_NTEventLogFile properties that can be used to query or modify properties of an Event Log.
Table : Useful Win32_NTEventLogFile properties
Property
Description
FileSize
Size of the Event Log file in bytes.
LogFileName
Standard name used for describing the Event Log (e.g., Application).
MaxFileSize
Max size in bytes that the Event Log file can reach. This is a writeable property.
Name
Fully qualified path to the Event Log file.
NumberOfRecords
Total number of records in the Event Log.
OverwriteOutDated
Number of days after which events can be overwritten. This is a writeable property with 0 indicating to overwrite events as needed, 1–365 being the number of days to wait before overwriting, and 4294967295 indicating that events should never be overwritten.
OverwritePolicy
Text description of the overwrite policy (as specified by the OverwriteOutDated property). Can be one of WhenNeeded, OutDated, or Never.
Sources
Array of registered sources that may write entries to the Event Log.
Let’s look at an example that displays all of the properties listed in for each Event Log and sets the MaxFileSize and OverwriteOutDated properties if they have not already been set to the correct values. Since we want to iterate over all Event Logs, we will pass Win32_NTEventLogFile to the InstancesOf method. shows how to accomplish this.
Example . Displaying properties of the Event Log using Win32_NTEventLogFile
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Monitoring Trusts
Inhaltsvorschau
New to Windows Server 2003 is the Trustmon WMI provider. The Trustmon provider allows you to query the list of trusts supported on a domain controller and determine if they are working correctly. The Trustmon provider consists of three classes, but the primary one is the Microsoft_DomainTrustStatus class, which represents each trust the domain controller knows about. The Trustmon provider is contained under the root\MicrosoftActiveDirectory namespace. Note that this namespace is different than for the Active Directory provider, which is contained under root\directory\ldap.
provides a list of the property methods available to this class.
Table : Microsoft_DomainTrustStatus properties
Property
Description
Flatname
NetBIOS name for the domain.
SID
SID for the domain.
TrustAttributes
Flag indicating special properties of the trust. Can be any combination of the following:
  • 0x1 (nontransitive)
  • 0x2 (uplevel clients only)
  • 0x40000 (tree parent)
  • 0x80000 (tree root)
TrustDCName
Name of the domain controller the trust is set up with.
TrustDirection
Integer representing direction of the trust. Valid values include:
  • 1 (inbound)
  • 2 (outbound)
  • 3 (bidirectional)
TrustedDomain
Naming of trusted domain.
TrustIsOK
Boolean indicating whether the trust is functioning properly.
TrustStatus
Integer representing the status for the trust. 0 indicates no failure.
TrustStatusString
Textual description of status for the trust.
TrustType
Integer representing the type of trust. Valid values include:
  • 1 (downlevel)
  • 2 (uplevel)
  • 3 (Kerberos realm)
  • 4 (DCE)
As you can see from , the Microsoft_DomainTrustStatus class provides just about all the information you’d want to know concerning a trust. The following example shows how easy it is to enumerate all the trusts using this class:
Option Explicit

Dim strComputer, objWMI, objTrusts, objTrust

strComputer = "."



Set objWMI = GetObject("winmgmts:\\" & strComputer & _

                   "\root\MicrosoftActiveDirectory")

Set objTrusts = objWMI.ExecQuery("Select * from Microsoft_DomainTrustStatus")



For Each objTrust In objTrusts

  WScript.Echo objTrust.TrustedDomain

  WScript.Echo " TrustedAttributes: " & objTrust.TrustAttributes

  WScript.Echo " TrustedDCName: "     & objTrust.TrustedDCName

  WScript.Echo " TrustedDirection: "  & objTrust.TrustDirection

  WScript.Echo " TrustIsOk: "         & objTrust.TrustIsOK

  WScript.Echo " TrustStatus: "       & objTrust.TrustStatus

  WScript.Echo " TrustStatusString: " & objTrust.TrustStatusString

  WScript.Echo " TrustType: "         & objTrust.TrustType

  WScript.Echo ""

Next

WScript.Echo "The script has completed successfully."
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Monitoring Replication
Inhaltsvorschau
The WMI Replication provider is another good example of how Microsoft is leveraging WMI to help with monitoring Active Directory. Like the Trustmon provider, the Replication provider is only available with Windows Server 2003 and later, and is contained under the root\MicrosoftActiveDirectory namespace. It provides classes to list the replication partners for a domain controller, view the supported Naming Contexts for a domain controller, and also see the pending replication operations.
contains some of the more useful properties for the MSAD_ReplNeighbor class, which represents a replication partner (or neighbor) for a given domain controller.
Table : Useful MSAD_ReplNeighbor properties
Property
Description
IsDeletedSourceDsa
Boolean indicating whether the source DC has been deleted.
LastSyncResult
Number representing the result of the last sync operation with this neighbor. A value of 0 indicates success.
NamingContextDN
DN of the Naming Context for which the partners replicate.
NumConsecutiveSyncFailures
Number of consecutive sync failures between the two neighbors.
SourceDsaCN
CN of the replication neighbor.
SourceDsaSite
Site the replication neighbor is in.
TimeOfLastSyncAttempt
Time of the last sync attempt.
TimeOfLastSyncSuccess
Time of last successful sync attempt.
There are actually several property methods available other than what is shown in , so in the following example, we will enumerate all the replication neighbors and print out every property available to the MSAD_ReplNeighbor class:
Option Explicit

Dim strComputer, objWMI, objReplNeighbors, objReplNeighbor, objProp

strComputer = "."



Set objWMI = GetObject("winmgmts:\\" & strComputer & _

                   "\root\MicrosoftActiveDirectory")

Set objReplNeighbors = objWMI.ExecQuery("Select * from MSAD_ReplNeighbor")



For Each objReplNeighbor In objReplNeighbors

  WScript.Echo objReplNeighbor.SourceDsaCN & "/" & _

            objReplNeighbor.NamingContextDN & ":"

  For Each objProp In objReplNeighbor.Properties_

    If IsNull(objProp.Value) Then

       WScript.Echo " " & objProp.Name & " : NULL"

    Else

       WScript.Echo " " & objProp.Name & " : " & objProp.Value

    End If

  Next

  WScript.Echo ""

Next

WScript.Echo "The script has completed successfully."
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we gave a quick introduction into the WMI architecture and the concepts behind it. We then covered some of the tools available for querying and modifying WMI data. Next, we went through several examples for querying and manipulating services and the Event Logs. The last part of the chapter covered the WMI hooks into Active Directory, including the WMI providers for Trustmon and Replication .
In the next chapter, we will put our WMI knowledge to use as we work with the WMI DNS Provider. We will use WMI to configure Microsoft DNS server settings programmatically and manipulate zones and resource records.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 28: Scripting DNS
Inhaltsvorschau
DNS is a core technology of Active Directory that cannot be overlooked. Although features such as Active Directory Integrated DNS can take a lot of the hassle of managing DNS servers and zones out of your hands, you still have to set up the initial zone configurations. Unfortunately, lack of a good DNS API has always been a big gap for managing a Microsoft DNS server environment. The only way to automate maintenance and management of Microsoft DNS has been by executing Dnscmd commands from within a batch, VBScript, or Perl script. Over time, Microsoft has continued to improve Dnscmd, and as of Windows 2000, it provides just about every option you need to manage DNS server configuration, zones, and resource records using a command line. In Windows Server 2003, it even allows you to manage Application Partitions! Microsoft also provides the DNS MMC snap-in for those who want to manage DNS via a GUI, although it is not very suitable for managing large environments or making bulk modifications.
Microsoft’s answer to the DNS API issue is WMI. As explained in , WMI is one of Microsoft’s APIs for managing and monitoring systems and services. With the WMI DNS provider, you have complete programmatic control over a Microsoft DNS environment, much as you do with Dnscmd from a command line.
In this chapter, we will cover the WMI DNS provider at length, including the properties and methods available for the primary WMI DNS classes. Several sample scripts will be shown, which will give you a head start on developing scripts to manage your own DNS environment.
The DNS WMI provider was first released as part of the Windows 2000 Resource Kit Supplement 1, but unfortunately it was not ready for prime time. That version was buggy, did not include all the documented features, and in several cases behaved differently than what the documentation described. Also, since the DNS provider was included as part of a Resource Kit, it was not fully supported by Microsoft, which means that if you encountered problems, you were largely on your own. That said, much of the functionality you probably need is present in the Windows 2000 version, so it may be suitable. You can download the Windows 2000 DNS provider separately from the Resource Kit via FTP from
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
DNS Provider Overview
Inhaltsvorschau
The DNS WMI provider was first released as part of the Windows 2000 Resource Kit Supplement 1, but unfortunately it was not ready for prime time. That version was buggy, did not include all the documented features, and in several cases behaved differently than what the documentation described. Also, since the DNS provider was included as part of a Resource Kit, it was not fully supported by Microsoft, which means that if you encountered problems, you were largely on your own. That said, much of the functionality you probably need is present in the Windows 2000 version, so it may be suitable. You can download the Windows 2000 DNS provider separately from the Resource Kit via FTP from ftp://ftp.microsoft.com/reskit/win2000/dnsprov.zip.
Beginning with Windows Server 2003, the DNS provider is fully functional and supported. It is installed automatically whenever you install the DNS Server service. You can also install it separately as described in the next section. This may be necessary when doing development with the provider on a machine that does not have the DNS Server installed.
For our purposes, all sample code has been tested using the Windows Server 2008 DNS provider.
You do not need to manually install the provider if you are installing the DNS Server service on a Windows Server 2003 or better server because it gets installed with the service.
If you downloaded the DNS provider files for Windows 2000 (dnsschema.mof and dnsprov.dll), you will first need to copy them to the %SystemRoot%\System32\wbem directory. Next, you’ll need to compile the DNS managed object format (MOF ) file by executing mofcomp filename from a command line. With Windows 2000, the DNS MOF file is named dnsschema.mof, and beginning with Windows Server 2003, it is called dnsprov.mof. The output of the command should look like the following:
C:\WINDOWS\system32\wbem>mofcomp dnsprov.mof

Microsoft (R) 32-bit MOF Compiler Version 5.2.3628.0

Copyright (c) Microsoft Corp. 1997-2001. All rights reserved.

Parsing MOF file: dnsprov.mof

MOF file has been successfully parsed

Storing data in the repository...

Done!
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Manipulating DNS Server Configuration
Inhaltsvorschau
There are close to 50 different settings that can be configured on a Microsoft DNS server. They range from default scavenging and logging settings to settings that customize the DNS server behavior, such as how zone transfers will be sent to secondaries and whether to round-robin multiple A-record responses.
The DNS provider is mapped to the root\MicrosoftDNS namespace. A DNS server is represented by an instance of a MicrosoftDNS_Server class, which is derived from the CIM_Service class. contains all the property methods available in the MicrosoftDNS_Server class.
Table : MicrosoftDNS_Server class properties
Property name
Property description
AddressAnswerLimit
Max number of records to return for address requests (e.g., A records).
AllowUpdate
Determines whether DDNS updates are allowed.
AutoCacheUpdate
Indicates whether the DNS server will dynamically attempt to update its root hints (also known as cache) file.
AutoConfigFileZones
Indicates which standard primary zones that are authoritative for the name of the DNS server must be updated when the name server changes.
BindSecondaries
Determines the format zone transfers (AXFR) will be sent as to non-Microsoft DNS servers.
BootMethod
Determines where the server will read its zone information.
DefaultAgingState
For AD-integrated zones, the default scavenging interval in hours.
DefaultNoRefreshInterval
For AD-integrated zones, the default no-refresh interval in hours.
DefaultRefreshInterval
For AD-integrated zones, the default refresh interval in hours.
DisableAutoReverseZones
Determines whether the server automatically creates reverse zones.
DisjointsNets
Indicates whether the default port binding for a socket used to send queries to remote DNS servers can be overridden.
DsAvailable
Indicates whether Active Directory is available on the server.
DsPollingInterval
For AD-integrated zones, the interval in seconds to poll Active Directory for updates.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Creating and Manipulating Zones
Inhaltsvorschau
The MicrosoftDNS_Zone class provides a plethora of properties and methods to aid in managing your zones. Even if you are using AD-integrated zones, which help reduce the amount of work it takes to maintain DNS, you will inevitably need to configure settings on a zone or create additional zones. Tables and present the list of available properties and methods for the MicrosoftDNS_Zone class.
Table : MicrosoftDNS_Zone class properties
Property name
Property description
Aging
Specifies aging and scavenging behavior. Zero indicates scavenging is disabled.
AllowUpdate
Flag indicating whether dynamic updates are allowed.
AutoCreated
Flag indicating whether the zone was auto-created.
Specifies the time when the server may attempt scavenging the zone.
DataFile
Name of zone file.
DisableWINSRecordReplication
If TRUE, WINS record replication is disabled.
DsIntegrated
Specified if zone is AD integrated.
ForwarderSlave
Indicates whether the DNS server acts as a slave when resolving the names for the specified forward zone. Applicable to Forward zones only.
ForwarderTimeout
Indicates the time, in seconds, a DNS server forwarding a query for the name under the forward zone waits for resolution from the forwarder before attempting to resolve the query itself. This parameter is applicable to the Forward zones only.
Number of seconds since the beginning of January 1, 1970 GMT, since the SOA serial number for the zone was last checked.
LastSuccessfulXfr
Number of seconds since the beginning of January 1, 1970 GMT, since the zone was last transferred from a master server.
LocalMasterServers
Local IP addresses of the master DNS servers for this zone. If set, these masters override the MasterServers found in Active Directory.
MasterServers
IP addresses of the master DNS servers for this zone.
NoRefreshInterval
Specifies the time interval between the last update of a record’s timestamp and the earliest moment when the timestamp can be refreshed.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Creating and Manipulating Resource Records
Inhaltsvorschau
Resource records are the basic unit of information in DNS. A DNS server’s primary job is to respond to queries for resource records. Most people don’t realize they are generating resource record queries with nearly every network-based operation they do, including accessing a website, pinging a host via its Fully Qualified Domain Name (FQDN), or logging into Active Directory.
Resource records come in many different flavors or types. Each type corresponds to a certain type of name or address lookup. Each record type also has additional information encoded with the record that represents things such as the time to live (TTL) of the record. The following is a textual example of what a CNAME record looks like:
www.mycorp.com.  1800  IN  CNAME  www1.mycorp.com.
Or, more generically:
Owner  TTL  Class  Type  RR-Data
Now let’s break down the record into its individual parts:
Owner
The owner of the resource record. This field is typically what is specified during a query for the particular type.
TTL
The time to live, or length of time a nonauthoritative DNS server should cache the record. After the TTL expires, a nonauthoritative server should requery for an authoritative answer.
Class
Resource record classification. In nearly all cases, this will be “IN” for Internet.
Type
Name of the resource record type. Each type has a standard name that is used in zones (e.g., CNAME, A, PTR, SRV).
RR-Data
Resource record specific data. When you perform a query, you are typically looking for the information returned as part of the RR-Data.
The WMI DNS provider fully supports querying and manipulating resource records. In Tables and , the supported properties and methods are listed for the MicrosoftDNS_ResourceRecord class, which implements a generic interface for resource records.
Table : MicrosoftDNS_ResourceRecord class properties
Property name
Property description
ContainerName
Name of container (e.g., zone name) that holds the RR
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
The WMI DNS provider fills a much-needed gap for programmatic management of a Microsoft DNS environment. In this chapter, we reviewed how to install the DNS provider, including some of the caveats for using it on Windows 2000. We then covered the classes used for managing server configuration, along with each of the available server settings. Next, we showed how to create and manipulate zones with the DNS provider. Finally, we covered the various resource record types and their associated WMI classes.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 29: Programming the Directory with the .NET Framework
Inhaltsvorschau
In 2002, Microsoft announced a major new initiative called “.NET” that was intended to fundamentally change the way software is written for the Windows platform. Something called “.NET Framework” would provide a unified, cross-language programming model and a “managed” runtime environment for this code, which would take care of the messy details such as memory management, making software development easier.
The .NET Framework, now on version 3.5, has seen three major releases, expanding the capability of the programming library substantially. The landscape for directory services programming has also expanded dramatically. In fact, over the last five years or so, the .NET directory services programming interfaces have seen the only really substantial investment by Microsoft in interfaces for programming the directory.
While a skeptic might suggest this is because .NET was just playing catch up, the reality is that now, more than ever before, the .NET Framework is the place for Windows developers of all stripes to access the directory. It is also the case that we have a lot more to talk about than we did last time. Let’s dig in.
Why bother learning about .NET? After all, many AD administrators have been scripting happily for years with VBScript, ADSI, WMI, and a pile of command-line tools. We have been getting along just fine. This .NET stuff is really for the enterprise developers writing line of business applications, is it not?
First, let’s be clear that .NET may not be for everyone. There are many techniques available for programming the directory, and you may not need to move away from the tools and techniques you already use. However, there are some compelling reasons to consider it:
  • Powerful features that were once only available to C++ developers are now being exposed in the .NET Framework. This makes it easier for the vast majority of us who do not program in C++ to get to these features.
  • Microsoft has a powerful new web development platform called ASP.NET that vastly improves how we can build applications for the web. Many AD development tasks lend themselves to web-based deployment. We’ll see more about ASP.NET in .
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Why .NET?
Inhaltsvorschau
Why bother learning about .NET? After all, many AD administrators have been scripting happily for years with VBScript, ADSI, WMI, and a pile of command-line tools. We have been getting along just fine. This .NET stuff is really for the enterprise developers writing line of business applications, is it not?
First, let’s be clear that .NET may not be for everyone. There are many techniques available for programming the directory, and you may not need to move away from the tools and techniques you already use. However, there are some compelling reasons to consider it:
  • Powerful features that were once only available to C++ developers are now being exposed in the .NET Framework. This makes it easier for the vast majority of us who do not program in C++ to get to these features.
  • Microsoft has a powerful new web development platform called ASP.NET that vastly improves how we can build applications for the web. Many AD development tasks lend themselves to web-based deployment. We’ll see more about ASP.NET in .
  • Microsoft has a new command shell called PowerShell that is based on the .NET Framework. PowerShell completely changes the equation for how shell programmers and scripters can program and administrate Windows. We’ll see more about PowerShell in .
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Choosing a .NET Programming Language
Inhaltsvorschau
As we previously mentioned, .NET is a programming environment that can be accessed from many different languages. In fact, the runtime environment for .NET (or “”) code is called the Common Language Runtime or CLR. The runtime is fundamentally object-oriented, but is otherwise neutral to the language syntax used to program it. At the time of this writing, there are dozens of different languages that can be used to write .NET code, from the time-honored COBOL to experimental languages like F#.
Microsoft itself ships tools for several of these languages, including C#, Visual Basic.NET (or VB.NET), C++, and JScript.NET. It is fair to say that most .NET developers use either C# or VB.NET, with Microsoft itself using C# for the vast majority of their own work. C# as a language looks a bit like C++, but a lot more like Java. However, for most of us, our background is in writing VBScript code, so for this book we will present all of the examples in VB.NET.
This decision will likely make a few people grumpy, but it is the best compromise. For those who are put off by this decision, please take consolation in the fact that the thing that really matters is learning the framework itself. The language details are not usually that important. In fact, the languages are often so similar that there are many free tools that can translate code from one language to another with no loss at all.
Unfortunately, there is no way we can explain the basics of programming .NET or any specific languages features. Those sorts of primers already exist on the Internet and in bookstores. Instead, we will take the approach of keeping things simple enough to not require a lot of background and additional depth.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Choosing a Development Tool
Inhaltsvorschau
Since the last version of this book, the landscape for .NET development tools has expanded as much as the framework itself. Today, you have a lot of choices for how you can write .NET code. The primary decision to make is whether you want to use an integrated development environment (IDE) for your development tasks. IDE’s simplify development by making it easier to organize your code files and build them into .
Back in the days of Visual Studio.NET 2002, Microsoft was basically the only game in town for .NET IDEs. However, that story has changed significantly. Not only does Visual Studio 2008 come in a variety of different packages, some of them completely free, but there are other non-Microsoft products available to choose from such as SharpDevelop from IC# Code (http://www.sharpdevelop.net) and Primal Code.NET by HALLoGRAM Publishing (http://www.hallogram.com).
The point here is that there are many options and quite a few of them are free. It is not necessary to buy an expensive tool to write .NET code. Although we do not endorse a particular tool, we will say that most .NET developers use Microsoft’s Visual Studio, and the free Express versions (http://www.microsoft.com/express/) are suitable for our needs, so that is a reasonable place to start.
Although an IDE can be nice, we do not actually need one to write code for the .NET Framework. In fact, Microsoft provides a free downloadable SDK with all versions of the framework that includes all the tools we need to build .NET code. Though it is rarely done, it is certainly possible to dive right in with Notepad and a command prompt! There are also a variety of tools available such as Snippet Compiler by Jeff Key (http://www.sliver.com/dotnet/SnippetCompiler/) that provide an experience similar to scripting, but with compiled code.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
.NET Framework Versions
Inhaltsvorschau
At the time of this writing, Microsoft has released versions 1.0, 1.1, 2.0, 3.0, and 3.5 of the .NET Framework. It can be confusing to understand which .NET features are available in which releases, which release came bundled with which operating system release and how code written for one version will work on another version. Let’s unravel all that. Both .NET 3.0 and 3.5 require .NET 2.0 to be installed because they are not actually standalone releases. NET 3.5 also requires Service Pack 1 for .NET 2.0 to be installed.
First, a few general notes on .NET Framework versions:
  • It is not a problem to install multiple versions of the framework on the same machine. They happily coexist when installed side by side.
  • By default, code compiled against a specific version of the framework will run against that same version of the framework if it is installed on the machine from which it is executed. However, if that version of the framework is not installed where the code is running but a newer version is installed, it will load against the newer version.
  • Generally speaking, code written against an earlier version of the framework will run with no problems against a later version of the framework. There are a few backwards compatibility problems, but they are rare overall.
  • Make sure you have installed the latest service packs as they are released.
Depending on the operating system (OS) of the machine where you want to execute .NET code, a version of the framework may already be included. summarizes which OS has what.
Table : .NET Framework/Windows OS cross-reference
Operating system
Included framework versions
Windows 2000
None
Windows XP
None
Windows Server 2003
1.1
Windows Server 2003 R2
1.1, 2.0
Windows Vista
2.0, 3.0
Windows Server 2008
2.0, 3.0
This basically means that unless you control the infrastructure and have made provisions to install some version of .NET through other means, you cannot assume any version of the .NET Framework is available unless the operating system is Windows Server 2003 or higher. You may install whatever version(s) of the framework you wish on any machine, with the exception that .NET 2.0 is the last version of the framework supported on Windows 2000.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Directory Services Programming Landscape
Inhaltsvorschau
First, let’s take a high-level view of how all of the various pieces fit together.
As you might imagine, the .NET Framework does not attempt to implement the entire operating system from the ground up, but instead uses existing operating system services to some extent or another and repackages them in the more consistent .NET programming model. All of the .NET directory services features leverage existing operating system functionality, some of which we have already covered in this book.
depicts how the various pieces fit together.
Figure : Windows Directory Services API mode
As with most software architectures, the model is built up in layers from low-level components to high-level ones. At the top, we see how the various .NET components fit together and depend on each other.
Right at the center of the diagram, we see ADSI and how it depends on various lower level operating system components. You will find it reassuring that much of the investment you have already made in learning ADSI from this book and other sources will directly carry over to your .NET programming activities.
Now, let’s dig into the high-level details of each namespace in turn.
The System.DirectoryServices namespace (SDS) is the primary namespace we use for programming directory services in .NET. It is the oldest namespace, having been included with .NET since the very first 1.0 release.
SDS is basically just a simple interop layer over the existing ADSI programming model. Most of what you already know about ADSI will apply directly to SDS. SDS is in many ways more like a stripped-down version of ADSI, but in other ways is more powerful. In all cases, it is ADSI that does the bulk of the work, with the components it depends on doing the actual heavy lifting.
Even though there are quite a few types in the namespace, almost everything in SDS revolves around two core classes:
  • DirectoryEntry
  • DirectorySearcher
DirectoryEntry is essentially a wrapper around the ADSI
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
.NET Directory Services Programming by Example
Inhaltsvorschau
Now, let’s switch focus and dive into some code. Unfortunately, there is no possible way we can do much more than scratch the surface of all of the types of things we can do with .NET directory services programming. This topic could easily fill an entire book (and has a few times already). If you need a deeper reference, The .NET Developer’s Guide to Directory Services Programming by Kaplan and Dunn (Addison-Wesley) is an excellent option.
Conventions for the code samples:
  • Unless otherwise stated, assume we are using .NET 2.0.
  • For brevity, we will skip error handling and object cleanup code that we really should be using in most “real” work.
  • Assume that we are using a simple console application type for our samples, but do not let that imply that you can only build console applications. All of these samples may be used in any .NET application type.
  • Assume we have an assembly reference to System.DirectoryServices.dll and have imported namespaces for SDS and SDS.AD via the following block of code.
Imports System.DirectoryServices 

Imports System.DirectoryServices.ActiveDirectory
Like VBScript and VB6, VB.NET supports a programming technique called “late binding.” Late binding allows us to refer to properties or methods on an object that may not be explicitly available on the current class. This is mostly helpful when working with COM interfaces in .NET.
However, C# does not have such a feature and requires complex “reflection” code to accomplish the same goal. For that reason, we will avoid using any late binding in our samples. SDS provides other ways to accomplish the same tasks anyway, so late binding is not really necessary. You can add the Option Strict and Option Explicit directives in your code to disable late binding if you wish.
Additionally, VB.NET is not case-sensitive but C# is, so we’ll use proper case in all of our examples.
There are two basic options available for connecting to the directory:
  • Use DirectorySearcher
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
.NET, now in version 3.5, is here to stay, and Microsoft continues to invest in these resources for developers while the options in native code APIs have been largely unchanged for years now. Not only does .NET allow us to do the same things we are used to doing in our other tools, but it also provides access to features that were previously only available to C++ developers and new approaches that make development easier.
.NET is also an essential tool to learn for tackling other new technologies such as ASP.NET web development and Windows PowerShell.
In this chapter, we took a quick tour of the now-expansive landscape of directory services development namespace in .NET, including the following:
  • System.DirectoryServices
  • System.DirectoryServices.ActiveDirectory
  • System.DirectoryServices.AccountManagement
  • System.DirectoryServices.Protocols
A single chapter can only scratch the surface of what we can do, but hopefully we have given you enough to get your feet wet and generate some excitement about the .
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 30: PowerShell Basics
Inhaltsvorschau
The goal of this chapter is to give you a basic understanding of what Windows is, how it can help you, and a quick reference source for PowerShell constructs. We’ll take a look at the PowerShell language, the built-in cmdlets, and how to integrate PowerShell with technologies like WMI.
PowerShell is more than just a shell. It’s a scripting platform, a programming language, a development environment, and a replacement for the legacy Windows command shell, cmd.exe. Automation is a key facet of running a successful IT operation, and Windows PowerShell extends the ability to automate across numerous Microsoft and third-party technologies in an easy and cohesive manner.
As with any shell, PowerShell has a number of basic features that you should be familiar with as you move through this chapter.
Variables are named data storage that you can use in PowerShell to store whatever you want. Variables are always prefixed with a $ sign followed by a name of your choosing. For example, if you wanted to store Brian in a variable called $FirstName, you would run $FirstName = "Brian".
Variables also have scope. Scope determines which level of access is provided to variables (and also functions) within the PowerShell environment. details the three possible scopes for your variables. You need to remember scope when you start working with scripts and functions as you may find that variables you were looking to use are not always accessible.
Table : Scopes
Scope
Description
Local
Limited to the current function
Script
Limited to the context of the current executing script, with the exception of dot-sourced scripts
Global
Available across all scopes
When you launch a script with a period in front of the name, the script is said to be “dot sourced”. Dot sourcing takes all the variables in the script and makes them available to the calling scope. An example of where this might be useful is if you had a script that had a series of library functions you wanted to make available. If you wanted to dot source
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Exploring the PowerShell
Inhaltsvorschau
As with any shell, PowerShell has a number of basic features that you should be familiar with as you move through this chapter.
Variables are named data storage that you can use in PowerShell to store whatever you want. Variables are always prefixed with a $ sign followed by a name of your choosing. For example, if you wanted to store Brian in a variable called $FirstName, you would run $FirstName = "Brian".
Variables also have scope. Scope determines which level of access is provided to variables (and also functions) within the PowerShell environment. details the three possible scopes for your variables. You need to remember scope when you start working with scripts and functions as you may find that variables you were looking to use are not always accessible.
Table : Scopes
Scope
Description
Local
Limited to the current function
Script
Limited to the context of the current executing script, with the exception of dot-sourced scripts
Global
Available across all scopes
When you launch a script with a period in front of the name, the script is said to be “dot sourced”. Dot sourcing takes all the variables in the script and makes them available to the calling scope. An example of where this might be useful is if you had a script that had a series of library functions you wanted to make available. If you wanted to dot source c:\scripts\Myfunctions.ps1, you would run:
c:\scripts\Myfunctions.ps1
Nearly everything we work with in PowerShell is an object of some kind. If you’re a programmer, objects in PowerShell are just like objects in any other language. You can think of an object as a structured way to store data. There are two important facets of objects throughout this chapter—properties and methods.
Properties describe a given aspect of an object. For example, a user could have a property of Name. Properties are accessed by using a period. If you wanted to access the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Working with the Pipeline
Inhaltsvorschau
The concept of a pipeline has been around for decades, but PowerShell has taken the pipeline to a new level. A pipeline is traditionally defined as the redirecting of the textual output of one process into the input of another process. However, this is text output, which has to be parsed, reparsed, modified, and passed along. Oftentimes, there is a lot of data loss along the way with this model.
PowerShell changes this paradigm by passing .NET objects in the pipeline. As a result the data which is passed is high fidelity compared to the typical text output which often loses detail every step of the way.
You’ll see throughout this chapter that we frequently use $_ in our scripts and commands. When you are working with the pipeline, you often need to refer to the current object being passed. $_ is a shortcut for doing this. We’ll cover a number of scenarios where the $_ expression is critical as we go through this chapter.
In order to demonstrate the difference between the traditional command-shell pipeline and the PowerShell pipeline, let’s explore a common task—find all files in a folder structure that are greater than 1 MB in size.
First, let’s look at how you’d do this in the traditional Windows command shell:
for /f "tokens=*" %F in ('dir /s /b') do @(if %~zF GTR 1048576 echo %F)
The same task can be accomplished in PowerShell using the following command:
dir C:\ -Recurse | Where-Object { $_.Length -gt 1mb } | `

    ForEach-Object{ $_.FullName }
Dir is an alias for the Get-ChildItem cmdlet.
While the PowerShell command is certainly easier to read, there’s definitely not an obvious benefit as it’s even a bit longer than the DOS command. Consider if you needed to expand upon this example to determine additional information such as timestamps on the file, or even to filter on those timestamps:
# To output the last time the file was accessed and when it was created

dir c:\ -Recurse | ?{$_.Length -gt 1mb} | Format-Table `

    FullName,LastAccessTime,CreationTime



# Now... all files greater than 1 MB and not accessed in the last month

dir c:\ -Recurse | ?{($_.Length -gt 1mb) -And ($_.LastAccessTime `

    -lt (Get-Date).AddMonths(-1))}
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Cmdlets
Inhaltsvorschau
PowerShell cmdlets are a key piece of the overall PowerShell environment. Out of the box, Windows PowerShell brings to the table numerous cmdlets that you can leverage in your scripts. As PowerShell has continued to evolve, third party software developers have begun releasing cmdlets for their own products, further enhancing the PowerShell environment. Microsoft makes the information required for anyone to build cmdlets available in the Windows SDK.
Windows PowerShell brings predictability and discoverability by providing a standard naming scheme for cmdlets. Every cmdlet is named in a Verb-Noun fashion, and the list of approved verbs is defined by Microsoft. details a list of approved verbs by category.
A few examples of this naming schema revolve around Windows services. If you wanted to get the list of all the services on a system, you could run the Get-Service cmdlet. To start a service, you could use the Start-Service cmdlet. Predictably, a list of processes is accessible with the Get-Process cmdlet.
While it’s not required, we recommend that as a best practice you name the functions in your PowerShell scripts using the Verb-Noun model we’ve discussed.
The list of verbs in is simply a list of approved verbs. You can use other verbs and you will come across cmdlets that do, but as a best practice you should limit yourself to the verbs in .
Table : Approved verbs
Common verbs
Communication verbs
Data verbs
Diagnostic verbs
Lifecycle verbs
Security verbs
Add
Connect
Backup
Debug
Disable
Block
Clear
Disconnect
Checkpoint
Measure
Enable
Grant
Copy
Read
Compare
Ping
Install
Revoke
Get
Receive
Convert
Resolve
Restart
Unblock
Join
Send
ConvertFrom
Test
Resume
Security
Lock
Write
ConvertTo
Trace
Start
Move
Dismount
Stop
New
Export
Suspend
Remove
Import
Uninstall
Rename
Initialize
Select
Limit
Set
Merge
Split
Mount
Unlock
Restore
Update
Out
Nearly all of the cmdlets (and scripts) you work with in PowerShell will accept parameters, or arguments. Any information you need to provide to a cmdlet in order for it to run will be specified as a parameter. There are two types of parameters—named and positional.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Building PowerShell Scripts
Inhaltsvorschau
PowerShell scripts are text files that contain a series of PowerShell commands that are run sequentially. Typically, scripts also contain functions that you can reference throughout the script, and sometimes from the PowerShell console at large. Scripts are always stored in a file named with a .ps1 extension. To execute a script, you would pass the fully qualified or relative path followed by any arguments. To run MyScript.ps1, which is in the current directory, you would run .\MyScript.ps1.
If you want to structure your scripts to use the pipeline, you will want to use a process block as well as optional begin and end blocks. The syntax is similar to the following:
begin

{

    # This code is executed once at the beginning of the script

}

process

{

    # This code is executed for each object in the pipeline

}

end

{

    # This code is executed once at the end of the script



}
Any time you prefix a line with the # symbol, you are making a comment. Comments are ignored by PowerShell and are purely for making your scripts easier to understand.
To access the current pipeline object in the pipeline during the process block, you would use the $_ variable. In this example we simply print each object in the pipeline:
begin

{

    Write-Host "Starting"

}

process

{

    Write-Host $_

}

end

{

    Write-Host "Complete"

}
PowerShell exposes any arguments to your scripts through the $args array variable. If you want to check how many arguments have been passed, you can access $args.Count. Since $args is an array, you can loop through the contents as described later in this chapter in the section on loops.
Any arguments which are declared as named or positional arguments in the script declaration will not be included in the $args array variable. Refer to the discussion on the param keyword in the section on Functions for more information about declaring arguments.
If you want to have a formal definition of the arguments your script expects, you should start your script with a
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Using WMI
Inhaltsvorschau
PowerShell fully exposes WMI through the Get-WMIObject cmdlet (alias gwmi). There are a number of parameters you’ll want to take a look at when using the Get-WMIObject cmdlet:
Class
The -Class parameter specifies the WMI class you want to retrieve. In this example, we retrieve the contents of the Win32_ComputerSystem class for the current machine:
Get-WMIObject Win32_ComputerSystem



Domain              : WORKGROUP

Manufacturer        : Dell Inc.

Model               : Dimension 4700

Name                : BRIAN-WKS01

PrimaryOwnerName    : Brian Desmond

TotalPhysicalMemory : 3219177472
Property
If you want to filter the properties returned from a WMI class, you can use the -Property parameter. In this example, we retrieve two properties from the Win32_OperatingSystem class:
Get-WmiObject Win32_OperatingSystem -Property `

    SystemDirectory,Version

SystemDirectory  : C:\WINDOWS\system32

Version          : 5.2.3790
Namespace
The -Namespace parameter works in conjunction with -Class to tell WMI where the class is located. For example, if you wanted to see the ICMP settings for the Windows Firewall, you could use the HNet_FwICMPSettings class from the Root\Microsoft\HomeNet namespace:
gwmi -Name Root\Microsoft\HomeNet -Class HNet_FwIcmpSettings



AllowInboundEchoRequest             : False

AllowInboundMaskRequest             : False

AllowInboundRouterRequest           : False

AllowInboundTimestampRequest        : False

AllowOutboundDestinationUnreachable : False

AllowOutboundParameterProblem       : False

AllowOutboundSourceQuench           : False

AllowOutboundTimeExceeded           : False

AllowRedirect                       : False

Name                                : Default
Notice that in this example, we used the gwmi alias to Get-WMIObject.
ComputerName
You can provide the -ComputerName parameter with a list of remote machine names to connect to, and Get-WMIObject will execute the WMI query against each of those machines. In this example, we connect to two remote machines specified in
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we’ve taken a look at the Windows PowerShell language and environment. We took a look at the cmdlets that PowerShell is centered around and how to work with them. The pipeline is an extremely powerful component of PowerShell that allows you to pass objects between cmdlets for manipulation without any loss of fidelity. PowerShell exposes WMI and the .NET framework to you for use in addition to the cmdlets available, and we took a look at how to work with WMI as well. In , we explore how to use PowerShell specifically for managing Active .
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 31: Scripting Active Directory with PowerShell
Inhaltsvorschau
This chapter will show you how take advantage of Windows PowerShell to execute common Active Directory administration tasks. Over the course of this chapter, we’ll examine tasks centered on management of users, groups, computers, and organizational units. After mastering these elements, we will go on to assemble a PowerShell script that can be used to populate an Active Directory test domain. As a capstone to this activity, we will look at a number of third-party PowerShell snap-ins that can extend the script built in this chapter.
If you haven’t already, take a few minutes to review for an introduction to managing Active Directory with .NET.
Working with Windows PowerShell doesn’t require that you understand all the intricacies of .NET or even be a developer. However, having a basic grasp of the .NET classes used for working with Active Directory will make you much more productive. In this section, we’ll take a look at the key .NET classes used throughout this chapter and how to leverage them in PowerShell. The majority of these classes are located in the System.DirectoryServices namespace, which we’ll abbreviate as SDS throughout this chapter.
Almost anytime you need to represent an object in Active Directory, chances are you’ll be using the DirectoryEntry class. This is so common that PowerShell actually includes a shortcut for referencing objects in Active Directory. If you prefix a distinguished name with [ADSI], PowerShell will create a DirectoryEntry object for you. For example, you could build a DirectoryEntry for a user bdesmond like this:
[ADSI]"LDAP://cn=bdesmond,cn=users,dc=corp,dc=lab"



distinguishedName

-----------------

{cn=bdesmond,cn=users,dc=corp,dc=lab}
You will often see the use of [ADSI] in scripts or samples on the Internet since it makes code shorter and easier to read. If you’re wondering what is happening behind the scenes, the equivalent PowerShell command to the previous code sample would be:
New-Object System.DirectoryServices.DirectoryEntry `

"LDAP://cn=bdesmond,cn=users,dc=corp,dc=lab"
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Becoming Familiar with .NET
Inhaltsvorschau
Working with Windows PowerShell doesn’t require that you understand all the intricacies of .NET or even be a developer. However, having a basic grasp of the .NET classes used for working with Active Directory will make you much more productive. In this section, we’ll take a look at the key .NET classes used throughout this chapter and how to leverage them in PowerShell. The majority of these classes are located in the System.DirectoryServices namespace, which we’ll abbreviate as SDS throughout this chapter.
Almost anytime you need to represent an object in Active Directory, chances are you’ll be using the DirectoryEntry class. This is so common that PowerShell actually includes a shortcut for referencing objects in Active Directory. If you prefix a distinguished name with [ADSI], PowerShell will create a DirectoryEntry object for you. For example, you could build a DirectoryEntry for a user bdesmond like this:
[ADSI]"LDAP://cn=bdesmond,cn=users,dc=corp,dc=lab"



distinguishedName

-----------------

{cn=bdesmond,cn=users,dc=corp,dc=lab}
You will often see the use of [ADSI] in scripts or samples on the Internet since it makes code shorter and easier to read. If you’re wondering what is happening behind the scenes, the equivalent PowerShell command to the previous code sample would be:
New-Object System.DirectoryServices.DirectoryEntry `

"LDAP://cn=bdesmond,cn=users,dc=corp,dc=lab"
[ADSI] is an example of a type accelerator.
The DirectorySearcher class is, as its name implies, for searching for objects in Active Directory. It’s important to remember that the search results returned from a DirectorySearcher are SearchResult objects, not DirectoryEntry objects.
If you need to get the DirectoryEntry object (such as for making an update to the search result), call SearchResult.GetDirectoryEntry().
In this example, we will search the domain for user bdesmond:
$filter = "(sAMAccountName=bdesmond)"

$ds = New-Object DirectoryServices.DirectorySearcher([ADSI]"", $filter)

$ds.FindOne()
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Understanding Client-Side Processing
Inhaltsvorschau
Before we dive into building our script, it is important to take a minute to understand what is actually happening under the covers when you run ADSI code under PowerShell. illustrates how PowerShell interacts with Active Directory to execute the following code sample:
# Script To Change User CN and Display Name

$user = [ADSI]"LDAP://CN=Jsmith,OU=MyUsers,DC=Corp,DC=lab"

$user.DisplayName = "Jon Smith"

$user.GivenName = "Jon"

$user.SetInfo()
Figure : Client-side object processing
The eight steps in are:
  1. We create a reference to an Active Directory object in our local in-memory cache.
  2. We attempt to access the user.
  3. A request to get the attributes of the object from Active Directory is made.
  4. The data is returned from Active Directory and the local object is populated.
  5. Local object display name is set (but not committed to Active Directory).
  6. Local object name is set (but not committed to Active Directory).
  7. The local object changes are committed.
  8. The Active Directory object is modified to match the local copy.
Notice that we do not make a connection to a domain controller until we access the object the first time. It is a common mistake to think the connection is established on the initial object setup. Here are some other failure scenarios to watch out for.
This code sample will not cause an error and will instead print Domain Bind Successful:
$domain = [ADSI]"LDAP://Some.Erroneous.Domain.Name"

If($?){ "Domain Bind Successful" } `

    else{ "Domain Bind Failed" }
This code sample will lead to an error and will print Domain Bind Failed:
$domain = [ADSI]"LDAP://Some.Erroneous.Domain.Name"

If($domain.name) { "Domain Bind Successful" } `

    else{ "Domain Bind Failed" }
The second code sample led to an error condition because instead of testing for an error using the ($?) statement, we tried to access a known property of the expected object. When PowerShell tries to expand $domain.name, it makes the bind attempt, which will fail.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Building the Lab Build Script
Inhaltsvorschau
Now that we’ve reviewed some of the common .NET Active Directory classes and how to work with them under Windows PowerShell, we’re ready to begin building our script. We’ll first take a look at some boilerplate setup code for the script, and then we’ll begin building the functions necessary to support the logic of our script.
To kick off our script, we’re going to need to lay the foundation for our code. The code sample below is the code we will start off with:
Param($dc, $domain, $count=10)

# Script Setup

if($dc -ne $null)

{

    $ldapConnectionString = "LDAP://$dc/"

    $domainDN = ([ADSI]"LDAP://$dc").distinguishedName[0]

}

else

{

    $ldapConnectionString = "LDAP://"

    $domainDN = ([ADSI]"").distinguishedName[0]

}

if(!$domain){$domain = $domainDN -Replace "dc=", "" -Replace ",", "."}
In this section we define what we want to accept from the command line as parameters (also called arguments). The Param statement defines which parameters we want to accept:
Param($dc, $domain, $count=10)
Our script will accept three parameters:
$dc
This value, if supplied, is used as the domain controller to connect to when we make our Active Directory connections. This is an optional parameter, and the code is smart enough to locate a domain controller for us if we don’t specify $dc.
$domain
We will use $domain to create the userPrincipalName for user objects. If $domain is not specified, the code will generate it by using the distinguished name of the discovered Domain:
if(!$domain){$domain = $DomainDN -Replace "dc=", "" -Replace ",", "."}
$count
This parameter specifies how many OrganizationalUnit objects to create. By default we will create 10 child OrganizationalUnit objects, 50 User objects (5 per child OrganizationalUnit), and 50 Computer objects (5 per child OrganizationalUnit) for each test OrganizationalUnit.
After the Param statement, our code parses the parameters passed and builds two local variables which will be used later on. First, we check to see if a
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Working with Forests and Domains
Inhaltsvorschau
Manipulating forest and domain properties are both very common Active Directory tasks when writing scripts. As we discussed early in the chapter, PowerShell exposes these task through the .NET Framework.
This code snippet will get a Forest object and put it in the variable called $forest:
$forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
GetCurrentForest() is a method that returns a Forest object for the current user context. As you can see in output below, forest objects have quite a few properties that can be utilized in scripts:
PS> $forest



Name                  : corp.lab

Sites                 : {Default-First-Site-Name}

Domains               : {corp.lab}

GlobalCatalogs        : {Win2k8x64dc1.corp.lab, Win2k8x64DC2.corp.lab}

ApplicationPartitions : {DC=ForestDnsZones,DC=corp,DC=lab, 

                         DC=DomainDnsZones,DC=corp,DC=lab}

ForestMode            : Windows2003Forest

RootDomain            : corp.lab

Schema                : CN=Schema,CN=Configuration,DC=corp,DC=lab

SchemaRoleOwner       : Win2k8x64dc1.corp.lab

NamingRoleOwner       : Win2k8x64dc1.corp.lab
You can get the name of the forest root (Name), a listing of sites, child domains, and global catalogs (Sites, Domains, and GlobalCatalogs, respectively), the functional level (ForestMode), and the owners of the schema master and domain naming master FSMOs (SchemaRoleOwner and NamingRoleOwner, respectively).
In addition to properties, the Forest class also has a number of methods you can use to manipulate the forest. You can pipe $forest to Get-Member to get a listing of these methods. Since we only want to see the members and the associated type of each member, we are going to use Format-Table to control the output:
PS>$forest | Get-Member -MemberType Method | `

    Format-Table Name,MemberType -Auto



Name                               MemberType

----                               ----------

CreateLocalSideOfTrustRelationship     Method

CreateTrustRelationship                Method

DeleteLocalSideOfTrustRelationship     Method

DeleteTrustRelationship                Method

FindAllDiscoverableGlobalCatalogs      Method

FindAllGlobalCatalogs                  Method

FindGlobalCatalog                      Method

GetAllTrustRelationships               Method

GetSelectiveAuthenticationStatus       Method

GetSidFilteringStatus                  Method

GetTrustRelationship                   Method

RaiseForestFunctionality               Method

RepairTrustRelationship                Method

SetSelectiveAuthenticationStatus       Method

SetSidFilteringStatus                  Method

UpdateLocalSideOfTrustRelationship     Method

UpdateTrustRelationship                Method

VerifyOutboundTrustRelationship        Method

VerifyTrustRelationship                Method
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Understanding Group Policy
Inhaltsvorschau
Scripting Group Policy has historically been a task that was not easily accomplished. SDM Software, a third party software vendor, offers a number of free Group Policy cmdlets on their website. You can download these cmdlets from http://www.sdmsoftware.com/freeware.php.
The Update-SDMgp cmdlet allows you to remotely refresh Group Policy data on a machine from PowerShell. There are a number of parameters:
Target
This mandatory parameter is the name of the remote computer on which to trigger a Group Policy refresh.
Username
Use this parameter when you need to enter alternate credentials to connect to the remote system.
Password <SecureString>
This is the password for the user specified in the Username parameter.
Computer
Indicates that Group Policy refresh should only target the computer-specific .
User
Indicates that Group Policy refresh should only target the user-specific settings.
Force
This parameter tells the remote refresh to issue a forced refresh.
Logoff
This parameter tells the remote refresh to issue a refresh and then logoff the current user.
Boot
This parameter tells the remote refresh to issue a refresh and then reboot the remote system.
Sync
This tells the remote machine to issue a sync command, which will cause the next foreground refresh event to occur synchronously.
Ignore
When used with the Force, Boot, and Logoff switches, the reboot or logoff will not occur.
In this example, we refresh Group Policy on machine win2k8x64dc2:
Update-SDMgp "win2k8x64DC2"
To force the refresh on win2k8x64dc2, add the -force switch:
Update-SDMgp "win2k8x64DC2" -force
To refresh just the computer policy on win2k8x64dc2, add the -computer switch:
Update-SDMgp "win2k8x64DC2" -computer
If you had a list of machines stored in a variable called $list, you could run this command to refresh the Group Policy on each machine:
$list | %{Update-SDMgp $_}
SDM Software ships a second package of cmdlets that allow you to manipulate Group Policy objects in Active Directory. provides a listing of those cmdlets as of version 1.2 of the package.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
This chapter covered many common Active Directory automation tasks using Windows PowerShell. After building functions that manipulated users, computers, groups, and organizational units, we assembled them all to build a script that can populate an Active Directory domain with a configurable amount of test data. We also took a look at some of the .NET classes that you can use to work with forest and domain settings from PowerShell.
As Windows PowerShell has continued to gain acceptance in the community, third party software vendors have begun shipping PowerShell cmdlets. SDM Software and Quest Software both ship free cmdlet packages for working with Active Directory. We took a look at a few samples of both and also built a script to import a CSV of users into Active Directory.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 32: Scripting Basic Exchange 2003 Tasks
Inhaltsvorschau
In this chapter, we will show you how to automate manipulating some of the basic Exchange settings, specifically concerning users (and by extension inetOrgPersons), groups, and contacts. Although tools to manage Exchange settings already exist (e.g., Active Directory Users and Computers), scripting allows you quickly handle mailbox-enabling or moving thousands of users based on whatever business logic you require. Simple scripts can take the place of Exchange migration or management utilities that you would possibly otherwise need to purchase.
This chapter covers Exchange 2003. The concepts presented in this chapter will generally not work with Exchange 2007. Since there are still a very large number of Exchange 2003 deployments, we’ve elected to leave this chapter in the 4th Edition. covers the concepts discussed in this chapter with respect to Exchange 2007.
Managing Exchange is a little different from managing most other Microsoft applications. The computer where you run the tools or scripts must be a member of a domain in the forest where the Exchange organization resides; this is true whether you are using a script or the GUI. Also, Exchange doesn’t allow you to select other organizations to manage. This can be troublesome for someone managing multiple Exchange organizations, or a mobile worker who moves between sites or companies and likes to run her workstation in workgroup mode instead of being a member of any specific domain.
Permissions are very important and are often misunderstood in Exchange. Permissions can be set up very simply or in a very complicated way; it is tough to find a middle ground. The simplest method is to give Domain Admin access to your Exchange administrators. This is pretty standard in small companies where the Exchange administrators are doing all aspects of administration. But this practice is usually unacceptable in larger companies where separation of duties and more security is required. Please see the section on Exchange Delegation for more discussion and details on permissions.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Notes on Managing Exchange
Inhaltsvorschau
Managing Exchange is a little different from managing most other Microsoft applications. The computer where you run the tools or scripts must be a member of a domain in the forest where the Exchange organization resides; this is true whether you are using a script or the GUI. Also, Exchange doesn’t allow you to select other organizations to manage. This can be troublesome for someone managing multiple Exchange organizations, or a mobile worker who moves between sites or companies and likes to run her workstation in workgroup mode instead of being a member of any specific domain.
Permissions are very important and are often misunderstood in Exchange. Permissions can be set up very simply or in a very complicated way; it is tough to find a middle ground. The simplest method is to give Domain Admin access to your Exchange administrators. This is pretty standard in small companies where the Exchange administrators are doing all aspects of administration. But this practice is usually unacceptable in larger companies where separation of duties and more security is required. Please see the section on Exchange Delegation for more discussion and details on permissions.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Exchange Management Tools
Inhaltsvorschau
Most of the scripts in this chapter require that the Exchange Management Tools from the Exchange media are loaded. Specifically, many will need the Collaboration Data Objects for Exchange Management (CDOEXM) installed and registered, and that is only installed with the Exchange Management Tools. Although it is possible to load and register the specific DLLs involved, Microsoft does not support that configuration. Additionally, Microsoft does not support loading Outlook and the Exchange Management Tools on the same machine, though they generally interact just fine.
The primary issue that has been publicly reported when running Outlook and the Exchange Management Tools on the same machine is profile switching in Outlook when Exchange System Manager (ESM) is running. The solution is to simply close out Outlook and ESM, and then you can restart Outlook and choose the alternate profile. If you wish to relaunch ESM then, that will work fine as well.
For more details on the Microsoft guideline, see Microsoft Knowledge Base Article 266418 at http://support.microsoft.com/kb/266418/.
Installation of the tools for most Windows operating systems requires Internet Information Services (IIS), World Wide Web (WWW) service, Simple Mail Transport Protocol (SMTP) service, and the appropriate Admin Pack to be installed on the machine. Windows XP SP2 has eased this requirement to only needing IIS and the Windows Server 2003 Admin Pack. Once the tools are loaded, these requirements can be removed because they aren’t actually used. You install the tools by running <driveletter>:\setup\i386\setup.exe on the Exchange media; replace <driveletter>: with the drive letter of the CD-ROM drive. Once the installation starts, follow the prompts to the component selection screen. Select Custom, then select Install next to Microsoft Exchange System Management Tools. Finally, click Next and complete the remainder of the prompts. The Exchange Server 2003 Management Tools cannot be installed on Windows Vista or Windows Server 2008, but only on Windows XP and Windows Server 2000/2003.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Mail-Enabling Versus Mailbox-Enabling
Inhaltsvorschau
Exchange has two primary mechanisms for hooking users into the mail system. The first mechanism is called mailbox-enabling and associates a mailbox in the Exchange organization to a user. This is the normal setting for users in most organizations that allows them to log into the Exchange system with Outlook, Outlook Web Access (OWA), or other mail clients that can communicate through standard mail interfaces such as POP3 or IMAP.
The second mechanism is called mail-enabling; this connects one or more email addresses to the user that are external to the Exchange organization. This is used for someone who needs to log into the forest, but does not want a mailbox in the Exchange organization. For example, Dr. Amy Gramzow of the Acme Consulting Company could be on a long-term assignment at MyCorp, Inc. and have any email sent that is sent to her at DrAmy@MyCorp.com forwarded to her AGramzow@AcmeConsulting.com mailbox so that she doesn’t have to manage multiple mailboxes.
Mail-enabling is also used to make Exchange aware of contacts and groups. These objects can’t be authenticated, so creating a mailbox for them doesn’t make sense; they must be mail-enabled instead of mailbox-enabled. Contacts will almost always have an external email address associated with them; a group, on the other hand, will be used as a distribution list to forward messages on to multiple recipients, which could be internal to the organization or outside of it.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Exchange Delegation
Inhaltsvorschau
Exchange delegation is a delicate and complicated topic. It is discussed in this chapter with the scripts so that it is fresh in your mind and so that you understand the level of permissions required to do the tasks that are illustrated.
Most of the Exchange permissions are granted through access control lists (ACLs) on objects in Active Directory. These permissions in Active Directory can be delegated in a very granular way. Exchange consolidates the permissions into three main layers of delegation called roles:
  • Exchange View Only Administrator allows you to look at the Exchange System.
  • Exchange Administrator allows you to fully administer Exchange Server computer information.
  • Exchange Full Administrator allows you to fully administer Exchange.
Be aware that none of these Exchange Roles give you access rights on user objects themselves. You can be an Exchange Full Administrator and not be able to mailbox-enable a single user. For that, you need to determine what rights you want the Exchange Administrators to have on user objects and grant them separately.
Unfortunately, it is beyond the scope of this book to dig into all of the various ways to delegate rights to Active Directory objects. We will assume for the remainder of this chapter that any administrator who needs to make changes to a user or group, such as mail-enabling or mailbox-enabling a user, mail-enabling a distribution group, creating a contact, and so on, is a member of the Account Operators group with the additional permissions outlined in the next paragraph delegated in Active Directory.
By default, Account Operators have permissions to manage user objects, inetOrgPerson objects, and group objects. They do not have permissions to manage contacts or query-based distribution lists. In order for an Account Operator to be able to fully manage mail-specific contents of Active Directory, you must grant permissions separately to create, delete, and manage contacts (i.e., objects with an
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Mail-Enabling a User
Inhaltsvorschau
You can easily mail-enable a user with very little code using ADSI and CDOEXM. The following code shows you how to mail-enable a single user specified by a known DN:
' This code mail enables a user.

Option Explicit

Dim strUserDN, strEmailAddr, objUser

' ------ SCRIPT CONFIGURATION ------

strUserDN = "<UserDN>"   ' e.g. cn=DrAmy,cn=Users,dc=mycorp,dc=com

strEmailAddr = "<EmailAddress>"  'e.g. Agramzow@AcmeConsulting.com

' ------ END CONFIGURATION ---------

Set objUser = GetObject("LDAP://" & strUserDN)

objUser.MailEnable strEmailAddr

objUser.Put "internetEncoding",1310720

objUser.SetInfo()

WScript.Echo "Successfully mail-enabled user."
Mail-enabling a user requires Exchange Data Administrator .
This should all be familiar, with the exception of MailEnable. MailEnable is a method of the IMailRecipient CDOEXM interface. For a user, it takes a single argument: the email address to associate with the user. In the background, the specific changes made by the MailEnable method are on the user object in Active Directory and include changes to the following attributes:
  • targetAddress
  • mailNickname
  • mAPIRecipient
  • legacyExchangeDN
You are probably looking at that list of attributes and thinking, “Hey, I can just populate those attributes with LDAP calls; I don’t even need to use CDOEXM!” To be honest, that is almost true. It is only “almost” true for two reasons: first, depending on which knowledge base articles you read, you will find confusion on whether or not setting the LDAP attributes is supported by Microsoft or not. Second, you actually don’t need to set all of those attributes; the minimum attributes needed are mailNickname and targetAddress.
In addition to those attributes, the internetEncoding attribute should also be set for proper message handling. This is the attribute that is updated if you go into the Advanced tab of the Internet Address Properties screen in ADUC. The default value for this attribute is 1310720, which tells Exchange to use the default settings of the Internet Mail Service. You can specify other values to force email to be converted to various formats. contains the list of alternate values for the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Mail-Disabling a User
Inhaltsvorschau
Now that you have seen how to mail-enable a user, it is a good time to show a code sample illustrating mail-disabling a user:
' This code mail disables a user.

Option Explicit

Dim strUserDN, objUser

' ------ SCRIPT CONFIGURATION ------

strUserDN = "<UserDN>"   ' e.g. cn=DrAmy,cn=Users,dc=mycorp,dc=com

' ------ END CONFIGURATION ---------

Set objUser = GetObject("LDAP://" & strUserDN)

objUser.MailDisable

objUser.SetInfo()

WScript.Echo "Successfully mail-disabled user."
Mail-disabling a user requires Exchange Data Administrator .
Once again, this is a very simple script with one new method, the MailDisable method. This method is aptly named in that it mail-disables a user, and that is all it does. Unfortunately, you cannot use this method to mailbox-disable a user. So when you call this method, you should be sure that the user is mail-enabled versus mailbox-enabled. If you use this method on a mailbox-enabled user, you will get an error such as “E-mail addresses cannot be removed from this user because it has a mailbox.” The quick way to ascertain whether a user has a mailbox versus being simply mail-enabled is to check for the existence of the homeMDB attribute. If a user object has homeMDB populated, there is an associated mailbox for that account.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Creating and Mail-Enabling a Contact
Inhaltsvorschau
A contact in Exchange 2000 or above is similar to a custom recipient in Exchange 5.5. Contacts can be created in Active Directory like a user is created, and mail-enabling a contact is identical to mail-enabling a user. Because the users and groups chapter didn’t discuss creating a contact, it will be wrapped into the script here. You can shorten the following script down to just mail-enabling of an existing contact or by using the script shown in the previous section and substituting in the contact DN for the user DN:
' This code creates and then mail-enables a contact.

Option Explicit

Dim strOU, strContactCN, strEmailAddr, strDisplayName,

Dim objOU, objContact

' ------ SCRIPT CONFIGURATION ------

strOU = "<OU>" ' e.g. ou=Contacts,dc=mycorp,dc=com

strContactCN = "<ContactCN>" ' e.g. cn=DrAmy

strEmailAddr = "<EmailAddress>" 'e.g. Agramzow@AcmeConsulting.com

strDisplayName = "<Display Name>" 'e.g. Dr. Amy Gramzow

' ------ END CONFIGURATION ---------

' Create Contact

Set objOU = GetObject("LDAP://" & strOU)

Set objContact = objOU.Create("contact",strContactCN)

objContact.Put "displayName", strDisplayName

objContact.SetInfo

WScript.Echo "Successfully created contact."

' Mail-Enable Contact

objContact.MailEnable strEmailAddr

objContact.Put "internetEncoding", 1310720

objContact.SetInfo()

WScript.Echo "Successfully mail-enabled contact."
Mail-enabling a contact requires Exchange Data Administrator .
Creating a contact is very simple; there are no mandatory attributes, though a Display Name (displayName) is usually set so that the cn isn’t used for display in the Global Address List (GAL) when the contact is mail-enabled. You will note that the mail-enable process is exactly the same as it is done for user objects; simply specify the external email address as the parameter to the MailEnable method.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Mail-Disabling a Contact
Inhaltsvorschau
Mail-disabling a contact is exactly like mail-disabling a user:
' This code mail disables a contact.

Option Explicit

Dim strContactDN, objContact

' ------ SCRIPT CONFIGURATION ------

strContactDN = "<ContactDN>"   ' e.g. cn=DrAmy,ou=Contacts,dc=mycorp,dc=com

' ------ END CONFIGURATION ---------

set objContact = GetObject("LDAP://" & strContactDN)

objContact.MailDisable

objContact.SetInfo()

WScript.Echo "Successfully mail-disabled contact."
Mail-disabling a contact requires Exchange Data Administrator .
It was mentioned previously that you needed to know if the user was mail-enabled or mailbox-enabled. This is not the case with contacts because they cannot be mailbox-enabled; you can always use the MailDisable method for Exchange contacts.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Mail-Enabling a Group (Distribution List)
Inhaltsvorschau
A mail-enabled group is a group that is used as an Exchange Distribution List. You send email to the group’s email address, and all users and contacts in the group that are known to Exchange (either mail- or mailbox-enabled) will receive a copy of the :
' This code mail enables a group.

Option Explicit

Dim strGroupDN, objGroup

' ------ SCRIPT CONFIGURATION ------

strGroupDN = "<GroupDN>"   ' e.g. cn=MyDL,ou=Groups,dc=mycorp,dc=com

' ------ END CONFIGURATION ---------

Set objGroup = GetObject("LDAP://" & strGroupDN)

objGroup.MailEnable

objGroup.SetInfo()

WScript.Echo "Successfully mail-enabled group."
Mail-enabling a group requires Exchange Data Administrator .
You probably noticed that the email address wasn’t specified when the MailEnable method was called. The email address is automatically created based on the sAMAccountName of the group. Unfortunately, CDOEXM does not allow you to specify the address for the group. It is possible to modify the email address programmatically, but you will need to modify the multivalued attribute called proxyAddresses directly. This attribute controls the addresses available for a given mail object within the Exchange system.
The proxyAddresses attribute is a collection of addresses for a given mail object. Each value is of the form prefix:address—e.g., SMTP:DrAmy@MyCorp.com. The two prefixes you will always find are smtp and x400, which specify addresses for those mandatory protocols.
The prefix can be in all capital letters or all lowercase; if capitalized, it means that the address is the primary address for that protocol. For example, a prefix with an uppercase SMTP: means the address is the primary SMTP address. A prefix with a lowercase smtp: means the address is a secondary address. You must always have one and only one primary address per protocol. You can, however, add multiple secondary addresses.
One final note on proxyAddresses: the attribute values MUST be unique across the entire forest. Exchange queries for proxy addresses on a regular basis throughout the day, and duplicates can cause considerable confusion and several additional queries to resolve the confusion. The GUI tools will look for duplicates, but if you change these values programmatically, it is up to you to verify that the values are unique.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Mail-Disabling a Group
Inhaltsvorschau
Mail-disabling a group is exactly like mail-disabling a contact:
' This code mail disables a group.

Option Explicit

Dim strGroupDN, objGroup

' ------ SCRIPT CONFIGURATION ------

strGroupDN = "<GroupDN>"   ' e.g. cn=MyDL,ou=Groups,dc=mycorp,dc=com

' ------ END CONFIGURATION ---------

Set objGroup = GetObject("LDAP://" & strGroupDN)

objGroup.MailDisable

objGroup.SetInfo()

WScript.Echo "Successfully mail-disabled group."
Mail-disabling a group requires Exchange Data Administrator .
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Mailbox-Enabling a User
Inhaltsvorschau
You can easily mailbox-enable a user with very little code using ADSI and CDOEXM. The following code shows you how to mailbox-enable a single user specified by a known DN:
' This code creates a mailbox for a user.

Option Explicit

Dim strUserDN, strEmailAddr, objUser

' ------ SCRIPT CONFIGURATION ------

strUserDN = "<UserDN>"   ' e.g. cn=DrAmy,cn=Users,dc=mycorp,dc=com

strHomeMDB = "<Home MDB DN>"

' e.g. CN=Mailbox Store (SERVER),CN=First Storage Group,CN=InformationStore,

' CN=SERVER,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,

'      CN=MYCORP,CN=Microsoft Exchange,CN=Services,

'      CN=Configuration,DC=mycorp,DC=com"

' ------ END CONFIGURATION ---------

Set objUser = GetObject("LDAP://" & strUserDN)

objUser.CreateMailBox strHomeMDB

objUser.SetInfo()

WScript.Echo "Successfully mailbox-enabled user."
Mailbox-enabling a user requires Exchange Data Administrator .
That should all be familiar with the exception of CreateMailBox. CreateMailBox is a method of the IMailBoxStore CDOEXM interface. This method takes a single argument, the LDAP URL of the mail store object, to create the mailbox in. In the background, the specific changes made by the CreateMailBox method are on the user object in Active Directory and include changes to the following attributes:
  • mDBUseDefaults
  • msExchUserAccountControl
  • homeMTA
  • msExchHomeServerName
  • homeMDB
  • mailNickname
  • msExchMailboxGuid
  • msExchMailboxSecurityDescriptor
  • legacyExchangeDN
Once all of those attributes are in place, the Recipient Update Service (RUS) sets additional attributes on the user object. The mailbox cannot be used nor receive email until the RUS has gone through this stamping process.
As with mail-enabling a user, mailbox-enabling a user can be accomplished with just setting a few LDAP attributes. Also as before, depending on what knowledge base articles you read, you will find confusion on whether or not setting the LDAP attributes is supported or not by Microsoft. You actually don’t need to set all of those attributes; the minimum attributes needed are
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Mailbox-Disabling a User (Mailbox Deletion)
Inhaltsvorschau
Now that you have seen how to mailbox-enable a user, it seems a good time to show a code sample illustrating this concept:
' This code removes a user's mailbox.

Option Explicit

Dim strUserDN, objUser

' ------ SCRIPT CONFIGURATION ------

strUserDN = "<UserDN>"   ' e.g. cn=DrAmy,cn=Users,dc=mycorp,dc=com

' ------ END CONFIGURATION ---------

Set objUser = GetObject("LDAP://" & strUserDN)

objUser.DeleteMailBox 

objUser.SetInfo()

WScript.Echo "Successfully deleted user's mailbox."
Mailbox-disabling a user requires Exchange Data Administrator permissions.
Once again, this is a very simple script with one new method, the DeleteMailBox method. Unfortunately, you cannot use this method to mail-disable a user. So when you call this method, you should be sure that the user is mailbox-enabled versus mail-enabled. If you use this method on a mail-enabled user, you will get an error such as “This user does not have a mailbox.” The quick way to ascertain whether a user has a mailbox or is simply mail-enabled is to check for the existence of the homeMDB attribute. If a user object has homeMDB populated, there is an associated mailbox for that account.
The DeleteMailBox method is actually not well named because it doesn’t really delete the mailbox. In actuality, it disconnects the mailbox from the user. The mailbox, by default, will still exist in the exchange store for 30 days and can be reconnected to the same or any other user object that doesn’t have a mailbox associated with it. To actually delete the mailbox, you need to purge the mailbox.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Purging a Disconnected Mailbox
Inhaltsvorschau
In order to truly delete a mailbox out of the store, you must purge the mailbox. The following code shows how to purge a mailbox:
' This code purges a deleted mailbox.

Option Explicit

Dim strComputer, strMailbox, objWMI, objDiscMbx, objMbx

' ------ SCRIPT CONFIGURATION ------

strComputer = "<Exchange Server>" 'e.g. ExchServer2

strMailbox = "<Mailbox Alias>"    'e.g. DrAmy

' ------ END CONFIGURATION ---------

Set objWMI = GetObject("winmgmts:\\" & strComputer & _

                       "\root\MicrosoftExchangeV2")

Set objDiscMbx = objWMI.ExecQuery("Select * from Exchange_Mailbox WHERE " _

                              & "MailboxDisplayName='" & strMailbox & "'",,48)

For Each objMbx In objDiscMbx

  objMbx.Purge

Next

Wscript.Echo "Successfully purged mailbox."
Purging a mailbox requires Exchange Service Administrator .
This script doesn’t need CDOEXM; it actually does what it needs to do through Windows Management Instrumentation (WMI). is entirely devoted to WMI, so the documentation here will be sparse. Suffice to say, this script executes a query against the Exchange server using the WMI Exchange_Mailbox class, which is available in Exchange 2003 only, and asks for all mailboxes with the specified name. It then loops through the returned mailboxes and executes the Purge method against each, which effectively removes it from the store. After a purge, the mailbox can only be recovered by restoring from a backup. If there have been multiple mailboxes disconnected from the given user in the last 30 days, there will be multiple mailboxes to purge.
If you want to narrow down which specific mailboxes are being returned by the query, there are other attributes you can query against, such as DateDiscoveredAbsentInDS or LastLogonTime properties. See the Exchange_Mailbox class documentation in MSDN at http://msdn.microsoft.com/en-us/library/aa143732.aspx.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Reconnecting a Disconnected Mailbox
Inhaltsvorschau
After a mailbox has been disconnected, and prior to it being purged or exceeding its retention period, it can be reconnected to a user object that doesn’t currently have a mailbox associated with it. The following code shows how to reconnect a mailbox:
' This code reconnects a mailbox to a user.

Option Explicit

Dim strComputer, strUser, strMailbox, objWMI, objDiscMbx, objMbx

strComputer = "<Exchange Server>" ' e.g. ExchServer2

' ------ SCRIPT CONFIGURATION ------

strUser = "<Userid>"              ' e.g. DrAmy

strMailbox = "<Mailbox Alias>"    ' e.g. DrAmy

' ------ END CONFIGURATION ---------

 Set objWMI = GetObject("winmgmts:\\" & strComputer & _

                       "\root\MicrosoftExchangeV2")

Set objDiscMbx = objWMI.ExecQuery("Select * from Exchange_Mailbox WHERE " _

                           & "MailboxDisplayName='" & strMailbox & "'",,48)

For Each objMbx In objDiscMbx

  objMbx.Reconnect strUser

Next

WScript.Echo "Successfully reconnected mailbox."
Reconnecting a mailbox requires Exchange Service Administrator permissions, plus additional permissions on user objects. See the earlier section .”
This script is like the purge mailbox script and doesn’t need CDOEXM; it also does what it needs to do through Windows Management Instrumentation (WMI). This script executes a query against the Exchange server using the WMI Exchange_Mailbox class (which is available in Exchange 2003) and asks for all mailboxes with the specified name. It then loops through the returned mailboxes and executes the Reconnect method against the mailbox returned. Unfortunately, there are some rather serious flaws with the implementation of the Reconnect method, which severely limits its usability in some environments.
The first flaw is that the WMI Reconnect method must be run directly on the Exchange Server with the disconnected mailbox so that the script must run on the Exchange server. You can’t, for instance, have a script that runs from a workstation that will reconnect mailboxes on any of your Exchange servers.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Moving a Mailbox
Inhaltsvorschau
There are times when you want to move mailboxes from one Exchange server to another. The reason for the move may be for a migration from an older Exchange server to a new one (e.g., Exchange 5.5 to Exchange 2003) to better load balance mailboxes between Exchange Servers, or any number of other reasons. This is a very simple task to handle through a CDOEXM script. The following code shows how to move a :
' This code moves a mailbox.

Option Explicit

Dim strUserDN, strServer, strSGName, strMailStoreName, strSearch

Dim objSrv, strSg, strSGUrl, strMBUrl, objUser

' ------ SCRIPT CONFIGURATION ------

strUserDN  = "<UserDN>" ' e.g. cn=DrAmy,cn=Users,dc=mycorp,dc=com

strServer  = "<Exchange Server>"         ' e.g. ExchServer2

strSGName  = "<Storage Group Name>"      ' e.g. SG1

strMailStoreName = "<MailBox Store Name>" ' e.g. DB1

' ------ END CONFIGURATION ---------

' Find Storage Group URL and Generate Mailbox Store URL

strSearch = "cn=" & strSGName  & ","

Set objSrv = CreateObject("CDOEXM.ExchangeServer")

objSrv.DataSource.Open strServer

For Each strSg In objSrv.StorageGroups

   If InStr(1, strSg, strSearch, 1) > 0 Then

      strSGUrl = strSg

      Exit For

   End If

Next

strMBUrl = "LDAP://cn=" & strMailStoreName & "," & strSGUrl

' Attach to user and move mailbox

Set objUser = GetObject("LDAP://" & strUserDN)

objUser.MoveMailbox(strMBUrl)

WScript.Echo "Successfully moved mailbox."
Moving a mailbox requires Exchange Service Administrator permissions, plus additional permissions on user objects. See the earlier section .”
The main work of moving a mailbox is handled by the MoveMailBox method of the IMailBoxStore interface. The trickiest aspect is getting the argument you need to specify for the move, which is the Home MDB URL for the database you want to move the user to. Previously in the MailBox-Enable script, the absolute path of the Home MDB object was specified. The method used here allows you to specify three well-known components (server, storage group, store name), which can be used to determine the proper value.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Enumerating Disconnected Mailboxes
Inhaltsvorschau
If you want to know which disconnected mailboxes exist on an Exchange server, you can simply enumerate them. The following code shows how to enumerate disconnected mailboxes:
' This code enumerates disconnected mailboxes.

Option Explicit

Dim strComputer, objWMI, objDiscMbx, objMbx

' ------ SCRIPT CONFIGURATION ------

strComputer = "<Exchange Server>" 'e.g. ExchServer2

' ------ END CONFIGURATION ---------

Set objWMI = GetObject("winmgmts:\\" & strComputer & _

                       "\root\MicrosoftExchangeV2")

Set objDiscMbx = objWMI.ExecQuery("Select * from Exchange_Mailbox",,48)

For Each objMbx In objDiscMbx

  If (objMbx.DateDiscoveredAbsentInDS <> "") then

     WScript.Echo objMbx.MailBoxDisplayName & " " & _

                  objMbx.DateDiscoveredAbsentInDS

  End If

Next

WScript.Echo "Successfully enumerated disconnected mailboxes."
Although viewing mailbox details in the Exchange System Manager (ESM) requires only Exchange View-Only Administrator role access, in order to do this with a script, the WMI provider also requires local administrator permissions on the Exchange server.
Just like the Purge Mailbox and Reconnect Mailbox scripts, this script uses the WMI Exchange_Mailbox class to gather the requested information.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Viewing Mailbox Sizes and Message Counts
Inhaltsvorschau
A common task is to look at an Exchange server and determine the sizes and counts of messages on the server for all mailboxes. The following code shows how simple this is to do:
' This code enumerates mailbox sizes and message counts.

Option Explicit

Dim strComputer, objWMI, objMbxs, objMbx

' ------ SCRIPT CONFIGURATION ------

strComputer = "<Exchange Server>" 'e.g. ExchServer2

' ------ END CONFIGURATION ---------

 Set objWMI = GetObject("winmgmts:\\" & strComputer & _

                       "\root\MicrosoftExchangeV2")

Set objMbxs = objWMI.ExecQuery("Select * from Exchange_Mailbox",,48)

For Each objMbx In objMbxs

  WScript.Echo objMbx.MailBoxDisplayName & " " & objMbx.size & "KB  " _

               & objMbx.TotalItems & " items"

Next

WScript.Echo "Script completed successfully."
This script is very similar to the script to enumerate disconnected mailboxes. The same basic process is used; we have simply changed the initial query to select the record set to enumerate through. There are actually several properties that can be displayed this way. lists the properties and their descriptions.
Table : Exchange_Mailbox properties
Property
Description
LegacyDN
legacyDN of the mailbox. This matches the legacyExchangeDN attribute of the user object in Active Directory.
MailboxGUID
Indicates the globally unique identifier (GUID) that links the mailbox to a user in Active Directory. This value is also populated in the user’s Active Directory object as msExchMailboxGuid.
ServerName
Name of the server the mailbox resides on.
StorageGroupName
Indicates the name of the storage group that contains the mailbox.
StoreName
Indicates the name of the message database (MDB) that contains the mailbox.
AssocContentCount
Indicates the total number of messages associated with the mailbox folders.
Indicates when the store detected that the mailbox no longer had a corresponding user entry in Active Directory, i.e., when the mailbox was disconnected.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Viewing All Store Details of All Mailboxes on a Server
Inhaltsvorschau
The following code takes all of the properties from and displays them for all mailboxes on a specified server:
' This code enumerates all store details about all mailboxes

' on a single specified server

Option Explicit

Dim strComputer, objWMI, objMbxs, objMbx

' ------ SCRIPT CONFIGURATION ------

strComputer = "<Exchange Server>" 'e.g. ExchServer2

' ------ END CONFIGURATION ---------

Set objWMI = GetObject("winmgmts:\\" & strComputer & _

                       "\root\MicrosoftExchangeV2")

Set objMbxs = objWMI.ExecQuery("Select * from Exchange_Mailbox",,48)

For Each objMbx In objMbxs

  WScript.Echo "LegacyDN: " _

                      & objMbx.LegacyDN

  WScript.Echo "MailBoxGUID: " _

                      & objMbx.MailboxGUID

  WScript.Echo "ServerName: " _

                      & objMbx.ServerName

  WScript.Echo "StorageGroupName: " _

                      & objMbx.StorageGroupName

  WScript.Echo "StoreName: " _

                      & objMbx.StoreName

  WScript.Echo "AssocContentCount: " _

                      & objMbx.AssocContentCount

  WScript.Echo "DateDiscoveredAbsentInDS: " _

                      & objMbx.DateDiscoveredAbsentInDS

  WScript.Echo "DeletedMessageSizeExtended: " _

                      & objMbx.DeletedMessageSizeExtended

  WScript.Echo "LastLoggedOnUserAccount: " _

                      & objMbx.LastLoggedOnUserAccount

  WScript.Echo "LastLogoffTime: " _

                      & objMbx.LastLogoffTime

  WScript.Echo "LastLogonTime: " _

                      & objMbx.LastLogonTime

  WScript.Echo "Size: " _

                      & objMbx.Size

  WScript.Echo "StorageLimitInfo: " _

                      & objMbx.StorageLimitInfo

  WScript.Echo "TotalItems: " _

                      & objMbx.TotalItems

  WScript.Echo ""

  WScript.Echo ""

Next

WScript.Echo "Script completed successfully."
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Dumping All Store Details of All Mailboxes on All Servers in Exchange Org
Inhaltsvorschau
The following code takes the preceding script and extends it by extracting all information from all Exchange servers and dumping it to a text file in semicolon delimited format:
'This script dumps all store details of all mailboxes in an

'Exchange ORG to a text file in semi-colon delimited format

Option Explicit

Dim objConn, objComm, objRS

Dim strBase, strFilter, strAttrs, strScope

Dim fso, outfile

Dim strComputer, objWMI, objMbx, objMbxs

' ------ SCRIPT CONFIGURATION ------

strConfigDN = "<Config NC DN>" 'e.g. cn=configuration,dc=mycorp,dc=com

' ------ END CONFIGURATION ---------



'Set the ADO search criteria

strBase   = "<LDAP:// " & strConfigDN & ">;"

strFilter = "(objectcategory=msExchExchangeServer);"

strAttrs  = "name;"

strScope  = "Subtree"

set objConn = CreateObject("ADODB.Connection")

objConn.Provider = "ADsDSOObject"

objConn.Open



'Need to enable Paging in case there are more than 1000 objects returned

Set objComm = CreateObject("ADODB.Command")

Set objComm.ActiveConnection = objConn

objComm.CommandText = strBase & strFilter & strAttrs & strScope

objComm.Properties("Page Size") = 1000

Set objRS = objComm.Execute()



'Create a VBScript file object and use it to open a text file. The

'second parameter specifies to overwrite any existing file that exists.

Set fso = CreateObject("Scripting.FileSystemObject")

Set outfile = fso.CreateTextFile("c:\out.txt", TRUE)



'Write header line to file

outfile.WriteLine "LegacyDN;" _

                  & "MailBoxGUID;" _

                  & "ServerName;" _

                  & "StorageGroupName;" _

                  & "StoreName;" _

                  & "AssocContentCount;" _

                  & "DateDiscoveredAbsentInDS;" _

                  & "DeletedMessageSizeExtended;" _

                  & "LastLoggedOnUserAccount;" _

                  & "LastLogoffTime;" _

                  & "LastLogonTime;" _

                  & "Size;" _

                  & "StorageLimitInfo;" _

                  & "TotalItems"



'Loop through all servers and dump all store info for all mailboxes

While Not objRS.EOF

  strComputer = objRS.Fields.Item("name").Value

  Set objWMI = GetObject("winmgmts:\\" & strComputer & _

                       "\root\MicrosoftExchangeV2")

  Set objMbxs = objWMI.ExecQuery("Select * from Exchange_Mailbox",,48)

  For Each objMbx In objMbxs

    outfile.Write objMbx.LegacyDN

    outfile.Write ";" & objMbx.MailboxGUID

    outfile.Write ";" & objMbx.ServerName

    outfile.Write ";" & objMbx.StorageGroupName

    outfile.Write ";" & objMbx.StoreName

    outfile.Write ";" & objMbx.AssocContentCount

    outfile.Write ";" & objMbx.DateDiscoveredAbsentInDS

    outfile.Write ";" & objMbx.DeletedMessageSizeExtended

    outfile.Write ";" & objMbx.LastLoggedOnUserAccount

    outfile.Write ";" & objMbx.LastLogoffTime

    outfile.Write ";" & objMbx.LastLogonTime

    outfile.Write ";" & objMbx.Size

    outfile.Write ";" & objMbx.StorageLimitInfo

    outfile.WriteLine ";" & objMbx.TotalItems

  Next

  objRS.MoveNext

Wend

outfile.Close
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter, we had a basic discussion of some basic concepts of Exchange, such as mail- and mailbox-enabling Active Directory objects and delegation of Exchange permissions. Next, we looked at the mechanisms available to manipulate various Exchange properties of user, contact, and group objects in Active Directory via script interfaces. Then we used these mechanisms to mail- and mailbox-enable various objects, as well as several other admin tasks commonly handled through the Active Directory Users and Computers and Exchange System Manager Tools. Finally, we presented a script to gather all information available from the mailbox store through the IMailBoxStore interface for all mailboxes on all Exchange servers and dumped that information to a file in a semicolon delimited format. This script illustrated how you can take simple concepts and build them up to generate a great deal of useful information about your environment. That simple dump could be used to analyze mailbox use in your organization or be used to track mailbox growth and trending information.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Chapter 33: Scripting Basic Exchange 2007 Tasks
Inhaltsvorschau
This chapter is about providing a brief jumpstart to managing Exchange 2007 recipients with PowerShell. While you can accomplish nearly all of the tasks in this chapter with the Exchange Management Console (EMC), managing large numbers of objects with the GUI never scales. In order to efficiently work with large scale environments, it’s typically necessary to use scripts instead.
In this chapter we’ll cover managing users, groups, and contacts, and end with a couple of larger scripts that bring together the skills taught in this chapter. If you’re not familiar with PowerShell, take a few minutes to read for an introduction to PowerShell, and provides an introduction to managing Active Directory objects with PowerShell.
In order to manage Exchange 2007 servers from your workstation, you’ll need to have a couple of additional components installed. The first prerequisite is PowerShell. For more information about installing PowerShell, reference . The second prerequisite is the Exchange management tools. While Exchange 2007 will only run on 64-bit hardware, the management tools can run on 32-bit or 64-bit hardware. You can download the 32-bit management tools from http://www.microsoft.com/downloads/details.aspx?FamilyID=6be38633-7248-4532-929b-76e9c677e802.
Unlike Exchange 2003 and earlier, Exchange 2007 is entirely supported to run the Exchange management tools on a machine that is also running Microsoft Outlook. The conflicts that precluded doing this safely in earlier versions are no longer an issue with Exchange 2007.
Once you’ve loaded the Exchange management tools, it is important to make sure you use the Exchange Management Shell shortcut on your Start menu in order to launch PowerShell. If you use the generic PowerShell shortcut, you will receive an error when you try to run Exchange cmdlets. If you have launched the correct shortcut, your window should look similar to .
Figure : Exchange Management Shell
Under Exchange 2000 and Exchange 2003, enabling an Active Directory object for Exchange was effectively a two step process. The first step was to set a few key attributes on the object (or use CDOEXM which did that for you), and the second step was to wait for the Exchange Recipient Update Service (RUS) to notice the changes to this object and finish enabling it. This asynchronous process caused many headaches for administrators over the years, and in Exchange 2007 the RUS has been eliminated.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Exchange Scripting Notes
Inhaltsvorschau
In order to manage Exchange 2007 servers from your workstation, you’ll need to have a couple of additional components installed. The first prerequisite is PowerShell. For more information about installing PowerShell, reference . The second prerequisite is the Exchange management tools. While Exchange 2007 will only run on 64-bit hardware, the management tools can run on 32-bit or 64-bit hardware. You can download the 32-bit management tools from http://www.microsoft.com/downloads/details.aspx?FamilyID=6be38633-7248-4532-929b-76e9c677e802.
Unlike Exchange 2003 and earlier, Exchange 2007 is entirely supported to run the Exchange management tools on a machine that is also running Microsoft Outlook. The conflicts that precluded doing this safely in earlier versions are no longer an issue with Exchange 2007.
Once you’ve loaded the Exchange management tools, it is important to make sure you use the Exchange Management Shell shortcut on your Start menu in order to launch PowerShell. If you use the generic PowerShell shortcut, you will receive an error when you try to run Exchange cmdlets. If you have launched the correct shortcut, your window should look similar to .
Figure : Exchange Management Shell
Under Exchange 2000 and Exchange 2003, enabling an Active Directory object for Exchange was effectively a two step process. The first step was to set a few key attributes on the object (or use CDOEXM which did that for you), and the second step was to wait for the Exchange Recipient Update Service (RUS) to notice the changes to this object and finish enabling it. This asynchronous process caused many headaches for administrators over the years, and in Exchange 2007 the RUS has been eliminated.
Under Exchange 2007, the process for enabling an object is completely synchronous. When Exchange cmdlets are called to enable the object, all of the changes are made on the spot and the object is immediately ready to receive email (assuming the necessary changes have replicated throughout your Active Directory).
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Managing Users
Inhaltsvorschau
There are four tasks that we’ll explore in this section:
  • Mailbox- and mail-enabling users
  • Mailbox- and mail-disabling users
  • Displaying Exchange specific properties
  • Moving user mailboxes
Throughout the examples in this section, we will assume that you are working with an existing user object in Active Directory. Where appropriate, we will make a note of the cmdlet you should substitute to create the user in the same transaction.
In order to mailbox enable a user, you will need to call Enable-Mailbox and specify, at a minimum, the user object to enable (-Identity) and a target mailbox database (-TargetDatabase). In this example, we mailbox-enable user bdesmond (we’ve specified the identity as domain\username) and create the mailbox on server K8DEVXMB01 in mailbox database MB01SG01MS01:
[PS]    C:\>Enable-Mailbox   -Identity      "k8dev01\bdesmond" `

-Database "K8DEVXMB01\MB01SG01MS01"

   Name           Alias        ServerName   ProhibitSendQuota

   ----           -----        ----------   -----------------

   Brian Desmond  bdesmond     k8devxmb01   unlimited
As soon as Enable-Mailbox completes, the user’s mailbox will be ready for use. For a complete description of how to use this cmdlet, visit http://technet.microsoft.com/en-us/library/aa998251(EXCHG.80).aspx.
If you need to create the Active Directory user in the same transaction, use the New-Mailbox cmdlet instead.
In order to mailbox-enable a user, you will need to call Disable-Mailbox and specify at a minimum the user object to enable (-Identity). In this example, we will disable the mailbox for user bdesmond in domain k8dev01:
[PS] C:\>Disable-Mailbox -Identity "k8dev01\bdesmond"
If you don’t want to be prompted, you can attach the -confirm .
As soon as the Disable-Mailbox cmdlet completes, the mailbox will be marked as disconnected in the Exchange Mailbox Database. For a complete description of the usage for this cmdlet, visit http://technet.microsoft.com/en-us/library/aa997210(EXCHG.80).aspx.
If you use the Remove-Mailbox
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Managing Groups
Inhaltsvorschau
There are three tasks that we’ll explore in this section:
  • Mail-enabling and mail-disabling groups
  • Displaying Exchange specific properties
Throughout the examples in this section, we will assume that you are working with an existing group object in Active Directory. Where appropriate, we will make a note of the cmdlet you should substitute to create the group in the same transaction.
In order to mail-enable a group, you’ll need to call the Enable-DistributionGroup cmdlet and specify the group to mail-enable (-Identity). In this case we specify the complete distinguished name of the group:
[PS]    C:\>Enable-DistributionGroup    -Identity     `

"CN=Cool People,OU=Groups,DC=k8dev01,dc=brianlab,dc=local"

   Name            DisplayName      GroupType         PrimarySmtpAddress

   ----            -----------      ---------         ------------------

   Cool People     Cool People      Universal         CoolPeople@k8dev...
As soon as Enable-DistributionGroup completes, the distribution group will be ready for use. For a complete description of the usage for this cmdlet, visit http://technet.microsoft.com/en-us/library/aa998916(EXCHG.80).aspx.
If you need to create the Active Directory group in the same transaction, use the New-DistributionGroup cmdlet instead.
To create a dynamic distribution group, use New-DynamicDistributionGroup.
In order to disable an existing mail-enabled group, you will need to call the Disable-DistributionGroup cmdlet and specify at a minimum the group object to disable (-Identity):
[PS]   C:\>Disable-DistributionGroup   -Identity    `

"CN=CoolPeople,OU=Groups,DC=k8dev01,dc=brianlab,dc=local"
If you don’t want to be prompted, you can attach the -confirm .
For more information about the Disable-DistributionGroup cmdlet, visit http://technet.microsoft.com/en-us/library/aa997942(EXCHG.80).aspx.
If you use the Remove-DistributionGroup cmdlet, the group object in Active Directory will be deleted!
If you need to remove a dynamic distribution group, use the Remove-DynamicDistributionGroup
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
Summary
Inhaltsvorschau
In this chapter we took a look at a number of PowerShell commands that can be used for managing users and groups under Exchange 2007. We also looked at some handy tricks for leveraging the PowerShell pipeline capabilities to work with batches of objects. Exchange 2007 brings a different process for provisioning objects—there is no more Recipient Update Service (RUS). Thus, we took a brief look at a couple of strategies for working around this new behavior when you are using an identity management system to provision users and other objects to your Active Directory.
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
	

Zurück zu Active Directory


Themen

Buchreihen

Special Interest

International Sites

O'Reilly China O'Reilly USA O'Reilly Japan O'Reilly Taiwan