When an EAM Controller is installed, several services dedicated to specific features are installed at the same time. The set of functions provided by EAM are gathered in the following services:
Each EAM Controller may offer the set of services or only a part of these services.
EAM Controllers are not specialized at installation time: all the above listed services are available on all EAM Controllers.
EAM Console allows you to dedicate an EAM Controller to a subset of services. Once specialized, each controller continues to run all the services but only a part of them is used by the workstations.
You can change the EAM Controller configuration at any time from EAM Console (as explained in Section Managing EAM controller services), without having to install anything on the controller.
The first time a workstation needs to connect to an EAM Controller, it obtains the list of existing controllers from the directory and builds in a cache the list of the available services classified by sites. Then the workstation tries to connect to an EAM Controller located in the same site that explicitly provides the required service. If no such controller is available, then the workstation tries to connect to an EAM Controller located in the same site that provides all services. If no such controller is available, the workstation tries to connect to a controller located in another site.
The list of the controllers is rebuilt each time the cache expires. So when you change the services configuration from EAM Console, it needs time before all the workstation use the new services. For this reason and for backward compatibility with the previous versions of EAM (called Enterprise SSO), the EAM Controllers provide all the services.
To ensure high availability and good performances, it is interesting to install EAM on several servers and to dedicate each of them to specific services. The following figure shows an example of service distribution: one controller is dedicated to the audit and another one to the administration.
On Windows server systems, a Domain Controller (DC) is a server that manages all security-related aspects between user and domain interactions (authentication, permissions and so on) within the Windows server domain.
Each domain controller has a copy of the Active Directory (synchronized by a multi-master replication) and is associated with a site. Within the same site, replication is fast (with an appropriate data transmission), but it can take a long time between different sites, depending on the data type and the configuration of the replication.
EAM introduces a way to select a specific domain controller to work on. There are two situations where the current domain controller can be changed:
So, for example, a user created in Domain A would be listed only in Domain A's domain controllers.With this architecture, the storage of the EAM data can be done in two ways:
When the EAM data is stored in an AD multi-domain forest, the propagation of the data in the other directories of the forest is made by AD, but you have to declare the EAM administrators in others domains if they have to manage data stored in these others domains. You have also to declare representatives of users and access points if they have to connect on the workstations of the others domains.
When the EAM data is stored in ADAM, the EAM administration is greatly simplified and identical to the mono domain administration.
The above illustration shows an EAM software architecture that allows administrators to manage users that reside in different LDAP domains.
|NOTE: The software architecture depends on the way the EAM module is installed. For more details on the possible architectures depending on the LDAP directories infrastructures, see One Identity EAM Installation Guide.|
The architecture consists of the following modules:
In this section: