| Skip Navigation Links | |
| Exit Print View | |
|
Oracle Fusion Middleware Administration Guide for Oracle Unified Directory 11g Release 1 (11.1.1) |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Oracle Fusion Middleware Administration Guide for Oracle Unified Directory 11g Release 1 (11.1.1) |
1. Starting and Stopping the Server
2. Configuring the Server Instance
3. Configuring the Proxy Components
4. Configuring Security Between Clients and Servers
5. Configuring Security Between the Proxy and the Data Source
6. Managing Oracle Unified Directory With Oracle Directory Services Manager
10. Managing Users and Groups With dsconfig
11. Managing Password Policies
Designing and Extending the Schema
Working With Object Identifiers (OIDs)
Managing the Schema With Oracle Directory Services Manager
Add an Attribute Based on an Existing Attribute
View the Indexing Details of an Attribute
Add an Object Class Based on an Existing Object Class
View the Properties of an Object Class
Display a List of LDAP Syntaxes
Display a List of LDAP Matching Rules
Display a List of Content Rules
Create a Content Rule Based on an Existing Content Rule
The directory server supports multiple methods to extend the schema. The schema files are a set of LDIF files located in the install-dir/config/schema directory. Do not modify these files directly, because doing so can result in unpredictable server behavior.
You can extend the schema as follows:
Extend the schema over LDAP. Define your schema extensions, write the definitions to an LDIF file, and then add the custom schema extensions by using the ldapmodify command. When you use this method, the directory server automatically writes the new schema definitions to a file, 99user.ldif. If you want to specify a different schema file, include the X-SCHEMA-FILE element with the name of your schema file. For example, as part of your attribute type definition, include the element X-SCHEMA-FILE '98myschema.ldif'.
Create a custom schema file. Create a custom schema file with your definitions, save it as 98myschema.ldif, and then move the file to the install-dir/config/schema directory.
Modify an existing schema file. You can add a custom schema extension to an existing custom schema file, such as 99user.ldif.
When adding new schema elements, all attributes must be defined before they can be used in an object class.
If you are creating several object classes that inherit from other object classes, you must create the parent object class first.
Each custom attribute or object class that you create should be defined in only one schema file.
When defining new schema definitions manually, the best practice is to add these definitions to the 99user.ldif file or to your designated schema file.
The directory loads schema files in alphanumeric order with numbers loaded first, so you should name custom schema files as follows: [00-99]filename.ldif.
You can add new attribute types to the schema by using the ldapmodify command. The attribute types syntax requires that you provide at least a valid OID to define a new element. In typical applications, you can optionally include the following identifiers for the attribute type. To see the full set of attribute type elements, see Understanding Attribute Types in Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory.
Required. Specifies the OID that uniquely identifies the attribute type in the directory server. The LDAP v3 specification requires the OID to be a numeric number, but the directory server supports the use of non-numeric OIDs for easy identification as long as the schema is used internally within the organization. The format is attributename-oid, for example, telephoneNumber-oid. Each non-numeric OID must have its corresponding numeric OID defined in the schema.
Optional. Specifies the set of human-readable names that are used to refer to the attribute type. If there is a single name, enclose it in single quotes, for example, 'blogURL'. If there are multiple names, enclose each name in single quotes separated by spaces, and then enclose the entire set of names within parentheses, for example, ( 'blog' 'blogURL' ). Ensure that there is a space between the left parenthesis and the name, and a space before the closing parenthesis.
Optional. Specifies the superior attribute type when you want one attribute type to inherit elements from another attribute type. The matching rule and attribute syntax specifications from the superior attribute type can be inherited by the subordinate type if it does not override the superior attribute type definition. The OID, any of the human-readable names associated with the superior attribute type or both can be used to collectively reference all of the subordinate attribute types.
Optional. Specifies a human-readable description of the attribute type.
Optional. Specifies the attribute syntax for use with the attribute type. If provided, it should be given as a numeric OID. The core syntaxes are defined in section 3.3. of RFC 4517 and in Appendix A of the same document.
Optional. Specifies whether the attributes of that type are allowed to have only a single value in any entry in which they appear. If SINGLE-VALUE is not present, the attributes are allowed to have multiple distinct values in the same entry.
Optional. Indicates that the values of the attributes of the given type cannot be modified by external clients (that is, the values can be modified only by internal processing within the directory server).
Optional. Indicates how the attribute is to be used. Possible values are as follows: userApplications. Used to store user data. directoryOperation. Used to store data required for internal processing within the directory server. distributeOperation. Used to store operational data that must be synchronized across directory servers in the topology. dSAOperation. Used to store operational data that is specific to a particular directory server and should not be synchronized across the topology.
Optional. Specifies the extensions available to the attribute type. Oracle Unified Directory provides the following extensions:
X-ORIGIN. Provides information on where the attribute type is defined. The element is a non-standard tool that you can use to locate the schema element, for example, the RFC number (RFC4517).
X-SCHEMA-FILE. Indicates which schema file contains the attribute type definition. Used for internal purposes only and is not exposed to clients. You can use this extension to specify where the directory server should store your custom schema definitions.
X-APPROX. Indicates which approximate matching rule should be used for the attribute type. If specified, the value should be the name of the OID of a registered approximate matching rule.
For example, you can specify the addition of a new attribute type, blogURL, in an LDIF file that will be added to the schema.
$ cat blogURL.ldif dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Oracle Unified Directory Server' USAGE userApplications )
Note - Pay special attention to the spaces in an attribute type declaration. The LDAP specification requires that a space exist between the opening parenthesis and the OID, and the value of the USAGE element and the closing parenthesis. Further, the LDIF specification states that LDIF parsers should ignore exactly one space at the beginning of each line. Therefore, it is a good practice to add two (2) spaces at the beginning of the line that starts with an element keyword. For example, add two spaces before NAME, DESC, SYNTAX, SINGLE-VALUE, X-ORIGIN, and USAGE in the previous example.
The OIDs used in this example are for illustration purposes only and should not be implemented in your directory.
The cn=schema entry has a multivalued attribute, attributeTypes, that contains definitions of each attribute type in the directory schema. You can view the schema definitions by using the ldapsearch command.
Manipulation of the cn=schema suffix is regarded as an administrative action and, as such, it is recommended that you use the administration connector when accessing this suffix. See Managing Administration Traffic to the Server for more information.
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \
--baseDN cn=schema --searchScope base \
"(objectclass=*)" attributeTypes
dn: cn=schema
attributeTypes: ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch SUBSTR caseIgnore
eSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} X-ORIGIN 'RFC 4519
' )
attributeTypes: ( 2.5.4.49 NAME 'distinguishedName' EQUALITY distinguishedNameMa
tch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'RFC 4519' )
attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch SYNT
AX 1.3.6.1.4.1.1466.115.121.1.38 X-ORIGIN 'RFC 4512' )
...(more output)...$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \ -b cn=schema -s base --dontWrap "(objectclass=*)" attributeTypes | grep "telexNumber" attributeTypes: ( 2.5.4.21 NAME 'telexNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 X-ORIGIN 'RFC 4519' )
The cn=schema entry has a multivalued attribute, attributeTypes, that contains definitions of each attribute type in the directory schema. You add custom schema definitions by using the ldapmodify command. This example adds an attribute named blog.
Manipulation of the cn=schema suffix is regarded as an administrative action and, as such, it is recommended that you use the administration connector when accessing this suffix. See Managing Administration Traffic to the Server for more information.
dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Oracle Unified Directory Server' USAGE userApplications )
$ ldapmodify -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \ -a -f blogURL.ldif Processing MODIFY request for cn=schema MODIFY operation successful for DN cn=schema
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \ -b cn=schema -s base --dontWrap "(objectclass=*)" attributeTypes | grep 'blog' attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Oracle Unified Directory Server' USAGE userApplications )
Note - The directory server automatically adds new attribute definitions to the 99user.ldif file.
The cn=schema entry has a multivalued attribute, attributeTypes, that contains definitions of each attribute type in the directory schema. You can delete definitions with X-ORIGIN 'user defined' by using the ldapmodify command. The directory server does not allow deletions to other definitions.
 | Caution - Be careful when deleting attribute types, because doing so can harm your directory. Do not delete an attribute type unless absolutely necessary. |
Manipulation of the cn=schema suffix is regarded as an administrative action and, as such, it is recommended that you use the administration connector when accessing this suffix. For more information, see Managing Administration Traffic to the Server.
dn: cn=schema changetype: modify delete: attributeTypes attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Oracle Unified Directory Server' USAGE userApplications )
$ ldapmodify -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \ --defaultAdd --fileName "remove_blogURL.ldif" Processing MODIFY request for cn=schema MODIFY operation successful for DN cn=schema
Object classes are named sets of attribute definitions that are used to control the types of data stored in entries. You can add new object classes to the schema by using the ldapmodify command. The object class syntax requires that you provide at least a valid OID to define your new element. In typical applications, you will also include the following optional identifiers for the object class type. For more information about the object class definition, see Directory Schema Overview.
Required. Specifies the OID that uniquely identifies the object class in the directory server. The LDAP v3 specification requires the OID to be a numeric number, but Oracle Unified Directory supports the use of non-numeric OIDs for easy identification because the schema is used internally within the organization. For example, the format is objectClassName-oid, such as person-oid.
Optional. Specifies the set of human-readable names that are used to refer to the object class. If there is a single name, enclose it in single quotes, for example, 'blogURL'. If there are multiple names, enclose each name in single quotes separated by spaces, and then enclose the entire set of names within parentheses, for example, ( 'blog' 'blogURL' ). Ensure that there is a space between the left parenthesis and the name, and a space before the closing parenthesis.
Optional. Specifies a human-readable description of the object class. If specified, the description should be enclosed in single quotation marks.
Optional. Specifies the superior object class when you want it to inherit elements from another object class. The directory server allows only one superior object class, although the LDAP v3 specification allows for multiple superior object classes.
Optional. Indicates whether the object class is active or not. If an object class is marked as OBSOLETE, then it should not be referenced by any new elements created in the directory server.
Optional. The SUP keyword should be followed by the OID of the superior class.
Optional. Indicates the type of object class that is being defined. Allowed values are ABSTRACT, AUXILIARY and STRUCTURAL.
Optional. Specifies the set of attribute types that are required to be present (that is, have at least one value) in entries with that object class. If there is only a single required attribute, then the MUST keyword should be followed by the name or the OID of that attribute type. If there are multiple required attribute types, then separate them with dollar signs ($) and enclose the entire set of attribute types in parentheses. For example, MUST ( sn $ cn ).
Optional. Specifies the set of attribute types that are allowed but not required to be present in entries with that object class. If there is only a single required attribute, then the MAY keyword should be followed by the name or the OID of that attribute type. If multiple required attribute types are specified, then separate them by dollar signs ($) and enclose the entire set of attribute types in parentheses. For example, MAY ( userPassword $ telephoneNumber $ seeAlso $ description ).
Optional. Specifies the extensions available to the object class. The directory server provides the following extensions: X-ORIGIN. Provides information on where the object class is defined. The element is a non-standard tool that the user can use to conveniently locate the schema element. X-SCHEMA-FILE. Indicates which schema file contains the object class definition. Used for internal purposes only and is not exposed to clients. You can use this extension to specify where the directory server is to store your custom schema definitions.
For example, you can specify the addition of a new object class, blogger, in an LDIF file to be added to the schema.
$ cat blogger.ldif dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 1.3.6.1.4.1.32473.1.1.10 NAME ( 'blogger' ) DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog X-ORIGIN 'Oracle Unified Directory Server' )
Note - Pay special attention to the spaces in your object class declaration. The LDAP specification requires that a space exist between the opening parenthesis and the OID, and the value of the X-ORIGIN element and the closing parenthesis. Further, the LDIF specification states that LDIF parsers should ignore exactly one space at the beginning of each line. Therefore, it is a good practice to add two spaces before the line that begins with an element keyword, such as, NAME, DESC, SUP, STRUCTURAL, MAY, and X-ORIGIN in the previous example.
The OIDs used in this example are for illustration purposes only and should not be implemented in your directory.
The cn=schema entry has a multivalued attribute, objectClass, that contains definitions of each object class in the directory schema. You can view the schema definitions by using the ldapsearch command.
Manipulation of the cn=schema suffix is regarded as an administrative action and, as such, it is recommended that you use the administration connector when accessing this suffix. See Managing Administration Traffic to the Server for more information.
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \ -b cn=schema -s base "(objectclass=*)" objectClasses dn: cn=schema objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass X-ORIGIN 'RFC 4512 ' ) objectClasses: ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName X-ORIGIN 'RFC 4512' ) objectClasses: ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c MAY ( searchGu ide $ description ) X-ORIGIN 'RFC 4519' ) objectClasses: ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL MAY ( street $ seeAl so $ searchGuide $ st $ l $ description ) X-ORIGIN 'RFC 4519' ) objectClasses: ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o MAY ( use rPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registered Address $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ telete xTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTele phoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDel iveryOfficeName $ st $ l $ description ) X-ORIGIN 'RFC 4519' ) ...(more output)...
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -w password -X \ --useSSL -b cn=schema -s base --dontWrap "(objectclass=*)" \ objectClasses | grep "inetOrgPerson" objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500UniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) X-ORIGIN 'RFC 2798' )
The cn=schema entry has a multivalued attribute, objectClasses, that contains definitions of each object class in the directory schema. You add custom schema by using the ldapmodify command. This example adds an object class blogger based on the attribute created in the previous example.
Manipulation of the cn=schema suffix is regarded as an administrative action and, as such, it is recommended that you use the administration connector when accessing this suffix. See Managing Administration Traffic to the Server for more information.
dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 1.3.6.1.4.1.32473.1.1.10 NAME ( 'blogger' ) DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog X-ORIGIN 'Oracle Unified Directory Server' )
$ ldapmodify -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \ -a -f blogger.ldif Processing MODIFY request for cn=schema MODIFY operation successful for DN cn=schema
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \ -b cn=schema -s base --dontWrap "(objectclass=*)" objectClasses | grep 'blogger'
Note - The directory server automatically adds new object class definitions to the 99user.ldif file.
The cn=schema entry has a multivalued attribute, objectClasses, that contains definitions for each object class in the directory schema. You can delete these definitions by using the ldapmodify command.
| Caution - Be careful when deleting object classes, because doing so can harm your directory. Do not delete an object class unless absolutely necessary. |
Manipulation of the cn=schema suffix is regarded as an administrative action and, as such, it is recommended that you use the administration connector when accessing this suffix. See Managing Administration Traffic to the Server for more information.
dn: cn=schema changetype: modify delete: objectClasses objectClasses: ( 1.3.6.1.4.1.32473.1.1.10 NAME ( 'blogger' ) DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog X-ORIGIN 'Oracle Unified Directory Server' )
$ ldapmodify -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \ --fileName "remove_objectclass_schema.ldif"
You can extend the schema by using a schema file that contains customized definitions. In general, the best practice is to modify the existing 99user.ldif file in the install-dir/config/schema directory to add new definitions. When you update schema elements using LDAP, the new definitions are written to the 99user.ldif file.
Alternatively, you can create a custom schema file and save it to the install-dir/config/schema directory. The directory server loads schema files in alphanumeric order with numbers loaded first. As such, you should name custom schema files as follows: 00-99filename.ldif. The number should be higher than any standard schema file that has already been defined. If you name custom schema files with a number that is lower than the standard schema files, the server might encounter errors when loading the schema.
|