The Schema-Checking Process

   

The Schema-Checking Process

When a new entry is added to the directory or an existing entry is modified, the directory server that processes the request goes through a schema-checking process before committing the add or modify request. The schema-checking process is done before the directory database itself is altered and ensures that all new or modified directory entries conform to the schema rules. If an entry violates any of the schema rules in effect, the directory server rejects the request and a "constraint violation" error is returned to the LDAP client.

The steps that a server typically performs when checking schemas are as follows :

Step 1. Verify that all new or modified values conform to the syntax rules.

Step 2. Verify that at least one value for the objectclass attribute is present.

Step 3. For each object class, make sure that at least one value for each of the mandatory attributes is present.

Step 4. Check each attribute to make sure that it is allowed by one of the object classes and that the attribute has only one value if it is a single-valued attribute.

Note that the specifics and order of execution of some of the steps shown may vary in different directory service implementations . However, the basic idea is always the same: The resulting entry (whether new or modified) is checked for complete conformity with the server's schema rules, and an error is sent to the directory client if any problems are found. If there is a schema violation, the entire add or modify operation is rejected by the server.

Some implementations, such as Netscape Directory Server, provide a way to disable schema checking entirely, in which case entries that are added or modified are not checked against the schema rules at all.

Schema-Checking Examples

Let's assume that the person and labeledURIObject schemas shown in Listing 8.8 and 8.10, respectively, are present in your directory server. If someone attempts to add this entry, the add operation will fail because a required attribute type, sn , is missing:

 dn: cn=Babs Jensen,ou=People,dc=example,dc=com objectClass: top objectClass: person cn: Babs Jensen 

The following entry will also cause a failure during the schema-checking process, but for a different reason: One of the attribute types in the entry definition, labeledURI , is not allowed by any of the object classes present in the entry:

 dn: cn=Babs Jensen,ou=People,dc=example,dc=com objectClass: top objectClass: person sn: Jensen cn: Babs Jensen labeledURI: http://www.example.com/bjensen Babs's Home Page 

The following entry will pass schema checking because all required attribute types are present and all attribute types are allowed by one of the object classes present in the entry:

 dn: cn=Babs Jensen,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: labeledURIObject sn: Jensen cn: Babs Jensen labeledURI: http://www.example.com/bjensen Babs's Home Page 
   


Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 2002
Pages: 242

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net