Active Directory Cookbook for windows server 2003- P34 pptx

10 223 0
Active Directory Cookbook for windows server 2003- P34 pptx

Đang tải... (xem toàn văn)

Thông tin tài liệu

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: http://www.winnetmag.com/Articles/Index.cfm?ArticleID=27096 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. . 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. 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. 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

Ngày đăng: 05/07/2014, 08:20

Từ khóa liên quan

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan