Understanding and Deploying LDAP Directory Services, Second Edition [Electronic resources] نسخه متنی

Sources of Predefined Schemas

Predefined schemas are provided by application vendors, directory standards documents, and directory service software vendors. By choosing predefined schemas to meet as many of your needs as possible, you avoid reinventing the wheel and help ensure compatibility with as many directory-enabled applications as possible.

Directory-Enabled Applications

All directory-enabled application software should include documentation that describes its schema requirements. If you can''t locate the schema information for an application that you plan to deploy, contact the vendor or author of the software and ask for the information. Often this important information is buried in an appendix or is available only on a vendor''s Web site.

Whereas some applications have specific requirements, others are more liberal in the schemas they can use. It is important to find out whether an application requires a specific set of object classes and attributes or can be configured to work with a variety of schemas. The directory-enabled application that is the least flexible of those you plan to deploy may in practice dictate many of your schema choices.

For example, routing of e-mail is a fairly exact process. If you plan to deploy a directory-enabled e-mail routing system, you may find that the e-mail software requires a specific object class to be present in all person and group entries and that specific attributes must have values for the mail-routing algorithms to function. Sun ONE Messaging Server is an example of LDAP-enabled mail-routing and delivery software that has fairly strict schema requirements.

In contrast, consider a directory lookup client such as a Web-based phone book or an e-mail client such as the Netscape 7 Mail client. These kinds of applications typically support the standard person object class and its associated attributes out of the box. They often support other schemas chosen by the vendor, such as the inetOrgPerson extended person object class. A good lookup client also provides some degree of customization so that it can be modified to accommodate organization-specific schemas.

Standard Schemas

Schemas endorsed by more than one vendor and published by a standards body can be good choices for use in your directory service. Usually a schema that has made it into a standards document has been reviewed and agreed to by several different implementers and users of directory services. Standard schemas also have the advantage that they are generally well documented and widely published.

It is especially useful to choose a standard schema when you''re caught between two different vendors of directory-enabled applications that are each promoting their own proprietary schemas. If the schema needs of two applications conflict, asking the application vendors to support a standard schema is a good approach. Because everyone claims to believe in open standards, it would be difficult for the vendors to explain why they cannot support the standard schema (unless it simply does not meet the needs of their particular application).

Several sources of standard schemas should be consulted:

• 
  LDAP standards documents

  
  




• 
  X.500 standards documents

  
  




• 
  Industry consortium standards

  
  

Most standard schema information is available free of cost on the World Wide Web. In some cases, you may need to contact the standards body directly to purchase a copy of the standards documents. Table 8.5 shows some examples of standard schemas.

If the schemas you design are of general use, consider submitting them to a standards body as well. Some URLs and other pointers to help you locate standard schemas are included in the Further Reading section near the end of this chapter.

Schemas Provided by Directory Vendors

Last, but certainly not least, most directory software comes with a generous collection of predefined schemas. In most cases, these schemas are a mix of standard schemas, application-specific schemas, and schemas that are being promoted by the directory vendor. One big advantage of directory vendorprovided schemas is that they are more than likely already installed in the directory service software, so they require less work to use.

On the other hand, just the fact that a schema comes preinstalled does not mean that it will meet your needs. As with all other schema-related decisions, read through the documentation and the schema definitions carefully to evaluate a vendor-provided schema against the needs of the applications you plan to deploy.

Adding a Schema to an Installed Directory Server

The procedure for adding a schema to a directory server varies from product to product, but an increasing number of servers support adding LDAPv3-format schemas over LDAP itself. You do this using an LDAP modify operation that targets the subschema entry to which you want to add the schema. A special utility may be provided for this purpose, or you may just need to create the correct LDAP Data Interchange Format (LDIF) file yourself.

With the Netscape Directory Server 6 product, schemas can be manipulated in several ways. The most interactive way is to use the graphical management console. But if you have a new schema that is in the LDAPv3 format, you will probably want to add the schema by dropping a new file into the INSTALLDIR/slapd-INSTANCE/config/schema/ subdirectory or by adding the schema over LDAP. To add it over LDAP, you need to create an LDIF file that represents an LDAP modify operation on the cn=schema entry. Listing 8.16 shows an example of an LDIF file that may be used to add some of the schema from RFC 2587 (

Internet X.509 Public Key Infrastructure LDAPv2 Schema ).

Listing 8.16 An LDIF File to Add Additional Parts of the RFC 2587 Schema

dn: cn=schema
changetype: modify
add: objectClasses
objectClasses: ( 2.5.6.21 NAME ''pkiUser'' SUP top AUXILIARY
MAY userCertificate )
objectClasses: ( 2.5.6.22 NAME ''pkiCA'' SUP top AUXILIARY
MAY ( cACertificate $ certificateRevocationList $
authorityRevocationList $ crossCertificatePair ) )

Note that the two lines that start with MAY and the one that starts with authorityRevocationList are continued LDIF lines that begin with two space characters. To add attribute type definitions, the procedure is similar: Just include the appropriate attributeTypes values in the LDIF file you use as input to an LDAP modify operation. Assuming that the preceding LDIF is placed in a file called pki-schema.ldif, an ldapmodify command to add this schema will look something like this:

ldapmodify -v -D "uid=dsadmin,dc=example,dc=com" -w secret < pki-schema.ldif

Here is sample output from such a command:

ldapmodify: started Mon Jun 6 16:45:39 2002
ldap_init( localhost, 389 )
add objectClasses: ( 2.5.6.21 NAME ''pkiUser'' SUP top AUXILIARY MAY userCertificate ) ( 2.
5.6.22 NAME ''pkiCA'' SUP top AUXILIARY MAY ( cACertificate $ certificateRevocationList $ 
authorityRevocationList $ crossCertificatePair ) )
modifying entry cn=schema
modify complete