JETZT ONLINE BESTELLEN
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
- InhaltsvorschauActive 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
- InhaltsvorschauNetwork 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
- InhaltsvorschauAs 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 NTActive DirectorySingle-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
- InhaltsvorschauAlthough 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
- InhaltsvorschauThe 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 FeatureDescriptionDirectory service backupSpecial messages logged to the Directory Service event log if directory partitions are not backed up.Additional replication security and fewer replicationReplication 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 DNSNew 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 toolsNewer 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
- InhaltsvorschauWindows 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 FeatureDescriptionRead-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 supportDomain controllers can now run on a version of the Windows Server 2008 operating system that is substantially lighter and thus more secure.Fine-grained passwordPassword policies can now be defined on a per user or group basis.Administrative roleUsers who are not domain administrators can be securely delegated administrative control of RODCs without providing access to Active Directory.Read-only DNSRODCs can host dynamic DNS zones and refer the updates to writeable domain controllers.GlobalNames DNS zoneA 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
- InhaltsvorschauThis 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
- InhaltsvorschauThis 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 objectsThe 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
- InhaltsvorschauData 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 objectsThe 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
- InhaltsvorschauNow 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
- InhaltsvorschauIn 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
- InhaltsvorschauDue 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
- InhaltsvorschauEach 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 Descriptioncn=BuiltinContainer for predefined built-in local security groups. Examples include Administrators, Domain Users, and Account Operators.cn=ComputersDefault 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 ControllersDefault organizational unit for computer objects representing domain controllers.cn=ForeignSecurityPrincipalsContainer for placeholder objects representing members of groups in the domain that are from a domain external to the forest.cn=LostandFoundContainer 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 QuotasContainer 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
- InhaltsvorschauThe 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 Descriptioncn=DisplaySpecifiersContainer that holds display specifier objects, which define various display formats for the Active Directory MMC Snap-ins.cn=Extended-RightsContainer for extended rights (controlAccessRight) objects.cn=ForestUpdatesContains objects that are used to represent the state of forest and domain functional level changes. This container is new in Windows Server 2003.cn=LostandFoundConfigContainer for orphaned objects.cn=NTDS QuotasContainer 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=PartitionsContains objects for each naming context, application partition, and external LDAP directory reference.cn=Physical LocationsContains location objects (physicalLocation), which can be associated with other objects to denote location of the object.cn=ServicesStore of configuration information about services such as FRS, Exchange, and Active Directory itself.cn=SitesContains all of the site topology and replication objects. This includessite,subnet,siteLink,server, andnTDSConnectionobjects, to name a few.Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Schema Naming Context
- InhaltsvorschauThe 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 contextsYou 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 hasclassSchema,attributeSchema, andsubSchemaobjects. TheclassSchemaobjects define the different types of classes and their associated attributes. TheattributeSchemaobjects define all the attributes that are used as part ofclassSchemadefinitions. There is also a singlesubSchemainstance that represents the abstract schema as defined in the LDAPv3 RFC (http://www.ietf.org/rfc/rfc2254.txtEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Application Partitions
- InhaltsvorschauApplication 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, andcomputerobjects. 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
- InhaltsvorschauIn 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
- InhaltsvorschauThe 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 versionRelease13Windows 200030Windows Server 200331Windows Server 2003 R244Windows Server 2008The Schema Container is located in Active Directory under the Configuration Container. For example, the distinguished name of the Schema Container in theEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Structure of the Schema
- InhaltsvorschauThe 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 asclassSchema(Class-Schema) andattributeSchema(Attribute-Schema) objects. The two distinct forms of the same names result from the fact that thecn(Common-Name) attribute of a class contains the hyphenated easy-to-read name of the class, and thelDAPDisplayName(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, thelDAPDisplayNameattribute 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 likeuser, as well as the more unusualsAMAccountNameandlDAPDisplayName. 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 aclassSchemaobject, 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 theEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Attributes (attributeSchema Objects)
- InhaltsvorschauJust as class information is stored in Active Directory as instances of the class called
classSchema, attributes are represented by instances of the class calledattributeSchema. As with all objects, theattributeSchemaclass has a number of attributes that can be set when specifying a new instance. TheattributeSchemaclass inherits attributes from the class calledtop. However, most of thetopattributes are not relevant here. All of the attributes of theattributeSchemaclass are documented in the Platforms SDK at http://msdn2.microsoft.com/en-us/library/ms680969(VS.85).aspx.TheuserPrincipalName(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 theuserPrincipalNameattributeSchema instance.Table : userPrincipalName’s attributes Attribute lDAPDisplayNameEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Attribute Properties
- InhaltsvorschauThere 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-inThe 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 SyntaxOIDDescriptionAddress2.5.5.13127Used internally by the system.Boolean2.5.5.81True or false.Case-insensitive string2.5.5.420A string that does not differentiate between uppercase and .Case-sensitive string2.5.5.327A string that differentiates between uppercase andDistinguished name2.5.5.1127The Fully Qualified Domain Name (FQDN) of an object in Active Directory.DN-Binary2.5.5.7127Octet 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)
- InhaltsvorschauSchema classes are defined as instances of the
classSchemaclass. A complete listing of the attributes on theclassSchemaclass 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 existinguserclass 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 aMarketing-Userclass, 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 originaluserclass individually, all we need to do is specify that the new classes inherit from theuserclass by setting thesubClassOfattribute touser. When we do this, both of the new classes inherit every single attribute that theuserclass 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 subclassesYou 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
- InhaltsvorschauIn 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
attributeSchemaobjects, using theuserPrincipalNameattribute as an example. We showed how attributes are added to classes by detailing how classes are stored in the schema as instances ofclassSchemaobjects. 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
- InhaltsvorschauThis 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
- InhaltsvorschauThe 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
- InhaltsvorschauMicrosoft 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” discussionReplication 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
- InhaltsvorschauWe 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
- InhaltsvorschauOne 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
- InhaltsvorschauDNS 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
- InhaltsvorschauOne 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:
- A client previously located in Site A is moved to Site B.
- 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.
- 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.
- The client will then perform a DNS lookup to find all DCs that service Site B.
- The client then contacts a DC servicing Site B. Three things can happen at this point:
- The DC servicing Site B can respond and authenticate the client.
- 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.
- 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
- InhaltsvorschauWhen 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
- InhaltsvorschauNow 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
- InhaltsvorschauIf 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-inEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Using Application Partitions for DNS
- InhaltsvorschauApplication 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 nameReplication scopecn=System,DomainDNExample: cn=System,dc=amer,dc=mycorp,dc=comTo all domain controllers in the domain. This is the only storage method available under Windows 2000.dc=DomainDnsZones, DomainDNExample: dc=DomainDnsZones,dc=amer, dc=mycorp,dc=comTo domain controllers in the domain that are also DNS servers.dc=ForestDnsZones, ForestDNExample: dc=ForestDnsZones,dc=mycorp,dc=comEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Aging and Scavenging
- InhaltsvorschauOne 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:
- 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
- InhaltsvorschauActive 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
- InhaltsvorschauOne 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 replicationGenerally 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
- InhaltsvorschauThere 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 topologyIn 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 thereplicateSingleObjectoperational attribute of theRootDSELDAP 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
- InhaltsvorschauAs 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 themsDS-RevealOnDemandGroupattribute by default, and the denied group is added to themsDS-NeverRevealGroupattribute 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
- InhaltsvorschauSo 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-KrbTgtLinkattribute on an RODC’s computer account, or themsDS-krbTgtLinkBLattribute 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 topologyLet’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:- 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
- InhaltsvorschauRODCs 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
- InhaltsvorschauAs 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:
- The RODC forwards the request to a Windows Server 2008 writeable domain controller.
- 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.
- 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
- InhaltsvorschauLike 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
RODCModeregistry value to1. TheRODCModeregistry value is a REG_DWORD located atHKLM\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
- InhaltsvorschauWhen 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
trustedDomainis created in Active Directory to represent that trust. ThetrustedDomainobject 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
- InhaltsvorschauOne 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
- InhaltsvorschauOne 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 theEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Summary
- InhaltsvorschauThis 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
- InhaltsvorschauGroup 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
- InhaltsvorschauGPOs 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
- InhaltsvorschauThe 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
- InhaltsvorschauThe 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
- InhaltsvorschauIf, 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 selectionTo 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
- InhaltsvorschauOne 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
- InhaltsvorschauUndoubtedly, 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
- InhaltsvorschauFine-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
- InhaltsvorschauNearly 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-PasswordSettingsschema class that was added with the Windows Server 2008 schema extensions. These attributes are outlined in .Table : Mandatory Password Setting Object attributes AttributeDescriptioncnThe name of the PSOmsDS-PasswordSettingsPrecedenceThe order of precedence of the PSO in the event multiple PSOs apply to a usermsDS-PasswordReversibleEncryptionEnabledToggles storing the password with reversible encryptionmsDS-PasswordHistoryLengthThe number of previous passwords stored in Active DirectorymsDS-PasswordComplexityEnabledToggles password complexity checkingmsDS-MinimumPasswordLengthThe minimum length of the passwordmsDS-MinimumPasswordAgeThe minimum interval before the password can be resetmsDS-MaximumPasswordAgeThe maximum age of the password before it must be resetmsDS-LockoutThresholdThe number of failed login attempts necessary to trigger a lockoutmsDS-LockoutDurationThe number of minutes to lock the account outmsDS-LockoutObservationWindowThe time window during which the lockout threshold isWhen 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
- InhaltsvorschauNow 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 ObjectsOne 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/forrealswitch 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/quickstartoption.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 SettingValueADSI Edit formatted valueNameCustomPSO1CustomPSO1Precedence1111Reversible Encryption EnabledNoFALSEPassword History Length10 passwords10Password Complexity EnabledYesTRUEMinimum Password Length8 characters8Minimum Password Age1 day1:00:00:00Maximum Password Age90 days90:00:00:00Account Lockout Threshold15 failed logons15Account Lockout Window30 minutes00:00:30:00Account Lockout Observation Window30 minutes00:00:30:00Creating 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
- InhaltsvorschauAs 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
- InhaltsvorschauOne 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
- InhaltsvorschauFine-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
- InhaltsvorschauThe 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
- InhaltsvorschauActive 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 PetroCorpHere 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
- InhaltsvorschauBefore 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 GPOsEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Overview of the Design Process
- InhaltsvorschauThe 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
- InhaltsvorschauThe 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
- InhaltsvorschauHaving 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
- InhaltsvorschauIn 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
- InhaltsvorschauHaving 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
- InhaltsvorschauIt’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
- InhaltsvorschauIn this chapter, we presented seven steps toward effective namespace design:
- Decide on the number of domains.
- Design and name the tree structure.
- Design the workstation- and server-naming scheme.
- Design the hierarchy of Organizational Units.
- Design the users and groups.
- Design the Global Catalog.
- 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
- InhaltsvorschauAs 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
- InhaltsvorschauTwo 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
- InhaltsvorschauThere 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
- InhaltsvorschauHaving 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
- InhaltsvorschauMicrosoft 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
- InhaltsvorschauBased 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
- InhaltsvorschauThis 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
- InhaltsvorschauIn , 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
- InhaltsvorschauOne 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
- InhaltsvorschauPermissions 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
- Inhaltsvorschaushows the basics. Each object stores a value called a Security Descriptor, or SD, in the
nTSecurityDescriptorattribute. 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 architectureThe 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
schemaIDGUIDfor the attribute or object class that the ACE applies to. Alternatively, therightsGuidfor the property set, validated write, or extended right that the ACE applies to such as thememberattribute,Personal Informationproperty set,Change Passwordextended right, oruserobjects. For delete or create child objects permissions, theobjectTypeshould be configured to the
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Using the GUI to Examine Permissions
- InhaltsvorschauTo 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
- InhaltsvorschauExamining 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 entriesshows 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
- InhaltsvorschauHaving 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:
- Whenever possible, assign object permissions to groups of users rather than individual users.
- Design group permissions so that you have a minimum of duplication.
- Manage permissions globally whenever possible.
- Allow inheritance: do not protect sections of the tree from inheritance.
- 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 objectRule 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
- InhaltsvorschauDesigning 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
- InhaltsvorschauIt 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
pagerandmobileproperties 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 thePre-Windows 2000 Compatible Accessgroup. 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
- InhaltsvorschauSecurity 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
- InhaltsvorschauFor 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
- InhaltsvorschauIf 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
- InhaltsvorschauBefore 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
physicalDeliveryOfficeNameattribute of the user object? What about thetelephonePagerattribute? 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 calledEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Creating Schema Extensions
- InhaltsvorschauThere 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, typemmc.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
- InhaltsvorschauCarefully 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
- InhaltsvorschauA 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
- InhaltsvorschauBacking 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
- InhaltsvorschauOne 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
- InhaltsvorschauNo 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
- InhaltsvorschauOne 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
dsamaincommand-line utility and browse it like the live Active Directory database usingldpor 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 thentdsutilcommand-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 thedsamainutility 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
- InhaltsvorschauThe 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:domainnameWhen 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
- InhaltsvorschauWindows 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 ValueDescription0You 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
- InhaltsvorschauUsing 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
bcdeditcommand-line utility to reconfigure the domain controller’s boot settings. This is a three step process: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}.bcdedit /set {49fa7976-5065-11dd-ae21-000c291a8e6c}
Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Summary
- InhaltsvorschauIn 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
- InhaltsvorschauThe 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
- InhaltsvorschauWhile 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
- InhaltsvorschauEven 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
linkTrackOMTEntryobjects 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
- InhaltsvorschauNow 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 calledEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.
- Preparing for ADPrep
- InhaltsvorschauBefore 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
ADPreputility.If you’ve installed Exchange 2000 or newer into your Active Directory forest, you are undoubtedly familiar with the Exchangesetup.exe /forestprepand/domainprepswitches. 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/forestprepcommand extends the schema and adds some objects in the Configuration Naming Context. The Exchange/domainprepcommand adds objects within the Domain Naming Context of the domain it is being run on and sets some ACLs. TheADPrepcommand 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 runningADPrep. 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.TheADPrepcommand can be found in the \i386 directory on the Windows Server 2003 CD. TheADPrepcommand 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 theEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Upgrade Process
- InhaltsvorschauThe 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 youradprepprocess, fully read and understand Microsoft Knowledge Base Article 555040 at http://support.microsoft.com/kb/555040. It details all of the known issues with theadprepprocess. Also review KB article 309628 at http://support.microsoft.com/kb/309628, which details the operationsadprepperforms.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
- InhaltsvorschauAfter 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 /showrepsandrepadmin /replsumand 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
- InhaltsvorschauIn 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
aDPrepprocess 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
- InhaltsvorschauWindows 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
ADPrepto 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 theADPreputility, which is like theADPreputility needed to upgrade Windows 2000 forests to Windows Server 2003 forests.ADPrepprimes 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 evenEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - New Active Directory Features in Windows Server 2003 Service Pack 1
- InhaltsvorschauOn 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
- InhaltsvorschauAs 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
- InhaltsvorschauWindows 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
- InhaltsvorschauBefore 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
ADPreputility. If you’ve upgraded from Windows 2000 to Windows Server 2003 AD, you are undoubtedly familiar with theadprep.exe/forestprepswitch. 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 runadprep.exe/domainpreporadprep.exe/domainprep /gpprepfor 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 runadprep.exe/domainprepandadprep.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.TheADPrepcommand can be found in the \CMPNENTS\R2\ADPREP directory on Windows Server 2003 R2 disk 2. TheADPrepcommand 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
- InhaltsvorschauThe 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
- InhaltsvorschauThe 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
- InhaltsvorschauIn 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
- InhaltsvorschauThe 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
- InhaltsvorschauWhile 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
- InhaltsvorschauEven 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
- InhaltsvorschauBefore 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
ADPreputility. If you’ve upgraded from Windows 2000 to Windows Server 2003 AD, you are undoubtedly familiar with theadprep.exe/forestprepswitch. 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 runadprep.exe/domainprepin 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 runadprep.exe/domainprep /gpprepin 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 runadprep/rodcpreponce per forest.TheADPrepcommand can be found in the \SOURCES\ADPREP directory on Windows Server 2008 DVD. TheADPrepcommand 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 theADPrepcommand by looking at the log files in the %SystemRoot%\system32\debug\adprep\logs directory. Each timeADPrepis executed, a new folder with the current date is generated that contains files with information concerning the actions taken during that particular invocation ofADPrep. The folders are named based on the time and dateEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Windows Server 2008 Upgrade Process
- InhaltsvorschauAs 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
- InhaltsvorschauIn 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
aDPrepprocess 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
- InhaltsvorschauMicrosoft 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
- InhaltsvorschauHere 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
- InhaltsvorschauBefore 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
/forestprepand/domainprepthat 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
- InhaltsvorschauIn 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 wizardshows 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
- InhaltsvorschauThe 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)
- InhaltsvorschauShortly 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
- InhaltsvorschauThere 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-BindableObjectlisted as a static auxiliary class in the schema definition for theobjectClass. The most common bindable object is theuserclass. Objects of this type are authenticated by ADAM directly. - Bindable proxy object
- An object instantiated from an objectClass that has
msDS-BindProxylisted as a static auxiliary class in the schema definition for the objectClass. The most common Bindable proxy object is theuserProxyclass. 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
- InhaltsvorschauADAM 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
- InhaltsvorschauThere 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
useranduserProxyobjects 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 themsDS-Other-Settingsattribute of the Directory Service object to enable this new capability.Password change requests to bindable proxy objects (such asuserProxy) 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
- InhaltsvorschauWindows 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
- InhaltsvorschauA 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 QuestionDescriptionExampleUnique 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 instanceInstance 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.AddressBookLDAP port number? ()The TCP port you should listen on for standard LDAP requests.389SSL port number? ()The TCP port you should listen on for SSL-based Secure LDAP (LDAPS) requests.636Create 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
- InhaltsvorschauADAM 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 FilenameNewDescriptionADAM-adsiedit.mscYesView/modify AD and ADAM objects.ADAM-schmmgmt.dllYesView/Modify ADAM schema objects. This tool will only work on ADAM not AD.adaminstall.exeYesADAM instance installer.adamsync.exeYesSynchronize data from Active Directory to ADAM.adamuninstall.exeYesADAM instance remover.ADSchemaAnalyzer.exeYesSchema comparison to assist with schema differencing/synchronization. Works with AD and ADAM.csvde.exeNoCSV directory object import/export. Works with AD and ADAM.dsacls.exeNoView/Modify AD and ADAM object ACLs.dsdbutil.exeYesADAM instance database management tool.dsdiag.exeYesDirectory diagnosis to assist in directory troubleshooting. Compare with Active Directory DCDiag tool.dsmgmt.exeYesADAM instance configuration management tool.ldifde.exeNoLDIF directory object import/export. Works with AD and ADAM.ldp.exeNoGUI LDAP query tool. Works with AD and ADAM. Great new ACL editor.repadmin.exeNoAD 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 thedefaultSDattribute 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 theirEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - ADAM Schema
- InhaltsvorschauAs 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
MaxTempTableSizesetting of theDefault 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
- InhaltsvorschauNow 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
ADMODandADFINDfreeware 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 acontainer,domainDNS,organizationalUnit,c,o, or even auser, you can easily set it up. You only have to specify three pieces of data to create an application partition: the distinguished name (DN), theobjectClass, andinstanceType. TheinstanceTypeattribute must always be 5, so that just leaves you with two attributes you have to figure out: the DN andobjectClass.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. TheEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Summary
- InhaltsvorschauADAM 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
- InhaltsvorschauThis 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?
- InhaltsvorschauFirst, 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
- InhaltsvorschauBefore 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
AddandRemovemethods, so that members could be added or removed from a group. Methods are normally represented asInterface::MethodNamewhen referenced, and this is the form we adopt in this book. Objects also have properties that are retrieved using theIADs::GetorIADs::GetExmethods, and set or replaced using theIADs::PutorIADs::PutExmethods.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 theobjectGUIDproperty of an object, you would use the :strGUID = objX.Get("objectGUID")You can see that we are calling theIADs::Getmethod on the object calledobjX; the dot (.) indicates the invocation of a property or method. TheIADs::Getmethod takes as its one parameter the property to retrieve, which in this case is theEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Simple Manipulation of ADSI Objects
- InhaltsvorschauLet’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
GetObjectto 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 useIADsOpenDSObject::OpenDSObjectas 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:- Create an Organizational Unit called Sales.
- Create two users in the Sales OU.
- Iterate through the Sales OU and delete each user.
- 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. TheIADsContainer::Createmethod 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 toIADsContainer::Create: the objectclass of the class of object you wish to create and the Relative Distinguished Name (RDN) of the object itself. We use theou=prefix because the type of object is an Organizational Unit. Most other objects use thecn=Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Summary
- InhaltsvorschauHopefully, 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
- InhaltsvorschauEach 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 propertiesOption 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 = NothingTo begin, we declare two variables (strandobjUser), invoke theGetObjectmethod to create a reference to the user object, and assign it toobjUser. We then set thestrvariable to the string"Name:"and apply theIADs::Nameproperty method (i.e.,objUser.Name) to retrieve theNameproperty’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,strrepresents the string"Name: Administrator".In the next line, we use theIADs::GUIDproperty method (objUser.GUIDEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - The IADs Properties
- InhaltsvorschauThe 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 propertiesOption 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 = NothingTo begin, we declare two variables (strandobjUser), invoke theGetObjectmethod to create a reference to the user object, and assign it toobjUser. We then set thestrvariable to the string"Name:"and apply theIADs::Nameproperty method (i.e.,objUser.Name) to retrieve theNameproperty’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,strrepresents the string"Name: Administrator".In the next line, we use theIADs::GUIDproperty method (objUser.GUID) to retrieve the GUID property’s value (i.e., {D83F1060-1E71-11CF-B1F3-02608C9E7553}). We are appending the GUID to previous valuesetinstrso the newstrrepresents theNameproperty value and theGUIDproperty value.While you can use property methods to access most of an object’s properties, you can also use the IADs interface’sIADs::GetandEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Manipulating the Property Cache
- InhaltsvorschauThere 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::GetInfocall (or an implicitIADs::GetInfocall usingIADs::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. ThePropertyListobject represents this list. You can use severalIADsPropertyListmethods 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 thePropertyEntryobject. You use theIADsPropertyEntryinterface to access property entries. A property entry can have one or more property values. To access values in a property entry, you use theEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Checking for Errors in VBScript
- InhaltsvorschauIt 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.DescriptionThis script fails to execute any of the lines after theOn Error Resume Nextstatement, as the first LDAP call into theobjGroupvariable failed. However, it will not terminate as usual with an error after theGetObjectline, due to theOn Errorstatement. 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 VBScriptOn 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 IfEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Summary
- InhaltsvorschauOver 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:
IADsIADsContainer(covered more fully later)IADsPropertyListIADsPropertyEntryIADsPropertyValue
We’ve also looked at how to supply credentials to authenticate with alternate credentials using theADsOpenDSObjectinterface 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
- InhaltsvorschauMicrosoft’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::Filteris 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, andStreams) and four collection objects (Errors,Fields,Parameters, andProperties). 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, theParameterobject 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 theCommand,Connection,Error,Field,Property, andRecordsetobjects. 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
- InhaltsvorschauThe 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 areobjConn(an ADOConnectionobject that lets you connect to the AD ) andobjRS(an ADORecordsetobject 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
TheOption Explicitstatement 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 withIADsOpenDSObject::OpenDSObject. Before you can establish this connection, you must create an ADOConnectionobject to use. This object can be created the same way you create a filesystem object: use theCreateObjectmethod, with"ADODB.Connection"as a parameter. You use the ADODB prefix to create all ADO objects, andConnectionis 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 theEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Understanding Search Filters
- InhaltsvorschauWhen 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 userobjectClassunder 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
- InhaltsvorschauWhen 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
objectCategoryor a combination ofobjectClassandobjectCategoryin every search. The problem with using onlyobjectClassis 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
- InhaltsvorschauWe 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, orSubTree - 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 anIf…Thencondition:If SearchAD("LDAP://dc=mycorp,dc=com", "(description=moose)", "SubTree", _ "ADsPath,cn,description", arrSearchResults) Then 'success code using arrSearchResults Else 'failure code End IfThe 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
- InhaltsvorschauIn 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
objectClassversusobjectCategory. 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
- InhaltsvorschauIn 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.SetInfoThe 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:sAMAccountNameanduserPrincipalName. 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 thesAMAccountNameattribute before you callIADs::SetInfoor the creation will fail. TheEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Creating a Simple User Account
- InhaltsvorschauYou 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.SetInfoThe 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:sAMAccountNameanduserPrincipalName. 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 thesAMAccountNameattribute before you callIADs::SetInfoor the creation will fail. TheuserPrincipalNameattribute 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 ofsAMAccountNamebeing populated during object creation. If you do not specify it, you will get a randomly generatedsAMAccountNamesuch as $KJK000-H4GJL6AQOV1I.Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Creating a Full-Featured User Account
- InhaltsvorschauCreating 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 theIADsUserinterface. The corresponding Active Directory attribute is included in parentheses for the property methods that can be set with the LDAP provider.Table : IADsUser methods MethodDescriptionIADsUser::ChangePasswordChanges the existing password.IADsUser::SetPasswordSets a new password without needing the old one.IADsUser::GroupsGets a list of groups of which the user is a member. You can use theIADsMembersinterface to iterate through the list.Table : IADsUser read-write property methods Property methodAvailable with WinNT or LDAP?IADsUser::AccountDisabledWinNT, LDAP (userAccountControl mask).IADsUser::AccountExpirationDateWinNT, LDAP (accountExpires).IADsUser::DepartmentLDAP (department).IADsUser::DescriptionWinNT, LDAP (description).IADsUser::DivisionLDAP (division).IADsUser::EmailAddressLDAP (mail).IADsUser::EmployeeIDLDAP (employeeID).IADsUser::FaxNumberLDAP (facsimileTelephoneNumber).IADsUser::FirstNameLDAP (givenName).IADsUser::FullNameWinNT, LDAP (displayName).IADsUser::GraceLoginsAllowedNeither.IADsUser::GraceLoginsRemainingNeither.IADsUser::HomeDirectoryWinNT, LDAP (homeDirectory).IADsUser::HomePageLDAP (wWWHomePage).Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Creating Many User Accounts
- InhaltsvorschauUser-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 fileOption 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.CloseEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Modifying Many User Accounts
- InhaltsvorschauOnce 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 WendEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Account Unlocker Utility
- InhaltsvorschauImagine 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 IfEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Creating a Group
- InhaltsvorschauNow we will move on to creating groups. Creating a group is very similar to creating a user. You use the same
IADsContainer::Createmethod:Set objGroup = objSalesOU.Create("group", "cn=Managers") objGroup.Put "sAMAccountName", "Managers" objGroup.SetInfoThis code assumes we already have a pointer to an OU in theobjSalesOUvariable. TheIADs::Putmethod is used to set thesAMAccountName, a mandatory attribute in Windows 2000 Active Directory with no default value, just like with users.TheIADsGroupinterface 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 propertiesActionAddAdds users to the group as membersRemoveRemoves user members from the groupIsMemberTests to see if a user is a member of a groupMembersReturns a list of all the members of the groupDescriptionReturns the text describing the groupIn , we show how to create a group with both the WinNT and LDAP providers.Example . Creating a group with both the WinNT and LDAP providersOption 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.SetInfoEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Adding Members to a Group
- InhaltsvorschauAdding 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 IfEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Evaluating Group Membership
- InhaltsvorschauThe
IADsGroup::IsMembermethod takes one argument, the DN of the object to check, just asAddandRemovedo. It returns a Boolean, i.e., true or false. That allows you to use it in anIf … Thenstatement 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 IfTo get a list of members in a group, theIADsGroup::Membersmethod can be used. TheIADsGroup::Membersfunction is different from the otherIADsGroupmethods we have shown so far, since it returns a pointer to anIADsMembersobject. shows the two methodsIADsMemberssupport.Table : The IADsMembers interface ActionCountThe number of items in the container. If there is a filter set, only the number of items that match the filter are returned.FilterA 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. TheFor Each … In … Nextloop 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 NextThis script displays the number of members and then prints each member’s name. As theForloop executes,objMemberends up holding an IADs object representing each member of the group.Another useful feature ofIADsMembersis theFiltermethod. 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 NextEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Summary
- InhaltsvorschauIn 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
- InhaltsvorschauSecurity 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
- InhaltsvorschauMicrosoft 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 propertyValue to be storedTrusteeNames the user who is to have the permission.AccessMaskGives full control (i.e., give every permission).AceTypeThis is an allow permission.AceFlagsThe 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
- InhaltsvorschauAll 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 usingIADsAccessControlListandIADsSecurityDescriptor.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 exampleOption 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.SetInfoA 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 aEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - A Complex ADSI Example
- Inhaltsvorschauis 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.SetInfoEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Creating Security Descriptors
- InhaltsvorschauIf 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
IADsAccessControlListinterface (see ) and theIADsSecurityDescriptorinterface (see ). We’ll go through these briefly now and then move on to some more examples.Table : IADsAccessControlList methods and properties IADsAccessControlList methods and propertiesActionAddAcemethodAdds an ACE to an ACLRemoveAcemethodRemoves an ACE from an ACLCopyAccessListmethodCopies the current ACLAclRevisionpropertyShows the revision of the ACL (always set to 4; see later text)AceCountpropertyIndicates the number of ACEs in the ACLTable : IADsSecurityDescriptor methods and properties ActionCopySecurityDescriptormethodA copy of an existing SD.RevisionpropertyThe revision of the SD (always set to 4, as noted earlier).ControlpropertyA 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.OwnerpropertyThe SID of the owner. If this field is null, no owner is set.OwnerDefaultedpropertyA 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.GrouppropertyThe 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
- InhaltsvorschauA 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 SubEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Summary
- InhaltsvorschauThis 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:
IADsAccessControlEntryIADsAccessControlListIADsSecurityDescriptorIADsSecurityUtility
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
- InhaltsvorschauThis 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
IADsinterface, there are two main schema-specific interfaces available:IADsClassandIADsProperty. 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 theIADsClassandIADsPropertymethods. 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
- InhaltsvorschauWe’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
IADsinterface, there are two main schema-specific interfaces available:IADsClassandIADsProperty. 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 theIADsClassandIADsPropertymethods. 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 ofIADsClass::Manda-toryProperties,IADsProperty::MultiValued,IADsProperty::OID, andIADsClass::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 calledMycorp-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 thatEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Customizing the Active Directory Administrative Snap-ins
- InhaltsvorschauIn 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-LanguagesSpokenattribute 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 theDisplaySpecifierscontainer. Within theDisplaySpecifierscontainer, 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 atEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Summary
- InhaltsvorschauIn 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
displaySpecifierobjects. 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
- InhaltsvorschauThe 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
- InhaltsvorschauThere 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
- InhaltsvorschauThe 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
- InhaltsvorschauOnce 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’sGetObjectfunction. ForGetObjectto 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 thewinmgmts: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. TheGetObjectcall 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
- InhaltsvorschauThere 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 alist briefsubcommand 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, typealiasat 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 atEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Manipulating Services
- InhaltsvorschauQuerying services is simple to do with WMI. The
Win32_Serviceclass is the WMI representation of a service. TheWin32_Serviceclass 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 PropertyDescriptionAcceptPauseReturns a Boolean indicating whether the service can be paused.AcceptStopReturns a Boolean indicating whether the service can be stopped.DescriptionDescription of the service.DisplayNameDisplay name of the service.NameUnique string identifier for the service.PathNameFully qualified path to the service executable.StartedBoolean indicating whether the service has been started.StartModeString specifying the start mode of the service. Will be one of Automatic, Manual, or Disabled.StartNameAccount under which the service runs.StateCurrent 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 allWin32_Serviceobjects 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
- InhaltsvorschauThe 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_NTEventLogFileclass represents an Event Log. contains severalWin32_NTEventLogFileproperties that can be used to query or modify properties of an Event Log.Table : Useful Win32_NTEventLogFile properties PropertyDescriptionFileSizeSize of the Event Log file in bytes.LogFileNameStandard name used for describing the Event Log (e.g., Application).MaxFileSizeMax size in bytes that the Event Log file can reach. This is a writeable property.NameFully qualified path to the Event Log file.NumberOfRecordsTotal number of records in the Event Log.OverwriteOutDatedNumber 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.OverwritePolicyText description of the overwrite policy (as specified by theOverwriteOutDatedproperty). Can be one of WhenNeeded, OutDated, or Never.SourcesArray 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 theMaxFileSizeandOverwriteOutDatedproperties if they have not already been set to the correct values. Since we want to iterate over all Event Logs, we will passWin32_NTEventLogFileto theInstancesOfmethod. shows how to accomplish this.Example . Displaying properties of the Event Log using Win32_NTEventLogFileEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Monitoring Trusts
- InhaltsvorschauNew 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_DomainTrustStatusclass, 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 PropertyDescriptionFlatnameNetBIOS name for the domain.SIDSID for the domain.TrustAttributesFlag 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)
TrustDCNameName of the domain controller the trust is set up with.TrustDirectionInteger representing direction of the trust. Valid values include:- 1 (inbound)
- 2 (outbound)
- 3 (bidirectional)
TrustedDomainNaming of trusted domain.TrustIsOKBoolean indicating whether the trust is functioning properly.TrustStatusInteger representing the status for the trust. 0 indicates no failure.TrustStatusStringTextual description of status for the trust.TrustTypeInteger representing the type of trust. Valid values include:- 1 (downlevel)
- 2 (uplevel)
- 3 (Kerberos realm)
- 4 (DCE)
As you can see from , theMicrosoft_DomainTrustStatusclass 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
- InhaltsvorschauThe 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_ReplNeighborclass, which represents a replication partner (or neighbor) for a given domain controller.Table : Useful MSAD_ReplNeighbor properties PropertyDescriptionIsDeletedSourceDsaBoolean indicating whether the source DC has been deleted.LastSyncResultNumber representing the result of the last sync operation with this neighbor. A value of 0 indicates success.NamingContextDNDN of the Naming Context for which the partners replicate.NumConsecutiveSyncFailuresNumber of consecutive sync failures between the two neighbors.SourceDsaCNCN of the replication neighbor.SourceDsaSiteSite the replication neighbor is in.TimeOfLastSyncAttemptTime of the last sync attempt.TimeOfLastSyncSuccessTime 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 theMSAD_ReplNeighborclass: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
- InhaltsvorschauIn 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
- InhaltsvorschauDNS 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
Dnscmdcommands from within a batch, VBScript, or Perl script. Over time, Microsoft has continued to improveDnscmd, 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 withDnscmdfrom 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 fromEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - DNS Provider Overview
- InhaltsvorschauThe 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
mofcompfilename 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
- InhaltsvorschauThere 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_Serverclass, which is derived from theCIM_Serviceclass. contains all the property methods available in theMicrosoftDNS_Serverclass.Table : MicrosoftDNS_Server class properties Property nameProperty descriptionAddressAnswerLimitMax number of records to return for address requests (e.g., A records).AllowUpdateDetermines whether DDNS updates are allowed.AutoCacheUpdateIndicates whether the DNS server will dynamically attempt to update its root hints (also known as cache) file.AutoConfigFileZonesIndicates which standard primary zones that are authoritative for the name of the DNS server must be updated when the name server changes.BindSecondariesDetermines the format zone transfers (AXFR) will be sent as to non-Microsoft DNS servers.BootMethodDetermines where the server will read its zone information.DefaultAgingStateFor AD-integrated zones, the default scavenging interval in hours.DefaultNoRefreshIntervalFor AD-integrated zones, the default no-refresh interval in hours.DefaultRefreshIntervalFor AD-integrated zones, the default refresh interval in hours.DisableAutoReverseZonesDetermines whether the server automatically creates reverse zones.DisjointsNetsIndicates whether the default port binding for a socket used to send queries to remote DNS servers can be overridden.DsAvailableIndicates whether Active Directory is available on the server.DsPollingIntervalFor 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
- InhaltsvorschauThe
MicrosoftDNS_Zoneclass 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 theMicrosoftDNS_Zoneclass.Table : MicrosoftDNS_Zone class properties Property nameProperty descriptionAgingSpecifies aging and scavenging behavior. Zero indicates scavenging is disabled.AllowUpdateFlag indicating whether dynamic updates are allowed.AutoCreatedFlag indicating whether the zone was auto-created.Specifies the time when the server may attempt scavenging the zone.DataFileName of zone file.DisableWINSRecordReplicationIf TRUE, WINS record replication is disabled.DsIntegratedSpecified if zone is AD integrated.ForwarderSlaveIndicates whether the DNS server acts as a slave when resolving the names for the specified forward zone. Applicable to Forward zones only.ForwarderTimeoutIndicates 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.LastSuccessfulXfrNumber of seconds since the beginning of January 1, 1970 GMT, since the zone was last transferred from a master server.LocalMasterServersLocal IP addresses of the master DNS servers for this zone. If set, these masters override the MasterServers found in Active Directory.MasterServersIP addresses of the master DNS servers for this zone.NoRefreshIntervalSpecifies 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
- InhaltsvorschauResource 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 theMicrosoftDNS_ResourceRecordclass, which implements a generic interface for resource records.Table : MicrosoftDNS_ResourceRecord class properties Property nameProperty descriptionContainerNameName of container (e.g., zone name) that holds the RREnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Summary
- InhaltsvorschauThe 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
- InhaltsvorschauIn 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?
- InhaltsvorschauWhy 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
- InhaltsvorschauAs 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
- InhaltsvorschauSince 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
- InhaltsvorschauAt 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 systemIncluded framework versionsWindows 2000NoneWindows XPNoneWindows Server 20031.1Windows Server 2003 R21.1, 2.0Windows Vista2.0, 3.0Windows Server 20082.0, 3.0This 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
- InhaltsvorschauFirst, 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 modeAs 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.TheSystem.DirectoryServicesnamespace (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.SDSis basically just a simple interop layer over the existing ADSI programming model. Most of what you already know about ADSI will apply directly toSDS.SDSis 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:DirectoryEntryDirectorySearcher
DirectoryEntryis essentially a wrapper around the ADSIEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - .NET Directory Services Programming by Example
- InhaltsvorschauNow, 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
SDSandSDS.ADvia 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.SDSprovides other ways to accomplish the same tasks anyway, so late binding is not really necessary. You can add theOption StrictandOption Explicitdirectives 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.DirectoryServicesSystem.DirectoryServices.ActiveDirectorySystem.DirectoryServices.AccountManagementSystem.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
- InhaltsvorschauThe 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 ScopeDescriptionLocalLimited to the current functionScriptLimited to the context of the current executing script, with the exception of dot-sourced scriptsGlobalAvailable across all scopesWhen 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 sourceEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Exploring the PowerShell
- InhaltsvorschauAs 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 ScopeDescriptionLocalLimited to the current functionScriptLimited to the context of the current executing script, with the exception of dot-sourced scriptsGlobalAvailable across all scopesWhen 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 sourcec:\scripts\Myfunctions.ps1, you would run:c:\scripts\Myfunctions.ps1Nearly 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 ofName. Properties are accessed by using a period. If you wanted to access theEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Working with the Pipeline
- InhaltsvorschauThe 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 }Diris an alias for theGet-ChildItemcmdlet.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
- InhaltsvorschauPowerShell 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-Servicecmdlet. To start a service, you could use theStart-Service cmdlet. Predictably, a list of processes is accessible with theGet-Processcmdlet.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 verbsCommunication verbsData verbsDiagnostic verbsLifecycle verbsSecurity verbsAddConnectBackupDebugDisableBlockClearDisconnectCheckpointMeasureEnableGrantCopyReadComparePingInstallRevokeGetReceiveConvertResolveRestartUnblockJoinSendConvertFromTestResumeSecurityLockWriteConvertToTraceStartMoveDismountStopNewExportSuspendRemoveImportUninstallRenameInitializeSelectLimitSetMergeSplitMountUnlockRestoreUpdateOutNearly 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
- InhaltsvorschauPowerShell 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$argsarray variable. If you want to check how many arguments have been passed, you can access$args.Count. Since$argsis 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$argsarray variable. Refer to the discussion on theparamkeyword 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 aEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Using WMI
- InhaltsvorschauPowerShell fully exposes WMI through the
Get-WMIObjectcmdlet (aliasgwmi). There are a number of parameters you’ll want to take a look at when using theGet-WMIObjectcmdlet:Class- The
-Classparameter specifies the WMI class you want to retrieve. In this example, we retrieve the contents of theWin32_ComputerSystemclass 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
-Propertyparameter. In this example, we retrieve two properties from theWin32_OperatingSystemclass:Get-WmiObject Win32_OperatingSystem -Property ` SystemDirectory,Version SystemDirectory : C:\WINDOWS\system32 Version : 5.2.3790 Namespace- The
-Namespaceparameter works in conjunction with-Classto tell WMI where the class is located. For example, if you wanted to see the ICMP settings for the Windows Firewall, you could use theHNet_FwICMPSettingsclass from theRoot\Microsoft\HomeNetnamespace: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 thegwmialias toGet-WMIObject. ComputerName- You can provide the
-ComputerNameparameter with a list of remote machine names to connect to, andGet-WMIObjectwill 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
- InhaltsvorschauIn 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
- InhaltsvorschauThis 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.DirectoryServicesnamespace, which we’ll abbreviate asSDSthroughout this chapter.Almost anytime you need to represent an object in Active Directory, chances are you’ll be using theDirectoryEntryclass. 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 aDirectoryEntryobject for you. For example, you could build aDirectoryEntryfor 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
- InhaltsvorschauWorking 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.DirectoryServicesnamespace, which we’ll abbreviate asSDSthroughout this chapter.Almost anytime you need to represent an object in Active Directory, chances are you’ll be using theDirectoryEntryclass. 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 aDirectoryEntryobject for you. For example, you could build aDirectoryEntryfor 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.TheDirectorySearcherclass is, as its name implies, for searching for objects in Active Directory. It’s important to remember that the search results returned from aDirectorySearcherareSearchResultobjects, notDirectoryEntryobjects.If you need to get theDirectoryEntryobject (such as for making an update to the search result), callSearchResult.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
- InhaltsvorschauBefore 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 processingThe eight steps in are:- We create a reference to an Active Directory object in our local in-memory cache.
- We attempt to access the user.
- A request to get the attributes of the object from Active Directory is made.
- The data is returned from Active Directory and the local object is populated.
- Local object display name is set (but not committed to Active Directory).
- Local object name is set (but not committed to Active Directory).
- The local object changes are committed.
- 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 printDomain 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 printDomain 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
- InhaltsvorschauNow 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). TheParamstatement 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
userPrincipalNamefor user objects. If$domainis 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
OrganizationalUnitobjects to create. By default we will create 10 childOrganizationalUnitobjects, 50Userobjects (5 per childOrganizationalUnit), and 50Computerobjects (5 per childOrganizationalUnit) for each testOrganizationalUnit.
After theParamstatement, our code parses the parameters passed and builds two local variables which will be used later on. First, we check to see if aEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Working with Forests and Domains
- InhaltsvorschauManipulating 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
Forestobject and put it in the variable called$forest:$forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
GetCurrentForest()is a method that returns aForestobject 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.labYou can get the name of the forest root (Name), a listing of sites, child domains, and global catalogs (Sites,Domains, andGlobalCatalogs, respectively), the functional level (ForestMode), and the owners of the schema master and domain naming master FSMOs (SchemaRoleOwnerandNamingRoleOwner, respectively).In addition to properties, the Forest class also has a number of methods you can use to manipulate the forest. You can pipe$foresttoGet-Memberto 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 useFormat-Tableto 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 MethodEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Understanding Group Policy
- InhaltsvorschauScripting 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-SDMgpcmdlet 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
Usernameparameter. 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, andLogoffswitches, 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-forceswitch:Update-SDMgp "win2k8x64DC2" -force
To refresh just the computer policy on win2k8x64dc2, add the-computerswitch: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
- InhaltsvorschauThis 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
- InhaltsvorschauIn 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
- InhaltsvorschauManaging 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
- InhaltsvorschauMost 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
- InhaltsvorschauExchange 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
- InhaltsvorschauExchange 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 anEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Mail-Enabling a User
- InhaltsvorschauYou 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 ofMailEnable.MailEnableis a method of theIMailRecipientCDOEXM 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 theMailEnablemethod are on theuserobject in Active Directory and include changes to the following attributes:targetAddressmailNicknamemAPIRecipientlegacyExchangeDN
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 aremailNicknameandtargetAddress.In addition to those attributes, theinternetEncodingattribute 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 theEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Mail-Disabling a User
- InhaltsvorschauNow 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, theMailDisablemethod. 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 thehomeMDBattribute. If a user object hashomeMDBpopulated, 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
- InhaltsvorschauA
contactin Exchange 2000 or above is similar to a custom recipient in Exchange 5.5. Contacts can be created in Active Directory like auseris created, and mail-enabling acontactis identical to mail-enabling auser. Because the users and groups chapter didn’t discuss creating acontact, it will be wrapped into the script here. You can shorten the following script down to just mail-enabling of an existingcontactor by using the script shown in the previous section and substituting in thecontactDN for theuserDN:' 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 thecnisn’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 theMailEnablemethod.Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Mail-Disabling a Contact
- InhaltsvorschauMail-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 theMailDisablemethod for Exchange contacts.Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Mail-Enabling a Group (Distribution List)
- InhaltsvorschauA mail-enabled
groupis 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 theMailEnablemethod was called. The email address is automatically created based on thesAMAccountNameof 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 calledproxyAddressesdirectly. This attribute controls the addresses available for a given mail object within the Exchange system.TheproxyAddressesattribute 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 onproxyAddresses: 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
- InhaltsvorschauMail-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
- InhaltsvorschauYou 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 ofCreateMailBox. CreateMailBoxis a method of theIMailBoxStoreCDOEXM 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 theCreateMailBoxmethod are on theuserobject in Active Directory and include changes to the following attributes:mDBUseDefaultsmsExchUserAccountControlhomeMTAmsExchHomeServerNamehomeMDBmailNicknamemsExchMailboxGuidmsExchMailboxSecurityDescriptorlegacyExchangeDN
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 areEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Mailbox-Disabling a User (Mailbox Deletion)
- InhaltsvorschauNow 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, theDeleteMailBoxmethod. 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 thehomeMDBattribute. If a user object hashomeMDBpopulated, there is an associated mailbox for that account.TheDeleteMailBoxmethod 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 otheruserobject 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
- InhaltsvorschauIn 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 WMIExchange_Mailboxclass, 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 thePurgemethod 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 asDateDiscoveredAbsentInDSorLastLogonTimeproperties. See theExchange_Mailboxclass 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
- InhaltsvorschauAfter 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 WMIExchange_Mailboxclass (which is available in Exchange 2003) and asks for all mailboxes with the specified name. It then loops through the returned mailboxes and executes theReconnectmethod against the mailbox returned. Unfortunately, there are some rather serious flaws with the implementation of theReconnectmethod, which severely limits its usability in some environments.The first flaw is that the WMIReconnectmethod 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
- InhaltsvorschauThere 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 theMoveMailBoxmethod of theIMailBoxStoreinterface. 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
- InhaltsvorschauIf 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 WMIExchange_Mailboxclass to gather the requested information.Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Viewing Mailbox Sizes and Message Counts
- InhaltsvorschauA 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 PropertyDescriptionLegacyDNlegacyDN of the mailbox. This matches thelegacyExchangeDNattribute of the user object in Active Directory.MailboxGUIDIndicates 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 asmsExchMailboxGuid.ServerNameName of the server the mailbox resides on.StorageGroupNameIndicates the name of the storage group that contains the mailbox.StoreNameIndicates the name of the message database (MDB) that contains the mailbox.AssocContentCountIndicates 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
- InhaltsvorschauThe 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
- InhaltsvorschauThe 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.CloseEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Summary
- InhaltsvorschauIn 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
IMailBoxStoreinterface 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
- InhaltsvorschauThis 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 ShellUnder 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
- InhaltsvorschauIn 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 ShellUnder 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
- InhaltsvorschauThere 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 callEnable-Mailboxand 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 asEnable-Mailboxcompletes, 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 theNew-Mailboxcmdlet instead.In order to mailbox-enable a user, you will need to callDisable-Mailboxand 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 theDisable-Mailboxcmdlet 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 theRemove-MailboxEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Managing Groups
- InhaltsvorschauThere 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 theEnable-DistributionGroupcmdlet 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 asEnable-DistributionGroupcompletes, 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 theNew-DistributionGroupcmdlet instead.To create a dynamic distribution group, useNew-DynamicDistributionGroup.In order to disable an existing mail-enabled group, you will need to call theDisable-DistributionGroupcmdlet 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 theDisable-DistributionGroupcmdlet, visit http://technet.microsoft.com/en-us/library/aa997942(EXCHG.80).aspx.If you use theRemove-DistributionGroupcmdlet, the group object in Active Directory will be deleted!If you need to remove a dynamic distribution group, use theRemove-DynamicDistributionGroupEnde der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar. - Summary
- InhaltsvorschauIn 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
