| Previous Contents Index Next |
| iPlanet Directory Server Access Management Edition Installation and Configuration Guide |
Appendix A DSAME ObjectClasses and Attributes
This appendix includes the following topics:
Using DSAME Object Classes as Markers
Using Alternative Naming Attributes
Using DSAME Object Classes as Markers
iPlanet Directory Server Access Management Edition (DSAME) defines the following entry types for its user and service management:The DSAME entry types are manageable entities that are identified by DSAME marker object classes in the directory entries. Each entry type represents an abstract object managed by DSAME. An entry type in DSAME does not necessarily match the same type in iDS. For example, an DSAME organization or container (also known as an organizational unit in Directory Server) may not be organization or organizational unit in iDS.
When you add a DSAME marker object class to a Directory Server entry, you enable DSAME to manage this entry. For example, if you mark an entry in iDS with the DSAME organization object class iplanet-am-managed-org, DSAME will manage this entry as DSAME organization entry.
Using Alternative Naming Attributes
There is a limitation in marking the Directory Server entries with DSAME object classes. You cannot mark two Directory Server entries that have different naming attributes that are not the same as the DSAME entry type. For example, you cannot mark as organizations both ou=iplanet.com (which uses the naming attribute of ou) and dc=engineering (which uses the naming attribute of dc).However, you can mark different entries with the same naming attribute for different DSAME entry types. For example, you can mark entry ou=Group as an DSAME container, and also mark entry ou=People as an DSAME people container. In this case, both use ou as their naming attributes, but are used for different entry types.
DITs That Cannot Be Managed by DSAME
It is important to understand that DSAME abstractly represents the entries it manages. This means that, for example, an organization in DSAME is not necessarily the same as an organization in iDS. Whether a specific 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 DSAME type.
Limitations to Consider
The limitations of DSAME entry types fall into three categories:
Only One Type of Entry Can be Marked as an Organization
People Containers Must be Parent Entries for Users
Only One Organization Description is Allowed in the DSAME XML
Only One Type of Entry Can be Marked as an Organization
By adding the DSAME iplanet-am-managed-org auxiliary class to any entry, DSAME will manage this entry as if it is an organization. But there is a limitation: only one type of entry may be marked as an organization in DSAME. 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 dc and o entries to be organizations, the DIT structure will not be manageable via DSAME.
There is one exception to this rule. The entry at the DSAME root suffix does not count as one entry. So in the following example, the DIT structure can indeed be managed by DSAME:
If you were 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 DSAME 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, since 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 UI, both organizations and containers have the same options. You can create subordination or subcontinents, people containers, groups, roles, and users under both of them. See "Organization".
People Containers Must be Parent Entries for Users
Another abstract entry type is the people container. The DSAME 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 may be this type in DSAME as long as it has the iplanet-am-managed-people-container object class and it has a DSAME manageable parent of type organization or container. See "People Container".
Only One Organization Description is Allowed in the DSAME XML
The DSAME 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 DSAME configuration. This DSAME 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=Edison-Watson), 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 DSAME:
In the following example, you would need three types of DSAME markers (dc,o,ou) plus the people container type (ou=people). Under these assumptions, the DIT would not work with DSAME:
Object Class and Attribute Descriptions
Organization
Object Class
iplanet-am-managed-org
Description
This entry type is used to manage DSAME organization entries. An DSAME DIT always starts with an organization. It usually maps to an organization or organizational unit in a Directory Server DIT.
Can Contain
suborganizations, people containers, containers (organizational units), roles, groups, group containers.
Other Required Object Class
inetDomain
Attributes
inetDomainStatus :Active
Container (Organizational Unit)
Object Class
iplanet-am-managed-org-unit
Description
This is referred to as a container in DSAME; it is usually mapped to an organizational unit in Directory Server. A container is functionally the same as an organization.
Can Contain
sub-organizations, people containers, containers, roles, groups.
People Container
Object Class
iplanet-am-managed-people-container
Description
A people container in DSAME is an organizational unit which is a parent for user entries. User entries can only be managed under a people container.
Can Contain
sub-people containers, users
Static Group
Object Classes
iplanet-am-managed-static-group
Description
This type of entry is usually mapped to a static group in Directory Server.
Can Contain
filtered or static sub-groups
Other Required Object Class
iplanet-am-managed-group
Attributes
iplanet-am-group-subscribableSet to true if the group is subscribable by user otherwise false.
Assignable Dynamic Group
Object Classes
iplanet-am-assignable-group
Description
This type of entry is usually mapped to a filtered group in Directory Server. It describes a special group containing filtered uids. Each user in the group has to have the member-of attribute set to the group.
Can Contain
filtered or assignable groups
Other Required Object Class
iplanet-am-managed-managed-group
Attributes
iplanet-am-group-subscribableSet to true if the group is subscribable by user, otherwise false.
Filtered Group
Object Class
iplanet-am-managed-group
Description
This entry type is usually mapped to a filtered group in Directory Server.
Other Required Object Class
iplanet-am-managed-filtered-group
User
Object Class
iplanet-am-managed-person
Description
A user entry in DSAME is a leaf node. It represents a user in an organization manageable by DSAME. It is always mapped to a user entry in Directory Server.
Other Required Object Classes
inetOrgPerson
Other Optional Object Classes
iplanet-am-logging-serviceiplanet-am-web-agent-service (only for URL access)
Set to Active if the user is able to login, or InActive if they are disabled. If this attribute is not present then they are active.
Set to the DN of the role of the admin who can create and delete this user.
Set to the DN of the role of the admin for the static group. This allows the administrator to manage this user.
Previous Contents Index Next
Copyright 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated May 13, 2002