EIM
This chapter examines the Enterprise Identity Mapping (EIM) concept and its implementation on z/OS.
 
7.1 Overview of EIM
Figure 7-1 Overview of EIM
Overview of EIM
Today’s network environments are made up of a complex group of systems and applications, resulting in the need to manage multiple user registries. Dealing with multiple user registries quickly grows into a large administrative problem that affects users, administrators, and application developers. Consequently, many companies are struggling to securely manage authentication and authorization for systems and applications. Enterprise Identity Mapping (EIM) is an IBM eServer infrastructure technology that allows administrators and application developers to address this problem more easily and inexpensively than previously possible.
EIM offers a new approach to enable inexpensive solutions to easily manage multiple user registries and user identities in an enterprise. EIM is an architecture for describing the relationships between individuals or entities (such as file servers and print servers) in the enterprise and the many identities that represent them within an enterprise. In addition, EIM provides a set of APIs that allow applications to ask questions about these relationships.
For example, given a person’s user identity in one user registry, you can determine which user identity in another user registry represents that same person. If the user has authenticated with one user identity and you can map that user identity to the appropriate identity in another user registry, the user does not need to provide credentials for authentication again. You know who the user is and only need to know which user identity represents that user in another user registry. Therefore, EIM provides a generalized identity mapping function for the enterprise.
EIM allows one-to-many mappings (in other words, a single user with more than one user identity in a single user registry). However, the administrator does not need to have specific individual mappings for all user identities in a user registry. EIM also allows many-to-one mappings (in other words, multiple users mapped to a single user identity in a single user registry).
The ability to map between a user’s identities in different user registries provides many benefits. Primarily, it means that applications may have the flexibility of using one user registry for authentication while using an entirely different user registry for authorization. For example, an administrator could map an SAP® identity (or better yet, SAP could do the mapping itself) to access SAP resources.
The use of identity mapping requires that administrators do the following:
1. Create EIM identifiers that represent people or entities in their enterprise.
2. Create EIM registry definitions that describe the existing user registries in their enterprise.
3. Define the relationship between the user identities in those registries to the EIM identifiers that they created.
4. Create policy associations.
No code changes are required to existing user registries. The administrator does not need to have mappings for all identities in a user registry. EIM allows one-to-many mappings (in other words, a single user with more than one user identity in a single user registry). EIM also allows many-to-one mappings (in other words, multiple users sharing a single user identity in a single user registry, which although supported is not advised). An administrator can represent any user registry of any type in EIM.
EIM is an open architecture that administrators may use to represent identity mapping relationships for any registry. It does not require copying existing data to a new repository and trying to keep both copies synchronized. The only new data that EIM introduces is the relationship information. Administrators manage this data in an LDAP directory, which provides the flexibility of managing the data in one place and having replicas wherever the information is used. Ultimately, EIM gives enterprises and application developers the flexibility to easily work in a wider range of environments with less cost than would be possible without this support.
7.2 EIM concepts
Figure 7-2 EIM concepts
EIM concepts
A conceptual understanding of how EIM works is necessary to fully understand how you can use EIM in your enterprise. Although the configuration and implementation of EIM APIs can differ among server platforms, EIM concepts are common across IBM eserver servers.
Figure 7-2 provides an EIM implementation example in an enterprise. Three servers act as EIM clients and contain EIM-enabled applications that request EIM data using lookup operations. The domain controller stores information about the EIM domain, which includes an EIM identifier, associations between these EIM identifiers and user identities, and EIM registry definitions.
EIM domain controller
The EIM domain controller is a Lightweight Directory Access Protocol (LDAP) server that is configured to manage at least one EIM domain. An EIM domain is an LDAP directory that consists of all the EIM identifiers, EIM associations, and user registries that are defined in that domain. Systems (EIM clients) participate in the EIM domain by using the domain data for EIM lookup operations. A minimum of one EIM domain controller must exist in the enterprise.
Currently, you can configure a number of IBM platforms to act as an EIM domain controller. Any system that supports the EIM APIs can participate as a client in the domain. These client systems use EIM APIs to contact an EIM domain controller to perform EIM lookup operations.
The location of the EIM client determines whether the EIM domain controller is a local or remote system. The domain controller is local if the EIM client is running on the same system as the domain controller. The domain controller is remote if the EIM client is running on a separate system from the domain controller.
EIM domain
An EIM domain is a directory within an LDAP server that contains EIM data for an enterprise. An EIM domain is the collection of all the EIM identifiers, EIM associations, and user registries that are defined in that domain. Systems (EIM clients) participate in the domain by using the domain data for EIM lookup operations.
An EIM domain is different from a user registry. A user registry defines a set of user identities known to and trusted by a particular instance of an operating system or application. A user registry also contains the information needed to authenticate the user of the identity. Additionally, a user registry often contains other attributes such as user preferences, system privileges, or personal information for that identity.
In contrast, an EIM domain refers to user identities that are defined in user registries. An EIM domain contains information about the relationship between identities in various user registries (user name, registry type, and registry instance) and the actual people or entities that these identities represent. Because EIM tracks relationship information only, there is nothing to synchronize between user registries and EIM.
The right side of Figure 7-2 on page 360, shows the data that is stored within an EIM domain. This data includes EIM identifiers, EIM registry definitions, and EIM associations. EIM data defines the relationship between user identities and the people or entities that these identities represent in an enterprise.
EIM data includes:
•EIM identifier: Each EIM identifier that you create represents a person or entity (such as a print server or a file server) within an enterprise.
•EIM registry definition: Each EIM registry definition that you create represents an actual user registry (and the user identity information it contains) that exists on a system within the enterprise. After you define a specific user registry in EIM, that user registry can participate in the EIM domain. You can create two types of registry definitions, one type refers to system user registries and the other type refers to application user registries.
•EIM association: Each EIM association that you create represents the relationship between an EIM identifier and an associated identity within an enterprise. You must define associations so that EIM clients can use EIM APIs to perform successful EIM lookup operations. These EIM lookup operations search an EIM domain for defined associations between EIM identifiers and user identities in recognized user registries. Associations provide the information that ties an EIM identifier to a specific user identity in a specific user registry.
You can create two different types of associations:
 – Identifier associations: Identifier associations allow you to define a one-to-one relationship between user identities through an EIM identifier defined for an individual. Each EIM identifier association that you create represents a single, specific relationship between an EIM identifier and an associated user identity within an enterprise.
Identifier associations provide the information that ties an EIM identifier to a specific user identity in a specific user registry and allow you to create one-to-one identity mapping for a user. Identity associations are especially useful when individuals have user identities with special authorities and other privileges that you want to specifically control by creating one-to-one mappings between their user identities.
 – Policy associations: Policy associations allow you to define a relationship between a group of user identities in one or more user registries and an individual user identity in another user registry. Each EIM policy association that you create results in a many-to-one mapping between the source group of user identities in one user registry and a single target user identity. Typically, you create policy associations to map a group of users who all require the same level of authorization to a single user identity with that level of authorization.
After you create your EIM identifiers, registry definitions, and associations, you can begin using EIM to more easily organize and work with user identities within your enterprise.
EIM identifier
An EIM identifier represents a person or entity in an enterprise. A typical network consists of various hardware platforms and applications and their associated user registries. Most platforms and many applications use platform-specific or application-specific user registries. These user registries contain all of the user identification information for users who work with those servers or applications.
When you create an EIM identifier and associate it with the various user identities for a person or entity, it becomes easier to build heterogeneous, multiple-tier applications (for example, a single sign-on environment). When you create an EIM identifier and associations, it also becomes easier to build and use tools that simplify the administration involved with managing every user identity that a person or entity has within the enterprise.
EIM registry definition
An EIM registry definition represents an actual user registry that exists on a system within the enterprise. A user registry operates such as a directory and contains a list of valid user identities for a particular system or application. A basic user registry contains user identities and their passwords. One example of a user registry is the z/OS Security Server RACF registry. User registries can contain other information as well. For example, an LDAP directory contains bind distinguished names, passwords, and access controls to data that is stored in LDAP. Other examples of common user registries are a Kerberos key distribution center (KDC) and the OS/400® user profiles registry.
You can also define user registries that exist within other user registries. Some applications use a subset of user identities within a single instance of a user registry. For example, the z/OS Security Server RACF registry can contain specific user registries that are a subset of users within the overall RACF user registry. To model this behavior, EIM allows administrators to create two kinds of EIM registry definitions:
•System registry definitions
•Application registry definitions
EIM registry definitions provide information regarding those user registries in an enterprise. The administrator defines these registries to EIM by providing the following information:
•A unique, arbitrary EIM registry name
•The type of user registry
Each registry definition represents a specific instance of a user registry. Consequently, you need to choose an EIM registry definition name that helps you to identify the particular instance of the user registry. For example, you could choose the TCP/IP host name for a system user registry, or the host name combined with the name of the application for an application user registry. You can use any combination of alphanumeric characters, mixed case, and spaces to create unique EIM registry definition names.
There are a number of predefined user registry types that EIM provides to cover most operating system user registries, including:
•AIX®
•Domino - long name
•Domino - short name
•Kerberos
•Kerberos - case sensitive
•LDAP
•Linux
•Policy director
•Novell® Directory Server
•OS/400
•Tivoli Access Manager
•RACF
•Windows - local
•Windows domain (Kerberos)
•X.509
 
Note: Although the predefined registry definition types cover most operating system user registries, you may need to create a registry definition for which EIM does not include a predefined registry type. You have two options in this situation. You can either use an existing registry definition which matches the characteristics of your user registry or you can define a private user registry type.
For example in Figure 7-3 on page 364, the administrator followed the process required and defined the type of registry as WebSphere® Third-Party Authentication (LTPA) for the System_A_WAS application registry definition.
In Figure 7-3 on page 364, the administrator creates EIM registry definitions for user registries representing System A, System B, and System C and a Windows Active Directory® that contains users’ Kerberos principals with which users log into their desk top workstations. In addition, the administrator created an application registry definition for WebSphere Lightweight Third-Party Authentication (LTPA), which runs on System A.
The registry definition name that the administrator uses helps to identify the specific occurrence of the type of user registry. For example, an IP address or host name is often sufficient for many types of user registries. In this example, the administrator identifies the specific user registry instance by using System_A_WAS as the registry definition name to identify this specific instance of the WebSphere LTPA application. In addition to the name, the administrator also provides the type of registry as System_A.
Figure 7-3 EIM registry definitions
You can also define user registries that exist within other user registries. For example, the z/OS Security Server RACF registry can contain specific user registries that are a subset of users within the overall RACF user registry.
EIM associations
An EIM association is an entry that you create in an EIM domain to define a relationship between user identities in different user registries. The type of association that you create determines whether the defined relationship is direct or indirect. You can create one of two types of associations in EIM: identifier associations and policy associations. You can use policy associations instead of, or in combination with, identifier associations. How you use associations depends on your overall EIM implementation plan.
EIM lookup operation
An application or an operating system uses an EIM API to perform a lookup operation so that the application or operating system can map from one user identity in one registry to another user identity in another registry. An EIM lookup operation is a process through which an application or operating system finds an unknown associated user identity in a specific target registry by supplying some known and trusted information. Applications that use EIM APIs can perform these EIM lookup operations on information only if that information is stored in the EIM domain. An application can perform one of two types of EIM lookup operations based on the type of information the application supplies as the source of the EIM lookup operation: a user identity or an EIM identifier.
When applications or operating systems use the eimGetTargetFromSource API to obtain a target user identity for a given target registry, they must supply a user identity as the source of the lookup operation. To be used as the source in a EIM lookup operation, a user identity must have either an identifier source association defined for it or be covered by a policy association.
When an application or operating system uses this API, the application or operating system must supply these pieces of information:
•A user identity as the source or starting point of the operation.
•The EIM registry definition name for the source user identity.
•The EIM registry definition name that is the target of the EIM lookup operation. This registry definition describes the user registry that contains the user identity that the application is seeking.
When applications or operating systems use the eimGetTargetFromIdentifier API to obtain a user identity for a given target registry, they must supply an EIM identifier as the source of the EIM lookup operation. When an application uses this API, the application must supply the following pieces of information:
•A user identity as the source, or starting point of the operation.
•The EIM registry definition name that is the target of the EIM lookup operation. This registry definition describes the user registry that contains the user identity that the application is seeking.
For a user identity to be returned as the target of either type of EIM lookup operation, the user identity must have a target association defined for it. This target association can be in the form of an identifier association or a policy association.
The supplied information is passed to EIM and the lookup operation searches for and returns any target user identities, by searching EIM data in the following order:
1. Identifier target association for an EIM identifier. The EIM identifier is identified in one of two ways: It is supplied by the eimGetTargetFromIdentifier API. Alternatively, the EIM identifier is determined from information supplied by the eimGetTargetFromSource API.
2. Certificate filter policy association.
3. Default registry policy association.
4. Default domain policy association.
Figure 7-4 EIM lookup operation
The lookup operation, illustrated in Figure 7-4, searches flows in this manner:
1. The lookup operation checks whether mapping lookups are enabled. The lookup operation determines whether mapping lookups are enabled for the specified source registry, the specified target registry, or both specified registries. If mapping lookups are not enabled for one or both of the registries, then the lookup operation ends without returning a target user identity
2. The lookup operation checks whether there are identifier associations that match the lookup criteria. If an EIM identifier was provided, the lookup operation uses the specified EIM identifier name. Otherwise, the lookup operation checks whether there is a specific identifier source association that matches the supplied source user identity and source registry. If there is one, the lookup operation uses it to determine the appropriate EIM identifier name. The lookup operation then uses the EIM identifier name to search for an identifier target association for the EIM identifier that matches the specified target EIM registry definition name. If there is an identifier target association that matches, the lookup operation returns the target user identity defined in the target association
3. The lookup operation checks whether the use of policy associations are enabled. The lookup operation checks whether the domain is enabled to allow mapping lookups using policy associations. The lookup operation also checks whether the target registry is enabled to use policy associations. If the domain is not enabled for policy associations or the registry is not enabled for policy associations, then the lookup operation ends without returning a target user identity.
4. The lookup operation checks for certificate filter policy associations. The lookup operation checks whether the source registry is an X.509 registry type. If it is an X.509 registry type, the lookup operation checks whether there is a certificate filter policy association that matches the source and target registry definition names. The lookup operation checks whether there are certificates in the source X.509 registry that satisfy the criteria specified in the certificate filter policy association. If there is a matching policy association and there are certificates that satisfy the certificate filter criteria, the lookup operation returns the appropriate target user identity for that policy association.
5. The lookup operation checks for default registry policy associations. The lookup operation checks whether there is a default registry policy association that matches the source and target registry definition names. If there is a matching policy association, the lookup operation returns the appropriate target user identity for that policy association.
6. The lookup operation checks for default domain policy associations. The lookup operation checks whether there is a default domain policy association defined for the target registry definition. If there is a matching policy association, the lookup operation returns the associated target user identity for that policy association.
7. The lookup operation is unable to return any results.
When an application supplies a user identity as the source, the application also must supply the EIM registry definition name for the source user identity and the EIM registry definition name that is the target of the EIM lookup operation. To be used as the source in a EIM lookup operation, a user identity must have a source association defined for it.
When an application supplies an EIM identifier as the source of the EIM lookup operation, the application must also supply the EIM registry definition name that is the target of the EIM lookup operation. For a user identity to be returned as the target of either type of EIM lookup operation, the user identity must have a target association defined for it.
The supplied information is passed to the EIM domain controller where all EIM information is stored and the EIM lookup operation searches for the source association that matches the supplied information. Based on the EIM identifier (supplied to the API or determined from the source association information), the EIM lookup operation then searches for a target association for that identifier that matches the target EIM registry definition name.
In Figure 7-5 on page 368, the user identity johnday authenticates to the WebSphere Application Server using lightweight third-party authentication (LPTA) on System A.
Figure 7-5 EIM lookup
The WebSphere Application Server on System A calls a native program on System B to access data on System B. The native program uses an EIM API to perform an EIM lookup operation based on the user identity on System A as the source of the operation. The application supplies the following information to perform the operation:
•johnday as the source user identity
•System_A_WAS as the source EIM registry definition name
•System_B as the target EIM registry definition name
This source information is passed to the EIM domain controller and the EIM lookup operation finds a source association that matches the information. Using the EIM identifier name, the EIM lookup operation searches for a target association for the johnday identifier that matches the target EIM registry definition name for System_B. When the matching target association is found, the EIM lookup operation returns the jsd1 user identity to the application.
Mapping policy support and enablement
EIM mapping policy support allows you to use policy associations as well as specific identifier associations in an EIM domain. You can use policy associations instead of, or in combination with, identifier associations.
EIM mapping policy support provides a means of enabling and disabling the use of policy associations for the entire domain, as well as for each specific target user registry. EIM also allows you to set whether a specific registry can participate in mapping lookup operations in general. Consequently, you can use mapping policy support to more precisely control how mapping lookup operations return results.
The default setting for an EIM domain is that mapping lookups that use policy associations are disabled for the domain. When the use of policy associations is disabled for the domain, all mapping lookup operations for the domain return results only by using specific, identifier associations between user identities and EIM identifiers.
The default setting for each individual registry is that mapping lookup participation is enabled and the use of policy associations is disabled. When you enable the use of policy associations for an individual target registry, you must also ensure that this setting is enabled for the domain.
You can configure mapping lookup participation and the use of policy associations for each registry in one of the following ways:
•Mapping lookup operations cannot be used for the specified registry at all. In other words, an application that performs a mapping lookup operation involving that registry will fail to return results.
•Mapping lookup operations can use specific identifier associations between user identities and EIM identifiers only. Mapping lookups are enabled for the registry, but the use of policy associations is disabled for the registry.
•Mapping lookup operations can use specific identifier associations when they exist and policy associations when specific identifier associations do not exist (all settings are enabled).
EIM access control
An EIM user is a user who possesses EIM access control based on their membership in a predefined LDAP user group for a specific domain. Specifying EIM access control for a user adds that user to a specific LDAP user group for a particular domain. Each LDAP group has authority to perform specific EIM administrative tasks for that domain. Which and what type of administrative tasks, including lookup operations, an EIM user can perform is determined by the access control group to which the EIM user belongs.
EIM access controls allow a user to perform specific administrative tasks or EIM lookup operations. Only users with EIM administrator access are allowed to grant or revoke authorities for other users. EIM access controls are granted only to user identities that are known to the EIM domain controller.
The following sections provide brief descriptions of the functions that each EIM access control group can perform.
LDAP administrator
This access control allows the user to configure a new EIM domain. A user with this access control can perform the following functions:
•Create a domain v Delete a domain
•Create and remove EIM identifiers
•Create and remove EIM registry definitions
•Create and remove source, target, and administrative associations
•Perform EIM lookup operations
•Retrieve associations, EIM identifiers, and EIM registry definitions
•Add, remove, and list EIM authority information
EIM administrator
This access control allows the user to manage all of the EIM data within this EIM domain. A user with this access control can perform the following functions:
•Delete a domain
•Create and remove EIM identifiers
•Create and remove EIM registry definitions
•Create and remove source, target, and administrative associations
•Perform EIM lookup operations
•Retrieve associations, EIM identifiers, and EIM registry definitions
•Add, remove, and list EIM authority information
EIM identifiers administrator
This access control allows the user to add and change EIM identifiers and manage source and administrative associations. A user with this access control can perform the following functions:
•Create an EIM identifier
•Add and remove source associations
•Add and remove administrative associations
•Perform EIM lookup operations
•Retrieve associations, EIM identifiers, and EIM registry definitions
EIM mapping lookup
This access control allows the user to conduct EIM lookup operations. A user with this access control can perform the following functions:
•Perform EIM lookup operations
•Retrieve associations, EIM identifiers, and EIM registry definitions
EIM registries administrator
This access control allows the user to manage all EIM registry definitions. A user with this access control can perform the following functions:
•Add and remove target associations
•Perform EIM lookup operations
•Retrieve associations, EIM identifiers, and EIM registry definitions
EIM registry X administrator
This access control allows the user to manage a specific EIM registry definition. Membership in this access control group also allows the user to add and remove target associations only for a specified user registry definition. To take full advantage of mapping lookup operations and policy associations, a user with this access control should also have EIM mapping operations access control. This access control allows a user to:
•Create, remove, and list target associations for the specified EIM registry definitions only
•Add and remove default domain policy associations
•Add and remove policy associations for the specified registry definitions only
•Add certificate filters for the specified registry definitions only
•Enable and disable mapping lookups for the specified registry definitions only
•Add and remove policy associations only for the specified registries
•Retrieve EIM identifiers
•Retrieve identifier associations and certificate filters for the specified registry definitions only
•Add and remove target associations for the specific EIM registry definition
•Perform EIM lookup operations
•Retrieve EIM registry definition information for the specified registry definitions only
7.3 Setting up EIM in z/OS
Figure 7-6 Setting up EIM on z/OS
Steps for installing and configuring the EIM domain controller on z/OS
 
Note: For the z/OS Integrated Security Services LDAP server, the following requirements must be met:
•APAR OW55078 (PTF UW92346) must be applied.
•LDAP must be configured to use the TDBM back end.
•The SDBM (RACF) back end is optional.
1. Install and configure LDAP.
Note:
a. The z/OS Integrated Security Services LDAP server must be configured to accept the different types of bind requests.
b. Start the z/OS LDAP server.
c. Load the schema definitions.
 
Attention:
•An EIM domain must be updated using the EIM APIs or administrative applications that use the EIM APIs. We do not recommend using the LDAP utilities and LDAP client APIs to update information in an EIM domain.
•Do not alter the EIM schema definitions unless directed to do so by your IBM service representative during problem diagnosing.
 
Restriction: z/OS LDAP by default has a 511 character limit on the length of a distinguished name for an entry. If this default length is exceeded, message ITY0023 (indicating an unexpected LDAP error) is issued, indicating that DB2 needs to be reconfigured to support longer distinguished names. This error might show up when working with long identifier, registry, domain names or suffixes.
2. Consider the options you have for setting up an EIM domain that includes z/OS:
a. Use LDAP on z/OS as the domain controller. (z/OS and non-z/OS applications could access the data.) The LDAP server on z/OS must be configured with the TDBM back end. If you plan to use RACF user IDs and passwords for the bind credentials, configure the server with the SDBM and the TDBM back ends.
b. Set up the z/OS LDAP server in multi-server mode. This configuration has multiple LDAP servers sharing the same TDBM back-end store, which is useful if you want to balance the work load between your LDAP servers.
c. The z/OS EIM application can access a domain controller that resides on another platform.
7.4 Installing and configuring EIM on z/OS
Figure 7-7 Installing and configuring EIM on z/OS
Installation considerations for applications
EIM applications on z/OS must be APF-authorized. Requiring APF authorization prevents inadvertent or malicious use of EIM APIs to change information in an EIM domain or to extract unauthorized information.
Installing and configuring EIM on z/OS
Your z/OS system programmer uses SMP/E to install EIM into an HFS directory. By default, EIM is installed in the /usr/lpp/eim directory, but your system programmer can determine whether to change the default for these directories.
Figure 7-7 lists important directories for EIM installation. Your system programmer should review the right-most column of this table, crossing out any defaults that have changed and recording the correct directory names.
 
Tip: An EIM administrator who uses the eimadmin utility might desire that the directory for the eimadmin utility be placed in the PATH environment variable. This enables the ability to run the utility without having to specify the path when issuing the command (or changing to the /usr/lpp/eim/bin directory prior to issuing the command). The PATH environment variable can be modified to include the EIM programs directory by issuing the following command from a shell prompt:
export PATH=$PATH:/usr/lpp/eim/bin
This adds the EIM programs directory to the end of the list of directories to search for programs. Add the export command to a user’s .profile file so that each time the user enters a shell, the PATH is updated.
Steps for using the eimadmin utility to manage an EIM domain
Perform the steps listed in this section to create and manage an EIM domain using the eimadmin utility.
Before you begin:
•The eimadmin utility examples can be entered from the z/OS UNIX System Services shell by an EIM administrator.
•For improved readability each command option is shown on a separate line.
•In most cases you specify multiple options on a single line, separating them with one or more spaces.
•If necessary, you can use the backslash () continuation character to break the command into multiple lines.
•The access authority required for successful completion depends on the particular eimadmin operation you specify, and is determined by the bind credential you specify for LDAP authentication. The distinguished name that LDAP associates with the credential should be a member of one or more EIM access groups, which define access authority to EIM data.
To create the domain:
1. Create an EIM domain by entering a command such as the following from the z/OS shell:
eimadmin -aD -d domainDN -n description -h ldapHost -b bindDN -w bindPassword
The bindDN must be the distinguished name for the LDAP administrator. (The description is optional.)
The following command creates the EIM domain My Domain:
eimadmin
-aD
-d ’ibm-eimDomainName=My Domain,o=IBM,c=US’
-n ’An EIM Domain’
-h ldap://some.ldap.host
-b ’cn=ldap administrator’
-w secret
 
Note: This assumes that the o=IBM,c=US objects are defined in the LDAP Directory.
2. Give an administrator EIM administrator authority to the domain by entering a command such as the following command from the z/OS shell:
eimadmin
-aC
-d domainDN
-c ADMIN
-q accessUser
-f accessUserType
-h ldapHost
-b bindDN
-w bindPassword
The parameter following -c is the accessType parameter. In this situation, the value must be ADMIN. The bindDN must be the distinguished name for the LDAP administrator.
 
Tip: If you plan on dividing the administration responsibilities, repeat this command for the other administrative users.
The following command can be issued by the LDAP administrator to give EIM administrator, cn=eim administrator,ou=dept20,o=IBM,c=US, authority to administer the EIM domain:
eimadmin
-aC
-d ’ibm-eimDomainName=My Domain,o=IBM,c=US’
-c ADMIN
-q ’cn=eim administrator,ou=dept20,o=IBM,c=US’
-f DN
-h ldap://some.ldap.host
-b ’cn=ldap administrator’
-w secret
 
Note: This assumes that the cn=eim administrator,ou=dept20,o=IBM,c=US is defined in the LDAP Directory.
3. Add registries to the EIM domain by entering a command such as the following command from the z/OS shell:
eimadmin
-aR
-d domainDN
-r registryName
-y registryType
-n description
-h ldapHost
-b bindDN
-w bindPassword
 
Note: The -y parameter specifies registry type.
The following command adds a RACF registry to the EIM domain named My Domain:
eimadmin
-aR
-d ’ibm-eimDomainName=My Domain,o=IBM,c=US’
-r ’RACF Pok1’
-y RACF
-n ’the RACF Registry on Pok System 1’
-h ldap://some.ldap.host
-b ’cn=eim administrator,ou=dept20,o=IBM,c=US’
-w secret
The following command adds an OS/400 registry to the EIM domain named My Domain:
eimadmin
-aR
-d ’ibm-eimDomainName=My Domain,o=IBM,c=US’
-r ’OS400 RCH1’
-y OS400
-n ’the OS400 Registry on Rochester System 1’
-h ldap://some.ldap.host
-b ’cn=eim administrator,ou=dept20,o=IBM,c=US’
-w secret
4. Add enterprise identifiers to the domain by entering a command such as the following from the z/OS shell:
eimadmin
-aI
-d domainDN
-i identifier
-n description
-h ldapHost
-b bindDN
-w bindPassword
You can add identifiers at any time after creating the domain.
The preceding command adds a single identifier to the domain. Alternately, you can add multiple identifiers by specifying a file name as standard input to the eimadmin utility. Specifying a file name indicates using the file of identifiers as input for batch processing of multiple identifiers.
Repeat this step as needed.
The bindDN must have EIM administrator authority or EIM Identifier administrator authority. The following command can be issued by the EIM administrator add to an EIM identifier to the domain My Domain:
eimadmin
-aI
-d ’ibm-eimDomainName=My Domain,o=IBM,c=US’
-i ’John Adam Day’
-h ldap://some.ldap.host
-b ’cn=eim administrator,ou=dept20,o=IBM,c=US’
-w secret
5. Create associations between registry user IDs and identifiers by entering commands from the z/OS shell (One or more of the association types, -t source, -t target, -t admin are required on the command.):
eimadmin
-aA
-d domainDN
-r registryName
-u userid
-i identifier
-t admin
-t source
-t target
-h ldapHost
-b bindDN
-w bindPassword
The following command creates associations between the user ID JD in the RACF Pok1 registry:
eimadmin
-aA
-d ’ibm-eimDomainName=My Domain,o=IBM,c=US’
-r ’RACF Pok1’
-u JD
-i ’John Day’
-t source
-t target
-h ldap://some.ldap.host
-b ’cn=eim administrator,ou=dept20,o=IBM,c=US’
-w secret
After you enter these commands, you can use the domain for lookup operations. For the preceding examples, the only user mappings available are mappings from JD to JOHNDAY and from JOHNDAY to JD.
 
Note: You can create associations only after registries and identifiers are in place.
The command creates only two associations. Conversely, you can create multiple associations by specifying a file name as standard input to the eimadmin command. Specifying a file name indicates using a file of associations as input for batch processing of multiple associations.
Repeat this step as needed.
6. Give users lookup access to the EIM domain. Use the following command:
eimadmin
-aC
-d domainDN
-c MAPPING
-q accessUser
-f DN
-h ldapHost
-b bindDN
-w bindPassword
The eimadmin utility allows you to grant access one user at a time or a list of users can be provided in a file using the following command:
eimadmin
-aC
-d domainDN
-c MAPPING
-h ldapHost
-b bindDN
-w bindPassword <input-fileName
The file must contain a label line following by at least one user name. For example, a bind distinguished name, and the type of the user name as follows:
CU ;CS ; cn=John Day,c=US DN
The EIM administrator can issue the following command to give the user John Day mapping (lookup) authority to the domain My Domain:
eimadmin
-aC
-d ’ibm-eimDomainName=My Domain,o=IBM,c=US’
-c MAPPING
-q ’cn=John Day,c=US’ -h ldap://some.ldap.host
-b ’cn=eim administrator,ou=dept20,o=IBM,c=US’
-w secret
7.5 Domain authentication methods
Figure 7-8 Domain authentication methods
Domain authentication methods
Authentication occurs when an EIM application connects (binds) to the EIM domain controller. z/OS EIM supports the following three authentication methods recognized by LDAP:
•Simple (with or without CRAM-MD5 password protection)
•Digital certificate
•Kerberos
Your LDAP server configuration and security requirements determine which method you choose. The examples in this section illustrate how you can use these methods with the eimadmin utility.
This information explains how the bind credentials specified correspond to the distinguished name that LDAP uses for access checking. Your access to EIM data is determined by the authority groups of which the distinguished name is a member. The exception is the distinguished name for the LDAP administrator that has unrestricted access.
Using simple binds
A distinguished name and password are sufficient credentials for a SIMPLE eimadmin connect type, as follows:
eimadmin
-lD
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-S SIMPLE
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
 
Note: Unless an SSL session has been established, the password is sent over the network in plain text, making this method the least secure. The distinguished name that you specify is the one LDAP uses for access checking.
Using CRAM-MD5 password protection
You can use CRAM-MD5 for simple authentication without sending the bind password over the network in plain text, provided both client and server support the method. In the utility command, specify the connect type CRAM-MD5 to indicate simple authentication with password protection, as follows:
eimadmin
-lD
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-S CRAM-MD5
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
Using digital certificates
To bind using a digital certificate, specify the EXTERNAL connect type on the eimadmin command. Ensure that the host name identifies a secure host:port value prefixed with ldaps://, as follows:
eimadmin
-lD
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldaps://secure.ldap.host
-S EXTERNAL
-K client.kdb
-P clientpw
-N eimadmincert
 
Note: LDAP uses the client certificate’s subject distinguished name for access checking.
Use the following rules:
•You must also specify the name of either a key database file or RACF key ring that contains your client certificate.
•You must specify the label for that certificate if it is not the defined default. If you specify a key database file but not its password, the utility prompts you for it.
Using Kerberos
To bind using a Kerberos identity, specify connect type GSSAPI on the eimadmin command. No other credential information is required, but the default Kerberos credential must be established through a service such as kinit prior to entering the command, as follows:
eimadmin
-lD
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-S GSSAPI
For access checking, LDAP considers a distinguished name formed by prefixing the Kerberos principal name with ibm-kgn= or distinguished names located through special mapping or searches.
Using Secure Sockets Layer
You can establish a Secure Sockets Layer (SSL) connection along with any of the supported authentication types if your domain controller is configured as a secure host enabled for server authentication.
A secure host is required for EXTERNAL connect.
The strength of SSL is that data transferred over the connection is encrypted, including the password for a SIMPLE bind. The eimadmin utility recognizes the need for an SSL connection when you specify an LDAP host name prefixed with ldaps://. It then requires that you specify a RACF key ring, or a key database file and its password.
7.6 EIM additional administration tasks
Figure 7-9 EIM additional administration tasks
Managing registries
A domain typically contains multiple registries. User identities for a particular system are associated with a system registry, while a subset of identities might be associated with an application registry.
Adding a system and application registry
Create a system registry by entering the following command:
eimadmin
-aR
-r ’RACF Pok1’
-y racf
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
Enter the following command to define an application registry that is dependent on a previously defined system registry:
eimadmin
-aR
-r ’App1’
-y racf
-g ’RACF Pok1’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
 
Note: After you define an application registry, you can refer to it by name in EIM APIs and eimadmin commands without having to identify it as an application-type registry.
Listing a registry
You can list any registry using a command similar to the following:
eimadmin
-lR
-r ’App1’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
Removing a registry
To remove a registry, issue the following command:
eimadmin
-pR
-r ’App1’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
All associations linked to the registry are deleted automatically.
 
Attention: EIM refuses to remove a system registry if any application registries depend on it.
You can find the dependents that you must remove by searching for all occurrences of the system registry name in the output from the following command, which lists all registries:
eimadmin
-lR
-r ’*’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
With caution, you can use the -s rmdeps option of eimadmin to remove dependent application registries automatically when removing the system registry, as follows:
eimadmin
-s rmdeps
-pR
-r ’RACF Pok1’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
Working with registry aliases
You can define alias names to facilitate registry administration. By establishing aliases that applications use to look up actual registry names, you can make nondisruptive registry changes by managing alias assignments.
 
Rule: When defining or referencing a registry alias, you must specify an associated registry type.
Assigning an alias
Enter the following command to assign an alias name to an existing registry:
eimadmin
-mR
-r ’RACF Test Pok1’
-x ’z/OS’
-z ’RACF’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
This example defines the alias z/OS (of type RACF) for registry RACF Test Pok1.
Listing an alias
You can list the registry and its aliases using the following command:
eimadmin
-lR
-r ’RACF Test Pok1’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
Removing an alias
You can delete an alias for a registry using the following command:
eimadmin
-eR
-r ’RACF Test Pok1’
-x ’z/OS’
-z ’RACF’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
This example removes the alias z/OS (of type RACF) for registry RACF Test Pok1.
Assigning an alias name to a different registry
To assign an alias name to a different registry, add the alias name and type to the registry attributes as shown in the example for adding an alias name to a registry above. Multiple registries can have the same registry alias values. However, if you want the alias to map to a single registry, you must remove that alias from registries in which is was previously defined.
Enter the following two commands to reassign alias z/OS from registry RACF Test Pok1 to registry RACF Pok1:
eimadmin
-mR
-r ’RACF Pok1’
-x ’z/OS’
-z ’RACF’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
 
eimadmin
-eR
-r ’RACF Test Pok1’
-x ’z/OS’
-z ’RACF’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
Adding a new user
You can create an new EIM identifier to represent a new person entering your enterprise. As the person is given access to each system or application through its user registry, you can define an EIM association between the EIM identifier and the corresponding registry defined in EIM.
Adding an identifier
When you create a new EIM identifier, it is assigned a name that is unique within the domain.
The eimadmin utility requires that you specify a unique name (unlike the eimAddIdentifier API option that generates a unique name for you).
You can assign an alternate name, or alias, to multiple identifiers. This non-unique name can be used to further describe the represented individual or to serve as an alternate identifier for lookup operations.
Enter the following command to add a new identifier John S. Day with two aliases:
eimadmin
-aI
-i ’John S. Day’
-j ’654321’
-j ’Contractor’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
You can list the new identifier using the unique name.
The utility returns one entry only, as follows:
eimadmin
-lI
-i ’John S. Day’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
You can also list the new identifier using an alias name.
The utility returns all entries having Contractor defined as an alternate name, as follows:
eimadmin
-lI
-j ’Contractor’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
Adding associations
You can register the system and application user IDs assigned to the individual by defining EIM associations between the identifier and the corresponding registries.
Enter the following command to create source and target associations for user ID JD in registry RACF Pok1:
eimadmin
-aA
-i ’John S. Day’
-r ’RACF Pok1’
-u ’JD’
-t source
-t target
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
Listing associations
Enter the following command to list all associations for John S. Day:
eimadmin
-lA
-i ’John S. Day’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
Removing a user
To completely erase a person’s identity from your EIM domain, remove the identifier.
If you only need to reflect the deletion of a user ID from a registry, simply remove the corresponding EIM associations.
Removing associations
Enter the following command to remove the source and target associations for user ID JD in registry RACF Pok1:
eimadmin
-pA
-i ’John S. Day’
-r ’RACF Pok1’
-u ’JD’
-t source
-t target
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
Removing an identifier
Enter the following command to remove an identifier and its associations, including identifier aliases:
eimadmin
-pI
-i ’John S. Day’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
Changing access authority
A user is permitted to perform EIM administrative or lookup operations based on the authority groups containing the user’s LDAP DN. The user’s DN is determined by the credentials authenticated when connecting to LDAP.
Suppose that a user has registry administrator authority over a specific registry, and your task is to switch the user’s authority to a different registry. You can accomplish this task in two steps:
1. Add the user to the new registry administrator group.
2. Remove the user from the prior group.
Adding access authorities
Enter the following command to add user DN cn=Reggie King,ou=dept20,o=IBM,c=US to the registry administration group for RACF Pok1:
eimadmin
-aC
-q ’cn=Reggie King,ou=dept20,o=IBM,c=US’
-f DN
-c registry
-r ’RACF Pok1’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
Listing access authorities
Enter the following command to list all EIM access authorities for the user:
eimadmin
-lC
-q ’cn=Reggie King,ou=dept20,o=IBM,c=US’
-f DN
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
Removing access authorities
Enter the following command to remove the user from the prior registry administration group for RACF Test Pok1:
eimadmin
-pC
-q ’cn=Reggie King,ou=dept20,o=IBM,c=US’
-f DN
-c registry
-r ’RACF Test Pok1’
-d ’ibm-eimDomainName=MyDomain,o=IBM,c=US’
-h ldap://some.ldap.host
-b ’cn=eimadministrator,ou=dept20,o=IBM,c=US’
-w secret
7.7 RACF support for EIM
Figure 7-10 RACF support for EIM
Using RACF for EIM domain access
The RACF administrator can use RACF commands to do the following:
•Add an EIM domain name and bind information for system-wide use
•Add an EIM domain name and bind information for use by a server
•Add an EIM domain name and bind information for use by an administrative user
•Assign a name to the local RACF registry for use by a lookup application
 
Tip: Issuing these commands is optional. However, setting up your system this way can eliminate the need for individual applications to handle EIM domain and bind information.
The default domain and bind information can be specified in one of three places:
1. The user ID the application runs under has the name of an LDAPBIND class profile in its USER profile
2. The IRR.EIM.DEFAULTS profile in the LDAPBIND class
3. The IRR.PROXY.DEFAULTS profile in the FACILITY class
These RACF profiles can be set up in such a way as to control the access the application has to the EIM domain:
•New connections with an EIM domain can be enabled or disabled by using keywords on the RDEFINE or RALTER commands.
•Bind credentials can be specific to the server or administrator who uses them.
The EIM APIs try to retrieve the information from a profile if the application does not explicitly supply the information to the EIM APIs using parameters. Applications or other services that use EIM can instruct their callers to define a profile in the LDAPBIND class profile.
7.8 Storing LDAP binding information in a profile
Figure 7-11 Storing LDAP bind information in a profile
Before you begin, use the decision table of Figure 7-11 to determine which profile to use.
Adding EIM domain and bind information for servers or administrative users
To create a profile for LDAP binding information:
1. If you are creating a profile in the LDAPBIND class, define the domain in the LDAPBIND class. Enter the following command:
RDEFINE LDAPBIND racfProfileName EIM(DOMAINDN(domainDN)) PROXY(LDAPHOST(ldapHost) + BINDDN(bindDN) BINDPW(bindPasswd))
2. To update the user profile:
ADDUSER ASERVER EIM(LDAPPROF(racfProfileName))
Adding a system default using the IRR.EIM.DEFAULTS profile
If you are using the IRR.PROXY.DEFAULTS profile in the FACILITY class, enter:
RDEFINE LDAPBIND IRR.EIM.DEFAULTS PROXY(LDAPHOST(ldapHost) BINDDN(bindDN) + BINDPW(bindPasswd)) EIM(DOMAINDN(domainDN))
Adding a system default using the IRR.PROXY.DEFAULTS profile
If no LDAPBIND class profile is associated with the caller’s user profile, the EIM services look for the EIM domain’s LDAP URL and binding information in the IRR.EIM.DEFAULTS profile in the LDAPBIND class followed by the IRR.PROXY.DEFAULTS profile in the FACILITY class. For example, the following command sets up the binding information in the IRR.PROXY.DEFAULTS profile in the FACILITY class:
RDEFINE FACILITY IRR.PROXY.DEFAULTS PROXY(LDAPHOST(LDAP://SOME.BIG.HOST:389) + BINDDN(’cn=Joes Admin,o=IBM,c=US’) BINDPW(secret)) + EIM(DOMAINDN(’ibm-eimDomainName=Joes Domain,o=IBM,c=US’))
In this case, the domain’s LDAP URL is:
LDAP://SOME.BIG.HOST:389/ibm-eimDomainName=Joes Domain,o=IBM,c=US
7.9 Setting up a registry name for your local RACF registry
Figure 7-12 Setting up a registry name for your local RACF registry
Many of the EIM APIs require the name of a registry. For example, if you are adding a registry to an EIM domain, you should know the name of the new registry. However, you can use the lookup APIs (such as eimGetTargetFromSource, eimGetIdentifierFromSource, and eimGetAssociatedIdentifiers) to convert:
1. A user ID to its equivalent RACF user ID
2. A local RACF user ID to an enterprise identifier
For such applications, you can eliminate the requirement for providing the RACF registry name or its alias on the local system. You do this by giving a name to the local RACF registry.
Steps for setting up lookups that do not need a registry name
Before you begin, you need to know the registry name.
To set up EIM so that you do not need a registry name on every lookup follow the instructions in this section. To define the local registry, enter the following RACF command in which registryName is the name of the local registry:
RDEFINE FACILITY IRR.PROXY.DEFAULTS EIM(LOCALREGISTRY(registryName))
 
Note: EIM does not look for the registry name in an LDAPBIND class profile.
You can also configure the system with a kerberos registry name and an X.509 registry name. Issue the following commands to define default kerberos and X.509 registries for the configured EIM domain:
RALTER FACILITY IRR.PROXY.DEFAULTS EIM(KERBREGISTRY(registry name) + X509REGISTRY(registry name))
This access can be removed with the following command:
RALTER FACILITY IRR.PROXY.DEFAULTS EIM(NOKERBREGISTRY NOX509REGISTRY)
 
Note: You need to define these registry names in the configured EIM domain.
Disabling use of an EIM domain
You might need to temporarily disable use of a RACF profile with a configured EIM domain or a system-wide default EIM domain. You might want to do this if the EIM information in a domain has been compromised or a security administrator wants to stop the system or server from establishing new connections with the EIM domain. You can use RACF commands to disable a domain without deleting EIM information from the RACF profiles. When an EIM domain is disabled through a RACF profile, existing connections to the domain complete their work. However, if an EIM service is trying to establish a connection with such a domain, the EIM service does not continue to look for an enabled domain.
If you want to disable a server (rather than a system) from using a configured EIM domain, enter the following command:
RALTER LDAPBIND ldapbind_profile EIM(OPTIONS(DISABLE))
This command applies only to a server that has an ldapbind class profile specified for its user ID.
 
Tip: To disable a system-wide default EIM domain (rather than a server) that default profiles use, enter one of the following commands:
RALTER FACILITY IRR.PROXY.DEFAULTS EIM(OPTIONS(DISABLE))
RALTER LDAPBIND IRR.EIM.DEFAULTS EIM(OPTIONS(DISABLE))
Using output from the RACF database unload utility and eimadmin
to prime your EIM domain with information
You can start to put EIM information (identifiers, RACF user IDs, and associations) into your EIM domain by using output from DBUNLOAD and eimadmin.
For large installations, priming the EIM domain with identifiers and associations can involve a lot of work. To make the task of getting started with EIM easier, the eimadmin utility accepts as input a file containing a list of identifiers and associations.
The section explores the steps for setting up an EIM domain based on user information contained in a RACF database. The initial assumptions are that the EIM domain, World Wide Domain, has been created and a SAF system registry, SAF user IDs, is defined in the domain. The LDAP host name for the domain is ldap://some.big.host. The EIM administrator uses the bind distinguished name of cn=EIM Admin,o=My Company,c=US and the password is secret. The EIM administrator bind distinguished name has been given EIM administrator authority and can perform all of the steps that we list here.
A user with other types of EIM authority, such as the following types of authority, can perform a subset of the following steps:
•EIM identifier administrator authority only works with identifiers and source and target associations.
•EIM registries administrator authority only works with target associations.
•EIM registry-specific administrator authority for the SAF registry only works with target associations in the SAF registry.
To set up an EIM domain based on user information contained in a RACF database:
1. Request from your RACF security administrator a file containing a copy of the user profiles in the RACF database. The RACF security administrator can:
a. Run the database unload utility (IRRDBU00) to create the sequential file
b. Run the file through a sort program, such as DFSORT™ or DFSORT ICETOOL to extract just the user profiles and desired fields. The User Basic Data Record (0200) contains the user ID and the programmer name. In this example, the programmer name is used for the EIM identifier.
The DFSORT ICETOOL Report format has a 1 to 4 character name (for example, EIM). It contains the ICETOOL statements that control report format and record summary information, such as SORT, COPY, DISPLAY, and OCCURS statements. Example 7-1 shows a report format that can be used to extract RACF user IDs and the programmer names that are associated with the user IDs.
Example 7-1 A sample report format
**********************************************************************
* Name: EIM
*
*
* Find all user IDs in the RACF database and their name **********************************************************************
COPY FROM(DBUDATA) TO(TEMP0001) USING(RACF)
OCCURS FROM(TEMP0001) LIST(PRINT) -
TITLE(’user IDs and Names’) -
ON(10,8,CH) HEADER(’USER ID’) -
ON(79,20,CH) HEADER(’Name’)
The record selection criteria is as follows:
 – The name of the member containing the record selection criteria is the report member name followed by CNTL (such as EIMCNTL).
 – Record selection is performed using DFSORT control statements, such as SORT and INCLUDE.
 – The SORT command is used to select and sort records.
 – The INCLUDE command is used to specify conditions required for records to appear in the report.
2. When you receive the report from the security administrator, move it to a file in the HFS.
3. Add a eimadmin utility ?label line? to the file containing user profiles. You can use any one of the editors available from the OMVS shell (such as OEDIT).
4. Add identifiers and list the results using the eimadmin shell command:
eimadmin
-aI
-d "ibm-eimDomainName=World Wide Domain,o=My Company,c=US"
-h ldap://some.big.host
-b "cn=EIM Admin,o=My Company,c=US"
-w secret <racfUsers.txt
5. To list the identifiers that you added, issue the following command:
eimadmin
-lI
-d "ibm-eimDomainName=World Wide Domain,o=My Company,c=US"
-h ldap://some.big.host
-b "cn=EIM Admin,o=My Company,c=US"
-w secret <racfUsers.txt
6. Create source and target associations between the identifiers and the user IDs in RACF. Because the file racfUsers.txt contains a label line that identifies user IDs as well as unique identifier names, it can be used to create associations:
eimadmin
-aA
-t source
-t target
-r"SAF user IDs"
-d "ibm-eimDomainName=World Wide Domain,o=My Company,c=US"
-h ldap://some.big.host
-b "cn=EIM Admin,o=My Company,c=US" -w secret <racfUsers.txt
7. To list the associations that you added, issue the following command:
eimadmin
-lA
-d "ibm-eimDomainName=World Wide Domain,o=My Company,c=US"
-h ldap://some.big.host
-b "cn=EIM Admin,o=My Company,c=US"
-w secret <racfUsers.txt
8. The following eimadmin commands can be used to give EIM Mapping Operations authority to each of the users (identified in the file racfUsersDNs.txt):
eimadmin
-aC
-c MAPPING
-d "ibm-eimDomainName=World Wide Domain,o=My Company,c=US"
-f DN
-h ldap://some.big.host
-b "cn=EIM Admin,o=My Company,c=US"
-w secret <racfUsersDNs.txt
9. To list the accesses that have been granted, issue the following command:
eimadmin
-lC
-c MAPPING
-d "ibm-eimDomainName=World Wide Domain,o=My Company,c=US"
-h ldap://some.big.host
-b "cn=EIM Admin,o=My Company,c=US"
-w secret <racfUsersDNs.txt
 
Tip: At a minimum, a user who is looking for a mapping in the EIM domain needs to have EIM mapping operations authority. In most cases, the application has one set of credentials for connect to an EIM domain, and those credentials are shared by all users. However, if individual access is needed, then a bind distinguished name needs to be defined for each of the users and given EIM mapping operations authority.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.22.74.232