Enterprise Single Sign-On 9.0.2 - Enterprise Access Management Installation Guide

Table of Contents

Preface Overview Preparing the Storage of Security Data in the LDAP Directory Installing EAM Controllers and Audit Databases Installing and Configuring the Software Modules on the Workstations Enabling the Self Service Password Request (SSPR) Feature Enabling One-Time Password (OTP) Authentication Enabling the Group Membership Modification Feature Centralizing Parameters Using Group Policy Objects (GPO) Installing EAM MSI Packages in Silent Mode Enhancing EAM Activating Traces Retrieving the Serial Number on MiFARE and MiFARE DESFire RFID Badges

Preface

Subject

This guide describes how to install and configure Enterprise Access Management (EAM); which gathers Authentication Manager and Enterprise SSO modules.

Audience

This guide is intended for:

System Integrators.
Administrators.

Required Software

EAM 9.0 evolution 2 and later versions. For more information about the versions of the required operating systems and software solutions quoted in this guide, please refer to One Identity EAM Release Notes.

Typographical Conventions

Bold Indicates:

Interface objects, such as menu names, buttons, icons and labels.
File, folder and path names.
Keywords to which particular attention must be paid.

Italics - Indicates references to other guides.

Code - Indicates portions of program codes, command lines or messages displayed in command windows.

CAPITALIZATI ON Indicates specific objects within the application (in addition to standard capitalization rules).

< > Identifies parameters to be supplied by the user.

Warning: A WARNING icon indicates a potential for property damage, personal injury, or death.

Caution: A CAUTION icon indicates potential damage to hardware or loss of data if instructions are not followed.

IMPORTANT, NOTE, TIP, MOBILE, or VIDEO: An information icon indicates supporting information.

Documentation support

The information contained in this document is subject to change without notice. As our products are continuously enhanced, certain pieces of information in this guide can be incorrect. Send us your comments or suggestions regarding the documentation on the One Identity support website.

Overview

Enterprise Access Management solution enables you to deploy a high level of security. It uses the corporate LDAP directory of your company to manage Single Sign-On (SSO) on this distributed LDAP architecture. Enterprise Access Management also provides Single Sign-On in the Cloud, allowing to save SSO data in the Cloud instead of the LDAP directory of your company.

This guide explains how to install Enterprise Access Management, or EAM, (EAM gathers Authentication Manager and Enterprise SSO modules).

The EAM Software Suite

The EAM Security Services

EAM is composed of several software applications, which run through a middleware, called the EAM Security Services. It is a Windows service, which is automatically installed during the EAM installation process. It provides the following services:

Authentication (by passwords, smart cards, USB tokens, biometrics, mobile devices...).
Single Sign-On: retrieval of the SSO policy and management of the users’ secure SSO data depending on the authentication method.
Administration: daily administration tasks and creation and management of the SSO policy.
Audit.

IMPORTANT: The EAM applications do not run directly with the LDAP directory of your company with your users’ tokens. All the operations are performed by the Security Services, in a secure system environment.

The Security Services work directly with the corporate LDAP directory, except for the audit and administration services, for which it can use the EAM Controller.

EAM Components

Enterprise SSO

Enterprise SSO is the single sign-on (SSO) engine. It is installed on the client workstations. This software module offers many optional components.

Authentication Manager

Authentication Manager software module allows you to enforce users’ authentication and to use other authentication sources than Active Directory. When installed, it is used instead of the standard Windows log on dialog box.

Authentication Manager allows users to log on their workstation using several authentication methods, as login/password, smart cards, biometrics or mobile phone authentication methods.

It allows you also to manage primary authentication policies: authentication methods authorized by workstations or by users.

EAM Controller

The EAM Controller is an administration server that enables the management of administration profiles.

The administration actions are not directly sent from the workstations to the LDAP account of the EAM administrator, but through the EAM Controller: upon the EAM installation, you will have to define an LDAP account that will be used by the EAM Controller to perform any EAM administration action on the LDAP directory.

You do not have to set different ACLs depending on the EAM administrators. You just have to set ACLs only once, on the LDAP account used by the EAM Controller, which manages the administration requests depending on the administration profiles defined using EAM Console.

The EAM Controller runs also as the EAM audit server. It retrieves audit information of the EAM workstations in an SQL database. The pieces of audit data are available through EAM Console, either globally, or contextually (that is depending on the selected audited EAM object).

EAM Console

EAM Console is a centralized administration and audit consultation tool that can be installed on any EAM workstation client. This administration console allows you also to define extended security policies by managing Access Points, and by defining authentication scheduling.

NOTE: For details on supported authentication devices, see One Identity EAM Release NotesReplace this text with a description of a feature that is noteworthy.

Updating EAM

To update EAM or one of its components, run the installation through the Administration Tools window (see Starting the Administration Tools window) and re-install the wanted component(s): it(they) will be automatically updated.

EAM Architecture

EAM with an LDAP Directory

Subject

The following illustration details the different interactions between the different components of the EAM software suite, the corporate LDAP directory and applications.

Description

The Security Services components are installed on the EAM workstations (end-user and administration workstations). They are running as client of the EAM Controller to carry out the following functionalities:

Sending Audit events.
Enabling the administration of the EAM security objects.

It allows EAM users to authenticate to their corporate LDAP directory, either using their usual authentication interface, or using Authentication Manager if installed on the workstation.

The authentication allows EAM users to:

Get the SSO security policies stored in the directory.
Get their specific container used to store their SSO data.
Get cipher keys to secure their stored SSO data. Each EAM user has a unique key pair.

The EAM Controller gathers all the audit events sent by the EAM workstations in an SQL database.The link between the EAM workstations and the EAM Controller is secure (SSPI). An audit cache located on the EAM workstation manages network flows and stores the audit events if the workstation is disconnected from the network.

In disconnected mode, the administration actions are no longer carried out by the EAM applications (through the Security Services running as client of the EAM Controller), but directly by the EAM Controller.

EAM in the Cloud

Subject

The following illustration details the different interactions between the different components of the EAM software suite, the Cloud and applications.

Description

Only Enterprise SSO is installed on the user’s workstation, along with the E-SSO cache. Instead of being stored in the company’s LDAP directory, the SSO data as well as the other components are stored in the Cloud.

IMPORTANT: To create technical definitions on applications available on customer site only, Enterprise-SSO in registry mode is mandatory.

The user authenticates with his e-mail address and his Cloud password; the latter is locally stored on his workstation. The user has to enter it only once per workstation.

NOTE:

The password can also be stored encrypted in the LDAP directory by activating the following registry key on the client workstation: HKLM\SOFTWARE\Policies\Enatel\SSOWatch\CommonConfig\
CloudADAttribute, which contains the name of the attribute of type OCTET STRING of the user class objects. The user must be able to modify the value of this attribute; therefore it is recommended to create an attribute dedicated to Cloud E-SSO.
When this option is activated, Enterprise SSO is available on all the workstations of the company without any password to enter.

The SSO data is then downloaded through an HTTPS request sent to a Web service. The URL of this Web service is written during the installation under the following registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Enatel\SSOWatch\CommonConfig\DefaultCloudServer REG_SZ

The SSO Data is stored in C:\Users\username\AppData\Local\Evidian\EAM.

For more information on installing Cloud E-SSO, see Installing Cloud E-SSO.

EAM and Your Corporate LDAP Directory Infrastructure

Since EAM works directly with the directory in place to deploy the SSO policies, you must take into account your directory infrastructure before starting the installation process. The following sub-sections introduces EAM concepts related with directory infrastructure, and provides examples that may correspond to your situation.

Separation of the EAM Data

Subject

Depending on your LDAP directory infrastructure, you may not want to modify the schema of your corporate LDAP directory. In this case, it is possible to separate the storage of the EAM data.

NOTE: This feature is available with some of the LDAP directories supported by EAM. For details, see One Identity EAM Release Notes.

Example

For example, if you are using an Active Directory infrastructure, you can use an AD LDS (formerly named ADAM) directory to store the EAM configuration and the SSO data. In this mode, the Active Directory service is the identities directory, and AD LDS is an EAM dedicated directory used to store EAM data.

NOTE: The authentication process is not modified, as a user who authenticates to an Active Directory service can authenticate to an AD LDS service using the same credentials, through the Kerberos SSO mechanisms.

AD LDS Architecture

The following illustration shows an EAM architecture using an Active Directory service combined with an EAM dedicated AD LDS (formerly named ADAM) infrastructure.

Inter Domain and Multi Domain

Subject

This section introduces two EAM specific concepts dealing with Active Directory infrastructures: inter domain and multi domain.

NOTE:These concepts imply that your directory infrastructure is not a single domain infrastructure.

Inter-Domain

The inter domain concept refers to the EAM users. It consists in setting up EAM so that a user of one domain can authenticate on workstations of another domain.

For example, to set up EAM inter domain, you must follow the following requirements:

A relationship trust must be set up between the domains.
Users’ workstations must be members of their respective domains.

Multi-Domain

The multi domain concept refers to the EAM administrators. It consists in setting up EAM so that an EAM administrator can manage several domains at the same time using the EAM administration console.

The following illustration shows an EAM solution running in a multi domain configuration.

NOTE: Inter-domain can exist in a multi-domain configuration.

For an example of AD+AD LDS multi domain infrastructure, see Active Directory + AD LDS Infrastructure.

Examples of Supported Active Directory Infrastructures

Consider the following Active Directory infrastructure:

In this organization, the Active Directory infrastructure consists of the following:

Two Forests: Forest 1 and Forest 2.
Forest 1 is composed as follows:
- Domain A1 is the root domain.
- Domain B1 is the child domain of the parent domain Domain A1.
- Domain C1 is the child domain of the parent domain Domain B1.
Forest 2 is composed as follows:
- Domain A2 is the root domain.
- Domain B2 is the child domain of the parent domain Domain A2.
- Domain C2, which is another domain of Forest 2.

Multi-Domain Infrastructure

Infrastructure Example

Description

This example shows an Active Directory infrastructure designed to set up EAM multi domain. You can see that:

Forest 1 and Forest 2 support multi-domain, but multi domain is not supported for Forest 1 + Forest 2.
Inter-domain is supported for all domains of Forest 1 and for all domains of Forest 2. But inter domain is not supported between Forest 1 and Forest 2.

Active Directory + AD LDS Infrastructure

AD + AD LDS Infrastructure

The following example shows an Active Directory infrastructure combined with an EAM dedicated AD LDS infrastructure. You can see that there is one AD LDS instance for one Active Directory domain.

AD + AD LDS Multi Domain Infrastructure

The following example infrastructure shows an AD LDS infrastructure with AD multi domain.

Preparing the Storage of Security Data in the LDAP Directory

Subject

To implement the EAM environment, you have to create objects used by EAM in the LDAP directory. These objects will allow you to create security rules and to store the users’ single sign-on data. These pieces of data are ciphered.

EAM supports the following types of LDAP directory for storing user security data:

Active Directory.
Active Directory Lightweight Directory Services (AD LDS - formerly named ADAM)
Netscape iPlanet/Sun Java System/Red Hat/Fedora Directory Server.
OpenLDAP Directory Server.
Novell eDirectory.
IBM Tivoli Directory Server (ITDS).
Atos DirX Directory.

NOTE:For information on the supported versions of the listed LDAP directories, see One Identity EAM Release Notes.

Active Directory

Global Installation Process within an Active Directory Infrastructure

Subject

Depending on your Active Directory infrastructure, you may have to install several types of EAM Controllers. This section describes a multi domain architecture example. This may help you define your own software architecture depending on your requirements.

Definitions

There are three types of controllers that you can or must install depending on your needs:

The primary controller is mandatory. It corresponds to the first server that you install in a domain.
Secondary controllers, which correspond to other servers that you install in the same directory domain as the primary controller. Secondary controllers are redundant servers: if a controller is unavailable for any reason, user and administrator stations will just connect to another available controller:
If you are working in a multi-domain environment, you must install Associated controllers. These controllers are always installed after the primary controller, in another directory domain and they share the same security database. They allow EAM administrators to manage several domains using the same administration token (hardware protection mode) or pass phrase (software protection mode):

Multi Domain Architecture Example

The above illustration shows a multi-domain software architecture that uses four EAM Controllers (two controllers per domain) and a Master Audit Database:

The primary controller, which corresponds to the first EAM Controller, installed in Domain 1.
An associated controller, which corresponds to the EAM Controller installed in Domain 2.
Two secondary controllers (one in each domain).
The Audit Master Database, which contains the log entries of every individual EAM Controller. This concerns both user action log entries and administration action log entries. In this example, the local SQL Server databases of individual EAM Controllers are only used to store the audit events temporarily, before sending them to the Master base.

NOTE: By default, the Master Database is an SQL server. This audit base can be hosted on other databases than SQL Server. The list of databases for which this feature is supported is detailed in One Identity EAM Release Notes.

This example of architecture allows administrators to manage users that reside in different LDAP domains, and they can switch users from one domain to another in the forest. The secondary controllers provide high-availability.

Global Process

To set the EAM software architecture described above, do the following:

Extend the schema and set the ACLs of your Active Directory service (see Extending the Schema and Setting ACLs).
Install the Primary controller in Domain A.
In the same domain, install a Secondary controller.
Install an Associated controller in Domain B.
In the same domain, install a Secondary controller.
Install the Master Audit Database.
Then, install the workstation clients (administration workstation and end-users workstations).

Extending the Schema and Setting ACLs

Subject

For Active Directory, Evidian provides a schema management tool that allows you to:

Install or repair the Active Directory schema extension for EAM. These operations will be applied to the Active Directory domain controller that holds the role of Schema Master. This server must be made accessible for these operations.
Add or repair the ACLs specific to EAM on the existing user objects in the different domains of the forest.

The modifications to the Active Directory schema for EAM have been designed to be least intrusive as possible:

A few optional attributes types are added to the definition of standard classes like User and Group. These modifications are totally reversible.
All the identifiers of the attributes and classes that are added (LDAP names, OID, for example) have been registered with Microsoft and with international organizations.

Before Starting

Check that the Microsoft Active Directory is unlocked before starting the schema extension:
- In the Start menu, click Run and type regedt32.
- Open the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
  Services\NTDS\Parameters key.
- If necessary, set the Schema Update Allowed value to 1.
NOTE: You do not have to restart your computer..

EAM requires at least one dedicated user account to extend the Active Directory schema and to apply ACLs on the domain. This account must exist before starting the installation procedure, as the wizard will prompt you for account credentials.

So make sure you have a user account in the Active Directory forest which allows you to:

Modify the Active Directory schema (members of the Schema Admins group have this right).
Apply EAM ACLs on your domain (members of the Domain Admins group have this right).

NOTE: You are advised to use only one account that is at the same time member of the Schema Admins and of the Domain Admins groups. If it is not possible (depending on your Active Directory design), you can use two different accounts.

Each EAM Controller requires one dedicated user account to perform operations on the directory (such as the execution of administration requests, read and save operations on audit events, modifications on EAM objects). To simplify the configuration and the use of the solution, it is strongly recommended to gather these dedicated user accounts in Local groups, as detailed in the following procedure.

NOTE:

You may find the term "technical account" throughout this manual. We use this term to designate these EAM Controllers dedicated accounts.
You may find the term "technical account" throughout this manual. We use this term to designate these EAM Controllers dedicated accounts

Start Active Directory Users and Computers.
Create one Local Group for each domain of the forest.
Create one technical account for each EAM Controller that you will install on the domain, and define it as a member of the Local Group just created.

IMPORTANT:

For each technical account, enable the Password never expires option.

Each technical account must have the SE_RESTORE_NAME privilege. To be sure about it, add the technical account in the Backup Operators group of each domain.
Each technical account must have the right to force the password change of users. To assign this right, using Active Directory Users and Computers, start the Delegation of Control wizard (right-click the container(s) where the users that will have their passwords reset are located and select Delegate control), and delegate control of the following common task: Reset user passwords and force password change at next logon. Repeat the same operation on the AdminSDHolder container.In multi-domain mode, each technical account must be included in the other local groups..

Start Active Directory Sites and Services and for each domain controller of your forest, select NTDS Settings, then, in the right panel, right-click the connection objects and select Replicate now, as shown below:
If you are setting-up an inter-domain Active Directory infrastructure, you may have to deploy a domain account for WGSS to do LDAP requests to avoid Kerberos-related problems, as described in Deploying a Workstation LDAP User Account.
Windows 2000 Service Pack 2 servers only: if the Schema Master (which is the domain controller on which the schema extension operation is performed) is a Windows 2000 Service Pack 2 server, you must define, on each of your workstation clients, the UseCustomApplicationClass registry variable (DWORD) with value 1, in HKLM\Software\Enatel\Framework\Directory or HKLM\Software\Policies\Enatel\Framework\Directory.

Procedure

IMPORTANT: If you are installing EAM in multi-domain mode, read the following:

You must extend the schema and set ACLs only to install the EAM primary controller.
To install an associated controller, you just have to set ACLs.
Do not use this tool to install a secondary controller.

On the domain controller where you want to install the primary or the associated EAM controller, open the root folder of the Authentication Manager or Enterprise SSO installation package and run start.hta.

The EAM installation window appears.

NOTE: If the window does not appear, do the following:

Browse the downloaded installation package and open the folder corresponding to your Windows system processor: E-SSO for 32 bits processors and E-SSO.x64 for 64 bits processors.
Browse the TOOLS directory, and run WGAdSetup\WGADSetup.exe, and go to Step 4 of the current procedure.

In the Advanced Installation area, click one of the following, depending on your Windows system processor:
- Enterprise Access Management services: for 32 bits processors.
- Enterprise Access Management services - x64: for 64 bits processors.
The Administration Tools interface appears:
Click Extend Active Directory Schema.
IAM Active Directory Setup Tool starts.
Follow the displayed instructions with the following guidelines:

Step	When this window appears…	Do the following
1		If you are installing the EAM primary controller, enter the dedicated user account that is member of the Schema Admins group (for more information, see Before Starting above). If you are installing an associated controller: Enter the user account of an EAM user who is an administrator of the domain. This user must have full rights on the domain. Select Skip schema checking and jump directly to the domains setup. Click Next.
2		Click Next.
3		Click Next.
4		Click Yes.
5		At this step, the Active Directory schema extension is done. Click Next.
6		At this step, you have two possibilities: If the user account declared at Step 1 is also a member of the Domain Admins group, click Next and see Step 8. If not, change the user account: click Exit, restart the wizard and see Step 7.
7		Enter a user account that is member of the Domain Admins group (for more information, see Before Starting above). Select Skip schema checking and jump directly to the domains setup. Click Next.
8		Check that the selected domain is correct. Click Next.
9		If you do not want to store the configuration data in Program Data\IAM, click Choose another location and select in the displayed tree the wanted location. Click Next.
10		Select With controller. Click Next.
11		Select Enable the use of software. Click Next.
12		Read carefully the displayed instructions. As explained, it is strongly recommended to select Enable (or Keep, in case of update) the access control for members of protected groups. Click Next.
13		Select the mandatory container Program Data\IAM or the location where you store the configuration data. Select the following containers: The Users and Groups who will use EAM. The SSO Applications and SSO Objects. The computers where EAM is installed. Click Apply changes. Click Next.
14		If you have created a Local Group to gather the technical accounts used by the EAM controller (for more information, see Before Starting above), select Give some administration profiles to a group of the domain and enter the Group name. Then, select the Controller Server Account check box and click Next. Otherwise, see Step 17.
15		In System, select AdminSDHolder (this container allows you to administer the Active Directory administrators. Moreover, it enables any user to delegate accounts to Active Directory administrators). The modification is effective within one hour. Select the container(s) storing the Users, Groups, Computers and Domain Controllers that will be administered by the Administration Group entered at Step 14. Click Apply Changes. Click Next.
16		Select the following mandatory containers: Program Data\IAM or the location where you store the configuration data. System\AdminSDHolder Select the container(s) storing the EAM configuration data that will be administered by the Administration Group entered at Step 14 (the containers storing the configuration data were defined at Step 9). Click Apply Changes. Click Next.
17		If you want to set another Group, see Step 14. Else, select Finished for the selected domain, and click Next.
18		If you want to set ACLs on another domain (inter-domain or multi-domain infrastructures), or if you want to modify a configuration, select Configure another domain and click Next (see Step 8). Else, select Exit this program and click Exit.

NOTE: During the existing schema validation phase, objects that use EAM object identifiers may be detected. If this is the case, software from other suppliers that do not adhere to Microsoft’s recommendations for extending the Active Directory schema may have been installed. In these circumstances, contact the One Identity support center.

Setting Indexes on Active Directory Attributes (Optional)

Subject

IMPORTANT: This task is optional and may be done only if the directory repository has not been installed and configured in a standard way.

It is recommended to set indexes on both standard attributes and EAM specific attributes.

Before Starting

You must know how to set indexes manually.

Indexes on Standard Attributes

General Use

It is strongly recommended to index the following attributes:

cn.
objectCategory.
member.
dNSHostName.
objectGUID.

Custom LDAP Attributes Stored on the Authentication Token

When using a custom LDAP attribute stored on the authentication token, this attribute must be indexed for presence and equality searches.

User Search for Delegation

When searching users to which delegate an account, several attributes are used to search the directory using a substring match. These attributes must be indexed for substring search. By default, the attributes used are:

cn.
sn.
givenName.
mail.

Since administrators can change the attributes used for this search by modifying the UserSearchFilter registry value, check if the attributes you choose are indexed.

Indexes on EAM Specific Attributes

The following specific attributes must be indexed:

enatelUserSecurityProfileObject.
enatelApplicationProfileObject.
enatelUserEntityObject.
enatelComputerSecurityProfileObject.

If you plan smart card authentication, set the following attributes:

enatelSerialNumber.
enatelTokenClassName.
enatelTokenState.

If you plan cluster management, index the enatelPrettyName attribute (used for the alias feature) for performance reasons.

If you want to use Web Access Manager with EAM, set the following attributes:

enatelAccountBaseID.
enatelPersonalApplicationId.

Configuring Secure Authentication and Data Securization

With Active Directory, EAM uses automatically the most secure available method. No configuration is needed.

Active Directory + AD LDS

Subject

Microsoft Active Directory Lightweight Directory Services (AD LDS) is an LDAP directory service that runs as a user service, rather than as a system service.

The use of AD LDS with EAM allows you to store all EAM data (configuration objects, user security data, access information and so on) in the AD LDS directory, while the users data remains in the enterprise Active Directory. In this case, no modification is made to the Active Directory (no schema extension, no ACL modification or object creation.)

This section explains how to extend the schema of AD LDS and set some access control rules (ACL).

Multi Domain Architecture Example

If you want to work in a multi domain AD LDS environment, you must first install all the necessary AD domain controllers and then install the AD LDS directory.

The above illustration shows a multi-domain software architecture that uses two EAM Controllers and a Master Audit Database:

The primary controller, which corresponds to the first EAM Controller.
One secondary controller.
The Audit Master Database, which contains the log entries of every individual EAM Controller. This concerns both user action log entries and administration action log entries. In this example, the local SQL Server databases of individual EAM Controllers are only used to store the audit events temporarily, before sending them to the Master base.

NOTE: By default, the Master Database is an SQL server. However, this audit base can be hosted on other databases than SQL Server. The list of databases for which this feature is supported is detailed in One Identity EAM Release Notes.

Global Process

To set the EAM software architecture described above, do the following:

Extend the Schema and Set the ACLs of your AD LDS (see Extending the Schema of AD LDS and Setting ACLs on AD LDS).
Install the Primary controller.
Install a Secondary controller.
Install the Master Audit Database.
Then, install the workstation clients (administration workstation and end-users workstations).

Before Starting

Download and install AD LDS from the Microsoft web site.

NOTE: For more information on supported versions and operating systems on which it can be installed, see One Identity EAM Release Notes.
Create an AD LDS instance with at least one partition and with the following parameters and restrictions:

Parameters:

Wizard Window Name	EAM Requirements
"Setup Options"	Choose Unique instance.
"Application Directory Partition"	Choose Yes
"ADAM Administrators"	An AD LDS administrator is an account with control over the AD LDS instance. You must select an account in the Active Directory domain, not a local account. In case of a multi domain architecture, you are advised to select an account with the Reset Password permission, to change the primary passwords of the Active Directory users. This permission is not mandatory if you do not need to use EAM Console to change user passwords (case of a EAM installation in session authentication mode for example). This account must have the SE_RESTORE_NAME privilege. To be sure about it, add the user in the local Backup Operators group.
"Importing LDIF Files"	Import all LDIF files. The MS-User.LDF file is mandatory.

Restrictions:

The Distinguished Name of the AD LDS partition must not include the Naming Context of an existing Windows domain. For example, if your domain naming context is DC=domain,DC=com, do not set CN=SSO,DC=domain,DC=COM as your AD LDS naming context.
AD LDS must not be installed on a Domain Controller.
EAM uses the Kerberos protocol for authenticating to LDAP with AD LDS servers. To avoid Kerberos-related problems, read carefully the following:
- Enter the real fully qualified DNS name (and not an DNS alias) to set the name of the AD LDS host, and NOT its IP address (if you enter an IP address, the Kerberos authentication is not guaranteed to be yielded and you may have Kerberos errors.).
- If despite the restriction you absolutely need to install AD LDS on a Domain Controller, some functionalities won’t not work properly. In this case, you must deploy a domain account for each EAM Security Services (wgss) (see Deploying a Workstation LDAP User Account).
NOTE: For more information on how to create an AD LDS instance, please refer to the Microsoft website and documentation.

Extending the Schema of AD LDS

Procedure

In a command line console, change to the %WINDIR%\ADAM directory and type the following command for each of the provided LDIF files:

ldifde -i -v -k -s <host:port> -f <file.ldif> -c "CN=Schema,CN=Configuration,DC=X" #schemaNamingContext -b <user> <domain> <password>

IMPORTANT: Do not replace the following string: "CN=Schema,CN=Configuration,DC=X"..

Where:

String	Description
<host:port>	The AD LDS server hostname and TCP port. For example: adam.domain.local:389.
<file.ldif>	The provided ldif file, which is located in the TOOLS\ESSODirectory\AD LDS (users in AD) directory.
<user>	The user name of the AD LDS administrator chosen during the instance installation.
<domain>	The NetBios domain of the user.
<password>	The user password.

NOTE: ldifde is located in the %WINDIR%\ADAM directory.

Once you have run the command for each of the LDIF files, the AD LDS schema is extended.

Preparing the AD LDS Instance Administrator Account

The Windows account you chose when setting the AD LDS instance to be the administrator of this instance (see the Before Starting of Preparing the Storage of Security Data in the LDAP Directory) must have the SE_RESTORE_NAME privilege in the local computer policy. To do so, set this account in the Backup Operators local group of the local computer.

Setting ACLs on AD LDS

Subject

You must set some access control rules on the partition, for the domain users to store and retrieve data in AD LDS. For that, the ACL-ADAM-EXTMGR.cmd file is provided in the Authentication Manager or Enterprise SSO installation package.

Procedure

Edit the ACL-ADAM-EXTMGR.cmd file located in the TOOLS\ESSODirectory\AD LDS (users in AD) directory.
In the ACL-ADAM-EXTMGR.cmd file, uncomment the following lines:
- set DSACLS=dsacls.exe or set DSACLS=%WINDIR%\ADAM\dsacls.exe, depending on your system:
  - If the EAM Controller is installed on Windows Server 2008 (or above), uncomment the following line:
    set DSACLS=dsacls.exe
  - If the EAM Controller is not installed on Windows Server 2008 (or above), uncomment the following line:
    set DSACLS=%WINDIR%\ADAM\dsacls.exe
- set HOSTNAME=myadamserver.domain.com:port
  Replace myadamserver.domain.com with the fully qualified AD LDS host name and TCP port.
- set LDAPROOT=o=my,c=root
  Replace o=my,c=root with the partition root chosen during the AD LDS instance installation.
Copy the ACL-ADAM-EXTMGR.cmd file in the %WINDIR%\ADAM directory.
In a command line console, change to the %WINDIR%\ADAM and run the ACL-ADAM-EXTMGR.cmd script.

Setting Indexes on AD LDS Attributes

Setting Indexes on Standard Attributes

The following standard attributes must be indexed:

cn.
objectCategory.
member.
objectGUID.

Setting Indexes on EAM Specific Attributes

The following EAM specific attributes must be indexed:

enatelUserSecurityProfileObject.
enatelApplicationProfileObject.
enatelUserEntityObject.
enatelComputerSecurityProfileObject.

If you plan smart card authentication, set the following attributes:

enatelSerialNumber.
enatelTokenClassName.
enatelTokenState.

If you want to use Web Access Manager with EAM, set the following attributes:

enatelAccountBaseID.
enatelPersonalApplicationId.

Configuring Secure Authentication and Data Securization

With AD LDS, EAM uses automatically the most secure available method. No configuration is needed.

OpenLDAP

IMPORTANT: The configuration of EAM Services with an OpenLDAP directory requires advanced skills and integration service is required. Please contact One Identity services at srv-expertise@one identity.com.

It is strongly recommended to set up your OpenLDAP directory with TLS support (Transport Layer Security) to secure critical data (as user account parameters, passwords…).
It is also recommended to set up the SASL/DIGEST-MD5 authentication on your directory to secure authentication.
The OpenLDAP installation must include the following schema definitions in the slapd.conf file:
- core.schema
- cosine.schema
- inetorgperson.schema

Extending the Schema of an OpenLDAP Directory

Subject

To extend the schema of an existing OpenLDAP directory, the wiseguard.schema file is provided on the Authentication Manager or Enterprise SSO installation package, in TOOLS\ESSODirectory\OpenLDAP.

Procedure

Include the EAM schema definition after the standard schema definitions by adding the following command line in slapd.conf:

include <file path>/wiseguard.schema

Setting ACLs on an OpenLDAP Directory

Subject

To position ACLs on an OpenLDAP directory, use the wiseguard-em.acl file located on the Authentication Manager or Enterprise SSO installation package, in TOOLS\ESSODirectory\OpenLDAP.

Before Starting

If you want to authenticate as an administrator in EAM, you must create a user or a group of users and give it administration rights in the directory.

Procedure

Edit slapd.conf to set your ACLs, with the following guidelines:

The access directive, which is used to set ACLs is complex. It allows very fine control over who can access what objects and attributes and under what conditions. The side-effect of this complexity and power is that it is very easy to get the access directive wrong. You must thoroughly test ACL directives with all possible permissions.
The access directive may be placed in either the global or the database section of slapd.conf.
Multiple access directives may be included.
The order of the access directives is very important. If possible, it is strongly recommended to set them in the following order:
- rootDSE.
- Password.
- Directory administrators.
- EAM.
- Others.

Example

The following example shows configuration parameters to enter to integrate the EAM rules into existing rules.

# reading the rootDSE special entry

access to dn.base="" by * read

# authentication
access to attrs=userPassword

by dn="cn=administrateur,dc=evidian,dc=fr" write

by groupdn="cn=administrateurs,dc=evidian,dc=fr" write

by anonymous auth

by self write

by * none

access to *

by dn="cn=administrateur,dc=evidian,dc=fr" write

by groupdn="cn=administrateurs,dc=evidian,dc=fr" write

by self write

by * break

# the ACL WG

include <file path>/wiseguard-em.acl

access to * by * read

Setting Indexes on OpenLDAP Attributes

Setting Indexes on Standard Attributes

General Use

The following standard attributes must be indexed:

cn (substring, equality, presence).
uid (equality, presence).
objectClass (equality, presence).
member (equality, presence).
uniqueMember (equality, presence).
displayName (equality, presence).
entryUUID (equality).

Custom LDAP Attributes Stored on the Authentication Token

When using a custom attribute stored on the authentication token, this attribute must be indexed for presence and equality searches.

User Search for Delegation

cn
sn
givenName
mail

Since the administrator can change the attributes used for this search by modifying the UserSearchFilter registry value, he has to check if the attributes he chooses are indexed.

Setting Indexes on EAM Specific Attributes

To set the indexes definitions for EAM specific attribute types, open the wiseguard-extmgr.indexes file. This file is located in TOOLS\ESSODirectory\OpenLDAP (in the Authentication Manager or Enterprise SSO installation package). Just include it in your slapd.conf configuration file.

IMPORTANT: As the indexes are subsequently changed, the directory needs to be re-indexed using slapindex with the following guidelines:

Stop the slapd daemon before using slapindex.
If you have several slapd.conf files, check that you specify the right one.
The slapd daemon must be able to write on the created index files.

Integrating SAMBA

You can combine EAM with a SAMBA domain controller storing its data in an OpenLDAP server.

We provide slapd-samba-extmgr-sample.conf, a sample OpenLDAP configuration file showing how to integrate EAM ACLs and SAMBA ACLs. This file is located in TOOLS\ESSODirectory\OpenLDAP (in the Authentication Manager or Enterprise SSO installation package).

SAMBA manages its own computer objects. In order that ESSO uses the SAMBA computer objects, instead of creating new ones, you must enable integration of SAMBA computer objects in EAM. See EAM Configuration with a User Database or Directory other than Microsoft Active Directory in Configuring Workstations.

SAMBA uses non-standard LDAP group entries, using the posixGroup objectClass, which is not handled by EAM in the default configuration. For EAM to use the SAMBA group objects, you must enable integration of SAMBA group objects in EAM. See EAM Configuration with a User Database or Directory other than Microsoft Active Directory in Configuring Workstations.

If passwords are synchronized from the SAMBA controller to the OpenLDAP server (and not from OpenLDAP to SAMBA), you must enable password synchronization from the SAMBA controller to the OpenLDAP server in EAM. Thus, when a user changes his password, the password change operation will then use Microsoft APIs calls to the SAMBA controller, and not LDAP request to the OpenLDAP server, which would have caused a password desynchronization between SAMBA and OpenLDAP. See EAM Configuration with a User Database or Directory other than Microsoft Active Directory in Configuring Workstations.

Configuring Secure Authentication

Subject

With OpenLDAP, EAM supports DIGEST-MD5 SASL mechanisms. This section explains how to configure EAM for DIGEST-MD5 with OpenLDAP.

Before Starting

Configure OpenLDAP for DIGEST-MD5: you must configure the matching between SASL authentication identity and directory users. For an authentication based on the uid attribute, you must put the following directives in the slapd.conf file:

sasl-regexp

uid=(.*),cn=digest-md5,cn=auth

ldap:///dc=evidian,dc=fr??subtree?(uid=$1)

NOTE: With OpenLDAP using DIGEST-MD5 implies that user passwords are stored in clear text in the directory.

Procedure

In the Windows registry set the following value (DWORD type) to 1:

HKLM/Software/Enatel/WiseGuard/FrameWork/Directory/LdapAuthMethod

Configuring Data Securization

Subject

This section describes how to configure your LDAP directory to secure authentication information and other sensitive EAM data transmitted on the network.

Before Starting

EAM supports TLS and SSL, but it is strongly recommended to configure your LDAP directory to support TLS.

Procedure

In the Windows registry, under the HKLM/Software/Enatel/WiseGuard/FrameWork/Directory key, configure TLS with the following values:

TLS: TLS activation. The following values are available:
- 0: TLS is not activated to secure EAM communications.
- 1: TLS is systematically activated. All communications are encrypted. This can lower the performance on the LDAP server.
- 2: TLS is only activated when a sensible data is transferred on the network (during password change or account creation).
IMPORTANT: It is strongly recommended to set the TLS value to 2.
TLSDemand: configures the behavior in case of TLS failure when it is activated:
- 0: TLS is not mandatory: If TLS fails, the connection is activated without encryption.
- 1: TLS is mandatory: if TLS fails, no connection is activated.
TLSVerifyServerCertificate: checks the server certificate.
- 0: the server certificate is not checked. You do not need to indicate the certification authority (CA) certificate.
- 1: the server certificate is checked with the certification authority. You need to specify the CA certificate.
TLSCACertificateFile: enter the path to the CA certificate file.
TLSCACertificatePassword: enter the password used if needed to open the CA certificate file.

NOTE: A certificate is public data that does not need to be protected.

Netscape iPlanet/Sun Java System/Red Hat/Fedora Directory Server

Extending the Schema of a Netscape iPlanet/Sun Java System/Red Hat/Fedora Directory Server

Subject

To extend the schema of an existing iPlanet/Sun Java System/Red Hat/Fedora Directory Server, a file is provided on the Authentication Manager or Enterprise SSO installation package, in TOOLS\ESSODirectory\Oracle DSEE - RedHat DS - 389 DS\wiseguard-schema.ldif.

IMPORTANT: The configuration of SSO for Java requires advanced skills. To deliver SSO access to Java applications, integration service is required. Please contact One Identity services at srv-expertise@one identity.com..

Before Starting

To extend the schema, the user needs to have the permission to create new objects.

Procedure

Extend the schema by typing the following command:

ldapmodify -h <host> –p <port> -D <administrator DN> -w <administrator password> -f wiseguard-schema.ldif

Where:

String	Description
<host>	LDAP server hostname.
<port>	TCP port number of the LDAP server instance you want to configure.
<administrator DN>	DN of the instance administrator.
<administrator password>	Password of the instance administrator.

Setting ACLs on a Netscape iPlanet/Sun Java System/Red Hat/Fedora Directory Server

The procedure is different depending on the data model you want to store EAM data. If you want to store EAM data in:

Your corporate naming context, see Standard Storage Mode.
A dedicated naming context, see Cooperative Storage Mode.

Standard Storage Mode

Subject

In this mode, EAM data is stored in your corporate naming context.

Before Starting

If you want to authenticate in EAM as an administrator, you must create a user or a group of users and give it administration rights in the directory.

Procedure

In the Authentication Manager or Enterprise SSO installation package, open the TOOLS\ESSODirectory\Oracle DSEE - RedHat DS - 389 DS\wiseguard-ACL-extmgr.ldif file in a text editor and perform the following modifications:
Replace ##SUFFIX## with the Distinguished Name of your corporate naming context.
Apply the modification by typing the following command line:
ldapmodify -h <host> –p <port> -D <administrator DN> -w <administrator password> -f wiseguard-ACL-extmgr.ldif

Where:

String	Description
<host>	LDAP server hostname.
<port>	TCP port number of the LDAP server instance you want to configure.
<administrator DN>	DN of the instance administrator.
<administrator password>	Password of the instance administrator.

Cooperative Storage Mode

Subject

In this mode, EAM data is stored in a dedicated naming context. The ACLs are set on this naming context.

Before Starting

IMPORTANT: Before carrying out the following procedure, create the EAM default objects, as described in Running the Default Objects Creation Tool..

If you want to authenticate in EAM as an administrator, you must create a user or a group of users and give it administration rights in the directory.

Procedure

In the Authentication Manager or Enterprise SSO installation package, open the TOOLS\ESSODirectory\Oracle DSEE - RedHat DS - 389 DS\wiseguard-ACL-cooperativemode-extmgr.ldif file in a text editor and perform the following modifications:
- Replace ##SUFFIX## with the Distinguished Name of the dedicated naming context.
- Replace ##AUTHSUFFIX## with the Distinguished Name of your corporate naming context.
- Replace ##WGFOREIGNOBJECTS## with the Distinguished Name of the container of the EAM naming context storing the user’s personal EAM data.
NOTE: To know the value of this DN, you must have previously created the EAM default objects. By default the value of this DN is: ou=IAMForeignObjects,ou=Default, ou=ESSO,<dedicated suffix>.

Apply the modification by typing the following command line:

ldapmodify -h <host> –p <port> -D <administrator DN> -w <administrator password> -f wiseguard-ACL-cooperativemode-extmgr.ldif

Where:

String	Description
<host>	LDAP server hostname.
<port>	TCP port number of the LDAP server instance you want to configure.
<administrator DN>	DN of the instance administrator.
<administrator password>	Password of the instance administrator.

Setting Indexes on Netscape iPlanet/Sun Java System/Red Hat/Fedora Directory Server Attributes

Setting Indexes on Standard Attributes

General Use

The following standard attributes must be indexed:

IMPORTANT: Set these attributes in the corporate and in the EAM dedicated naming contexts.

cn (substring, equality, presence).
uid (equality, presence).
objectClass (equality, presence).
member (equality, presence).
uniqueMember (equality, presence).
displayName (equality, presence).
nsuniqueid (equality).

Custom LDAP Attributes Stored on the Authentication Token

When using a custom attribute stored on the authentication token, this attribute must be indexed for presence and equality searches.

IMPORTANT: Set this attribute in the corporate naming context only.

User Search for Delegation

When searching users to which delegate an account, several attributes are used to search the directory using a substring match. These attributes must be indexed for substring search.

IMPORTANT: Set these attributes in the corporate naming context only.

By default, the attributes used are:

cn
sn
givenName
mail

Since the administrator can change the attributes used for this search by modifying the UserSearchFilter registry value, he has to check if the attributes he chooses are indexed.

Setting Indexes on EAM Specific Attributes

The following EAM specific attributes must be indexed:

IMPORTANT: Set these specific attributes in the EAM dedicated naming context only.

enatelUserSecurityProfileObject (equality, presence).
enatelApplicationProfileObject (equality, presence).
enatelUserEntityObject (equality, presence).
enatelComputerSecurityProfileObject (presence).
enatelApplicationObject (equality, presence).
enatelSSOParameterObject (equality, presence).
enatelSSOParameterPresetId (equality, presence).
enatelScheduleObject (equality, presence).
enatelPasswordFormatObject (equality, presence).
enatelPasswordChangePolicyObject (equality, presence).
enatelUserEntityObject (equality, presence).
enatelAllowedApplicationMask (equality, presence).
enatelUserRoleObject (equality, presence).
enatelAccountType (equality, presence).
enatelSoftwareModuleType (equality, presence).
enatelAuditId (equality, presence).
enatelAuditFilterObject (equality, presence).

If you plan smart card authentication, set the following attributes:

enatelSerialNumber (equality, presence).
enatelTokenClassName (equality, presence).
enatelTokenState (equality, presence).

If you want to use Web Access Manager with EAM, set the following attributes:

enatelAccountBaseID (equality, presence).
enatelPersonalApplicationId (equality, presence).

Configuring Secure Authentication

Subject

With Netscape iPlanet/Sun Java System/Red Hat/Fedora Directory Server, EAM supports DIGEST-MD5 SASL mechanisms. This section explains how to configure EAM for DIGEST-MD5 with Netscape iPlanet/Sun Java System/Red Hat/Fedora Directory Server.

IMPORTANT: This task is optional. Carry out the following procedure only if required.

Before Starting

Configure iPlanet/Sun Java System/Red Hat/Fedora Directory Server for DIGEST-MD5.

Depending on your directory version, to secure authentication in EAM it may be necessary to modify the password encryption method, so that the user password can be stored in clear text in your directory.

Procedure

In the Windows registry set the following value (DWORD type) to 1:

HKLM/Software/Enatel/WiseGuard/FrameWork/Directory/LdapAuthMethod

Configuring Data Securization

Subject

This section describes how to configure your LDAP directory to secure authentication information and other sensitive EAM data transmitted on the network.

Before Starting

EAM supports TLS and SSL, but it is strongly recommended to configure your LDAP directory to support TLS.

Procedure

In the Windows registry, under the HKLM/Software/Enatel/WiseGuard/FrameWork/Directory key, configure TLS with the following values:

TLS: TLS activation. The following values are available:
- 0: TLS is not activated to secure EAM communications.
- 1: TLS is systematically activated. All communications are encrypted. This can lower the performance on the LDAP server.
- 2: TLS is only activated when a sensible data is transferred on the network (during password change or account creation).
IMPORTANT: It is strongly recommended to set the TLS value to 2

TLSDemand: configures the behavior in case of TLS failure when it is activated:
- 0: TLS is not mandatory: If TLS fails, the connection is activated without encryption.
- 1: TLS is mandatory: if TLS fails, no connection is activated.
TLSVerifyServerCertificate: checks the server certificate.
- 0: the server certificate is not checked. You do not need to indicate the certification authority (CA) certificate.
- 1: the server certificate is checked with the certification authority. You need to specify the CA certificate.
TLSCACertificateFile: enter the path to the CA certificate file.
TLSCACertificatePassword: enter the password used if needed to open the CA certificate file.

NOTE: A certificate is public data that does not need to be protected.
TLSCACertificateFileFormat (file format used to store the certificate):
0 - OpenSSL PEM file (Base 64 encoding) or certificate file in the ASCII format of Directory Server.

Novell eDirectory

Extending the Schema of a Novell eDirectory

Subject

To extend the schema of a Novell eDirectory, the file wiseguard-schema.ldif is provided in the directory TOOLS\ESSODirectory\Novell eDirectory of the Authentication Manager or Enterprise SSO installation package. This contains the definition of the Evidian objects.

Procedure

Extend the schema using one of the following commands:

ldapmodify -c -h <host> -p <port>

-D <super-user DN> -w <super-user password>

-f wiseguard-schema.ldif

or:

ice -S LDIF -f wiseguard-schema.ldif

-D LDAP -s <host> -p <port>

-d <super-user DN> -w <super-user password>

Where:

<host> is replaced by your LDAP server hostname.
<port> is replaced by the port number of your LDAP server.
<super-user DN> is replaced by the distinguished name of your directory super-user.
<super-user password> is replaced by the password of the super-user.

Setting ACLs for Delegation (Optional)

Subject

To enable EAM account delegation, users must be able to search the directory for other users. The file wiseguard-delegation-ACL.ldif in the directory TOOLS\ESSODirectory\Novell eDirectory of the Authentication Manager or Enterprise SSO installation package is used to give the necessary access rights for this operation.

NOTE: This procedure can be performed at any time.

Procedure

Modify a copy of the file wiseguard-delegation-ACL.ldif and replace the text ##ROOT_DN## with the distinguished name of the root node of your LDAP server.
Set the ACLs with one of the following command:
ldapmodify -x -h <host> -p <port>

-D <super-user DN> -w <super-user password>

-c -f wiseguard-delegation-ACL.ldif

or:

ice -S LDIF -c -f wiseguard-delegation-ACL.ldif

-D LDAP -s <host> -p <port>

-d <super-user DN> -w <super-user password>

Where:

<host> is replaced by your LDAP server hostname.
<port> is replaced by the port number of your LDAP server.
<super-user DN> is replaced by the distinguished name of your directory super-user.
<super-user password> is replaced by the password of the super-user.

Setting Indexes on Novell eDirectory Attributes

Setting Indexes on Standard Attributes

General Use

The following standard attributes must be indexed:

cn (substring, equality, presence).
uid (equality, presence).
objectClass (equality, presence).
member (equality, presence).
uniqueMember (equality, presence).
displayName (equality, presence).
GUID (equality).

Custom LDAP Attributes Stored on the Authentication Token

When using a custom attribute stored on the authentication token, this attribute must be indexed for presence and equality searches.

User Search for Delegation

cn
sn
givenName
mail

Since the administrator can change the attributes used for this search by modifying the UserSearchFilter registry value, he has to check if the attributes he chooses are indexed.

Setting Indexes on EAM Specific Attributes

The following specific attributes must be indexed:

enatelUserSecurityProfileObject (equality, presence)
enatelApplicationProfileObject (equality, presence)
enatelTokenClassName (equality, presence)
enatelSerialNumber (equality, presence)
enatelTokenState (equality, presence)
enatelUserEntityObject (equality, presence)
enatelSoftwareModuleType (equality, presence)
enatelComputerSecurityProfileObject (presence)
enatelSSOParameterPresetId (equality, presence)
enatelComputerObject (equality, presence)
enatelAccountBaseID (equality, presence)
enatelAdmObject (equality, presence)
enatelTokenType (equality, presence)
enatelSSOKeys (presence)
enatelGlobalCertificateState (equality, presence)
enatelAccountType (equality, presence)
enatelAllowedApplicationMask (equality, presence)
enatelApplicationObject (equality, presence)
enatelSSOParameterObject (equality, presence)
enatelUserRoleObject (equality, presence)
enatelUserLocalAccountName (equality, presence)
enatelPasswordChangePolicyObject (equality, presence)
enatelExpirationDate (ordering, equality, presence)
enatelTokenPinState (equality, presence)
enatelLentUntil (ordering, equality, presence)
enatelPersonalApplicationId (equality, presence)

Configuring Secure Authentication (Optional)

Subject

With Novell eDirectory, EAM supports the following SASL mechanisms:

DIGEST-MD5.
NMAS: the SASL/NMAS mechanism allows the use of NMAS modular authentication from Novell, and allows a choice between available authentication sequences. EAM only supports the NDS sequence, which consists in a secure authentication with login and password.

This section explains how to configure EAM for DIGEST-MD5 and NMAS with Novell eDirectory.

IMPORTANT: It is strongly recommended to use the NMAS mechanism.This task is optional. Carry out the following procedure only if required.

Before Starting

To use NMAS authentication, the Novell NMAS Client software must be installed on your EAM Controller.

Procedure

In the Windows registry, set the DWORD value HKLM/Software/Enatel/WiseGuard/FrameWork/Directory/LdapAuthMethod as follows:

for NMAS: 4.
for DIGEST-MD5: 1.

Configuring Data Securization

Subject

This section describes how to configure your LDAP directory to secure authentication information and other sensitive EAM data transmitted on the network.

Before Starting

EAM supports TLS and SSL, but it is strongly recommended to configure your LDAP directory to support TLS.

Procedure

In the Windows registry, under the HKLM/Software/Enatel/WiseGuard/FrameWork/Directory key, configure TLS with the following values:

TLS: TLS activation. The following values are available:
0: TLS is not activated to secure EAM communications.
1: TLS is systematically activated. All communications are encrypted. This can lower the performance on the LDAP server.
2: TLS is only activated when a sensible data is transferred on the network (during password change or account creation).

IMPORTANT: It is strongly recommended to set the TLS value to 2.
TLSDemand: configures the behavior in case of TLS failure when it is activated:
- 0: TLS is not mandatory: If TLS fails, the connection is activated without encryption.
- 1: TLS is mandatory: if TLS fails, no connection is activated.
TLSVerifyServerCertificate: checks the server certificate.
- 0: the server certificate is not checked. You do not need to indicate the certification authority (CA) certificate.
- 1: the server certificate is checked with the certification authority. You need to specify the CA certificate.
TLSCACertificateFile: enter the path to the CA certificate file.
TLSCACertificatePassword: enter the password used if needed to open the CA certificate file.

NOTE: A certificate is public data that does not need to be protected.

IBM Tivoli Directory Server

Extending the Schema of an IBM Tivoli Directory Server

Subject

To extend the schema of an IBM Tivoli Directory Server, two files are provided on the Authentication Manager or Enterprise SSO installation package, in TOOLS\ESSODirectory\IBM Tivoli Directory Server:

wiseguard.at
wiseguard.oc

Before Starting

IMPORTANT:User objects must possess the enatelUser auxiliary class to be able to use EAM.

Procedure

Start the IBM Tivoli Directory Server (ITDS) server configuration tool.
Click the Manage schema files section.
Add the following file in this exact order:
- wiseguard.at
- wiseguard.oc

Setting ACLs on an IBM Tivoli Directory Server

Subject

This section explains how to set ACLs on an IBM Tivoli Directory Server.

Before Starting

IMPORTANT: Users must possess the following entry in their ACL (ibm-filterAclEntry attribute):

id:<DN>:(objectClass=*):object:ad:system:rsc:normal:rws c:restricted:rwsc:sensitive:rwsc

Where the <DN> string must be replaced with the user DN.

Procedure

To set EAM access permissions on the directory, apply the following LDIF file on the directory root:

dn: <DNSuffixe>

changetype: modify

add: ibm-filterAclEntry

ibm-filterAclEntry: group:CN=ANYBODY:(objectClass=*):system:rsc:restricted:rsc:normal:rsc

ibm-filterAclEntry: group:CN=AUTHENTICATED:(objectClass=enatelSSOStorage):object:a

ibm-filterAclEntry: group:CN=AUTHENTICATED:(&(objectClass=enatelSSOAccount)(enatelAccountType=3)):object:d:system:rsc:normal:rwsc:restricted:rwsc:sensitive:rwsc

ibm-filterAclEntry: access-id:CN=THIS:(objectClass=inetOrgPerson):at.userPassword:w

ibm-filterAclEntry: access-id:CN=THIS:(objectClass=enatelComputer):at.userPassword:w

Where:

The <DNSuffixe> string must be replaced with the directory suffix.

Setting Indexes on IBM Tivoli Directory Server Attributes

On IBM Tivoli Directory Server, indexes are set during the schema extension.

Configuring Secure Authentication

Subject

With IBM Directory Server, EAM supports DIGEST-MD5 SASL mechanisms. This section explains how to configure EAM for DIGEST-MD5 with IBM Directory Server.

Before Starting

The IBM LDAP client is mandatory to perform a DIGEST-MD5 authentication toward IBM Tivoli Directory Server.
Configure IBM Tivoli Directory Server for DIGEST-MD5:

With IBM Tivoli Directory Server, it implies that user passwords are stored in clear text in the directory or with the iMask symmetrical encryption.

Procedure

In the Windows registry set the following value (DWORD type) to 1:

HKLM/Software/Enatel/WiseGuard/FrameWork/Directory/LdapAuthMethod

Configuring Data Securization

Subject

This section describes how to configure your LDAP directory to secure authentication information and other sensitive EAM data transmitted on the network.

Before Starting

EAM supports TLS and SSL, but it is strongly recommended to configure your LDAP directory to support TLS.

Procedure

In the Windows registry, under the HKLM/Software/Enatel/WiseGuard/FrameWork/Directory key, configure TLS with the following values:

TLS: TLS activation. The following values are available:
- 0: TLS is not activated to secure EAM communications.
- 1: TLS is systematically activated. All communications are encrypted. This can lower the performance on the LDAP server.
- 2: TLS is only activated when a sensible data is transferred on the network (during password change or account creation).
IMPORTANT: It is strongly recommended to set the TLS value to 2.
TLSDemand: configures the behavior in case of TLS failure when it is activated:
- 0: TLS is not mandatory: If TLS fails, the connection is activated without encryption.
- 1: TLS is mandatory: if TLS fails, no connection is activated.
TLSVerifyServerCertificate: checks the server certificate.
- 0: the server certificate is not checked. You do not need to indicate the certification authority (CA) certificate.
- 1: the server certificate is checked with the certification authority. You need to specify the CA certificate.
TLSCACertificateFile: enter the path to the CA certificate file.
TLSCACertificatePassword: enter the password used if needed to open the CA certificate file.

NOTE: A certificate is public data that does not need to be protected.
TLSCACertificateFileFormat file format used to store the certificate:
1 - IBM Keyring "CMS" file.

Atos DirX Directory

Directory Requirements

EAM requires that EAM users have a unique directory attribute that distinguishes each from the others. For Atos DirX Directory, this attribute is the LDAP uid attribute.

E-SSO account entries must be of LDAP object class inetOrgPerson.

Extending the Schema of an Atos DirX Directory

The DirX Directory schema must be extended to allow the creation of EAM objects. The TOOLS\ESSODirectory\Atos DirX Directory\esso-dirx-schema.ldif file in the EAM installation package contains the schema modifications.

Procedure

Extend the schema by executing the following command on the DirX Directory workstation:
dirxmodify -h <host> -p <port> -D <administrator DN> -w <administrator password> -f esso-dirx-schema.ldif -v -e error.txt

where:

<host> is the hostname of the DirX server.
<port> is the port number of the DirX server.
<administrator DN> is the LDAP DN of a directory administrator who has the right to modify the directory schema.
<administrator password> is the password of the directory administrator.

NOTE: After executing the command, check the error.txt file for possible error messages.

Setting ACLs on an Atos DirX Directory

To give the necessary permissions to EAM users, EAM ACLs must be set in the Atos DirX Directory.

Procedure

Copy the TOOLS\ESSODirectory\Atos DirX Directory folder containing the files to set the ACLs from the EAM installation package to the DirX Directory workstation.
Modify the local copy of the esso-dirx-params.tcl file.
Provide the DNs of the directory administrator, EAM controller group and DirX administration point which will hold the ACLs.

NOTE: These names are in DirX DAP DN format.
In the same folder, execute the dirxcp esso-dirx-acl.tcl command to set the ACLs.

NOTE: Enter the administrator password if prompted.

Managing Anonymous Access Denial

If the directory your are connecting to enforces an anonymous access denial (bind), you can set the following registry value on all the EAM controllers and workstations to cope with this directory policy: HKLM\SOFTWARE[\Policies]\Enatel\WiseGuard\FrameWork\Directory\
AnonymousBindForbidden (REG_DWORD) = 0x01

IMPORTANT: This registry value must be set before starting the EAM Administration Tools (WGAdminTools).

Deploying a Workstation LDAP User Account

Subject

You can force EAM to use a given LDAP account to do requests on the directory server.

Before starting

Make sure the dedicated user is created in your directory.

IMPORTANT: If you are using Active Directory, the user must belong to the "Domain Computers" group.

Procedures

From a domain controller

At the Windows prompt, change to the C:\Program Files\Common Files\Evidian\WGSS folder and type the following command: wgss /c
The Administration Tools appears.
Fill in the LDAP Admin User Name (if you are working with Active Directory, do not forget the Domain name) and Password fields, and click the Get Encrypted Credentials button to generate and copy the encrypted string in the clipboard.
Deploy the following registry value on all the workstation clients using GPO (for more details, see Centralizing Parameters Using Group Policy Objects (GPO)): in HKEY_LOCAL_MACHINE\SOFTWARE\Enatel\WiseGuard\Framework\FmkServer, create the following value:
- Name: AccessPointLdapCredentials.
- Type: String.
- Value: paste the encrypted string copied in the clipboard.

From an EAM workstation (Access Point)

To use this account on a single workstation, do the following procedure:

Open the root folder of the EAM installation package and run start.hta.
In the Advanced Installation area, click either Enterprise Access Management services (if you are running the 32-bit version of Windows), or Enterprise Access Management services - x64 (Windows 64-bit version).
The Administration Tools interface appears.
In Controller configuration, click Configure Directory and Audit login/password.
The Controller Configuration window appears.
Complete the Access point account tabbed panel and click OK.

Installing EAM Controllers and Audit Databases

Subject

Evidian provides a set of administration tools which allow you to:

Initialize the LDAP directory by creating default objects which are necessary for the use of EAM modules.
Create the security database in the directory.
Publish your specific token configurations in the directory.
Install and configure the audit databases.
Declare the technical accounts used by the EAM Controllers.
Install EAM controllers.

This section details how to start and use the administration tools.

Before Starting

You must have prepared the LDAP Directory (see Preparing the Storage of Security Data in the LDAP Directory).
Log on to the domain as an LDAP directory administrator.

Starting the Administration Tools window

Subject

The Administration Tools window is a task-oriented interface that allows you to configure your EAM solution.

Procedure

Log on as system administrator.
Open the root folder of the Authentication Manager or Enterprise SSO installation package and run start.hta.
The EAM Installation window appears.

NOTE:

If the window does not appear, do the following:

Browse the downloaded installation package and open the folder corresponding to your Windows system processor: E-SSO for 32 bits processors and E-SSO.x64 for 64 bits processors.
Browse the TOOLS directory, and run WGSrvConfig\WGSRVConfig.exe.

In the Advanced Installation area, click one of the following, depending on your Windows system processor:
- Enterprise Access Management services: for 32 bits processors.
- Enterprise Access Management services - x64: for 64 bits processors.
The Administration Tools window appears.

Each tool that you can run from the Administration Tools window is a wizard that allows you to perform a specific operation during the installation process of the EAM databases.

Running the Default Objects Creation Tool

Subject

The "Default objects creation" tool initializes the LDAP directory with default EAM objects.

Restrictions

Use this tool only if you are installing primary or associated EAM controllers.

Before Starting

Depending on your directory type, the Default Objects creation must be executed with:

Active Directory: a domain administrator.
AD LDS: the Active Directory account which was selected to be the administrator of the AD LDS instance or a member of the Roles > Administrators group of the AD LDS instance.
Oracle DSEE, RedHat DS, 389 DS: your LDAP directory administrator account (such as CN=Directory Manager).
OpenLDAP: the super user defined in the rootdn directive (such as cn=Manager,dc=example,dc=com).
DirX: the user defined in the rootdn directive (such as cn=admin,o=my-company).
Other directories: the DN of the directory administrator account.

Procedure

In the Administration Tools window, click Create default objects.
The LDAP directory initialization wizard appears.
Follow carefully the displayed instructions (for more details, see section Hint just below).

Hint

Filling in the "LDAP configuration - Directory initialization" Window

The wizard allows you to choose the administration mode.

The following window appears.

To extend the administration capabilities of the solution, click Activate advanced administration mode (for more information on advanced administration mode, see One Identity EAM Console - Guide de l'administrateur).

IMPORTANT:The advanced administration mode cannot be changed later. If this is a new installation, this mode is recommended. If you are upgrading, existing administration profiles will be migrated.

Initializing the Primary Controller

Subject

This section describes how to use the Primary server initialization tool, which creates the EAM security database in the directory. For your security database you can choose either software or hardware protection.

Before Starting

If you use the hardware protection mode:
- You must have the Security Module, its associated PIN code and smart card reader.
- Connect the smart card reader on the computer.
If you use the software protection mode, you must provide a pass phrase.

Procedure

In the Administration Tools window, click Initialize the Primary controller.
The primary controller initialization wizard appears.
Follow the displayed instructions (for more details, see section Hint just below).

Hint

Filling in the Protection mode window

The wizard allows you to choose the protection mode for your security database.

The following window appears.

In software protection mode, administration keys are protected by a pass phrase.
In hardware protection mode, administration encryption keys are protected by cryptographic smart cards. In this mode, smart cards are required to perform EAM administration tasks.

For more information on protection mode, see One Identity EAM Console - Guide de l'administrateur.

Initializing an Associated Controller

Subject

This section describes how to use the Associated controller initialization tool, which creates the EAM security database from the primary controller.

Before Starting

The Primary controller must be installed.

You must have the Security Module and its PIN code. It is strongly recommended to use the same security module as the primary server to allow administrators to manage several servers.

Restriction

IMPORTANT: You must install Associated controllers only if you are implementing an EAM software architecture in a multi-domain environment.

Procedure

In the Administration Tools window, click Initialize an associated controller.
The associated controller initialization wizard appears.
Follow the displayed instructions.

Publishing a New Token Data File

Subject

This task is optional: if your organization needs to use smart cards or USB tokens which are not supported by EAM, you can import a personalization file in the LDAP directory, so that the use of specific smart card becomes possible.

NOTE: To know the list of standard smart cards supported by EAM, see One Identity EAM Release Notes.

The token personalization file is an XML file provided by Evidian.

Before Starting

Make sure you have the appropriate token personalization XML file.

Procedure

In the Administration Tools window, click Publish a new Token data file.
The wizard appears.
Follow the displayed instructions.

Defining Administrative Tokens for Self Service Password Request

See Enabling the Self Service Password Request (SSPR) Feature .

Importing an External Key

Subject

This task allows you to import the public key of an external application into the EAM security directory, in order to allow EAM users to share their accounts with the external application. It is used for example to enable the Mobile E-SSO feature. For more information, see Mobile E-SSO Installation and Configuration Guide.

Before Starting

The public key must be available as a PEM file.

Procedure

In the Administration Tools window, click Import an external key.
The wizard appears.
Follow the displayed instructions.

NOTE: If you are using Active Directory as the EAM security repository, when the wizard asks you to enter the login/password of an administrator account, use the account who is member of the Domain Admins group and that you have specifically created to install EAM.

Importing/Exporting the Controller Key

Subject

This task allows you to export the key of the primary controller to a secondary or associated controller. The server key is exported in an authentication description file and protected by password, then this key is imported into the secondary or associated server.

Before Starting

Before importing or exporting the controller key, make sure EAM Security Services are started.

Procedure

In the domain where the primary controller is installed, in the Administration Tools window, click Import/Export controller key.
The controller key management window appears.
Select Export server key.
1. Enter and confirm password to protect the key.
2. Click the Select button to create the authentication description file and click Ok.
In the domain where the secondary or associated controller is installed, in the Administration Tools window, click Import/Export server key.
The controller key management window appears.
Select Import server key.
1. Enter and confirm password.
2. Select the key file to be imported into a secondary or associated controller and click Ok.

Installing and Configuring the Audit Databases

Subject

All audit events received by EAM Controllers are stored in a local audit database. If several controllers are installed or if you plan to install several controllers, they must share the same audit database.

To achieve this, you can either:

Install a single database server and configure all EAM controllers to use that database as their local audit database (not recommended).
Install a local audit database on each EAM controller and set up a master audit database in which all controllers upload all their events.

The second solution provides the best performances. Indeed, the unavailability of the master audit database (for example during maintenance periods) does not prevent the collect of audit events from a workstation.

SQL scripts for creating the Audit V2 structure are available in the installation package, in the following folder: \TOOLS\WGSrvConfig\Support

These scripts are templates that you must analyze and adapt to your environment before executing them. If you need to store audit events in another type of database server than those listed below, please contact your Evidian representative.

For MySQL Server: MYSQLV2.sql
For Microsoft SQL Server: MSSQLV2.sql
For PostGreSQL: PostgreSQLV2.sql
For Oracle: OracleV2.sql

IMPORTANT:

If you want to migrate an existing EAM Audit database from V1 format to the V2 format, please contact your Evidian representative.
If you need another base, please contact your Evidian representative. For an Oracle database, you can follow the instructions in the OracleV2.sql file

Architecture Example

The following figure describes the use of a master audit database along with EAM:

All audit events received by the EAM Controller are stored in the local EAM audit cache (1). This local audit database prevents from losing audit events whenever the master database is not available.

The EAM Controller regularly uploads the content of the local audit cache to the master database (3), through a local OLE DB or ODBC driver (2). Once an audit record was successfully sent to the master database, it is removed from the local EAM audit cache.

NOTE:

All requests for audit events issued from EAM Console query the master database, and not the local EAM audit cache.
If the master database is not available, audit queries are not possible.

If there are connection problems between the local and master audit database, then the EAM Controller can send the content of its local database to a designated delegate controller. The latter then stores this content in its local database to be sent to the master audit database. This requires additional configuration: see Windows registry at the end of this Section for more information.

Installation processes

To install and configure an audit database, you must:

Install a supported database server (MySQL server, Microsoft SQL server...). Please refer to the product documentation for details on the installation procedure.

IMPORTANT: f you plan to install MySQL server, read the following:

You must use the following database instance name: MySQLESSO.
Make sure the ODBC connector is installed upon the MySQL server installation. You are strongly advised to use ODBC connector version 5.1 (you may experience problems with version 5.2). You can download connectors at the following URL: http://dev.mysql.com/downloads/connector/odbc/5.1.html#downloads.

Create the database audit tables, as detailed in Creating Audit V2 Tables in an Existing Local Audit Database.
Set up the connection between the EAM controller and the local audit database: see Setting up the Connection to the Local Audit Database.
Insert or update audit translation data, as described in Updating the Audit Translation Data.

To set up an architecture using a master audit database, you must:

Install and configure the local audit database on the EAM primary controller.

Install a master audit database, using the same procedure as for the local audit database, as described in Creating Audit V2 Tables in an Existing Local Audit Database.

Configure the master audit database, as detailed in Defining a Master Audit Database.

IMPORTANT: You must install and configure the master audit database right after installing the first local audit database (the configuration of the master audit database is described in Defining a Master Audit Database

Install and configure the local audit database on the other EAM controllers.

To set up an architecture using a single database server (not recommended), you must:

Install and configure the local audit database, either on a dedicated computer or on an EAM controller.
Set up the connection between the other EAM controllers and the local audit database: see Setting up the Connection to the Local Audit Database.

Creating Audit V2 Tables in an Existing Local Audit Database

IMPORTANT: The wizard supports the following database servers:

MySQL Server.
SQL Server.
PostgreSQL

In the Administration Tools window, click Install an Audit V2 Database Server.
The installation wizard appears.
Follow the displayed instructions with the following guidelines:

When this window appears

Do the following

Click Create audit database tables in an existing database server.
The wizard detects the database server(s) installed on the system and displays them in the drop-down list.
Select the wanted database server.
Click Next.

The wizard retrieves the necessary information from the existing database server.

Make sure the SQL script path is correct and modify it if necessary.
Type the name and password of the super user of the existing database server.

NOTE:

if this password is modified, you must modify the Audit V2 connection parameters by following the procedure explained in Setting up the Connection to the Local Audit Database.

Click Next.
The table creation starts.

IMPORTANT: If you create the audit V2 tables in an existing MySQL database, the connection to the EAM Controller is also set up by the wizard: the EAM local audit database is operational when the wizard completes. If the existing database installed on the EAM Controller is not a MySQL database, or if you want to set up the connection through the local OLE DB and/or ODBC driver, you must set up the connection parameters as detailed in "Setting up the Connection to the Local Audit Database".

Setting up the Connection to the Local Audit Database

Subject

This section describes how to set up the link between the EAM Controller and the local audit database.

Before Starting

You have created the audit V2 tables as detailed in Creating Audit V2 Tables in an Existing Local Audit Database.

Procedure

In the Administration Tools window, click Configure local audit database.
The wizard appears.
Depending on the audit database server, do one of the following:
1. To set up connection parameters for a Microsoft SQL Server 2000 (and previous):
  - Click Use Evidian EAM embedded database and enter the administrator's password.
  - If SQL Server is not installed on the EAM Controller, click the Advanced button to set a specific instance and the administrator's name (optional).
  - Click Apply.
2. To set up connection parameters for any other supported databases (including Microsoft SQL Server 2005 and above):
  - Select Use existing corporate database, click the button and complete the displayed window as follows:
Provider tab: select the OLE DB provider corresponding to the data you want to access:

Database

OLE DB Provider

Microsoft SQL Server 2005
(and above)

Microsoft OLE DB Provider for SQL server

MySQL

Microsoft OLE DB Provider for ODBC Drivers

IMPORTANT: you are strongly advised to use ODBC connector version 5.1 (you may experience problems with version 5.2).

Oracle

Oracle Provider for OLE DB

PostGreSQL

Microsoft OLE DB Provider for ODBC Drivers

IMPORTANT: not supported on Windows 64-bit version.

Connection tab:

Connection tab:
Select the data source name of the configured ODBC driver (MySQL or PostGreSQL) or the server name (Microsoft SQL Server or Oracle) corresponding to the data you want to access.

NOTE: Enter the NETBIOS name if you want to use the Windows authentication.

Select the authentication method to connect to the server:
- Use Windows NT Integrated security for Windows authentication.
OR
- Use a specific user name and password for a specific SQL account.
If required, provide the login and password used to authenticate to the data source.
Note: for Microsoft SQL servers, you can enter an:
- SQL account.
OR
- Active Directory account if you have selected the Windows Integrated Authentication.
Select the Allow saving password check box.

Select the database name that you want access (the database must exist).

These connection parameters are stored in the strongly encrypted area of the EAM configuration data.

Click OK.

NOTE: If you have selected the Windows authentication, you must enter the Active Directory account credentials to connect to the database, such as DOMAIN\loginName.
Select in the Table name drop-down list the proper audit table.

Click the Verify button to check the configuration settings.

IMPORTANT:When using the Windows authentication:The account password should never expire in order to allow the EAM controller to work continuously.If the account password is changed, the configuration must be re-executed. When changing the account password, the administrator must make sure the User must change password at next login check box is not selected.

Click Apply.
If necessary, restart EAM Security Services to take configuration changes into account.

Defining a Master Audit Database

Subject

This section describes how to set the master audit database connection parameters.

Before Starting

There is only one master audit database for all EAM servers.
Before defining a master audit database for a controller, the local database must have been previously created, as explained in Installing and Configuring the Audit Databases.

Procedure

Make sure the database client software (Oracle or Microsoft SQL Server) or the ODBC driver (MySQL) is installed on the EAM Controller and configured.
Make sure the structure of the Audit V2 tables has been created in the database server of the master database. To do so, use the administration tools of the database server by executing the appropriate SQL script.
In the Administration Tools window, click Define a master Audit database.
Select Upload audit events in a centralized master database, and complete the window as detailed below:
1. Master Database connection parameters area:
  - Microsoft SQL Server 2000 (and previous): click SQL Server database and fill in the Server name, Database name, Login, Password and Confirmation fields.
  - For any other supported databases (including Microsoft SQL Server 2005 and above), select Connect through an OLE DB Provider, click the button and complete the displayed window as follows:
Provider tab: select the OLE DB provider corresponding to the database you want to access.

Database

OLE DB Provider

Microsoft SQL Server 2005
(and above)

Microsoft OLE DB Provider for SQL server

MySQL

Microsoft OLE DB Provider for ODBC Drivers

IMPORTANT: you are strongly advised to use ODBC connector version 5.1 (you may experience problems with version 5.2).

Oracle

Oracle Provider for OLE DB

PostGreSQL

Microsoft OLE DB Provider for ODBC Drivers

IMPORTANT: not supported on Windows 64-bit version.

Connection tab:
Select the Data Source Name (DSN) of the configured ODBC driver (MySQL or PostGreSQL) or the server name (Microsoft SQL Server or Oracle) corresponding to the data you want to access.

IMPORTANT: if the wanted name does not appear in the list, the client database software (SQL server client, Oracle client, MySQL or PostGreSQL ODBC Driver) is not properly configured. Refer to the database documentation to configure it. When using an ODBC driver, you must select a DSN previously declared using the Microsoft ODBC Data Source Administrator tool (click Administrative Tools\Data Sources (ODBC) to start it).

Select the authentication method to connect to the server:

Use Windows NT Integrated security for Windows authentication.

Use a specific user name and password for a specific SQL account

NOTE: For Microsoft SQL servers, you can enter an SQL account. If you have selected the Windows Integrated Authentication, enter an Active Directory account .

Select the Allow saving password check box.

Select the database name that you want access (the database must exist).

NOTE: These connection parameters are stored in the strongly encrypted area of the EAM configuration data.

Click OK.

NOTE: If you have selected the Windows authentication, you must enter the Active Directory account credentials to connect to the database, such as DOMAIN\loginName.

IMPORTANT: When using the Windows authentication:

The account password should never expire in order to allow the EAM controller to work continuously.
If the account password is changed, the configuration must be re-executed. When changing the account password, the administrator must make sure the User must change password at next login check box is not selected..

Master Database table area:
Select the name of the table where EAM audit events are to be stored.

For Audit V2, the name of the table to use in case of a master database is v_iamaudit or dbo.v_iamaudit for SQL Server.
Master database table size management area
If you want that the EAM Controller sends e-mails to database or security administrators whenever the master database reaches a size threshold, fill in the following fields:
- Size warning threshold
  Size threshold (in number of audit records: about 2 KB are required for each record).
- Administrator’s e-mail
  E-mail address of the database administrator.
- also send e-mail to
  A set of comma-separated list of e-mail addresses of other administrators.
- SMTP server
  Name of the SMTP server in charge of routing e-mails.
E-mails are sent to the database administrator (with copy to co-administrators) once the master database reaches the specified size. Even though the master database reached the specified size, the EAM Controller still uploads audit events to the master database.
Upload periodicity area:
This area allows you to configure when EAM audit events are uploaded to this master database. Specify a fixed daily hour (for example at 02:00 everyday) or a frequency (every days, every 4 hours, every minute for example).
Local database management area:
You may also indicate that local audit events should be uploaded to the master database as soon as the local SQL Server database reaches a maximum size. For this purpose, indicate the maximum size (in number of stored events) and how often EAM should check the size of the local audit SQL Server database (every 120 seconds for example).

Windows registry

Registry values regarding the configuration of the master audit database are located in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Enatel\WiseGuard\FrameWork\
AuditMasterSrv

In case of communication issues between the master audit database and the EAM Controller, you can set the following values to force the appropriate SQL syntax:

UseOracleSyntax (REG_DWORD) = 1.

UseSQLServerSyntax (REG_DWORD) = 1.

NOTE: If required, you can also set these two values in HKEY_LOCAL_MACHINE\SOFTWARE\Enatel\WiseGuard\
FrameWork\AuditSrv, which is the registry key related to the configuration of the local audit database.

In case of communication issues between the master and local audit databases, you can set the following values to force the delegation to another controller:

IMPORTANT: These values should only be used as an exceptional measure and only in case of slow network.
Delegator EAM controller:
- UploadThruControllers (REG_DWORD) = DNS.name.of.delegate.controller[:port] [, another.dns.name[:port] ...].
  This value must contain the name of the delegate controller to which the delegator will send the content of its Local database. If several delegate controllers are defined in the corporate network, the controller names must be comma separated.
  The existing connection parameters for both Local database and Master database must not be changed. The Master database connection parameters are used by the delegator controller to read audit events and provide them to the EAM Console.
  The existing upload frequency configuration parameters must not be changed as they are used by this audit upload delegation mechanism.
- MaxCacheSize (REG_DWORD) = number of events to send at a time to the delegate controller.
  This registry value contains the number of events in the Local size that triggers the audit upload. For a frequent audit upload, this parameter is usually set to a small value. For the purpose of this audit upload delegation mechanism, you should set this parameter to a reasonably large value: Evidian recommends 1024 (0x400 in hexadecimal).
- Delegate EAM controller:
  Evidian recommends the installation of a dedicated EAM controller. Before installing this controller, the following registry value must be set in HKEY_LOCAL_MACHINE\SOFTWARE\Enatel\WiseGuard\
  FrameWork\Debug: DontDeclareSrv (REG_DWORD) = 0x01.
  Once it is set, the delegate EAM controller does not appear as a Controller in the Directory: no workstation will ever try to connect to it. This will ensure that this delegate controller is exclusively used by the delegator controller(s). For more information on the installation of an additional EAM controller, see Installing EAM Controller Software.

The delegate controller must be configured, including the connection to its audit database(s). To avoid additional delays while viewing audit events gathered by the delegator controller, you should either:

Configure the delegate controller to use the Central database as its Local database. In this case, you must not configure a Master database on this delegate controller.
Install a Local database on the controller, set the Central database as its Master database and set the Audit upload frequency parameters to ensure that events received from the delegate controller(s) are sent to the Master database every 5 minutes (or once the Local database contains 10 events).

One Identity recommends the second configuration (connect the Local database to the Central database with no defined Master database) as it avoids an additional delay between the generation of the audit event on a workstation and its availability for administrators using the Console.

Updating the Audit Translation Data

Subject

This section explains how to import the audit events translation data, so that audit events can be easily read.

Procedure

In the Administration Tools window, click Update Audit translation data.
The Insert/Update Audit MetaData window appears.

The metadata XML file location field is already filled-in.
Select a category to display the errors and resources translations that are about to be imported:
- Errors column: the list of available translations of errors found in the selected folder, for the selected category.
- Resources column: the list of available translations of resources (type, attribute, known values of objects appearing in audit events) found in the selected folder, for the selected category.
Select the check box(es) corresponding to the audit database(s) in which you want to import translations.

NOTE:

If no master database is configured on the controller, the second check box does not appear.
When a master database is used by a controller, you do not have to import the translation data in the controller local database.

Click Import.

A confirmation window appears.

Preparing the EAM Controller Configuration

Declaring the Technical Accounts Used by the EAM Controllers

Before Starting

The technical accounts are created and configured. For details, see one of the following sections depending on your LDAP directory type:
- Active Directory: see Extending the Schema and Setting ACLs.
- Active Directory + AD LDS: see Preparing the AD LDS Instance Administrator Account.
- In non-Microsoft directory servers, this account must be an administrator of the directory.
If you are using a local SQL Server database, you must have installed the audit database, as described in Installing and Configuring the Audit Databases.
You must have configured the audit database, as described in Setting up the Connection to the Local Audit Database.

Procedure

In the Administration Tools window, click Configure Directory and Audit login/password.
The Controller Configuration window appears.
Declare the technical account that will be used by the EAM Controller to connect to the directory.

Securing the EAM Web Service

IMPORTANT: The QRentry and Reporting Service functions can only be used with the EAM Web Service

Procedure

In the Administration Tools window > Controller configuration, click Configure Directory and Audit login/password.
The Controller Configuration window appears.
Select the Web Service Security tab.
Select the Key and Certificate file to use.
As an alternative, you can generate your own test certificate by clicking the Generate button.
If the certificate file is password protected, select the corresponding check box and enter the password.
Select the Certification path validation file to use.
Click OK.
The EAM Web Service is now secure.

Setting the Primary Administrator

Subject

By default, the super administrator is the user who created the database. However, you can select a specific user to be the Primary Administrator of the EAM solution.

Procedure

In the Administration Tools window > Controller configuration, click Configure Directory and Audit login/password.
The Controller Configuration window appears.
Select the Primary Administrator Account tab.
Enter the login name or the DN of the user you want to select.
Click OK.
The selected user is now the Primary Administrator of the solution.

Defining the Password for the Provisioning Connector Account

Subject

The E-SSO Provisioning connector enables the:

Password synchronization between the account base of a client application and Active Directory.
Regular and automatic password renewal.

To enable this connector, you must set the admin login of the administrator account of the target application in the EAM console (see One EAM Console - Guide de l'administrateur) and associate it with a password, as described in the following procedure.

Description

The following illustration details how the E-SSO provisioning connector works:

IMPORTANT: Password provisioning may slow down the sending of the login/password to the application. To avoid this, you can activate the window masking option in the application window (see Enterprise SSO - Guide de l'administrateur).

Procedure

In the Administration Tools window > Controller configuration, click Configure Directory and Audit login/password.
The Controller Configuration window appears.
Select the Provisioning connectors tab.
Enter the login name or the DN of the user you want to select.
Enter the password and confirm it.
Click OK to validate or Apply to associate passwords to other administrator accounts.
The administrator account is now created.

NOTE: If there are several accounts, they appear in the Login drop down list.

To delete an account:

Select it in the drop down list.
Erase the password fields.
Click Apply.

Installing EAM Controller Software

Subject

This section explains how to install an EAM Controller, which is made of the following components:

EAM server, which is used by the EAM Clients during some operations (administration, audit...). This module must be installed on a clearly identified machine.
EAM Console, which is the administration console. This module can be installed on any client workstations.

NOTE: To use EAM Console, EAM Controller must be installed on a computer. For more information, see EAM Architecture.

Depending on your needs, you may install these two modules on the same workstation or separately.

Interactive/Silent Mode Installation

The EAM Controller is delivered as installation packages using the Microsoft Windows Installer (MSI) format.

You can install this package:

In interactive mode: follow the instructions of the installation wizard, as described in the following procedure.
In silent mode: command line options allow you to specify installation options for each of the installation package: see Installing EAM MSI Packages in Silent Mode.

Before Starting

You must have prepared the LDAP Directory (see Preparing the Storage of Security Data in the LDAP Directory).
You must have installed the Security and Audit databases (see Installing EAM Controllers and Audit Databases).
Configure the EAM Security Services (see Configuring Workstations).
Make sure you have installed the Microsoft Redistributable as explained in Installing Microsoft Redistributable.
Check that your Windows operating system is supported by EAM. For details, see One Identity EAM Release Notes.

Procedure

Start the Administration Tools window (see Starting the Administration Tools window).
In the Administration Tools, click Install EAM Controller.
The EAM Controller installation wizard appears.

NOTE: If the EAM Console installation wizard does not automatically appear, from the Authentication Manager or Enterprise SSO installation package browse the INSTALL directory and double-click ESSOController.msi.

Follow the displayed instructions and the guidelines given in the following Controller Wizard Window Description section.

Restart the workstation.

If you have installed Authentication Manager, the Authentication Manager authentication window appears.

Controller Wizard Window Description

"Select Installation Type" and "Select Features" Windows Description

To choose the components to install, click Custom in the Select Installation Type window.

The feature selection window appears:
Enterprise Access Management Controller: EAM server installation.
Enterprise Access Management Console:EAM Console software module installation.
Proximity devices plugin: this feature is necessary if you want to manage RFID devices from EAM Console.
Supported languages: possible language of EAM modules.

Installing the Reporting Service

Subject

The reporting service enables to generate PDF reports for:

EAM administrators from the EAM console.
End-users from Authentication Manager.

Description

The reporting service must be installed on a controller. As this is not a mandatory module, you can install one or several controllers with a reporting service. In that case, the administrator must specify which controller hosting the reporting service he wants to use to create reports. The PDF report files are then generated locally on the controller.

This reporting service connects to the:

UAS web service hosted by the UAS security services.
Local and existing SQL database server to store:
- Its own configuration, such as predefined tools, plugins and models.
- Temporarily the data collected to build the reports.

IMPORTANT:

The reporting service is compatible only with MySQL and (Microsoft) SQL Server databases.
If the audit database is manually modified (emptied for example), reports using both the audit database and the directory can provide inaccurate information.

Architecture Example

The following figure describes the use of a reporting service along with EAM:

Before Starting

The following elements/pieces of software must be installed and configured:

At least one EAM Controller must be installed: seeInstalling EAM Controller Software.

IMPORTANT: The EAM Controller must be installed before securing the Web Service.

You have secured the Web Service role as described in Securing the EAM Web Service.
Java Runtime Environment on the same platform as the operating system, for more information on the version, see One Identity EAM Release Notes.

IMPORTANT: If the JRE is not installed when the Reporting Server installation starts, a window asking you to install the JRE will appear. Make sure to install the correct version: 32 or 64 bits.

Local audit database with the related Java Connector, for more information on the version, see One Identity EAM Release Notes.

If you have a:

MySQL database: go to Installing the Reporting Service on a MySQL Database.
(Microsoft) SQL Server database: go to Installing the Reporting Service on an (Microsoft) SQL Server Database.

Installing the Reporting Service on a MySQL Database

Preparing the Installation

Checking the MySQL Configuration

For the reporting service to operate correctly, you must check the values of some important MySQL parameters, such as:

max_allowed_packet: maximum packet length to send/receive to/from the MySQL server. Its value must be set to 32Mb.
wait_timeout: number of seconds the MySQL server waits for an activity on a connection before closing it. Its value must be set to the minimum default value 28800 seconds.

IMPORTANT: To be persistent, these parameters must be customized by the database administrator in the MySQL initialization file in the [mysqld] section.

Managing databases

The installation wizard creates:

Two databases for its own purpose, in addition to the existing iamaudit database:
- iar_db: to store its own configuration such as predefined tools (to log, sign reports, notify end of report generation, etc.), plugins (available connectors, data providers, etc.), models, etc.
- iar_wdb: to temporarily store the data collected to create the reports.

IMPORTANT: The iar_wdb database does not need to be saved or dumped since it is temporary, whereas the iar_db database should be added to your own process of database backup.

An SQL user for the reporting service named ureport and checks that the user has sufficient rights in both databases described previously.

NOTE: These installation steps are executed by the SQL account used by the controller account.

Executing the Installation

Procedure

Start the Administration Tools window (see Starting the Administration Tools window).
In the Administration Tools, click Install a Reporting Server.

The Reporting Server installation wizard appears.
Click Next to start the installation and follow the displayed instructions with the following guidelines:

NOTE: If you did not install the elements described in Before Starting above, the installation wizard will ask you to install them and will then restart.

When this window appears

Do the following

The wizard detects whether the following elements are installed and/or configured:

The current workstation is an EAM Controller.
The Web Service role is secure.
The EAM Web Service certificate is valid.

If all the ticks are green click Next, otherwise go back to Before Starting above to finish the configuration of the required elements/pieces of software.

The wizard detects whether the reporting database is configured by checking if the following elements are created and/or configured:

Local DB server is created.
Reporting DB user exists.
Reporting DB exists.
Reporting tables exist.

Create these elements by clicking the corresponding Create buttons; if all the ticks are green click Next.

NOTE: the account used to connect to the Reporting databases is the ureport user.

Select the Install Reporting Server check box and enter the Package and Destination paths.
Select the Install Java Database Connector check box and check that the Jar archive path is correct.
If you have not downloaded it, click the Download button.

NOTE: Network paths are not supported.

Click Next.

If you want to sign the generated PDF reports, fill-in the Signature certificate field.
If the certificate file is password protected, select the corresponding check box and enter the password.
As an alternative, you can generate your own test certificate by clicking the Generate button.

Click Next.

Click Finish to close the Wizard and start the Reporting Server.

Installing the Reporting Service on an (Microsoft) SQL Server Database

Preparing the Installation

To be able to execute the installation, you must first complete the following steps:

Create the technical account used by the reporting module named ureport with the following properties:
- The account password must never expire.
- This account must have the db_datareader right on the esso database.
With the administrator account named sa, execute the following SQL scripts:
- iar_mssql_create_db.sql (under TOOLS\WGSrvConfig\Support) to create the following databases:
  - iar_db: to store its own configuration such as predefined tools (to log, sign reports, notify end of report generation, etc.), plugins (available connectors, data providers, etc.), models, etc.
  - iar_wdb: to temporarily store the data collected to create the reports.

IMPORTANT: The iar_wdb database does not need to be saved or dumped since it is temporary, whereas the iar_db database should be added to your own process of database backup.

iar_mssql_create_tables.sql (under TOOLS\WGSrvConfig\Support) to create the reporting tables.

Executing the Installation

Procedure

Start the Administration Tools window (see Starting the Administration Tools window).
In the Administration Tools, click Setup a Reporting Server.

The Reporting Server installation wizard appears.
Click Next to start the installation and follow the displayed instructions with the following guidelines:

NOTE: If you did not install the elements described in Before Starting above, the installation wizard will ask you to install them and will then restart.

When this window appears

Do the following

The wizard detects whether the following elements are installed and/or configured:

The current workstation is an EAM Controller.
The Web Service role is secure.
The EAM Web Service certificate is valid.

If all the ticks are green click Next, otherwise go back to Before Starting above to finish the configuration of the required elements/pieces of software.

The wizard detects whether the reporting database is configured by checking if the following elements are created and/or configured:

Local DB server is created.
Reporting DB user exists.
Reporting DB exists.
Reporting tables exist.

Click Set to connect to the Reporting databases with the ureport user.

Enter the password of the ureport technical account, click OK and click Next if all the elements are checked.

Select the Install Reporting Server check box and enter the Package and Destination paths.
Select the Install Java Database Connector check box and check that the Jar archive path is correct.

NOTE: Network paths are not supported.

Click Next.

Click Next.

Click Finish to close the Wizard and start the Reporting Server.

Self Service Tools: Knowledge Base; Notifications & Alerts; Product Support; Software Downloads; Technical Documentation; User Forums; Video Tutorials; RSS Feed

Contact Us: Licensing Assistance; Technical Support; View All

Please select your product:

To serve you better, please complete the Purpose of your Chat:

Recommended Solutions for Your Problem

Enterprise Single Sign-On 9.0.2 - Enterprise Access Management Installation Guide

Preface

Preface

Overview

The EAM Software Suite

The EAM Security Services

EAM Components

Enterprise SSO

Authentication Manager

EAM Controller

EAM Console

Updating EAM

EAM Architecture

EAM with an LDAP Directory

Subject

Description

EAM in the Cloud

Subject

Description

EAM and Your Corporate LDAP Directory Infrastructure

Separation of the EAM Data

Subject

Example

AD LDS Architecture

Inter Domain and Multi Domain

Subject

Inter-Domain

Multi-Domain

Examples of Supported Active Directory Infrastructures

Multi-Domain Infrastructure

Infrastructure Example

Description

Active Directory + AD LDS Infrastructure

AD + AD LDS Infrastructure

AD + AD LDS Multi Domain Infrastructure

Preparing the Storage of Security Data in the LDAP Directory

Subject

Active Directory

Global Installation Process within an Active Directory Infrastructure

Subject

Definitions

Multi Domain Architecture Example

Global Process

Extending the Schema and Setting ACLs

Subject

Before Starting

Procedure

Setting Indexes on Active Directory Attributes (Optional)

Subject

Before Starting

Indexes on Standard Attributes

General Use

Custom LDAP Attributes Stored on the Authentication Token

User Search for Delegation

Indexes on EAM Specific Attributes

Configuring Secure Authentication and Data Securization

Active Directory + AD LDS

Subject

Multi Domain Architecture Example

Global Process

Before Starting

Extending the Schema of AD LDS

Procedure

Preparing the AD LDS Instance Administrator Account

Setting ACLs on AD LDS

Subject

Procedure

Setting Indexes on AD LDS Attributes

Setting Indexes on Standard Attributes

Setting Indexes on EAM Specific Attributes

Configuring Secure Authentication and Data Securization

OpenLDAP

Extending the Schema of an OpenLDAP Directory

Subject

Procedure

Setting ACLs on an OpenLDAP Directory

Subject