Previous Topic: InstallationNext Topic: LDAP Updates


Schema Changes

After APS Version 2.x, APS no longer uses an existing LDAP attribute to hold all of its data for a given user (the "Blob"). It now stores its data in separate attributes with specific names that need to be added to your LDAP schema. These attributes are described in detail in the chapter entitled User Directories: Schema, Storage and Capabilities.

Version 4.0 of APS requires a new attribute, smapsNextAction, that did not exist in APS 3.0. APSExpire will automatically set this attribute the first time that it is run.

Note: APSExpire, while its performance is greatly enhanced with Version 4, will still take some time to perform the process of initializing smapsNextAction for the entire directory. In your rollout schedule, plan for this additional time. Since the performance enhancements for APSExpire in Version 4 involve the use of smapsNextAction (which is not yet set at this point), do not use timings for this initial APSExpire run for planning for later operations.

The installation kit installs two .conf files to the APS_Docs directory. These files describe, in iPlanet (Netscape) terms, the schema changes required. They can be used (by an iPlanet LDAP Server-savvy administrator) to automate the update to the schema on iPlanet LDAP Version 4.x servers. These files should be appended to the end of the existing slapd.user_at.conf and slapd.user_oc.conf files (be sure to back up the existing files first). After appending the files, restart your LDAP server.

For iPlanet Directory Server version 5.0 (and later), these .conf files cannot be used. Instead, you must use the 56NetegrityAPS.ldif file installed onto the SiteMinder/APS_Docs directory. To use this file, perform the following steps:

  1. Edit the 56NetegrityAPS.ldif file using your favorite editor.
    1. Locate the two instances of smapsInfo (case-insensitive). Rename this class to the name of the class that you want to use. Note that if you want to add the APS attributes to an existing class, you will have to remove this class definition and add the attributes to your chosen class in the file in which it is defined (probably 99user.ldif).
    2. Save the file.
  2. Locate the file 99user.ldif in your iPlanet directory. Make sure that you locate the one associated with the desired LDAP directory instance.
  3. Put the modified 56NetegrityAPS.ldif file into the same directory.
  4. Restart the LDAP Directory Server.

These steps only need to be performed on a single Master Directory. The changes will be propagated to other masters and consumers (though the changes will be recorded in subsidiary servers in the 99user.ldif file).

The schema can also be updated manually, using the user interface provided with your LDAP implementation (this will certainly be required for non-LDAP native implementations, such as Active Directories and X.500 implementations). The chapter on the Schema defines each of the required attributes.

ObjectClasses

It is not sufficient to merely add the new attributes to your schema. You must also make these attributes available for your user objects. This can be done in three different ways.

  1. Create the smapsInfo objectClass with all of the new attributes.
  2. Add the new attributes to your existing custom user object class, if one exists.
  3. Add the new attributes to an existing standard user object class (such as inetOrgPerson). This is not desirable and some LDAP implementations (iPlanet/Netscape for one) forbid changing the standard object classes.

Your choice of the three options may have serious implications. You should read the next several sections before deciding.

You may be able to use the supplied smaps.user_oc.conf file to create a smapsInfo object class, or modify it to create a new object class with a different name. Use the file as described in the previous section. This will only work for iPlanet (Netscape) directories prior to version 5. Other implementations will require that you perform the object class updates manually. All attributes for the object class should be marked in the schema as optional (as opposed to mandatory).

User Entries

Just because the schema is updated does not mean that the changes are available for your user entries. The object class that allows the attributes must be part of every user entry in the system. If you have an existing object class that is already referenced by every user entry, then you should add the attributes to that object class.

Something to consider is your user maintenance tool. When creating new user entries, the tool must create new entries with the object class. Failure to do so will prevent APS from working with the new users, since it will be unable to update the user’s entry as required.