To suit most Identity Manager deployments, the integrated installation process creates a default structure for the Identity Vault.
Figure 1-1 Default Identity Vault Structure
Table 1-1 Identity Vault Object Descriptions
Object |
Description |
---|---|
t=idv |
The name of the eDirectory tree. For example, idv. |
o=system |
All of the system objects for Identity Manager are located in the system organization. Administrators should be the only users that have access to this container and all subcontainers. For more information, see Section 1.3.1, System Container. |
ou=sa.o=system |
The ou=sa.o=system container holds all of the system users. The system users are administrators, driver administrators, and other administrators. |
cn=admin.ou=sa.o=system |
This is the administrator account for the tree. |
ou=servers.o=system |
This container holds the server objects and all objects associated with the servers. This allows you to separate the server objects from the other system objects. |
cn=driverset1.o=system |
The driver set object contains all of the driver objects. The driver set objects are placed directly under the system container. |
cn=User Application Driver.cn=driverset1.o=system |
The User Application driver manages all tasks associated with the User Application. |
cn=Role and Resource Service Driver.cn=driverset1.o=system |
The Role and Resource Service driver manages all tasks associated with the Roles Based Provisioning Module. |
cn=Data Collection Service Driver.cn=driverset1.o=system |
The Data Collections Service driver manages tasks associated with the Identity Reporting Module. |
cn=Managed System Gateway Driver.cn=driverset1.o=system |
The Managed System Gateway driver manages tasks associated with the Identity Reporting Module. |
cn=Role Based Service 2.o=system |
This container holds object that help iManager work for Identity Manager. |
o=data |
All of the data objects for Identity Manager locations in the data organization. Administrators should ensure that all users have access to this container and all subcontainers. For more information, see Section 1.3.2, Data Container. |
ou=users.o=data |
The default container for all user objects in the Identity Vault. |
ou=groups.o=data |
The default container for all group objects in the Identity Vault. |
ou=sa.o=data |
The default container for the role admin user, super user, and service accounts for the User Application, the Roles Based Provisioning Module, and the Identity Reporting Module. |
cn=uaadmin.ou=sa.o=data |
The User Applications administrator object. |
ou=Devices.o=data |
The default container for devices. |
cn=security |
The security container holds all security objects for the tree and Identity Manager. Ensure that only administrators have access to this container and all subcontainers. For more information, see Section 1.3.3, Security Container. |
This default structure is primarily useful for a single-environment installation. For example, this is a good Identity Vault structure for small and medium Identity Manager deployments. Multi-tenant environments might have a slightly different structure. Also, you cannot organize large and distributed trees in this way.
Identity Manager 4.0 and later mostly uses organization containers, so users, groups, and service administrators are placed in the same container. You should use organizations (o=) if possible and use organizational units (ou=) where it makes sense. The Identity Manager structure is set up for scalability by having three main components: the system container, the data container, and the security container.
The system container is an organization. By default, it is designated as o=system. This container holds all of the technical and configuration information for your Identity Vault and for the Identity Manager system. The system container holds the following main subcontainers:
The Service Admins container holds administrative objects for the Identity Vault and drivers. Only admin users can access the system subtree. The default Identity Vault admin is admin.sa.system. The objects in this container might be referred to as sa or service admin users / super user / service accounts.
The server objects have many different objects associated with them that must reside in the same container as the server object. As you add more servers into your tree, scrolling through all of those objects can become very cumbersome.
You should have all server objects under the servers.system container. However, an administrator can create individual server containers for each of the servers deployed in the environment. The name of the container is the name of the server object.
This structure is designed for scalability. All objects associated with the server (volumes, licenses, certificates) are in place to help you find the objects that you need.
Driver sets are created as a separate partition during the Identity Manager engine configuration. The Identity Vault stores the driver set objects in the system container. This structure allows you to scale by adding more driver sets to the system container. Role-based services for iManager are also stored in the system container.
The data container holds groups, users, role admins, devices, and other objects. This is the data that makes up your system. The groups, users, and sa containers are organizational units. You can have additional organizational units to structure your data according to your organizational practices. For example, the Service Admins (ou=sa) container holds all user application administrator objects and service administrator accounts.
The security container is a special container created during the installation of the Identity Vault. It is designated as cn=security instead of dc, o, or ou. This container holds all security objects for the Identity Vault. For example, it contains the certificate authority and password policies.