Plan an Enterprise Identity Mapping domain controller

As you gather information to define your Enterprise Identity Mapping (EIM) domain, you need to determine which directory server product will act as the EIM domain controller. EIM requires that the domain controller be hosted by a directory server that supports Lightweight Directory Access Protocol (LDAP) Version 3. Additionally, the directory server product must be able to accept the LDAP schema and other considerations for EIM and understand certain attributes and object classes.

If your enterprise possesses more than one directory server that can host an EIM domain controller, you should also consider whether to use secondary replicated domain controllers. For example, if you expect to have a large number of EIM mapping lookup operations occurring, replicas can improve the performance of the lookup operations.

Also, you should consider whether to make your domain controller local or remote in relationship to the system you expect to be running the largest number of mapping lookup operations. By having the domain controller be local to the high-volume system, you may improve the performance of the lookup operations for the local system. Use the planning work sheets to record these planning decisions, as well as those you make about your domain and other directory information.

After you determine which directory server in your enterprise will host your EIM domain controller, you need to make some decisions about domain controller access.

Plan domain controller access

You need to plan how you and EIM-enable applications and operating systems will access the directory server that hosts the EIM domain controller. To access an EIM domain you must:

Be able to bind to the EIM domain controller
Make sure that the bind subject is a member of an EIM access control group, or is the LDAP administrator. Refer to Manage EIM access control for more information.

Select type of EIM binding

EIM APIs support several different mechanisms for establishing a connection, also known as binding, with the EIM domain controller. Each type of binding mechanism provides a different level of authentication and encryption for the connection. The possible choices are:

Simple Binds A simple bind is an LDAP connection where an LDAP client provides a bind distinguished name and a bind password to the LDAP server for authentication. The bind distinguished name and password are defined by the LDAP administrator in the LDAP directory. This is the weakest form of authentication and the least secure as the bind distinguished name and password are sent unencrypted and are vulnerable to eavesdropping. You use CRAM-MD5 (challenge-response authentication mechanism) to add an additional level of protection for the bind password. With the CRAM-MD5 protocol, the client sends a hashed value instead of the clear text password to the server for authentication.
Server authentication with Secure Sockets Layer (SSL) - server side authentication An LDAP server can be configured for SSL or Transport Layer Security (TLS) connections. The LDAP server uses a digital certificate to authenticate itself to the LDAP client and establishes an encrypted communications session between them. Only the LDAP server is authenticated by means of a certificate. The end user is authenticated by means of a bind distinguished name and password. The strength of the authentication is the same as for a simple bind, but all data (including the bind distinguished name and password) is encrypted for privacy.
Client authentication with SSL An LDAP server can be configured to require that the end user be authenticated by means of a digital certificate rather than a bind distinguished name and password for SSL or TLS secure connections to the LDAP server. Both client and server are authenticated and the session is encrypted. This option provides a stronger level of user authentication and protects the privacy of all data transmitted.
Kerberos authentication An LDAP client can be authenticated to the server by using a Kerberos ticket as an optional replacement for a bind distinguished name and password. (Kerberos), which is a trusted third-party network authentication system, allows a principal (a user or service) to prove its identity to another service within an unsecured network. Authentication of principals is completed through a centralized server called a key distribution center (KDC). The KDC authenticates a user with a Kerberos ticket. These tickets prove the principal's identity to other services in a network. After a principal is authenticated by these tickets, the principal and service can exchange encrypted data with a target service. This option provides a stronger level of user authentication and protects the privacy of authentication information.

The choice of a bind mechanism is based on the level of security required by the EIM-enabled application and the authentication mechanisms supported by the LDAP server that hosts the EIM domain.

Also, you might have to perform additional configuration tasks for the LDAP server to enable the authentication mechanism that you choose to use. Check the documentation for the LDAP server that hosts your domain controller to determine what other configuration tasks you may need to perform.

Example planning work sheet: domain controller information

After making your decisions about your EIM domain controller, use the planning worksheets to record the EIM domain controller information that your EIM-enabled operating systems and applications need. The information that you gather as part of this process can be used by the LDAP administrator to define the bind identity of the application or operating system to the LDAP directory server that hosts the EIM domain controller.

The following sample portion of the planning work sheets shows the type of information that you need to gather. It also includes sample values that you could use when you configure the EIM domain controller.

Table 1. Domain and domain controller information for EIM planning worksheet
Information needed to configure EIM domain and domain controller	Example answers
A meaningful name for the domain. This could be the name of a company, a department, or an application that uses the domain.	`MyDomain`
Optional: If configuring an EIM domain in an already existing LDAP directory, specify a parent distinguished name for the domain. This is the distinguished name that represents the entry immediately above your domain name entry in the directory information tree hierarchy, for example, `o=ibm,c=us`.	`o=ibm,c=us`
Resulting fully qualified EIM domain distinguished name. This is the fully defined name of the EIM domain that describes the directory location for EIM domain data. The fully qualified domain distinguished name consists of, at a minimum, the DN for the domain (`ibm-eimDomainName=`), plus the domain name that you specified. If you choose to specify a parent DN for the domain, then the fully qualified domain DN consists of the relative domain DN (`ibm-eimDomainName=`), the domain name (MyDomain), and the parent DN (`o=ibm,c=us`). Note:	Either of these, depending on whether you choose a parent DN: `ibm-eimDomainName=MyDomain` `ibm-eimDomainName=MyDomain,o=ibm,c=us`
Connection address for the domain controller. This consists of the type of connection (basic ldap or secure ldap, for example, `ldap://` or `ldaps://`) plus the following information:	`ldap://`
Optional: The host name or IP address Optional: The port number	`some.ldap.host` `389`
Resulting complete connection address for the domain controller.	`ldap://some.ldap.host:389`
Bind mechanism required by applications or systems. Choices include: Simple bind CRAM MD5 Server authentication Client authentication Kerberos	Kerberos

If your EIM configuration and administration team consists of multiple team members, you will need to determine the bind identity and mechanism that each team member should use for accessing the EIM domain based on their role. Also, you need to determine the bind identity and mechanism for EIM application end users. You may find the following work sheet helpful as an example for gathering this information.

Table 2. Example bind identities planning work sheet
EIM authority or role	Bind identity	Bind mechanism	Reason needed
EIM administrator	eimadmin@krbrealm1.com	kerberos	configure and manage EIM
LDAP administrator	cn=administrator	simple bind	configure EIM domain controller
EIM registry X administrator	cn=admin2	CRAM MD5	manage specific registry definition
EIM mapping lookup	cn=MyApp,c=US	simple bind	perform application mapping lookup operations

After you have gathered the information that you need for configuring your domain controller, you can develop an identity mapping plan.