Home > Articles > Operating Systems, Server > Microsoft Servers

  • Print
  • + Share This
This chapter is from the book

Classes

In the overview section of this chapter we introduced classes, and in the "Schema" section we mentioned that there is a class schema object for each class. In this section we examine classes and their schema objects in more detail.

Each class is defined by the attributes of its schema object. This means that examining classes actually means examining those attributes. Each classSchema object may contain at most 95 attributes. However, remember that many of these attributes are not related to defining the schema, but instead are "normal" attributes for any object. Examples of these normal attributes are wWWHomePage and uSNChanged. Here we discuss 36 attributes and omit 59 normal "uninteresting" attributes.

NOTE

You could claim that some of the 36 attributes we address are also uninteresting. For example, they include 5 attributes that are not used at all. We include them so that you don't need to wonder what they are if you run into them with ADSI Edit or some other tool.

NOTE

We list a few numbers of attributes in the text and in Table 8.5. The exact numbers are not important; we mention them to give you an idea of how many different kinds of attributes there are.

Classes can inherit from other classes attributes their instances must and may contain. Of the 95 classSchema attributes, 22 are the class' own attributes and 73 are inherited from the top class. In the list of 36 attributes in Table 8.5, 22 are the class' own attributes and 14 are inherited attributes.

TABLE 8.5 Attributes of a classSchema Object

Name

Type

Source Class

Base Schema Classes (142)

user Class Example

Names and Identifiers

lDAPDisplayName

O

classS.

All values are unique

user

cn (Common-Name)

M

classS.

All values are unique

User

adminDisplayName

O

top

Same as cn

User

name (RDN)

O

top

Same as cn

User

distinguishedName (Obj-Dist-Name)

O

top

All values are unique

CN=User, CN=Schema, CN=Configuration, DC=sanao, DC=com

canonicalName

O

top

All values are unique

sanao.com/ Configuration/ Schema/User

displayName

O

top

Not used

displayNamePrintable

O

top

Not used

classDisplayName

O

classS.

Not used

adminDescription

O

top

Same as cn

User

description

O

top

Not used

governsID

M

classS.

125 are Microsoft IDs (1.2.840.113556), 17 are X.500 IDs (2.5)

1.2.840.113556.1.5.9

schemaIDGUID

M

classS.

All values are unique

ba7a96bf e60dd011

a28500aa 003049e2

objectGUID

O

top

All values are unique

4856468b 62963047

8c32fcfe 70f6ca9b

rDNAttID

O

classS.

134 x cn, 4 x dc, 1 x c, 1 x l, 1 x o, 1 x ou

cn

Structure and Containment Rules

mustContain

O

classS.

All are <not set>

systemMustContain

O

classS.

51 are set; 91 are <not set>

mayContain

O

classS.

All are <not set>

systemMayContain

O

classS.

116 are set; 26 are <not set>

A long list of attributes

possSuperiors

O

classS.

All are <not set>

systemPossSuperiors

O

classS.

134 are set; 8 are <not set>

builtinDomain + organizationalUnit + domainDNS

possibleInferiors

O

top

56 are set (=container); 86 are not (=leaf)

nTFRSSubscriptions + classStore

Class Inheritance

objectClassCategory

M

classS.

124 are structural; 14 are abstract; 4 are auxiliary; none are 88-classes

1 (=structural)

subClassOf

M

classS.

89 are top; 53 are others

organizationalPerson

auxiliaryClass

O

classS.

All are <not set>

systemAuxiliaryClass

O

classS.

7 are set, 135 are <not set>

securityPrincipal + mailRecipient

Miscellaneous

nTSecurityDescriptor

M

top

All are set

A DACL, SACL, and so on

isDefunct

O

classS.

All are <not set>

defaultObject- Category

M

classS.

Almost all are same as the class distinguished name

CN=Person, CN=Schema, CN=Configuration, DC=sanao, DC=com

defaultHidingValue

O

classS.

123 are True; 19 are False

False

defaultSecurity- Descriptor

O

classS.

138 are set; 4 are <not set>

Almost a 1,000-character- long string, starting with D:(A;;RPWPCRCCDC

systemOnly

O

classS.

8 are True; 134 are False

False

systemFlags

O

top

140 are set; 2 are <not set>

16

objectClass

M

top

All are top+

top + classSchema

 

 

 

classSchema

 

objectCategory

M

top

All are CN=Class- Schema, CN=Schema, CN=Configuration, DC=sanao, DC=com

CN=Class-Schema, CN=Schema, CN=Configuration, DC=sanao, DC=com

schemaFlagsEx

O

classS.

Not used


We have divided the 36 attributes into four categories. These categories resemble those listed in the "Role of the Schema" section earlier in this chapter (see Table 8.1 and Table 8.2).

  • Names and identifiers. There are 14 of these attributes (plus 1 naming-type attribute). Fortunately, not all of them are used.

  • Structure and containment rules. These 7 attributes define where in the tree each object may be created (or instantiated) and which attribute values it must and may contain.

  • Class inheritance. A class may inherit containment from another class. The 4 attributes in this category define how this happens.

  • Miscellaneous. The remaining 10 attributes provide some defaults, for example, to the objects that will be created to the corresponding class.

Table 8.5 lists the 36 attributes by their LDAP names. If the common name has no resemblance to the LDAP name, the common name appears in parentheses (such as "distinguishedName (Obj-Dist-Name)"). The Type column indicates whether the attribute is mandatory or optional. The Source Class column indicates either classSchema or top, the latter meaning the attribute was inherited from the top class. The Base Schema Classes column gives a summary of the kind of values the 142 classes have for the attributes in the table. Finally, the user Class Example column lists the values for the user class.

In the remaining subsections, we examine each of the four categories.

Names and Identifiers

The various names and identifiers identify the classes by both people and Active Directory. This category of 15 attributes includes nine different names, two descriptions, and three identifiers. The fifteenth attribute (rDNAttID) is none of these, but we include it in this category because it is name-related.

Table 8.6 describes the 15 attributes. Fortunately, Active Directory doesn't use quite all of them, as indicated in the table. Consequently, we are left with "only" six different names and one description. Furthermore, canonicalName, distinguishedName, and RDN are redundant with cn, because you can derive them directly from cn. This leaves us with three "nonredundant" names (the first three in Table 8.6) and one description.

TABLE 8.6 Name and Identifier Attributes of a classSchema Object

Name

Syntax1

Multi- valued

Description

user
Class Example

lDAPDisplayName

Unicode string

No

Name to identify the class in ADSI scripts, LDAP filters, many low-level admin tools, and internally with all LDAP access.

user

cn (Common-Name)

Unicode string

No

Actual name of the class schema object.

User

adminDisplayName

Unicode string

No

Name that admin tools can use as their display name if there isn't a name in the Display- Specifiers container. If adminDisplayName is also not specified, the system will use cn instead.

User

name (RDN)

Unicode string

No

Same as cn.

User

distinguishedName

Distin-

No

"cn with a path,"

CN=User, CN=...

(Obj-Dist-Name)

guished name

 

identifies the location of the object (which is always the Schema container).

 

canonicalName

Unicode string

Yes

"cn with a path," but using a different format from distinguishedName.

sanao.com/ Configuration/ Schema/User

displayName

Unicode string

No

Not used.

displayName- Printable

Printable string

No

Not used.

classDisplayName

Unicode string

Yes

Not used.

adminDescription

Unicode string

No

Descriptive text for the class for admin tools.

User

description

Unicode string

Yes

Not used.

governsID

OID string

No

Object ID (OID) of the class (see the section, "Object Identifiers").

1.2.840.113556.1.5.9

schemaIDGUID

Octet string

No

128-bit unique GUID to identify the class.

ba7a96bf e60dd011

a28500aa 003049e2

objectGUID

Octet string

No

128-bit unique GUID to identify this class schema object (as well as any object in Active Directory).

4856468b 62963047

8c32fcfe 70f6ca9b

rDNAttID2

OID string

No

Whether the class pre- fix is cn=, ou=, dc=, c=, l=, or o=. This attribute also specifies whether the naming attribute(i.e., RDN) of the instances of this class is cn, ou, or some of the other choices just listed.

cn


Object Identifiers

As you see in Table 8.6, one of the many identifiers for each class schema object is an object identifier (OID). An OID consists of numbers that have dots in between them, such as 1.3.6.1.4.1.123123. The number is hierarchical, so the first number in an OID is the highest level of the tree.

Anyone who "owns" a certain OID can allocate new child OIDs to it. For example, if you have the base OID 1.2.3, you could allocate to it OIDs, such as 1.2.3.1, 1.2.3.77, and 1.2.3.77.4.3.2.1.

Just like IP addresses, OIDs are administered globally so that no two organizations in the world can have the same base OID. OIDs allow unique identification of all kinds of things—they are used to identify classes, attributes, and syntaxes in X.500 directories and variables in Simple Network Management Protocol (SNMP), among other things.

Microsoft uses the base OID 1.2.840.113556.1 in many Active Directory classes (and attributes). Table 8.7 describes the history of that OID.

TABLE 8.7 Microsoft Active Directory OIDs

Value

Owner

1

ISO, which issued 1.2 to ANSI

1.2

ANSI, which issued 1.2.840 to USA

1.2.840

USA, which issued 1.2.840.113556 to Microsoft

1.2.840.113556

Microsoft, which issued 1.2.840.113556.1 to Active Directory

1.2.840.113556.1

Active Directory, where class schema objects use either 1.2.840.113556.1.3 or 1.2.840.113556.1.5, and attribute schema objects use either 1.2.840.113556.1.2 or 1.2.840.113556.1.4.


NOTE

Not all class schema objects and attribute schema objects of the Active Directory base schema use the OIDs in Table 8.7. Some use OIDs defined in X.500 or some other source.

Another base OID that Microsoft owns is 1.3.6.1.4.1.311. Each numeric part has a name, so we can express this same base OID as iso.org.dod.internet. private.enterprise.microsoft. "Org" in the name indicates an "identified organization" that ISO acknowledges and "dod" indicates the U.S. Department of Defense. These "private enterprise numbers" are currently assigned by the Internet Corporation for Assigned Names and Numbers (ICANN, http://www. icann.org/). In addition to assigning enterprise OID numbers, ICANN coordinates the assignment of Internet domain names and IP address numbers. You can see the current list of assigned private enterprise numbers at ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers.

Recall that we discussed the X.500 standards in Chapter 1. OIDs have similar roots, as they were first defined in ITU-T X.208, which corresponds to ISO/IEC 8824. However, X.208 has been superseded by the ITU-T recommendation X.680 (12/97): "Abstract Syntax Notation One (ASN.1): Specification of basic notation."

In addition to the OID notation, X.680 specifies the following base OIDs:

  • 0: ITU-T assigned.

  • 1: ISO assigned.

  • 2: Joint ISO/ITU-T assigned. Active Directory contains some classes and attributes from X.500, and they use the base OIDs 2.5.6 and 2.5.4, respectively. There is also one "2.5.20" class ("X.500 schema object class") and six "2.5" attributes other than 2.5.4.

You can inspect various assigned OIDs at http://www.alvestrand.no/domen/objectid/top.html.

Obtaining a Base OID

If your organization needs to add classes or attributes to the schema, it must obtain a base OID. This need could rise from two situations.

  • You need to modify the Active Directory schema of your organization.

  • You sell applications to other organizations, and those applications need to modify the schema of the customer Active Directory.

There are three ways to get a base OID.

  • Run the OIDGEN utility included in the Windows 2000 Resource Kit. It generates one base OID for classes and another for attributes. A resulting OID could be 1.2.840.113556.1.4.7000.233.28688.28684.8.96821.760998.1196228.1142349. You can use these OIDs in your tests, but for a production network you should register a base OID, as explained in the next two choices.

  • Apply for a free private enterprise number from ICANN using the form at http://www.isi.edu/cgi-bin/iana/enterprise.pl. You should receive a number (1.3.6.1.4.1.something) in a few days by e-mail.

  • Apply for a base OID from another issuing authority, perhaps for a fee. Many countries have a country-specific organization to issue OIDs. For organizations in United States, you can try ANSI and the Web page http://web.ansi.org/public/services/reg_org.html. (However, ANSI seems not to be very responsive. We sent e-mail to three people whose e-mail addresses appeared on the ANSI Web page regarding OIDs, but we have not received an answer from them in 6 months.)

Once you get the base OID, you should establish the policy regarding administration of the numbers in your organization, just like you probably have had to do with IP addresses. For example, you can dedicate the branch ".1" to new classes and ".2" to new attributes. Because OIDs are a general standard, you may also need the base OID for uses other than Active Directory.

Structure and Containment Rules

The main job of the schema is to establish the structure and content rules for Active Directory. This is done with the first six attributes described in Table 8.8. They consist of three pairs of a normal attribute and a system attribute (mustContain + systemMustContain, mayContain + systemMayContain, and possSuperiors + systemPossSuperiors).

When creating classes, administrators can set all six attributes. For existing classes, they can change only the three normal attributes, not their system counterparts. The base schema uses only the three system attributes; it does not use their normal counterparts. This way, Active Directory can protect the base schema definitions. You cannot remove base schema attributes from any base schema class, nor can you remove possible parent classes.

NOTE

Even if an attribute is not a system attribute, it doesn't mean that you can change it freely. There are other restrictions to modifying the schema, which we discuss in the next chapter.

Because all seven attributes here are multivalued and use the OID string syntax, Table 8.8 does not include this information. Table 8.8 indicates if each attribute is constructed and if only the system, but not an administrator, can alter the value.

NOTE

If you compare the constructed possibleInferiors attribute to the attributes on which it is based, they seem not to match. The reason is that possibleInferiors accounts for the effect of inheritance, as discussed in the next subsection.

Figure 8.9 illustrates the role of the structure and containment attributes. The systemMayContain attribute of a classSchema object lists some of the attributes (inheritance may list more) that the instances of that class may contain (i.e., optional attributes). SystemPossSuperiors specifies some of the possible parents that the instances may have, and possibleInferiors displays the list of possible children.

Figure 8.9 The main job of the schema is to establish the structure and content rules for Active Directory.

Four constructed attributes that are based on the attributes in Table 8.8 reside in the normal objects, such as users. Therefore, these attributes are not part of the schema, but still, you can study the schema by studying them.

TABLE 8.8 Structure and Containment Attributes of a classSchema Object

Name

Constructed

System Only

Description

user Class Example

mustContain

No

No

Admin-changeable list of mandatory attributes for the instances of this class

systemMust- Contain

No

Yes

Same as previous, but only the Directory System Agent (DSA) can change the list after the class has been created

mayContain

No

No

Admin-changeable list of optional attributes for the instances of this class

systemMay- Contain

No

Yes

Same as previous, but only the DSA can change the list after the class has been created

A long list of attributes

possSuperiors

No

No

Admin-changeable list of possible parent containers for the instances of this class

systemPoss- Superiors

No

Yes

Same as previous, but only the DSA can change the list after the class has been created

builtinDomain + organizational- Unit + domainDNS

possible- Inferiors

Yes3

Yes

List of the classes that an instance of this class can contain instances of (i.e., possible child object types)

nTFRS- Subscriptions + classStore


  • AllowedChildClasses and allowedChildClassesEffective both contain the same information as possibleInferiors (mentioned in Table 8.8), but they reside in normal objects, such as the user Jack Brown.

  • AllowedAttributes and allowedAttributesEffective both contain a list of all mandatory and optional attributes of an object. For example, with Jack Brown, these two attributes both contain a list of 207 attributes, the number of mandatory and optional attributes of any user class object.

These four constructed attributes also take into account class inheritance.

Class Inheritance

A class gets most of its characteristics from the corresponding class schema object. However, a class inherits some features from several class schema objects, using class inheritance. We can also say that a class is derived from another class.

In this section we explain how, by means of inheritance, the list of possible superiors, mandatory attributes, and optional attributes are built from the information in several objects.

Class inheritance makes defining new classes easier, because they can build on existing classes. There is no need to list all possible superiors and attributes from the ground up. Table 8.9 lists the four attributes relevant to class inheritance.

TABLE 8.9 Class Inheritance Attributes of a classSchema Object

Name

Syntax

Multi- valued

Description

user
Class Example

objectClass- Category

Enumeration

No

1 = Structural

2 = Abstract

3 = Auxiliary

0 = 88-class

1 (=structural)

subClassOf

OID string

No

The class from which this class inherits containment and structure attributes. The parent is called a superclass and the child a subclass.

organizational- Person

auxiliaryClass

OID string

Yes

Admin-changeable list of auxiliary classes from which this class inherits containment attributes.

system- AuxiliaryClass

OID string

Yes

Same as previous, but only the Directory System Agent (DSA) can change the list.

securityPrincipal + mailRecipient


User Class Example

Figure 8.10 illustrates the way the three lists (possible superiors, mandatory attributes, and optional attributes) are built up for the user class. We picked the user class as an example because it is by far the most intuitive.

Figure 8.10 he list of possible superiors, mandatory attributes, and optional attributes for each class is the sum of its own list and the lists of all its superclasses. Also, auxiliary classes may add attributes to the list of mandatory and optional attributes.

The inheritance chain in Figure 8.10 (top—person—organizationalPerson—user) has nothing to do with the hierarchy of the schema objects. They all exist as siblings in CN=Schema, CN=Configuration, DC=sanao, DC=com. Nor is there any connection with the normal directory hierarchy (domain—OU—user).

Figure 8.10 requires several explanatory comments.

  • To save space, we abbreviated attribute names—sMayContain instead of systemMayContain, and so on.

  • In addition to the system attributes shown in Figure 8.10, mustContain, mayContain, and possSuperiors also will inherit. This base schema example just doesn't happen to use them.

  • Top has 69 optional attributes and person has 4 of its own. Still, the sum is 72 instead of 73 because there is 1 common attribute. For the same reason, the other sums may be a little less than you might expect.

  • The two auxiliary classes securityPrincipal and mailRecipient are also subclasses of top. To keep the figure simple, and because this relationship has no effect, Figure 8.10 does not show this relationship.

  • In Figure 8.10, only the user class happens to use auxiliary classes. Any superclass could also use auxiliary classes, in which case those attribute lists would also affect the subclasses.

  • We show LDAP names (such as mailRecipient) as object names, even though to be precise the object names should be common names (such as Mail-Recipient). LDAP names appear because in this book we systematically call classes and attributes by their LDAP names.

Class Categories

Each class in Figure 8.10 was marked to be in one of three categories: structural, abstract, or auxiliary. Active Directory classes belong to four categories, as Table 8.10 describes. Figure 8.11 shows three categories of classes and their relationships as superclasses and subclasses.

Figure 8.11 A class of any category can be inherited, or derived, from an abstract class. Only an auxiliary class can be inherited from another auxiliary class and only a structural class can be inherited from another structural class. In addition, the attribute lists in auxiliary classes can be used in abstract and structural classes (indicated by the dashed arrows).

TABLE 8.10 Class Categories

Category

Number of Classes in the Base Schema

Can Be Instantiated4

Purpose and Comments

Structural

124

Yes

  • Structural classes are the normal ones, because you can actually create objects for these classes.

  • Structural classes are derived from abstract or other structural classes and they can include auxiliary classes.

Abstract

14

No

  • Abstract classes act as templates from which you can derive the actual structural classes or auxiliary and other abstract classes, if necessary.

Auxiliary

4

No

  • Auxiliary classes just store lists of mandatory and optional attributes, which you can include in other classes.

  • Auxiliary class can be derived from another auxiliary class.

88-class

0

Yes

  • The 1993 version of X.500 introduced the three previous categories. Any class created before that time belongs to a generic 88-class, which refers to the year 1988 when the previous version of the standard was approved. You shouldn't create any 88-class classes.


Miscellaneous Characteristics of Classes

As the last set of class characteristics, we discuss ten miscellaneous attributes. Three of them provide defaults for objects to be created and four are quite general attributes that any Active Directory object will have. See Table 8.11 for details.

Table 8.11 introduces the following four concepts:

  • showInAdvancedViewOnly

  • Category 1 and 2 schema objects

  • objectCategory

  • Security Descriptor Definition Language (SDDL)

ShowInAdvancedViewOnly

All Active Directory objects have a showInAdvancedViewOnly attribute, which is derived from the top class. If the value of this attribute is set to True, an administrative snap-in can choose not to show the object in the user interface. If the attribute value is False or missing, an administrative snap-in should show the object.

Many objects are not interesting even to administrators, so setting this attribute helps to hide those objects. When you turn on Advanced Features in the Users and Computers snap-in, you make visible those objects that have the showInAdvancedViewOnly attribute set to True.

NOTE

CN=Dfs-Configuration has the value False for this attribute. However, it doesn't show in the normal view of the Users and Computers snap-in because the parent container, CN=System, has a value True. Once you turn on Advanced Features, they will both show.

Category 1 and 2 Schema Objects

One bit in the systemFlags attribute tells whether the class belongs to category 1 or 2. Category 1 classes and attributes are part of the base schema, and category 2 schema objects are something that you or your application have added. In other words, category 2 schema objects are part of the schema extensions.

The reason for the two categories is that there can be (and there are) stricter rules for modifications of category 1 schema objects.

Object Category

You have seen the word "category" used in more than one context in this chapter. Here is one more: As you know, each object belongs to some class—to be exact, it also belongs to all superclasses of the main class. For example, the object Jack Brown belongs to the classes user, person, organizationalPerson, and top. To be able to contain this list, the objectClass attribute is multivalued.

Each object belongs also to some object category, as expressed with a single-valued attribute objectCategory. The object category is usually the same as the class, but it may be different, most likely one of the superclasses. For example, the objectCategory of most user class objects is person, which is two steps up in the class hierarchy.

As you can see in Table 8.11, the schema defines only the defaultObjectCategory of each class, but the actual objectCategory attribute is per object. Consequently, two objects of the same class could belong in theory to two categories. However, this would only make things more confusing when you used the category as a search criterion. Also, Active Directory doesn't allow changing the defaultObjectCategory of any base schema object or the objectCategory of any existing object, which fortunately makes this confusing situation difficult to achieve.

Using object categories in LDAP filters and queries has the following advantages over using object classes.

  • ObjectCategory is an indexed attribute, whereas objectClass is not. Therefore, LDAP filters and queries that use objectCategory are much faster than those that use just objectClass.

  • Objects of several classes can use the same category. If you use a filter or query objectCategory=person, you will get a list of all people, regardless of whether they are users or contacts. Apart from this "person = user + contact," however, the base schema doesn't contain practical examples of several classes using the same object category.

Security Descriptor Definition Language

Microsoft uses Security Descriptor Definition Language (SDDL) whenever a security descriptor should be described in a string format. Two examples of this are as follows:

  • The defaultSecurityDescriptor attribute, mentioned in Table 8.11

  • Security templates, which are INF files in C:\Winnt\Security\Templates

TABLE 8.11 Miscellaneous Attributes of a classSchema Object

Name

Syntax

Multi- valued

Description

user
Class Example

nTSecurity- Descriptor

NT security descriptor

No

Security descriptor of the class schema object; allows Schema Admins to modify and other users to read schema objects.

A DACL, SACL, and so on

isDefunct

Boolean

No

If set to True, the class is disabled.

defaultObject- Category

Distinguished name

No

Default value for objectCategory attribute for each new instance of this class.

CN=Person, CN=...

defaultHiding- Value

Boolean

No

Default value for showInAdvanced- ViewOnly attribute for each new instance of this class.

False

defaultSecurity- Descriptor

Unicode string

No

Default value for the security descriptor for each new instance of this class, using Security Descriptor Definition Language (SDDL). The program that will create the instance can also specify a security descriptor to replace this default.

Long string, starting with D:(A;;RPWPCR

systemOnly

Boolean

No

If set to True, only the Directory System Agent (DSA) can create and modify instances of this class.

False

systemFlags

Integer

No

Fifth bit from right (0x10) tells whether this class belongs to category 1 (part of the base schema) or category 2(an extension).

16 (=0x10)

objectClass

OID string

Yes

Class of this class schema object itself, the value is obviously classSchema for all class schema objects(plus the superclass top—see discussion about object categories later in this chapter).

top + classSchema

objectCategory

Distinguished name

No

Object category of this class schema object itself, the value is the distinguished name of the object CN=Class- Schema for all class schema objects.

CN=Class-Schema, CN=Schema, CN=...

schemaFlagsEx

Integer

No

Not used


We explain SDDL briefly here by interpreting the defaultSecurityDescriptor for the group class (i.e., for each new group that you create). We don't use the user class as an example because the string would be ten times longer. For a detailed description of SDDL, refer to the Microsoft Platform SDK (software development kit) at http://msdn.microsoft.com/library.

The SDDL string for the group class is

D:
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPLCLORC;;;AU)
(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)
(A;;RPLCLORC;;;PS)
(OA;;CR;ab721a55-1e2f-11d0-9819-00aa0040529b;;AU)

NOTE

The string is divided here on seven lines to make it easier to read. In reality, it is one long string.

To interpret the string, you must be familiar with the contents of a security descriptor, as discussed in Chapter 4.

The D: in this string means that the subsequent data is a discretionary ACL. The owner, group, and system ACL are not included in this case.

The rest of the string consists of six pairs of parentheses, each of which is one ACE. The ACE in turn consists mostly of two-letter acronyms specifying who has what permissions.

The semicolons divide each ACE into six fields:

  • ACE type
  • ACE flags
  • Permissions
  • Object GUID
  • Inherit object GUID
  • Account SID

Table 8.12 shows the interpretation of the six ACEs. You can compare its elements to the SDDL string. Table 8.13 lists the SDDL acronyms, their spelled-out names, and their corresponding permission names in the user interface (i.e., in ACL Editor).

TABLE 8.12 Default ACEs for a Group Object

ACE Type

Permissions5

Object GUID

Account SID

Access allowed

Read Prop, Write Prop, Control Access, Create Child, Delete Child, List Children, List Object, Read Control, Write Owner, Write DAC, Standard Delete, Delete Tree, Self Write

 

Domain Admins

Access allowed

Read Prop, Write Prop, Control Access, Create Child, Delete Child, List Children, List Object, Read Control, Write Owner, Write DAC, Standard Delete, Delete Tree, Self Write

 

System

Access allowed

Read Prop, List Children, List Object, Read Control

 

Authenticated Users

Access allowed

Read Prop, Write Prop, Control Access, Create Child, Delete Child, List Children, List Object, Read Control, Write Owner, Write DAC, Standard Delete, Delete Tree, Self Write

 

Account Operators

Access allowed

Read Prop, List Children, List Object, Read Control

 

(Personal) Self

Object access allowed

Control Access (i.e., extended rights)

Send to

Authenticated Users


TABLE 8.13 SDDL Permissions

 

SDDL

SDDL Spelled-

Name in the

AccessMask Bit Name

Acronym

Out Name

User Interface

ADS_RIGHT_DS_CREATE_CHILD

CC

Create Child

Create All Child Objects

ADS_RIGHT_DS_DELETE_CHILD

DC

Delete Child

Delete All Child Objects

ADS_RIGHT_ACTRL_DS_LIST

LC

List Children

List Contents

ADS_RIGHT_DS_SELF

SW

Self Write

All Validated Writes

ADS_RIGHT_DS_READ_PROP

RP

Read Prop

Read All Properties

ADS_RIGHT_DS_WRITE_PROP

WP

Write Prop

Write All Properties

ADS_RIGHT_DS_DELETE_TREE

DT

Delete Tree

Delete Subtree

ADS_RIGHT_DS_LIST_OBJECT

LO

List Object

List Object

ADS_RIGHT_DS_CONTROL_ACCESS

CR

Control Access

All Extended Rights

ADS_RIGHT_DELETE

SD

Standard Delete

Delete

ADS_RIGHT_READ_CONTROL

RC

Read Control

Read Permissions

ADS_RIGHT_WRITE_DAC

WD

Write DAC

Modify Permissions

ADS_RIGHT_WRITE_OWNER

WO

Write Owner

Modify Owner


ClassSchema Object Property Pages

We conclude our discussion on classes by showing the Schema Manager snap-in property pages for a classSchema object. We picked (once again) the user class as an example.

We show three screen shots (Figure 8.12 through 8.14)—one for each property page. We exclude the Security tab because it is a normal access control screen. For each screen, we list the attributes that correspond to the fields in the screen.

In the course of this section we have discussed 38 attributes of a class. The screens in Figure 8.12 through 8.14 show the values for only 12 of them (13 if you count the Security tab) corresponding to the nTSecurityDescriptor attribute. To see the remaining attributes, you need to use ADSI Edit.

Figure 8.12 With the Schema Manager snap-in you can see the attributes of various classes, such as the user class.

Figure 8.12 shows the General tab. The corresponding attributes from top to bottom are as follows (the values are shown in parentheses):

  • lDAPDisplayName ("user")

  • adminDescription ("User")

  • cn ("User")

  • governsID ("1.2.840.113556.1.5.9")

  • objectClassCategory ("Structural")

  • defaultObjectCategory ("person")

  • showInAdvancedViewOnly (Note that the snap-in shipping with the original Windows 2000 has a bug so that setting this check box doesn't have the desired effect. The check box should control defaultHidingValue, which in turn controls the showInAdvancedViewOnly attribute of the objects to be created.)

  • isDefunct ("not set")

Figure 8.13 shows the Relationship tab. The corresponding attributes from top to bottom are as follows (the values are shown in parentheses):

Figure 8.13 The Relationship tab shows both the inheritance hierarchy in the schema and the possible superiors in the normal directory tree.

  • subClassOf ("organizationalPerson")

  • auxiliaryClass, systemAuxiliaryClass ("mailRecipient, securityPrincipal")

  • possSuperiors, systemPossSuperiors ("builtinDomain, domainDNS, organizationalUnit")

Figure 8.14 shows the Attributes tab. The corresponding attributes from top to bottom are as follows (the values are shown in parentheses):

Figure 8.14 The Attributes tab lists the mandatory and optional attributes for the class, excluding inherited attributes.

  • mustContain, systemMustContain (empty list)

  • mayContain, systemMayContain (a number of attributes)

Now that we have covered the different aspects of schema classes, we are ready to move on to the attributes and syntaxes. Attribute characteristics have something in common with class characteristics, but obviously there are also quite a few differences.

  • + Share This
  • 🔖 Save To Your Account