Schema Limitations

Access Manager abstractly represents the entries it manages. This means, for example, that an organization in Access Manager is not necessarily the same as an organization in Directory Server. Whether a specific Directory Information Tree (DIT) can be managed or not depends on how the you choose to represent or manage your directory entries and whether your DIT fits into the limitations of each Access Manager type.

The following sections describe these limitations of the Access Manager schema. At the end of this section, several Examples of Unsupported DITs are included.

Only One Type of Entry Can be Marked as an Organization

By adding the Access Manager sunISManagedOrganization auxiliary class to any entry, Access Manager can manage this entry as if it is an organization. However, only one type of entry may be marked as an organization in Access Manager. For example, if you have an entry o=sun and another entry dc=ibm in your DIT, you cannot mark them both as organizations.

In the following example, if you want both the dc and o entries to be organizations, the DIT structure will not be manageable using Access Manager:

The entry at the Access Manager root suffix, however, does not count as one entry. Therefore, in the following example, the DIT structure can be managed by Access Manager:

If you were able to add dc=company1 below o=continent1, then this DIT would be manageable only if dc is marked as a container. Container is another abstract type in Access Manager that typically maps to an OrganizationalUnit. In most DITs, you would add the iplanet-am-managed-container entry to all OrganizationlUnits.

However, you could add this marker object class to any entry type. The DIT structure in the following example is allowed:

In this example, because you cannot mark both o= and ou= entries as organizations, you could mark the o= entries as organization and the ou= entries as containers. When exposed in the console, both organizations and containers have the same options. You can create subordination or subcontinents, people containers, groups, roles, and users under both of them.

People Containers Must be Parent Entries for Users

Another abstract entry type is the people container. The Access Manager type assumes that this entry is a parent entry for users. When you mark an entry as a people container with iplanet-am-managed-people-container, the UI will assume it can only contain sub-people containers or users. The attribute OrganizationUnit is typically used as a people container, but any entry can be this type in Access Manager as long as it has the iplanet-am-managed-people-container object class and it has a Access Manager manageable parent of type organization or container.

Only One Organization Description is Allowed in the Access Manager XML

The Access Manager organization is defined in amEntrySpecific.xml. Only one organization description is allowed in this file. As a result, when you customize directory entry properties, or create administration pages or search pages in the UI, your custom attributes apply globally to the entire Access Manager configuration. This Access Manager requirement may not meet the needs of some companies, especially hosting companies, that require different display attributes for each organization in the deployment.

In the following example, Edison-Watson is a hosting company that provides internet services to a number of companies. CompanyA wants to display fields for capturing a user’s name First Name, Surname, and Badge Number. CompanyB wants to display fields for capturing a user’s First Name, Last Name, and Employee Number.

The organization description is defined at the root level (o=EdisonWatson), and not at the organization level. By default, the UI for both CompanyA and CompanyB must be identical. Also, all services globally define attributes to be of the subschema type user. So if CompanyA has attributes for its users in the auxiliary class CompanyA-user, and CompanyB has attributes in CompanyB-user then CompanyB’s attributes will be overridden and will not be displayed.

As a workaround, you can modify the ACIs to work for user display. However, this workaround will not address the attributes in Search and Create windows.

Examples of Unsupported DITs

In the following example, you would need three types of organization makers: o, ou, and l. Assuming that l=california and l=alabama are not a people containers, this DIT would not work with Access Manager:

In the following example, you would need three types of Access Manager markers (dc,o,ou) plus the people container type (ou=people). Under these assumptions, the DIT would not work with Access Manager: