Active Directory is the central information store
that Windows Server uses to maintain entity and relationship data for a
wide variety of objects in a networked environment. AD provides a set of
core services, including authentication, authorization, and directory services.
Configuration Manager requires an Active Directory environment and
takes advantage of AD to support many of its features. For more
information about Active Directory in Windows Server 2003 and Windows
Server 2008, see the following references:
In an Active
Directory environment, all processes run in the security context of a
user or a security context supplied by the operating system. System accounts
are special accounts included on each Windows system used to run
processes in a context supplied by the operating system. Prior to AD,
the only built-in system account context was the Local System
account. The Windows NT Local System account provided unlimited access
to system resources, but you could not use it for network requests.
Using Active Directory,
each system has a computer account that you can add to user groups and
grant access to resources anywhere on the network. Windows Server 2003
and later operating systems add two other built-in accounts with limited
access:
The Local Service account has essentially the same rights on the local system as a nonprivileged user and no access to the network.
The Network Service account has rights and network access similar to a nonprivileged user account.
ConfigMgr 2007 makes
extensive use of system and computer accounts to run processes. Using
system accounts greatly simplifies administration, eliminating the need
to create and manage the large number of service accounts required with
early versions of SMS.
In addition to
authentication and access control services, Configuration Manager 2007
can use AD to publish information about its sites and services, making
ConfigMgr easily accessible to Active Directory clients. To take
advantage of this capability, you must extend the AD schema to create
classes of objects specific to Configuration Manager. Although extending
the schema is not required for ConfigMgr to work, it is required for
certain Configuration Manager features. Extending the schema also
greatly simplifies ConfigMgr deployment and operations. The “Schema Extensions” section of this chapter discusses extending the AD schema, and the “Benefits of Extending Active Directory” section covers the feature dependencies and administrative advantages provided by the schema extensions.
Configuration Manager can also take advantage of Active Directory in the following ways:
Discovering information about your environment, including the existence of potential client systems.
Assigning and installing clients through group policy. In addition, you can use group policy to configure basic services used by ConfigMgr.
Using certificates and certificate settings deployed through AD to enhance its own security.
Schema Extensions
All
objects in Active Directory are instances of classes defined in the AD
schema. The schema provides definitions for common objects such as
users, computers, and printers. Each object class has a set of
attributes that describes members of the class. As an example, an object
of the computer class has a name, operating system, and so forth.
Additional information about the AD schema is available at http://msdn.microsoft.com/en-us/library/ms675085(VS.85).aspx.
The schema is
extensible, allowing administrators and applications to define new
object classes and modify existing classes. Using the schema extensions
provided with Configuration Manager eases administering your ConfigMgr
environment. The ConfigMgr schema extensions are relatively low risk and
involve only a specific set of classes not likely to cause conflicts.
Extending the schema is a recommended best practice for Configuration
Manager because it allows you to avoid additional configuration tasks
and implement stronger security. Nevertheless, you will want to test any
schema modifications before applying them to your production
environment.
Tools for Extending the Schema
You can extend the schema in either of two ways:
If you are extending the schema on a Windows 2000 domain controller, you must use the LDIF file.
Using ExtADSch
Using ExtADSch.exe is the
simplest way to extend the schema, and in SMS 2003, it was the only way
to extend the schema. ExtADSch.exe creates the log file extadsch.log,
located in the root of the system drive (%systemdrive%),
which lists all schema modifications it has made and the status of the
operation. After the list of attributes and classes that have been
created, the log should contain the entry “Successfully extended the
Active Directory schema.”
Using LDIFDE
LDIFDE is a
powerful command-line utility for extracting and updating directory
service data on Active Directory servers, beginning with Windows 2000.
LDIFDE provides command-line switches, allowing you to specify a number
of options, including some you may want to use when updating the schema
for ConfigMgr. Table 1 includes the options that you are most likely to use.
Table 1. LDIFDE Command-Line Switches and Descriptions
| Switch | Description |
|---|
| -i | Turns on Import Mode. (Required for updating the schema.) |
| -f | Filename. (Used to specify the location of the ConfigMgr_ad_schema.ldf file.) |
| -j | Log file location. |
| -v | Turns on Verbose Mode. |
| -k | Ignore
Constraint Violation and Object Already Exists errors. (Use with
caution. May be useful if the schema is previously extended for SMS.) |
The options vary
slightly, depending on the Windows Server version you are running. You
can see a complete listing of LDIFDE syntax by entering the following
command:
You can also find detailed information about using LDIFDE at http://technet2.microsoft.com/windowsserver2008/en/library/8fe5b815-f89d-48c0-8b2c-a9cd1d6986521033.mspx?mfr=true. A typical command to update the schema for ConfigMgr would be something like this:
ldifde –i –f ConfigMgr_ad_schema.ldf –v –j SchemaUpdate.log
The verbose logging
available with LDIFDE includes more detail than the log file generated
by ExtADSch.exe. The ConfigMgr_ad_schema.ldf file allows you to review
all the intended changes before they are applied. You can also modify
the LDF file to customize the schema extensions. As an example, you can
remove the sections for creating classes and attributes that already
exist as an alternative to using the –k switch referred to in Table 3.1.
Caution: Be Careful when Editing the LDF File
Do not attempt to
edit the LDF file unless you have a thorough understanding of LDF, and
remember to test all modifications before applying them to your
production environment.
Extending the Schema
Each AD forest
has a single domain controller that has the role of schema master. All
schema modifications are made on the schema master. To modify the
schema, you must log on using an account in the forest root domain that
is a member of the Schema Admins group.
Note: About the Schema Admins Group
The built-in Schema
Admins group exists in the root domain of your forest. Normally there
should not be any user accounts in the Schema Admins group. You should
only add accounts to the Schema Admins temporarily when you need to
modify the schema. Exercising this level of caution will protect the
schema from any accidental modifications.
The
ConfigMgr 2007 schema modifications create four new classes and 14 new
attributes used with these classes. The classes created represent the
following:
Management points— Clients can use this information to find a management point.
Roaming boundary ranges—
Clients can use this information to locate ConfigMgr services when they
connect to the network at a location not within the boundaries of their
assigned site.
Server locator points (SLPs)— Clients can use this information to find an SLP.
ConfigMgr sites— Clients can retrieve important information about the site from this AD object.
|
You will want to
exercise caution when planning any changes to the AD schema,
particularly when making modifications to existing classes, because this
may affect your environment.
When you modify the
schema, you should take the schema master offline temporarily while you
apply the changes. Regardless of the method you use to extend the
schema, you should review the logs to verify that the schema extensions
were successful before bringing the schema master back online. This way,
if there is a problem with the schema modifications, you can seize the
schema master role on another domain controller and retain your original
schema!
Before actually
extending the schema for ConfigMgr 2007, run the dcdiag and netdiag
command-line tools, part of the Windows Support Tools. These tools
validate that all domain controllers (DCs) are replicating and healthy.
Because it may be difficult to validate the output of these tools, you
can output the results to a text file using the following syntax:
Search the output text
file for failures and see if any domain controllers are having problems
replicating. If any failures are present, do not update the schema.
Upgrading the schema when domain controllers are not healthy or
replicating correctly will cause them to be orphaned as AD is revved to a
higher version. The machine will then need to be manually and painfully
cleaned out of AD.
|
Note: Schema Extensions and ConfigMgr 2007 Updates
There are no changes
to the schema extensions from the RTM (Release to Manufacturing, or
initial release) version of Configuration Manager 2007 in either Service
Pack (SP) 1 or Release 2 (R2) (it is unknown at the time of writing
this chapter whether SP 2 will incorporate schema changes). The
ConfigMgr schema extensions include previous changes from the SMS 2003
version of the schema extensions.
Although
you can deploy ConfigMgr with only the SMS 2003 schema extensions
applied to AD, you will not have all the functionality provided by the
ConfigMgr schema extensions. Configuration Manager features not
supported by the SMS 2003 Schema extensions include Network Access
Protection and native mode security. The “Benefits of Extending Active Directory” section of this chapter discusses these features.
Viewing Schema Changes
If you are curious
about the details of the new classes, you can use the Schema Management
Microsoft Management Console (MMC) snap-in to view their full schema
definitions. Before adding the snap-in to the management console, you
must install it by running the following command from the command
prompt:
After installing the snap-in, perform the following steps to add Schema Management to the MMC:
1. | Select Start, choose Run, and then enter MMC.
|
2. | Choose Add/Remove snap-in from the File menu of the Microsoft Management Console.
|
3. | Click the Add button and then choose Active Directory Schema.
|
4. | Choose Close and then click OK to complete the open dialog boxes.
|
The left pane of
the schema management tool displays a tree control with two main
nodes—classes and attributes. If you expand out the classes node, you
will find the following classes defined by ConfigMgr:
Clicking a class
selects it and displays the attributes associated with the class in the
right pane. The list of attributes for each class includes many
attributes previously defined in Active Directory, in addition to those
attributes specifically created for ConfigMgr 2007. You can right-click a
class and choose Properties to display its property page. As an
example, Figure 1
shows the general properties of the mSSMSSite class. You can see an
explanation of these properties by clicking the Help button on the
Properties page.
You can see the 14
ConfigMgr attributes under the Attributes node in the schema management
console. The names of each of these attributes start with mS-SMS. You can right-click an attribute and choose Properties to display its property page. Figure 2 shows the properties of the mS-SMS-Capabilities attribute.
Tip: Verifying the Schema Extensions
Check
ExtADSch.log for failures. Seeing the Event IDs 1137 in the Directory
Service Event Log alone is not confirmation that the schema was extended
properly; several experiences in the field have found what seemed to be
a successful schema extension to show failures in the log file.
Additional Tasks
After extending
the schema, you must complete several tasks before ConfigMgr can publish
the objects it will use to Active Directory:
Creating
the System Management container where the ConfigMgr objects will reside
in AD. If you previously extended the schema for SMS, the System
Management container will already exist. Each domain publishing
ConfigMgr data must have a System Management container.
Setting
permissions on the System Management container. Setting permissions
allows your ConfigMgr site servers to publish site information to the
container.
Configuring your sites to publish to AD.
The next sections describe these tasks.
Creating the System Management Container
You can use the
ADSIEdit MMC tool to create the System Management AD container. If you
do not already have ADSIEdit installed, you can install the tool
yourself. The steps to install ADSIEdit will vary depending on the
version of Windows Server you are running.
On Windows Server
2008, add ADSIEdit using Server Manager. Note that configuring the
domain controller server role automatically adds ADSIEdit to the
Administrative Tools program group.
To install ADSIEdit on Windows Server 2003 or Windows 2000 Server, perform the following steps:
1. | Run
the Windows Installer file at \SUPPORT\TOOLS\suptools.msi from the
Windows Server 2003 installation media. (For Windows 2000 systems, the
installer file is adminpak.msi.)
|
2. | Select Start, choose Run, and then enter MMC.
|
3. | Choose Add/Remove snap-in from the File menu.
|
4. | Click the Add button and choose ADSI Edit.
|
5. | Choose Close and then click OK to complete the open dialog boxes.
|
To create the System Management container from ADSIEdit, perform the following steps:
1. | Right-click
the Root ADSI Edit node in the tree pane, select Connect to..., and
then click OK to connect to the default name context.
|
2. | Expand
the default name context node in the tree pane. Then expand the node
showing the distinguished name of your domain (this will begin with
DC=<domain name>) and right-click CN=System node.
|
3. | Select New and then choose Object.
|
4. | Select Container in the Create Object dialog box and click Next.
|
5. | Enter the name System Management and then click Next and Finish, completing the wizard.
|
Figure 3 shows ADSIEdit with the tree control expanded to the CN=System node and the Create Object dialog box displayed.
Setting Permissions on the System Management Container
You can view the
System Management container and set permissions on it using the Active
Directory Users and Computers (ADUC) utility in the Windows Server
Administrative Tools menu group. After launching
ADUC, you need to enable the Advanced Features option from the View
menu. You can then expand out the domain partition and System container
to locate System Management.
By
default, only certain administrative groups have the rights required to
create and modify objects in the System Management container. For
security reasons, you should create a new group and add ConfigMgr site
servers to it, rather than adding them to the built-in administrative
groups. Perform the following steps to grant the required access to the
ConfigMgr site server security group:
1. | Right-click the System Management container, choose Properties, and then select the Security tab.
|
2. | Click the Add button and select the group used with your ConfigMgr site servers, as shown in Figure 4.
|
3. | Check the box for Full Control as displayed in Figure 5, and choose OK to apply the changes.
|
Configuring Sites to Publish to Active Directory
Perform the following steps to configure a ConfigMgr site to publish site information to AD:
1. | Navigate to System Center Configuration Manager -> Site Database -> Site Management -> <Site Code>
in the ConfigMgr console (select Start -> All Programs ->
Microsoft Configuration Manager to open the Configuration Manager
console).
|
2. | Right-click
the site code and choose Properties. Click the Advanced tab and then
select the Publish this site in Active Directory Domain Services check
box as shown in Figure 6. Choose OK to apply your changes.
|
After
extending the schema and taking the other steps necessary to enable
your sites to publish to AD, you should see the ConfigMgr objects
displayed in the System Management container. Figure 7 shows the ConfigMgr objects viewed in Active Directory Users and Computers.
Benefits of Extending Active Directory
Once you extend
the Active Directory schema and perform the other steps necessary to
publish site information to AD, clients in the same AD forest as your
ConfigMgr sites can query AD to locate Configuration Manager services
and retrieve important information about your ConfigMgr sites. Those
clients in workgroups and domains without trust relationships are not
able to take advantage of the schema extensions.
The following ConfigMgr features require extending the AD schema and publishing site information to AD:
Global roaming—
Roaming in ConfigMgr allows clients such as laptop computers to connect
to the network at various locations and receive certain services from
the local site. The schema extensions allow a client to query AD for the
mSSMSRoamingBoundaryRange objects and determine whether a site exists
on the IP subnet of their current network location. This is known as global roaming.
Without the schema extensions, clients can only receive services when
at their assigned site or roaming to the sites below their assigned site
in the ConfigMgr hierarchy.
Global
roaming can make content available to clients at network locations
where it would otherwise not be available. Global roaming can also
prevent unnecessary network traffic otherwise caused by those clients at
remote locations requiring services from their assigned site.
Network Access Protection—
You can use ConfigMgr’s NAP capabilities to prevent clients that do not
comply with specified security patch requirements from connecting to
the network. NAP requires the client to retrieve health state reference
information stored in the attributes of the mSSMSSite AD object.
ConfigMgr clients can also receive a number of services through the extended schema that may be available in other ways. In each case, the alternatives are
more difficult to implement and some require extensive manual effort.
You can use the schema extensions for the following capabilities:
Client site assignment—
To receive ConfigMgr services, you must first assign a client system to
a site. The schema extensions provide an option for the client to
retrieve the information from AD that it needs to identify and contact
its assigned site.
Client installation properties— A number of configurable options, such as the size of the download cache, are available through the extended schema.
Site mode settings—
The extended schema can supply information to the client about the
site’s security mode and certificate information required for native
sites.
Server locator point and management points—
Clients can use Active Directory to identify the server locator point
and management points. Without the schema extensions you must provide
this information in other ways, such as manually creating special
Windows Internet Naming Service (WINS) entries.
Custom Transmission Control Protocol (TCP)/Internet Protocol (IP) Port information—
If a site has been configured to use nonstandard ports for client
communications, this information can be provided through the schema
extensions.
In addition, the schema
extensions allow for automated public key exchange, thus facilitating
site-to-site communication. If you have clients assigned to your central
site and do not have the schema extended, recovery from a site failure
can require reprovisioning all clients manually using the trusted root
key.
The AD schema extensions
are a key enabling technology for Configuration Manager. You should
extend the schema and take the other steps previously listed in the “Schema Extensions” section of this chapter to publish site information to Active Directory, if this is possible.
