LDIF Schema Modifications

Overview#

The rumor that Modification to the Schema is permanent is False.

On this page we show several Examples of LDIF Schema Modifications.

In versions prior to 8.7#

NOTE: This process will not work on versions of Novell eDirectory prior to 8.7. In those versions, a local database repair with 'Rebuild Operational Schema' selected would add the SF_PUBLIC_READ flag back to the attributes.

Version 8.7 and 8.8#

This operation invokes a schema reset which clears the time stamps on the local schema and requests an inbound schema synchronization.

This operation is unavailable if executed from the master replica of the Root partition. This is to ensure that not all servers in the tree reset at once.

Atomic Operation#

On these operations it is necessary that the operation be performed within the same transaction. Modification of this type must be atomic or they will fail with an error of constraint violation.

Further as schema entries are typically done on attributetypes or objectClasses which are essentially muti-valued attributes, it the "delete" operation must reference the value being modified EXACTLY what exist in the schema.

Modify the OID of Entry in Schema#

Below is an LDIF fragment that shows how to change the Schema via a LDIF. The change is in the OID of the attribute. 
dn: cn=schema
changetype: modify
delete: attributetypes
attributeTypes:	( 1.3.6.1.4.1.16709.100.3.1.1.71 NAME 'B1ITRWaiver' 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64512} X-NDS_LOWER_BOUND '1' X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
-
add: attributetypes
attributeTypes:	( 1.3.6.1.4.1.16709.100.3.1.1.68 NAME 'B1ITRWaiver' 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64512} X-NDS_LOWER_BOUND '1' X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )

Changing Flagged Attributes#

eDirectory uses several X-FLAGs. X-FLAGs allow vendors to provide vendor specific abilities that may not be supported by other vendors.

One flag that has been troublesome with the recent privacy concerns is the X-NDS_PUBLIC_READ flag that was set in the default schema from Novell.

This process will work with attributes, e.g. Surname, that have been flagged SF_NONREMOVABLE.However, this flag should not be included in the LDIF file.
Even though it's omitted, the SF_NONREMOVABLE flag will be maintained.

Here's an example LDIF file that removes the X-NDS_PUBLIC_READ flag on Surname: 

dn: cn=schema
changetype: modify
delete: attributeTypes
attributeTypes: ( 2.5.4.4 NAME ( 'sn' 'surname' ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} X-NDS_NAME 'Surname' X-NDS_LOWER_BOUND '1' X-NDS_PUBLIC_READ '1'  )
-
add: attributeTypes
attributeTypes: ( 2.5.4.4 NAME ( 'sn' 'surname' ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} X-NDS_NAME 'Surname' X-NDS_LOWER_BOUND '1'  )

The mail Attribute#

The attribute mail is another attribute that has constantly been an issue with eDirectory. Many of the xxxx insist that the rights to read the email address of entries not be exposed.

Below we show this modification, done as an LDIF import for one of our eDirectory Servers (vendorVersion: LDAP Agent for Novell eDirectory 8.8 SP3 (20216.73)): 

# LDIF to remove X-NDS_PUBLIC_READ flag from mail

dn: cn=schema
changetype: modify
delete: attributeTypes
attributeTypes: ( 0.9.2342.19200300.100.1.3 NAME 'mail' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64512} X-NDS_NAME 'Internet EMail Address' X-NDS_PUBLIC_READ '1' )
-
add: attributeTypes
attributeTypes: ( 0.9.2342.19200300.100.1.3 NAME 'mail' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64512} X-NDS_NAME 'Internet EMail Address' )


#!RESULT OK
#!CONNECTION ldap://ldap.willeke.com:389
#!DATE 2009-07-09T07:26:55.703
dn: cn=schema
changetype: modify
delete: attributeTypes
attributeTypes: ( 0.9.2342.19200300.100.1.3 NAME 'mail' SYNTAX 1.3.6.1.4.1.146
 6.115.121.1.15{64512} X-NDS_NAME 'Internet EMail Address' X-NDS_PUBLIC_READ '
 1' )
-
add: attributeTypes
attributeTypes: ( 0.9.2342.19200300.100.1.3 NAME 'mail' SYNTAX 1.3.6.1.4.1.146
 6.115.121.1.15{64512} X-NDS_NAME 'Internet EMail Address' )
-

Modify Existing Attribute#

With the Current versions, existing schema entries can also be modified. Here is an example of an LDAP entry that will modify an existing schema attribute. This modification is written as a delete and an add. However, the NDS LDAP server will recognize this modification of a single DN as a modify since the delete and the add have the same attribute OID and name. Therefore, this modification will work even if there is data instantiated using this attribute. The following example modifies the upper bound of the attribute from 8 to 40. 
dn: cn=schema
changetype: modify
delete: attributetypes
attributetypes: ( 2.16.840.1.113719.1.131.4.1.7 NAME 'myNewAttr'
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{8} )
-
add: attributetypes
attributetypes: ( 2.16.840.1.113719.1.131.4.1.7 NAME 'myNewAttr'
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} ).

Add Attribute to a ObjectClass#

Here is an example of a modification to a class that adds an attribute to the class: 
dn: cn=schema
changetype: modify
delete: objectclasses
objectclasses: ( 2.16.840.1.113719.1.131.6.1.23 )
-
add: objectclasses
objectclasses: ( 2.16.840.1.113719.1.131.6.1.23 NAME 'myNewClass'
          SUP top MUST ( myNewAttrOne $ myNewAttrTwo ) MAY (
          myNewAttrThree $ myNewAttrFour $ myNewAttrFive $
          myNewAttrSix ) )

Limitations#

There are some limitations with making modifications to existing schema entries. These are based on referential integrity and follow common sense.

Any schema modification that could possibly invalidate any data is not allowed. For example, in the first example above, the upper bound was changed from 8 to 40, thus increasing the range of possible values. The bound could not be modified to a value below 8, or it could invalidate data values.

Similarly, an attribute could be changed from a single-valued attribute to a multivalued attribute, but not the reverse as there may be data with multiple values. You could change a class and make an object a container, but you cannot change a container object into a leaf object as the container may contain other objects.

Put it to Work#

Once you have a standard LDIF file, it is a simple process to modify the NDS schema. An LDIF file can be applied to the NDS schema using a standard LDAPModify utility, or statements similar to those contained in an LDIF file can be used to extend the NDS schema using an LDAP API. The LDAPModify utility can be used with a command line similar to the following: 
LDAPModify -h myHost - myPort -D cn=admin,o=novell -w myPassword -f myLDIFFile

This will extend the NDS schema adding the attributes and classes. In addition to adding and deleting classes, classes and attributes can be deleted from the schema. However, the referential integrity rules will not allow schema entries to be deleted if data has been instantiated using any part of the schema entries to be deleted. The following is an example of an LDIF file entry that will delete a class from the schema. 

dn: cn=schema
changetype: modify
delete: objectclasses
objectclasses: ( 2.16.840.1.113719.1.131.6.1.23 NAME 'myNewClass'
          SUP top MUST ( myNewAttrOne $ myNewAttrTwo ) MAY (
          myNewAttrThree    $ myNewAttrFour $ myNewAttrFive $
          myNewAttrSix ) )

More Information#

There might be more information for this subject on one of the following:
Please see our Copyright And Intellectual Property Page and Standard Disclaimer Pages!