1.4 Schema

Schema defines the types of objects that can be created in your tree (such as Users, Printers, and Groups) and what information is required or optional at the time the object is created. Every object has a defined schema class for that type of object.

The schema that originally shipped with the product is called the base schema. After the base schema has been modified in any way, such as adding a new class or a new attribute, then it is considered the extended schema.

You aren't required to extend the schema, but you have the ability to do so. The Schema role in iManager lets you extend the schema to meet organizational needs. For example, if your organization requires special footwear for employees and you need to keep track of employee shoe sizes, you might want to create a new attribute called Shoe Size and add the attribute to an auxiliary class. You can then use that auxiliary class to extend User objects as needed. For more information about creating auxiliary classes, see Creating an Auxiliary Class.

For more information about working with the eDirectory schema, see Section 5.0, Managing the Schema.

1.4.1 Schema Management

The Schema role in NetIQ iManager lets users who have the Supervisor rights to a tree customize the schema of that tree. The Schema role, and its associated tasks, is available on the Roles and Task page in iManager.

Use the Schema role to

  • View a list of all classes and attributes in the schema.

  • View information on an attribute such as its syntax and flags.

  • Extend the schema by adding a class or an attribute to the existing schema.

  • Create a class by naming it and specifying attributes, flags, containers that it can be added to, and parent classes that it can inherit attributes from.

  • Create an attribute by naming it and specifying its syntax and flags.

  • Add an optional attribute to an existing class.

  • Delete a class or attribute that is not used or that is obsolete.

1.4.2 Schema Classes, Attributes, and Syntaxes

Classes

A class is like a template for a directory object. A directory object is a class that has been filled in with data. In other words:

CLASS + DATA = DIRECTORY OBJECT

Each class has a class name, an inheritance class (unless it is at the top of the class hierarchy), class flags, and a group of attributes. Classes are named like directory objects (User, Printer, Queue, Server, etc.), yet they are just structure, with no content.

An inheritance class is a class that is a starting point for defining other object classes. All of the attributes of the inheritance class are inherited by the classes that come below it in the class hierarchy.

A class hierarchy shows how a class is associated with its parent classes. This is a way of associating similar classes and allowing attributes to be inherited. It also defines the types of containers the class is valid in.

When creating a new class, you can use the class hierarchy and the additional attributes available to customize each class. You can specify an inheritance class (which allows the new class to inherit all of the attributes and flags of a class higher in the hierarchy) and then customize the new class by selecting one or more attributes to add to those that were inherited. The additional attributes can be selected as mandatory, naming, or optional attributes.

You can also modify existing classes by adding optional attributes.

Attributes

Attributes are the data fields in the eDirectory database. For example, if a class is like a form, then an attribute is one field on the form. When an attribute is created, it is named (surname or employee number) and given a syntax type (string or number). From then on, it is available in the attribute lists in Schema Manager.

NOTE:Due to a replication issue, attributes in eDirectory other than the stream attribute type cannot contain values larger than 60 KB or 30,000 characters. If a user or application sets the value of a string or binary attribute and exceeds that limit, eDirectory returns a -649 error indicating that the value is too long.

Syntaxes

There are several syntax options to choose from. These are used to specify the type of data entered for each attribute. The syntax can be specified only when an attribute is created. You cannot modify it later. Available syntaxes include the following:

  • Back Link

    Used to keep track of other servers referring to an object. It is used for internal eDirectory management purposes.

  • Boolean

    Used by attributes whose values are True (represented as 1) or False (represented as 0). The single-valued flag is set for this syntax type.

  • Case Exact String

    Used by attributes whose values are Unicode strings that are case sensitive in comparison operations. Two Case Exact Strings match when they are of the same length and their corresponding characters, including case, are identical.

  • Case Ignore List

    Used by attributes whose values are ordered sequences of Unicode strings that are not case sensitive in comparisons operations. Two Case Ignore Lists match if the number of strings in each is the same and all corresponding strings match (that is, they are the same length and their corresponding characters are identical).

  • Case Ignore String

    Used by attributes whose values are Unicode strings that are not case sensitive in comparison operations. Two Case Ignore Strings match when they are of the same length and their corresponding characters are identical in all respects except that of case.

  • Class Name

    Used by attributes whose values are object class names. Two Class Names match when they are of the same length and their corresponding characters are identical in all respects except that of case.

  • Counter

    Used by attributes whose values are incrementally modified numeric signed integers. Any attribute defined using Counter is a single-valued attribute. This syntax differs from Integer in that any value added to an attribute of this syntax is arithmetically added to the total, and any value deleted is arithmetically subtracted from the total.

  • Distinguished Name

    Used by attributes whose values are the names of objects in the eDirectory tree. Distinguished Names (DN) are not case sensitive, even if one of the naming attributes is case sensitive.

  • EMail Address

    Used by attributes whose values are strings of binary information. eDirectory makes no assumption about the internal structure of the content of this syntax.

  • Facsimile Telephone Number

    Specifies a string that complies with the E.123 standard for storing international telephone numbers and an optional bit string formatted according to recommendation T.20. Facsimile Telephone Number values match when they are of the same length and their corresponding characters are identical, except that all spaces and hyphen characters are ignored during comparison.

  • Hold

    Used by attributes that are accounting quantities, whose values are signed integers. This syntax is an accounting quantity (which is an amount tentatively held against a subject’s credit limit, pending completion of a transaction). The hold amount is treated similarly to the Counter syntax, with new values added to or subtracted from the base total. If the evaluated hold amount goes to 0, the Hold record is deleted.

  • Integer

    Used by attributes represented as signed numeric values. Two Integer values match if they are identical. The comparison for ordering uses signed integer rules.

  • Integer 64

    Used by attributes represented as 64-bit integer values. Integer 64 attributes support the Microsoft Large Integer Syntax and can be used to store large-integer values or dates previous to 1970 or beyond 2038.

    NOTE:eDirectory uses its existing syntax and 32-bit values for internal timestamps.

  • Interval

    Used by attributes whose values are signed numeric integers and represent intervals of time. The Interval syntax uses the same representation as the Integer syntax. The Interval value is the number of seconds in a time interval.

  • Net Address

    Represents a network layer address in the server environment. The address is in binary format. For two values of Net Address to match, the type, length, and value of the address must match.

  • Numeric String

    Used by attributes whose values are numerical strings as defined in the CCITT X.208 definition of Numeric String. For two Numeric Strings to match, the strings must be the same length and their corresponding characters must be identical. Digits (0...9) and space characters are the only valid characters in the numeric string character set.

  • Object ACL

    Used by attributes whose values represent Access Control List (ACL) entries. An Object ACL value can protect either an object or an attribute.

  • Octet List

    Describes an ordered sequence of strings of binary information or Octet String. An Octet List matches a stored list if it is a subset of the stored list. For two Octet Lists to match, they must be the same length, and the corresponding bit sequence (octet) must be identical.

  • Octet String

    Used by attributes whose values are strings of binary information not interpreted by eDirectory. These octet strings are non-Unicode strings. For two octet strings to match, they must be the same length, and the corresponding bit sequence (octet) must be identical.

  • Path

    Attributes that represent a file system path contain all the information to locate a file on a server. Two paths match when they are of the same length and their corresponding characters, including case, are identical.

  • Postal Address

    Used by attributes whose values are Unicode strings of postal addresses. An attribute value for Postal Address is typically composed of selected attributes from the MHS Unformatted Postal O/R Address Specification version 1 according to recommendation F.401. The value is limited to six lines of 30 characters each, including a postal country name. Two postal addresses match if the number of strings in each is the same and all corresponding strings match (that is, they are the same length and their corresponding characters are identical).

  • Printable String

    Used by attributes whose values are printable strings, as defined in CCITT X.208. The printable character set consists of the following:

    • Uppercase and lowercase alphabetic characters

    • Digits (0...9)

    • Space character

    • Apostrophe (’)

    • Left and right parentheses ( )

    • Plus sign (+)

    • Comma (,)

    • Hyphen (-)

    • Period (.)

    • Forward slash (/)

    • Colon (:)

    • Equals sign (=)

    • Question mark (?)

    Two printable strings are equal when they are the same length and their corresponding characters are the same. Case is significant.

  • Replica Pointer

    Used by attributes whose values represent partition replicas. A partition of an eDirectory tree can have replicas on different servers. The syntax has six components:

    • Server Name

    • Replica Type (master, secondary, read-only, subordinate reference)

    • Replica Number

    • Replica Root ID

    • Number of Address

    • Address Record

  • Stream

    Represents arbitrary binary information. The Stream syntax provides a way to make an eDirectory attribute out of a file on a file server. Login scripts and other stream attributes use this syntax. The data stored in a stream file has no syntax enforcement of any kind. It is completely arbitrary data, defined by the application that created and uses it.

  • Telephone Number

    Used by attributes whose values are telephone numbers. Two telephone numbers match when they are of the same length and their corresponding characters are identical, except that all spaces and hyphen characters are ignored during comparison.

  • Time

    Used by attributes whose values are unsigned integers and represent time expressed in seconds.

  • Timestamp

    Used by attributes whose values mark the time when a particular event occurred. When a significant event occurs, an eDirectory server mints a new Timestamp value and associates the value with the event. Every Timestamp value is unique within an eDirectory partition. This provides a total ordering of events occurring on all servers holding replicas of a partition.

  • Typed Name

    Used by attributes whose values represent a level and an interval associated with an object. This syntax names an eDirectory object and attaches two numeric values to it:

    • Level of the attribute indicative of its priority

    • Interval representing the number of seconds between certain events or the frequency of the reference

  • Unknown

    Used by attributes whose attribute definition has been deleted from the schema. This syntax represents strings of binary information.

High-Valued Attributes (HVA)

HVAConfig attribute is configurable attribute. The deployment process is simple and time efficient. By default, HVAConfig monitors Dir-XMLEntitlementResults and oidpInstanceData. If the customer uses custom values for HVAConfig, then these two attributes must be configured again with appropriate values. Custom HVAConfig attribute can be configured using an ldif file. HVAConfig can monitor all attribute types except STREAM. All the attribute related values provided to HVAConfig must be provided in JSON format.

The 4 mandatory JSON keys used in configuring HVA are as follows:

  1. AttributeName- Name of the attribute to be monitored.

  2. Type - This key refers to the attribute type that is monitored. For example, 1 = count-based attribute, 2 = size-based attribute.

  3. Limit- The upper limit after which high value alert/logging starts.

  4. Interval- This key is used in case of count-based attributes. It shows an alert every interval count after the attribute exceeds limit.

There are various ways to add / modify HVAconfig attribute as described below.

  1. Adding HVAconfig attribute to NCP server object using ldif file.

    Sample ldif file is shown below.

    version:1
    # define attributes
    dn: cn=servername,o=server
    changetype: modify
    add: HVAConfig
    HVAConfig: [{"AttributeName":"oidpInstanceData","Type":2,"Limit":1,"Interval":0}]

    where dn: is ncp server object DN.

    Use ldapmodify to upload the ldif file as shown below.

    ldapmodify -h 10.xx.xx.xx -D cn=admin,o=novell -w password -f hvaPolicy.ldif

  2. Adding HVAConfig attribute from iManager.

    1. Go to Directory Administration from Roles and Tasks -> Modify Objects-> select NCP server Object. Click OK.

    2. Select “Others” tab in modify page from “Unvalued Attributes” and select HVAConfig.

    3. Enter the desired attribute to set limit for in JSON format.

      Example:[{"AttributeName":"oidpInstanceData","Type":2,"Limit":1,"Interval":0}]

    4. Click Save and Apply.

  3. Adding HVAConfig attribute from iConsole.

    1. Go to Object Management page and select NCP server object to modify.

    2. Under Valued attribute click on “+” button.

    3. From the list of attributes select HVAConfig.

    4. Enter the value in JSON format and save it.

      Example:[{"AttributeName":"oidpInstanceData","Type":2,"Limit":1,"Interval":0}]

HVAconfig can be modified as shown below.

The below sample ldif file depicts modifying the HVAConfig attribute:

Version:1
# define attributes
dn: cn=servername, o=server
changetype:modify
replace:HVAConfig
HVAConfig: [{AttributeName":"DirXML-EntitlementResult","Type":1,"Limit":5010,"Interval":500}], {"AttributeNAme":"oidpInstaceData","Type":2,"Limit":16588,"Interval":0}]

Similarly, we can add and modify multiple attribute in one ldif file.

Sample ldapmodify command:

ldapmodify -h 10.71.128.217 -D cn=admin,o=novell -w n -f hvaPolicy.ldif

In case an attribute mentioned in HVAConfig becomes high valued, the logs regarding the same will be logged under hvAttr-alert.log that will be created in the usual $LOG_DIR. Whenever the configuration is modified, Limber must be triggered from imonitor so that the changes are in effect.Since HVAConfig is part of NCPServer object, all the attributes monitored are server specific.

1.4.3 Understanding Mandatory and Optional Attributes

Every object has a schema class that has been defined for that type of object, and a class is a group of attributes organized in a meaningful way. Some of these attributes are mandatory and some are optional.

Mandatory Attributes

A mandatory attribute is one that must be filled in when an object is being created. For example, if a new user is being created using the User class, which has the employee number as a mandatory attribute, then the new User object cannot be created without providing the employee number.

Optional Attributes

An optional attribute is one that can be filled in if desired but can be left without content. For example, if a new User object is being created using the User class, which has Other Names as an optional attribute, then the new User object can be created with or without data provided for that attribute, depending on whether the new user is known by other names.

An exception to the rule is when an optional attribute is used for naming, the attribute then becomes mandatory.

1.4.4 Sample Schema

Figure 1-12 is a sample of part of a schema, which might be similar to your base schema. This figure shows information on the Organization class. Most of the information displayed on this screen was specified when the class was created. Some of the optional attributes were added later.

Extensions to the base schema object icon This icon is assigned to all classes and attributes that are extensions to the base schema.

Figure 1-12 Class Information Page in iManager

1.4.5 Designing the Schema

Designing your schema initially can save you time and effort in the long run. You can view the base schema and determine if it will meet your needs or if modifications are required. If changes are needed, use Schema Manager to extend the schema. See Extending the Schema and Viewing the Schema for more information.