Active Directory Cookbook for windows server 2003- P34 pptx

341
' Set to common name of class to view
strClassName = "<ClassCommonName>" ' e.g. Surname
' END CONFIGURATION

set objRootDSE = GetObject("LDAP://RootDSE")
set objClass = GetObject("LDAP://cn=" & strClassName & "," & _
objRootDSE.Get("schemaNamingContext"))

WScript.Echo "Class: " & strClassName & vbCrlf

' Need to enable this so that if an attribute is not set, it won't die
on error resume next

WScript.Echo "mayContain:"
for each strVal in objClass.Get("mayContain")
WScript.Echo vbTab & strVal
next

WScript.Echo vbCrlf & "systemMayContain:"
for each strVal in objClass.Get("systemMayContain")
WScript.Echo vbTab & strVal
next

WScript.Echo vbCrlf & "mustContain:"
for each strVal in objClass.Get("mustContain")
WScript.Echo vbTab & strVal
next

WScript.Echo vbCrlf & "systemMustContain:"

for each strVal in objClass.Get("systemMustContain")
WScript.Echo vbTab & strVal
next
10.18.3 Discussion
The mayContain and systemMayContain attributes define the optional attributes for a class
while the
mustContain and systemMustContain attributes contain the mandatory attributes.
The systemMayContain and systemMustContain attributes are set by Active Directory and
cannot be modified. You need to be careful when adding attributes to the mustContain attribute
for existing classes because you can easily cause objects that use those classes to become invalid
due to not having the mandatory attribute set.
It is also worth noting that each of the solutions display only the attributes defined directly on the
class. It will not show any inherited attributes that are defined by inherited classes.
Recipe 10.19 Modifying the Default Security of a Class
10.19.1 Problem
You want to modify the default security that is applied to objects instantiated from a particular
structural class.

342
10.19.2 Solution

For Windows 2000 Active Directory, you need to enable schema
modifications before proceeding. See Recipe 10.2 for more information.

10.19.2.1 Using a graphical user interface
1. Open the Active Directory Schema snap-in.
2. In the left pane, click on the Classes folder.
3. In the right pane, double-click the class you want to modify the security for.
4. Click the Default Security tab.
5. Modify the security as necessary.

6. Click OK.
10.19.3 Discussion
Whenever a new object is created in Active Directory, a default security descriptor (SD) is
applied to it along with any inherited security from its parent container. The default security
descriptor is stored in the defaultSecurityDescriptor attribute of the classSchema object. If
you modify the default SD, every new object will get that SD, but it does not affect any existing
objects.
10.19.4 See Also
MS KB 265399 (HOW TO: Change Default Permissions for Objects That Are Created in the
Active Directory)
Recipe 10.20 Deactivating Classes and Attributes
10.20.1 Problem
You want to deactivate a class or attribute in the schema because you no longer need it.
10.20.2 Solution
10.20.2.1 Using a graphical user interface
1. Open the Active Directory Schema snap-in.
2. In the left pane, click on the Classes folder.
3. In the right pane, double-click the class you want to deactivate.
4. Uncheck the box beside Class is active.
5. Click OK.
10.20.2.2 Using a command-line interface

343
You can deactivate a class using the ldifde utility and an LDIF file that contains the following
lines:
dn: cn=<SchemaObjectCommonName>,cn=schema,cn=configuration,<ForestRootDN>
changetype: modify
replace: isDefunct
isDefunct: TRUE
-

If the LDIF file were named deactivate_class.ldf, you would run the following command:
> ldifde -v -i -f deactivate_class.ldf
10.20.2.3 Using VBScript
' This code deactivates a class or attribute.
' SCRIPT CONFIGURATION
strName = "<SchemaObjectCommonName>" ' e.g. rallencorp-LanguagesSpoken
' END CONFIGURATION

set objRootDSE = GetObject("LDAP://RootDSE")
set objSchemaObject = GetObject("LDAP://cn=" & strName & "," & _
objRootDSE.Get("schemaNamingContext"))
objSchemaObject.Put "isDefunct", TRUE
objSchemaObject.SetInfo
WScript.Echo "Schema object deactivated: " & strName
10.20.3 Discussion
There is no supported way to delete classes or attributes defined in the schema. You can,
however, deactivate them, also known as making them defunct. Before you deactivate a class
you should make sure that no instantiated objects of that class exist. If you want to deactivate an
attribute, you should make sure no object classes define the attribute as mandatory. After you've
verified the class or attribute is no longer being used, you can deactivate by setting the
isDefunct attribute to TRUE. You can always reactivate it at a later time by simply setting
isDefunct to FALSE. With Windows Server 2003 Active Directory, you can even redefine the
class or attribute while it is defunct. This gives you much more flexibility over reusing classes or
attributes you may have added before, but no longer want.
10.20.4 See Also
Recipe 10.21 for redefining classes and attributes
Recipe 10.21 Redefining Classes and Attributes

This recipe requires the Windows Server 2003 forest functional level.

344
10.21.1 Problem
You want to redefine a class or attribute that was previously created.
10.21.2 Solution
To redefine a class or attribute, you must first deactivate it by setting the isDefunct attribute to
TRUE (see Recipe 10.20 for more details). If you are deactivating a class, make sure no objects
are instantiated that use the class. If you are deactivating an attribute, make sure it isn't populated
on any objects and remove it from any classes that have it defined as part of mayContain and
mustContain. After the class or attribute has been deactivated, you can modify (i.e., redefine)
the LDAP display name (lDAPDisplayName), the OID (governsID or attributeID), the syntax
(attributeSyntax and oMSyntax), and the schemaIDGUID. The one attribute that you cannot
modify is the common name.
10.21.3 Discussion
Redefining schema objects is a new feature of Windows Server 2003. Although you still cannot
delete schema objects in Windows Server 2003,
[1]
you can work around many of the reasons that
would cause you to want to delete a schema object by redefining it instead. Some examples of
when redefine comes in handy includes if you accidentally mistype an OID
(governsID/attributeID) or lDAPDisplayName, or no longer need an attribute you previously
created. You can reuse it by renaming the attribute and giving it a different syntax.
[1]
You could delete schema objects in W2K pre-SP3, but I won't get into that here. You find more information about that here:

10.21.4 See Also
Recipe 10.20 for deactivating classes and attributes
Recipe 10.22 Reloading the Schema Cache
10.22.1 Problem
You want to reload the schema cache so that schema extensions take effect immediately.

10.22.2 Solution
10.22.2.1 Using a graphical user interface
1. Open the Active Directory Schema snap-in.
2. In the left pane, click on Active Directory Schema.
3. Right-click on the label and select Reload the Schema.
10.22.2.2 Using a command-line interface

345
You can reload the schema by using the ldifde utility and an LDIF file that contains the
following:
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
If the LDIF file were named reload.ldf, you would run the following command:
> ldifde -v -i -f reload.ldf
10.22.2.3 Using VBScript
set objRootDSE = GetObject("LDAP://dc1/RootDSE")
objRootDSE.Put "schemaUpdateNow", 1
objRootDSE.SetInfo
WScript.Echo "Schema reloaded"
10.22.3 Discussion
Each domain controller maintains a complete copy of the schema in memory to make access to
the schema very fast. This is called the schema cache. When you extend the schema on the
Schema FSMO role owner, the change is written to the schema cache, and not committed to disk
yet. The schema automatically commits any changes to the schema every five minutes if a
change has taken place, but you can also do it manually/programmatically by writing to the
schemaUpdateNow operational attribute of the RootDSE on the Schema FSMO role owner. Once
that is done, any changes to the schema cache are written to disk.

It is necessary to force a schema cache update if your schema extensions reference newly created
attributes or classes. For example, lets say that we want to create one new auxiliary class that
contains one new attribute. To do that we would first need to create the attribute and then create
the auxiliary class. As part of the auxiliary class' definition, we would need to reference the new
attribute, but unless we reload the schema cache, an error would be returned stating that the
attribute does not exist. For this reason we need to add an additional step. First, create the
attribute, then reload the schema cache, and finally, create the auxiliary class. Here is what an
LDIF representation would look like:
dn: cn=rallencorp-TestAttr,cn=schema,cn=configuration,dc=rallencorp,dc=com
changetype: add
objectclass: attributeSchema
lDAPDisplayName: rallencorp-TestAttr
attributeId: 1.3.6.1.4.1.999.1.1.28.312
oMSyntax: 20
attributeSyntax: 2.5.5.4
isSingleValued: FALSE
searchFlags: 1

dn:
changetype: modify

346
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: cn=rallencorp-TestClass,cn=schema,cn=configuration,dc=rallencorp,dc=com
changetype: add
objectclass: classSchema
lDAPDisplayName: rallencorp-TestClass

governsId: 1.3.6.1.4.1.999.1.1.28.311
subClassOf: top
objectClassCategory: 3
mayContain: rallencorp-TestAttr
10.22.4 See Also
Recipe 10.7 for adding a new attribute to the schema and Recipe 10.9 for adding a new class to
the schema

347
Chapter 11. Site Topology
Introduction
Recipe 11.1. Creating a Site

Recipe 11.2. Listing the Sites
Recipe 11.3. Deleting a Site
Recipe 11.4. Creating a Subnet
Recipe 11.5. Listing the Subnets
Recipe 11.6. Finding Missing Subnets
Recipe 11.7. Creating a Site Link

Recipe 11.8. Finding the Site Links for a Site

Recipe 11.9. Modifying the Sites That Are Part of a Site Link
Recipe 11.10. Modifying the Cost for a Site Link
Recipe 11.11. Disabling Site Link Transitivity or Site Link Schedules
Recipe 11.12. Creating a Site Link Bridge
Recipe 11.13. Finding the Bridgehead Servers for a Site
Recipe 11.14. Setting a Preferred Bridgehead Server for a Site
Recipe 11.15. Listing the Servers

Recipe 11.16. Moving a Domain Controller to a Different Site
Recipe 11.17. Configuring a Domain Controller to Cover Multiple Sites
Recipe 11.18. Viewing the Site Coverage for a Domain Controller

Recipe 11.19. Disabling Automatic Site Coverage for a Domain Controller
Recipe 11.20. Finding the Site for a Client
Recipe 11.21. Forcing a Host to a Particular Site


348
Recipe 11.22. Creating a Connection Object
Recipe 11.23. Listing the Connection Objects for a Server
Recipe 11.24. Load-Balancing Connection Objects
Recipe 11.25. Finding the ISTG for a Site
Recipe 11.26. Transferring the ISTG to Another Server
Recipe 11.27. Triggering the KCC
Recipe 11.28. Determining if the KCC Is Completing Successfully
Recipe 11.29. Disabling the KCC for a Site
Recipe 11.30. Changing the Interval at Which the KCC Runs
Introduction
Active Directory needs information about the network to determine how domain controllers
should replicate and what domain controller(s) are optimal for a given client to authenticate with.
This network information is often referred to as the site or replication topology, and consists of
numerous object types that represent various aspects of the network.
At a high level, a site is a collection of high-speed LAN segments. One or more subnets can be
associated with a site, and this mapping is used to determine which site a client (based on IP
address) belongs to. Sites are connected via site links, which are analogous to WAN connections.
Finally, each domain controller in a site has one or more connection objects, which defines a
replication connection to another domain controller.
These site topology objects are contained under the

Sites container within the Configuration
naming context. Figure 11-1 shows an example of the site topology hierarchy using the Active
Directory Sites and Services snap-in.
Figure 11-1. Site topology hierarchy

349

Directly under the Sites container are the individual site containers, plus containers that store
the site link objects (cn=Inter-site Transports) and subnets (cn=Subnets). There are three
objects included within a site, an NTDS Site Settings (nTDSSiteSettings) object that contains
attributes that can customize replication behavior for the whole site, a License Site Settings
(licensingSiteSettings) object that can be used to direct hosts within the site to the
appropriate licensing server, and a Servers container. The Servers container contains a server
object for each of the domain controllers that are members of the site, along with any other
servers that need to be represented in the site topology (e.g., DFS servers).
A server object can contain a NTDS Settings (nTDSDSA) object, which distinguishes domain
controller server objects from other server objects. The NTDS Settings object stores several
attributes that are used to customize replication behavior for a specific domain controller. The
NTDS Settings object can contain one or more nTDSConnection objects, which define the
replication connections between domain controllers.
The Anatomy of Site Topology Objects
Table 11-1 through Table 11-7 contain some of the important attributes of the various site
topology objects.
Table 11-1. Attributes of site objects
Attribute Description
cn
RDN of the object. This is the name of the site (e.g., Raleigh).
gpLink
Contains a prioritized list of GPOs that are linked to the site.
siteObjectBL

Multivalued attribute that contains a list of distinguished names for each subnet

350
Table 11-1. Attributes of site objects
Attribute Description
that is associated with the site.
Table 11-2. Attributes of nTDSSiteSettings objects
Attribute Description
cn
RDN of the object, which is always equal to NTDS Site
Settings.
interSiteTopologyGenerator
Distinguished name of the NTDS Settings object of the current
Inter-site Topology Generator (ISTG).
msDS-Preferred-GC-Site
If universal group caching is enabled, this contains the
distinguished name of the site that domain controllers should
refresh their cache from. This attribute is new to Windows
Server 2003. See Recipe 7.9 for more information.
options
Bit flag that determines if universal group caching is enabled,
whether site link transitivity is disabled, and if replication
schedules should be ignored. For more information see Recipe
11.11.
schedule
Octet string that represents the default replication schedule for
the site.
Table 11-3. Attributes of subnet objects
Attribute Description
cn

RDN of the object. Contains the network number and bit mask for the subnet (e.g.,
10.1.3.0/24).
siteObject
Distinguished name of the site object the subnet is associated with.
Table 11-4. Attributes of siteLink objects
Attribute Description
cn
RDN of the object. Contains the name of the link.
cost
Number that represents the site link cost. See Recipe 11.10 for more
information.
replInterval
Interval in minutes that replication occurs over the site link.
schedule
Octet string that represents the replication schedule for the site link.