6.3 Prerequisites and Requirements for Installing the Identity Vault

Identity Vault uses a directory to store the objects that are synchronized through the Identity Manager solution. The follow sections contain guidelines that help you plan a deployment of NetIQ eDirectory to use as framework for the Identity Vault.

6.3.1 Considerations for Installing the Identity Vault

NetIQ recommends that you review the following considerations before you install eDirectory as the framework for the Identity Vault:

Before installing eDirectory, you must have a method for resolving tree names to server referrals. NetIQ recommends using Service Location Protocol (SLP) services. Releases of Novell eDirectory before version 8.8 included SLP in the installation. However, after version 8.8, you must separately install SLP. You can also use the flat file hosts.nds to resolve tree names. For more information, see Section 9.2, Using OpenSLP or hosts.nds for Resolving Tree Names.
When installing on a Linux server, you must enable the host for multicast routing, with 224.0.0.0 in the routing table. For example, enter the following command:
```
route add -net 224.0.0.0 netmask 240.0.0.0 dev interface
```
where interface represents a value such as eth0, hme0, hme1, or hme2, depending on the network interface card.
You must configure a static IP address on the server for the eDirectory infrastructure to perform efficiently. If you use DHCP addresses on the server, eDirectory might have unpredictable results.
Synchronize time across all network servers. NetIQ recommends using Network Time Protocol’s (NTP) ntp option.
(Conditional) To install a secondary server, all the replicas in the partition that you install the product on should be in the On state.
(Conditional) To install a secondary server into an existing tree as a non-administrator user, create a container and then partition it. Ensure that you have the following rights:
- Supervisor rights to the partition where you want to add the server.
- (Windows) Supervisor rights to the container where want to add the server.
- All Attributes rights: read, compare, and write rights over the W0.KAP.Security object.
- Attribute rights: read and compare rights over the Security container object.
- Entry rights: browse rights over the Security container object.
These rights are required for adding the replica when the replica count is less than 3.
(Conditional) To install a secondary server into an existing tree as a non-administrator user, ensure that at least one of the servers in the tree has the same or higher eDirectory version as that of the secondary being added as container admin. If the secondary being added is of later version, the administrator of the tree must extend the schema before adding the secondary using container admin.
While configuring eDirectory, you must enable a NetWare Core Protocol (NCP) port (the default is 524) in the firewall to allow the secondary server addition. Also, you can enable the following default service ports based on your requirements:
- LDAP clear text - 389
- LDAP clear text - 636
- HTTP clear text - 8028
- HTTP clear text - 8030
You must install Novell International Cryptgraphic Infrastructure (NICI) on every workstation using management utilities for eDirectory, such as iManager. NICI and eDirectory support key sizes up to 4096 bits.

On Linux, the Identity Vault installation program, nds-install, automatically installs NICI. However, you can install NICI manually. For more information, see “Installing NICI” in the NetIQ eDirectory Installation Guide.
(Conditional) NICI 2.7 and eDirectory 8.8 support key sizes up to 4096 bits. To use a 4 KB key size, you must upgrade every server to eDirectory 8.8. Also, you must also install NICI 2.7 on every workstation using the management utilities, such as iManager and ConsoleOne.

When you upgrade your Certificate Authority (CA) server to eDirectory 8.8, the key size will not change but will still be 2 KB. To create a 4 KB key size, you must recreate the CA on an eDirectory 8.8 server. In addition, during the CA creation, you must change the default from 2 KB to 4 KB for the key size.
(Conditional) If the names of containers in your eDirectory tree include a period, you must use escape characters to specify the Admin name, admin context, and server context parameters during installation and when adding server in to an existing tree. For more information, see Section 9.1, Using Escape Characters when a Container Name Includes a Period (“.”).

6.3.2 Considerations for Installing the Identity Vault as a Non-root User

To install the Identity Vault as a non-root user, your environment must meet the following conditions:

You cannot install the Identity Vault in a cluster environment as a non-root user.
NICI must be installed on the server by a root user. For more information, see Section 9.5, Installing NICI Manually on Workstations that have Management Utilities.
The SNMP subagent (NOVsubag) must be installed on the server by a root user and configured.
To install Novsubag

Enter the following command: rpm -ivh --nodeps NOVLsubag_rpm_file_name_with_path.

To configure SNMP:
Manually export the paths for the environment variables using the following command:
```
export LD_LIBRARY_PATH=custom_location/opt/novell/eDirectory/lib64:/opt/novell/eDirectory/lib64/nds-modules:/opt/novell/lib64:$LD_LIBRARY_PATH
export PATH=/opt/novell/eDirectory/bin:$PATH
export MANPATH=/opt/novell/man:$MANPATH
```
For example:
```
rpm -ivh --nodeps novell-NOVLsubag-8.8.1-5.i386.rpm
```
(Conditional) To use SLP and SNMP on the Identity Vault server, you must install the services as root.
The non-root user account that installs Identity Vault must have Write rights to the directory where you want to install.

6.3.3 Considerations for Installing Identity Vault on a Windows Server

NetIQ recommends that you review the following considerations before you install the Identity Vault on a Windows server:

You must have administrative rights to the Windows server and to all portions of the eDirectory tree that contain domain-enabled User objects. For an installation into an existing tree, you need administrative rights to the Tree object so that you can extend the schema and create objects.
(Conditional) Before performing a silent installation (unattended), you must install the following software on the target server:
- Microsoft Visual C++ 2005 and Microsoft Visual C++ 2012 Redistributable Packages. By default, the installation files, vcredist_x86.exe and vcredist_x64.exe are located in the eDirectory\Windows\x64\redist_pkg folder.
- Novell International Cryptgraphic Infrastructure (NICI). By default, the installation files are located in the eDirectory/Windows/x64/nici folder.
Because NTFS provides a safer transaction process than a FAT file system provides, you can install eDirectory only on an NTFS partition. Therefore, if you have only FAT file systems, do one of the following:
- Use Disk Administrator. Refer to the Windows Server documentation for more information.
- Create a new partition and format it as NTFS.
- Convert an existing FAT file system to NTFS, using the CONVERT command.
- Refer to the Windows Server documentation for more information.
If your server only has a FAT file system and you forget or overlook this process, the installation program prompts you to provide an NTFS partition.
You must be running the latest version of the Windows SNMP service.
Your Windows operating system must be running the latest service packs before you begin the installation process.
To install on a virtual machine that has a DHCP address or on a physical or virtual machine in which SLP is not broadcast, ensure that the Directory Agent is configured in your network. For more information, see Section 9.2.2, Understanding OpenSLP.

6.3.4 Considerations for Installing the Identity Vault in a Clustered Environment

Before installing the Identity Vault in a clustered environment, NetIQ recommends reviewing the following considerations:

You must have two or more Windows servers or Linux servers with clustering software.
You must have external shared storage supported by the cluster software, with sufficient disk space to store all Identity Vault and NICI data:
- The Identity Vault DIB must be located on the cluster shared storage. State data for the Identity Vault must be located on the shared storage so that it is available to the cluster node that is currently running the services.
- The root Identity Vault instance on each of the cluster nodes must be configured to use the DIB on the shared storage.
- You must also share NICI (NetIQ International Cryptographic Infrastructure) data so that server-specific keys are replicated among the cluster nodes. NICI data used by all cluster nodes must be located on the cluster shared storage.
- NetIQ recommends storing all other eDirectory configuration and log data on the shared storage.
You must have a virtual IP address.
(Conditional) If you are using eDirectory as the support structure for the Identity Vault, the nds-cluster-config utility supports configuring the root eDirectory instance only. eDirectory does not support configuring multiple instances and non-root installations of eDirectory in a cluster environment.

For more information, see Section 12.0, Installing the Identity Vault in a Clustered Environment.

6.3.5 Understanding Identity Manager Objects in eDirectory

The following list indicates the major Identity Manager objects that are stored in eDirectory and how they relate to each other. The installation process does not create objects. Instead, you create the Identity Manager objects when configuring the Identity Manager solution.

Driver Set: A driver set is a container that holds Identity Manager drivers and library objects. Only one driver set can be active on a server at a time. However, more than one server might be associated to one driver set. Also, a driver can be associated with more than one server at a time. However, the driver should only be running on one server at a time. The driver should be in a disabled state on the other servers. Any server that is associated with a driver set must have the Metadirectory server installed on it.
Library: The Library object is a repository of commonly used policies that can be referenced from multiple locations. The library is stored in the driver set. You can place a policy in the library so that every driver in the driver set can reference it.
Driver: A driver provides the connection between an application and the Identity Vault. It also enables data synchronization and sharing between systems. The driver is stored in the driver set.
Job: A job is automates a recurring task. For example, a job can configure a system to disable an account on a specific day, or initiate a workflow to request an extension of a person’s access to a corporate resource. The job is stored in the driver set.

6.3.6 Replicating the Objects that Identity Manager Needs on the Server

If your Identity Manager environment calls for multiple servers in order to run multiple Identity Manager drivers, your plan should make sure that certain eDirectory objects are replicated on servers where you want to run these Identity Manager drivers.

You can use filtered replicas, as long as all of the objects and attributes that the driver needs to read or synchronize are included in the filtered replica.

Keep in mind that you must give the Identity Manager Driver object sufficient eDirectory rights to any objects it is to synchronize, either by explicitly granting it rights or by making the Driver object security equivalent to an object that has the desired rights.

An eDirectory server that is running an Identity Manager driver (or that the driver refers to, if you are using the Remote Loader) must hold a master or read/write replica of the following:

The Driver Set object for that server.

You should have one Driver Set object for each server that is running Identity Manager. Unless you have specific needs, don’t associate more than one server with the same Driver Set object.

NOTE:When you create a Driver Set object, the default setting is to create a separate partition. Novell recommends creating a separate partition on the Driver Set object. For Identity Manager to function, the server is required to hold a full replica of the Driver Set object. If the server has a full replica of the location where the Driver Set object is installed, the partition is not required.
The Server object for that server.

The Server object is necessary because it allows the driver to generate key pairs for objects. It is also important for Remote Loader authentication.
The objects that you want this instance of the driver to synchronize.

The driver can’t synchronize objects unless a replica of those objects is on the same server as the driver. In fact, an Identity Manager driver synchronizes the objects in all the containers that are replicated on the server unless you create rules for scope filtering to specify otherwise.

For example, if you want a driver to synchronize all user objects, the simplest way is to use one instance of the driver on a server that holds a master or read/write replica of all your users.

However, many environments don’t have a single server that contains a replica of all the users. Instead, the complete set of users is spread across multiple servers. In this case, you have three choices:
- Aggregate users onto a single server. You can create a single server that holds all users by adding replicas to an existing server. Filtered replicas can be used to reduce the size of the eDirectory database if desired, as long as the necessary user objects and attributes are part of the filtered replica.
- Use multiple instances of the driver on multiple servers, with scope filtering. If you don’t want to aggregate users onto a single server, you need to determine which set of servers holds all the users, and set up one instance of the Identity Manager driver on each of those servers.
  
  To prevent separate instances of a driver from trying to synchronize the same users, you need to use scope filtering to define which users each instance of the driver should synchronize. Scope filtering means that you add rules to each driver to limit the scope of the driver’s management to specific containers. See Using Scope Filtering to Manage Users on Different Servers.
- Use multiple instances of the driver on multiple servers, without scope filtering. If you want to have multiple instances of a driver running on different servers without using filtered replicas, you need to define policies on the different driver instances that enable the driver to process different sets of objects within the same Identity Vault.
The Template objects you want the driver to use when creating users, if you choose to use templates.

Identity Manager drivers do not require you to specify eDirectory Template objects for creating users. However, if you specify that a driver should use a template when creating users in eDirectory, the Template object must be replicated on the server where the driver is running.
Any containers you want the Identity Manager driver to use for managing users.

For example, if you have created a container named Inactive Users to hold user accounts that have been disabled, you must have a master or read/write replica (preferably a master replica) of that container on the server where the driver is running.
Any other objects that the driver needs to refer to (for example, work order objects for the Avaya PBX driver).

If the other objects are only to be read by the driver, not changed, the replica for those objects on the server can be a read-only replica.

6.3.7 Using Scope Filtering to Manage Users on Different Servers

Scope filtering means adding rules to each driver to limit the scope of the driver’s actions to specific containers. The following are two situations in which you would need to use scope filtering:

You want the driver to synchronize only users that are in a particular container.

By default, an Identity Manager driver synchronizes objects in all the containers that are replicated on the server where it is running. To narrow that scope, you must create scope filtering rules.
You want an Identity Manager driver to synchronize all users, but you don’t want all users to be replicated on the same server.

To synchronize all users without having them replicated on one single server, you need to determine which set of servers holds all the users, and then create an instance of the Identity Manager driver on each of those servers. To prevent two instances of the driver from trying to synchronize the same users, you need to use scope filtering to define which users each instance of the driver should synchronize.

NOTE:You should use scope filtering even if your server’s replicas don’t currently overlap. In the future, replicas could be added to your servers and an overlap could be created unintentionally. If you have scope filtering in place, your Identity Manager drivers do not try to synchronize the same users, even if replicas are added to your servers in the future.

Figure 6-1 shows an example of an Identity Vault with three containers that hold users: Marketing, Finance, and Development. It also shows an Identity Management container that holds the driver sets. Each of these containers is a separate partition. In this example, the Identity Manager administrator has two Identity Vault servers, Server A and Server B. Neither server contains a copy of all the users. Each server contains two of the three partitions, so the scope of what the servers hold is overlapping.

Figure 6-1 Scope Filtering Defines Which Drivers Synchronize Each Container

The administrator wants all the users in the tree to be synchronized by the GroupWise driver, but does not want to aggregate replicas of the users onto a single server. He chooses instead to use two instances of the GroupWise driver, one on each server. He installs Identity Manager and sets up the GroupWise driver on each Identity Manager server.

Server A holds replicas of the Marketing and Finance containers. Also on the server is a replica of the Identity Management container, which holds the driver set for Server A and the GroupWise Driver object for Server A.

Server B holds replicas of the Development and Finance containers, and the Identity Management container holding the driver set for Server B and the GroupWise Driver object for Server B.

Because Server A and Server B both hold a replica of the Finance container, both servers hold the user JBassad, who is in the Finance container. Without scope filtering, both GroupWise Driver A and GroupWise Driver B would synchronize JBassad. Scope filtering prevents both instances of the driver from managing the same user, because it defines which drivers synchronize each container.

Identity Manager comes with predefined rules. There are two rules that help with scope filtering: Event Transformation - Scope Filtering - Include Subtrees and Event Transformation - Scope Filtering - Exclude Subtrees. For more information, see Understanding Policies for Identity Manager 4.0.2.

For this example, you would use the Include Subtrees predefined rule for Server A and Server B. You would define the scope for each driver differently so that they would only synchronize the users in the specified containers. Server A would synchronize Marketing and Finance. Server B would synchronize Development.

6.3.8 Understanding the Linux Packages in the Identity Vault Installation Kit

NetIQ eDirectory includes a Linux package system, which is a collection of tools that simplify the installation and uninstallation of various eDirectory components. Packages contain makefiles that describe the requirements to build a certain component of eDirectory. Packages also include configuration files, utilities, libraries, daemons, and man pages that use the standard Linux tools installed with the OS.

Some packages depend on other packages or Identity Manager components such as NICI. You must install all dependent packages for proper functionality.

The following table provides information about the Linux packages that are included with eDirectory. All the packages are prefixed with novell-. For example, NDSserv is novell-NDSserv.

Package	Description
NOVLice	Contains the NetiQ Import Convert Export utility. This package depends on the NOVLmgnt, NOVLxis, and NLDAPbase packages.
NOVbase	Represents the Directory User Agent. This package idepends on the NICI package. This package contains the following items: Authentication toolbox containing the RSA authentication needed for eDirectory. Platform-independent system abstraction library, a library containing all the defined Directory User Agent functions, and the schema extension library. Combined configuration utility and the Directory User Agent test utility. eDirectory configuration file and manual pages.
NDScommon	Contains the man pages for the eDirectory configuration file, install, and uninstall utilities. This package depends on the NDSbase package.
NDSmasv	Contains the libraries required for mandatory access control (MASV).
NDSserv	Contains all the binaries and libraries that the eDirectory server needs. It also contains the utilities to manage the eDirectory Server on the system. This package depends on the NDSbase, NDScommon, NDSmasv, NLDAPsdk, NOVLpkia and NOVLpkit packages. Also contains the following items: NDS install library, FLAIM library, trace library, NDS library, LDAP server library, LDAP install library, index editor library, DNS library, merge library, and LDAP extension library for LDAP SDK. eDirectory server daemon. Binary for DNS and a binary to load an unload LDAP. The utility needed to create the MAC address, the utility to trace the server and change some of the global variables of the server, the utility to back up and restore eDirectory, and the utility to merge eDirectory trees. Startup scripts for DNS, NDSD, and NLDAP. Man pages.
NDSrepair	Contains the runtime libraries and the utility that corrects problems in the eDirectory database. This package depends on the NDSbase package.
NLDAPbase	Contains LDAP libraries, extensions to LDAP libraries, and the following LDAP tools: ldapdelete ldapmodify ldapmodrdn ldapsearch This package is dependent on the NLDAPsdk package.
NOVLnmas	Contains all the NMAS libraries and the nmasinst binaries needed for NMAS server. This package depends on the NICI and NDSmasv packages.
NLDAPsdk	Contains NetIQ extensions to LDAP runtime and Security libraries (Client NICI).
NOVLsubag	Contains the runtime libraries and utilities for the eDirectory SNMP subagent. This package depends on the NICI, NDSbase, and NLDAPbase packages..
NOVLpkit	Provides PKI Services which do not require eDirectory. This package depend on the NICI and NLDAPsdk packages..
NOVLpkis	Provides PKI Server Service. This package depends on the NICI, NDSbase, and NLDAPsdk packages.
NOVLsnmp	The runtime libraries and utilities for SNMP. This package depends on the NICI package.
NDSdexvnt	Contains the library that manages events generated in NetIQ eDirectory to other databases..
NOVLpkia	Provides PKI services. This package depends on the NICI, NDSbase, and NLDAPsdk packages.
NOVLembox	Provides the eMBox infrastructure and eMTools..
NOVLlmgnt	Contains runtime libraries for NetIQ Language Management.
NOVLxis	Contains the runtime libraries for NetIQ XIS.
NOVLsas	Contains the NetIQ SAS libraries.
NOVLntls	Contains NetIQ TLS library. This package is also identified as ntls.
NOVLldif2	Contains the NetIQ Offline Bulkload utility and depends on the NDSbase, NDSserv, NOVLntls, NOVLlmgnt, and NICI packages.
NOVLncp	Contains the NetIQ Encrypted NCP Services for Linux. This package depends on the NDScommon package.

6.3.9 Improving Identity Vault Performance

eDirectory, the underlying infrastructure for the Identity Vault, is I/O intensive application rather than being processor-intensive. Two factors increase performance of Identity Vault : more cache memory and faster processors. For best results, cache as much of the Directory Information Base (DIB) Set as the hardware allows.

While eDirectory scales well on a single processor, you might consider using multiple processors. Adding processors improves performance in areas such as logins. Also, having multiple threads active on multiple processors improves performance.

The following table provides a general guideline for server settings, based on the expected number of objects in your eDirectory.

Objects	Memory	Hard Disk
100.000	2+ GB (Linux) 384 MB (Windows)	300 MB (Linux) 144 MB (Windows)
1 million	4 GB (Linux) 2 GB (Windows)	1.5 GB
10 million	4+ GB (Linux) 2+ GB (Windows)	15 GB

Objects

Memory

Hard Disk

100.000

2+ GB (Linux)

384 MB (Windows)

300 MB (Linux)

144 MB (Windows)

1 million

4 GB (Linux)

2 GB (Windows)

1.5 GB

10 million

4+ GB (Linux)

2+ GB (Windows)

15 GB

For example, a base installation of eDirectory with the standard schema requires about 74 MB of disk space for every 50,000 users. However, if you add a new set of attributes or completely fill in every existing attribute, the object size grows. These additions affect the disk space, processor, and memory needed. Also, requirements for processors depend on additional services available on the computer as well as the number of authentications, reads, and writes that the computer is handling. Processes such as encryption and indexing can be processor intensive.

6.3.10 System Requirements for Installing Identity Vault

This section provides requirements to help you set up the server hosting the Identity Vault.

Category	Minimum Requirement
Processor	1 GHz
Disk Space	300 MB for the Identity Vault server 150 MB of additional disk space for every 50,000 users
Memory	1 GB
Operating System	One of the following operating systems: Red Hat Enterprise Linux 5.7 (64-bit) Red Hat Enterprise Linux 6.2 (64-bit) SUSE Linux Enterprise Server 11 SP1 (64-bit) SUSE Linux Enterprise Server 10 SP4 (32-bit or 64-bit) SUSE Linux Enterprise Desktop 10 SP4 (32-bit or 64-bit) Windows Server 2012 Windows server 2008 R2 with the latest service pack Windows Server 2008 (64-bit) with the latest service pack NOTE:To use Identity Vault with RHEL, the glibc library must be version 2.4 at a minimum.
Virtualization Systems	One of the following systems running a supported operating system unless otherwise noted: VMware ESXi Windows Server 2008 R2 Virtualization with Hyper-V (64-bit) Xen Virtual Machine running SLES 10 or SLES 11 NOTE:To use Identity Vault with SUSE Linux Enterprise Server 10, the minimum patch level for the SLES operating system must be 3.02_09763-0.8.