LDAP authentication using Active Directory for TEMS and TEPS
The goal of this paper is to assist users of IBM® Tivoli® Monitoring V6.2.x who want to use Active Directory LDAP (Lightweight Directory Access Protocol) user authentication for Tivoli Enterprise Monitoring Server (monitoring server) and Tivoli Enterprise Portal Server (portal server) components.
Where the Tivoli Monitoring documentation provides guidance for enabling LDAP user authentication for the monitoring server and portal server, this document extends that information by presenting the topic from an Active Directory perspective. Active Directory is a Microsoft® Windows® LDAP implementation therefore the LDAP user authentication steps are presented here using the Tivoli Monitoring interface on Windows.
Manage Tivoli Monitoring Services is the administration tool on Windows systems for configuring and managing Tivoli Monitoring components. This tool serves as the primary interface for configuring the LDAP user authentication.
Tivoli Enterprise Portal Server extended services (TEPS/e) is an embedded, co-located extension of the Tivoli Enterprise Portal Server that provides J2EE-based Application Server integration facilities. TEPS/e provides support for a federated user repository. For more information about TEPS/e, see the IBM Tivoli Monitoring: Administrator's Guide.
In addition to Manage Tivoli Monitoring Services, the TEPS/e Web browser is also used but only for completing the portal server configuration. If your Tivoli Monitoring environment is a UNIX® or Linux environment, see the Linux or UNIX: Configuring user authenticationsection in the IBM Tivoli Monitoring Installation and Setup Guide to configure the Tivoli Monitoring LDAP user authentication.
The associations (bindings) that are required to use an external LDAP for user authentication are accomplished during Tivoli Monitoring configuration. The configuration procedures and steps for monitoring server and portal server LDAP user authentication are the same for all LDAP implementations (such as Active Directory and IBM Tivoli Director) but the configuration values (parameters) input vary. These differences result from the differences within the LDAP implementations. The most pronounced differences are the syntax for Distinguished Names of objects within the Directory. Additionally, the LDAP schema differences between LDAP implementations and any LDAP schema customizations will have a high impact on the Tivoli Monitoring LDAP user authentication configuration values (parameters) provided. The configuration uses all information provided to connect, bind, query, and filter from a specified LDAP base, within the targeted LDAP directory for Tivoli Monitoring user authentication.
The configurations of monitoring server and portal server LDAP user authentication are separate operations that you can enable and disable independently. Note that the steps for configuring monitoring server LDAP user authentication are not the same as portal server user authentication and the other way around.
This document and the Tivoli Monitoring documentation make the assumption that you have a working Active Directory environment. Additionally, this document assumes a familiarity with Active Directory, including these concepts:
- Organizational Units (OUs)
- ADSI Edit
- Group Policy Management
- User Administration
- AD User Object Schema
This document uses AD to refer to Microsoft Active Directory.
This document also assumes that you have installed the monitoring server and portal server and that you are familiar with Tivoli Monitoring user administration. See the User administration section of the IBM Tivoli Monitoring Administrator's Guide for creating and configuring Tivoli Monitoring users.
In planning for your AD administration, you must first determine which LDAP users will require monitoring server and portal server authentication. Then create an OU hierarchy that will contain your users. This step will facilitate a base name directory search that limits the search time and increases the performance of Tivoli Monitoring to LDAP user authentication. A sample user hierarchy is shown in Figure 1 that includes an OU=ITMUsers hierarchy with ITMtepsUsers and ITMtemsUsers containers that works very well for clarity and performance. The LDAP base to search for monitoring server users to authenticate is CN=ITMtemsUsers,OU=ITMUsers,DC=ad,DC=com. The base for searching portal server users to authenticate is CN=ITMtepsUsers,OU=ITMUsers,DC=ad,DC=com.
Figure 1 - Monitoring server and portal server OU AD structure_
You must also be aware of your AD 'User' Object/Attribute schema. This information is required for knowing how to code your monitoring server LDAP filter configuration and for portal server TEPS/e Repository Security Login Property. Figure 2 shows the User Account settings for one of the ITMtepsUsers. This portal server user also must be defined in the Tivoli Enterprise Portal (see the User administration section in the IBM Tivoli Monitoring Administrator's Guide). The TEPS/e portal server LDAP user authentication configuration requires that you specify the Login Property (AD User Object Attribute) that will contain the matching user name. Figure 3 presents the AD User class instance for user llassite. Use uid' as the TEPS/e portal server LDAP user authentication property to match your portal server user accounts. Edit your AD User/uid attribute for the llassite user and set the uid=llassite so that the portal user account llassite is matched against uid=llassite in the CN=Lin Lassiter,CN=ITMtepsUsers,OU=ITMUsers,DC=ad,DC=com LDAP object that can be found by searching the Directory beginning at the CN=ITMtepsUsers,OU=ITMUsers,DC=ad,DC=com base.
Figure 2 - Portal user properties_
Figure 3 - uid=llassite user class instance_
Figures 1 - 3 are provided to give you an idea of the properties within AD that are used and referenced for LDAP Authentication. Knowing where the LDAP users are located within AD (base to query/search for Tivoli Monitoring users in the Directory) and the user schema (the 'user object' attribute that contains the exact user name used for authentication) are critical to successful configuration of monitoring server and portal server LDAP user authentication configuration.
Portal server user account permissions, applications, Tivoli Monitoring views, and Tivoli Monitoring groups continue to be managed within the Tivoli Monitoring User Administration tooling as shown in figure 4.
Figure 4 - Portal server user authorities_
LDAP user authentication is available only for individual users. The enablement of LDAP authentication at the individual Tivoli Monitoring user level of granularity ensures maximum flexibility on both the Tivoli Monitoring and LDAP per user account basis. Tivoli Monitoring user groups cannot be enabled for LDAP authentication.
Scripting can be employed to maintain automated synchronization of AD and Tivoli Monitoring users. AD user account data collection scripts can ensure that AD account modifications (users added/deleted) are reflected back into the Tivoli Monitoring portal users using the tacmd CLI command to update portal server users.
Plan and create Active Directory monitoring server and portal server users.
Create and configure the portal server user accounts and permissions through the Tivoli Enterprise Portal (portal) 'Administer Users' interface or through the tacmd command. These user accounts use LDAP for authentication so the user IDs must exactly match the AD user (attribute chosen in Figure 3).
Enable and configure Tivoli Monitoring through the TEPS/e to enable portal server LDAP user authentication as needed.
- Enable and configure monitoring server LDAP user authentication as needed.
Complete the following steps to create AD users:
(Optional) Create an OU hierarchy for monitoring server and portal server users (Figure 1)
MMC snap-in ADSI Edit
Create the monitoring server and portal server users and groups in AD (Figure 2)
MMC snap-in AD users and computers
Apply desired user and group policies for AD users and groups
MMC snap-in for GPO
No Tivoli Monitoring and LDAP user synchronization is currently available. User accounts can be synchronized with scripting. AD scripting can be added for maintaining an awareness of user account modifications (limited to the OU that is applicable to Tivoli Monitoring). These detected modifications can then be made to the Tivoli Monitoring users through the tacmd command and to the AD users with scripting. A user synchronization script must run as a scheduled action to ensure that Tivoli Monitoring and AD user synchronization is performed as frequently as your environment requires.
Each portal server AD account previously created requires a matching Tivoli Monitoring portal user account. The portal user ID must be an exact match for the AD portal server user object attribute field planned for use within the TEPS/e configuration (Figure 3).
Configure all required permissions, applications, Tivoli Monitoring views, and Tivoli Monitoring groups for user account operations within Tivoli Monitoring. The portal user account permissions, applications, Tivoli Monitoring views, Tivoli Monitoring groups will not be available nor will they translate from Tivoli Monitoring to AD (Figure 4). Do not use the default sysadmin account for LDAP. The sysadmin account can be reserved for local monitoring server 'Security:Validate User' Authorization (leaving a non-LDAP method for accessing the monitoring server and portal server.
Note: The AD Schema User Object can be updated to contain mapping attributes of the Tivoli Monitoring user permissions, applications, and views into AD. These 'new' schema attributes can be leveraged to assist with both AD Tivoli Monitoring user synchronization and AD management of Tivoli Monitoring portal server user properties through AD scripting and the tacmd command.
For example, create Tivoli Monitoring "User1" user and Active Directory "User1" user. Notice that these user names are identical. Portal user names are limited to 10 characters dictating that the AD user names also cannot exceed 10 characters.
User name and user description are free from, but try to match the user name and user descriptions that you already created in AD for good form (Figure 5). The Distinguished Name is critical to binding the Tivoli Monitoring user ID to the LDAP user account based on the TEPS/e LDAP configuration. This point is discussed later. For now, select the UID=userid,O=DEFAULTWIMITMBASEDREALM.
Figure 5 - Portal Create New User window
Portal logon troubleshooting information is available in the administrator's guide.
Now that the portal server users have been created with the desired Tivoli Monitoring permissions, and these same user IDs exist within AD, you must enable Tivoli Monitoring LDAP authentication for the portal server users. First use the TEPS/e Web browser interface to set the portal server LDAP configuration Repository and AD Base name configuration. The steps for TEPS/e configuration are available in the administrator's guide.
Starting the TEPS/e administration console
Ensure that you have completed the TEPS/e enable and password setting steps if you are having issues with accessing http://localhost:15205/ibm/console. Also, the TEPS/e interface must be enabled after each restart of the portal server only if you want to use the TEPS/e interface. The enable of TEPS/e controls only the TEPS/e interface enablement and not the portal LDAP enablement. Log information for this activity can be found here:
UNIX and Linux systems
Observing the following notes, perform the steps in the Configuring an external LDAP data server.
Step #1 (Figure 6)
Figure 6 - Security → Secure administration, applications, and infrastructure_
Do not change the Realm Name. Accept the default. Realm Name refers to an IBM WebSphere® realm but, this concept does not exist within Tivoli Monitoring. Accept the default for this value and continue (Figure 7).
Figure 7 - Accept these default values
Enter your 'Repository Identifier' name on this configuration panel. Choose a descriptive name. The 'Repository Identifier' becomes a reference label for a configuration container within the TEPS/e that holds your LDAP Server information, your LDAP Bind Account password, and your LDAP 'Login Properties' (AD user class attribute name to search for matching portal server user ID (exactly Figure 3)). Additionally, in Step #8, this repository becomes associated with one or more LDAP base values/containers that portal server LDAP authentication will search. Again, as pointed out, use OU planning for this configuration step. Good OU planning restricts Tivoli Monitoring LDAP user authentication searches to the base and below. Grouping users within OUs (such as with ITMtepsUsers in Figure 1) allows for efficient base searches and Tivoli Monitoring LDAP User Authentication performance (Figure 8).
Figure 8 - Configure the repository_
- General Property - Repository identifier - This field is free form. Use a meaningful name that administrators can associate easily to the users defined within your Active Directory. In this case ITMtepsUsers is used because this will be the only repository created for portal server LDAP user authentication within this sample environment. It is also appropriate to name your repository using a convention that reflects the LDAP Bind User/pw account configured within. An example for this case might be to use a derivative of a Forest Name or a Domain Name if you require different repositories to allow for configuring different LDAP Bind User/pw to meet your requirements.
- LDAP Server Property - Directory Type - The AD Forest is running at the 2003 level. The value provided here must match your forest level. The sample Forest is running at an AD 2003 level.
- LDAP Server Property - Primary Host name - A Domain Controller within the AD Forest that is hosting the user accounts you created earlier for monitoring server and portal server LDAP user authentication. Your choice here should be driven by the hierarchy level within the forest that owns the Tivoli Monitoring users OU. Give consideration to your selection here in light of possible issues with Tivoli Monitoring LDAP authentication because of the AD connectivity or replication failures of your AD user objects.
- LDAP Server Property - Port - AD LDAP default port value is 389. Match this value to your LDAP environment port usage.
- LDAP Server Property - Failover server used when primary is not available - Additional AD LDAP (DC) servers can be added here to compensate for any replication or connectivity issues. This value should be completed with failover DCs (preferably with GC roles).
- LDAP Server Property - Support referrals to other LDAP Servers - This is your choice. Consider whether your environment is closed or open (no DCs within your secure zone).
- Security - Bind distinguished name - The user specified here must have sufficient authority (applied policy) for searching the AD directory base (that will be associated with the repository in Step #8). This user is the account that will connect, bind, and query collecting the specified 'Login Properties'. This value can be omitted if anonymous users can search the registry. The example uses CN=Administrator,CN=Users,DC=ad,DC=com but this is not absolutely required if the user exists within the CN=Users,DC=ad,DC=com container for AD. However, it is better to be specific using a complete distinguished name.
- Security - Bind password - ********** - The password for the 'Bind distinguished name' account mentioned previously.
- Security - Login properties - This configuration property is critical for A in that this is the name of the attribute within the AD Name object that is used to reflect exactly the Tivoli Monitoring portal user name (Figure 3).
- Security - Certificate - The default value of 'EXACT_DN' is set for searching AD and matching on an exact DN. Keep this default value.
- Security - Certificate Filtering - Selecting 'CERTIFICATE_FILTER' for the 'Certificate' field (above) requires LDAP filter parameters. These parameters are used to map attributes within the client certificate to entries within the LDAP directory.
Security - Require SSL communications - Select if you desire SSL LDAP communications. Select the radio button for the following options that apply to your SSL implementation. SSL is beyond the scope of this document.
- Centrally Managed
- Use specific SSL alias
Step #8 (Figure 9):
Now that you have a repository configured, you must add the Base entry as a starting point to search for the AD-defined portal server users OU. Multiple Base entries can be defined for your repository if you require. Multiple Base is required only if you have defined AD portal server users in multiple directory base locations (multiple OU hierarchy). The information provided in this panel for the '' property is reflected back into the Tivoli Monitoring User Distinguished Name choices (Figure 12). This field is made available from within the TEPS/e portal server configuration that is available to associate the Tivoli Monitoring portal-defined user ID to an LDAP connect, bind, query, and select (login properties from step #5).
The '' property is freeform and is TEPS/e configuration DN. Use the O=DNofChoice convention_._ Your choice of DN here should be meaningful for its relationship to your AD-defined portal server users base container (shorter is better).
The examples within have assigned O=ITMtepsUser for clarity when viewing the Tivoli Monitoring users Distinguished names in the 'Administer User' interface (Figure 12). Admittedly the example is redundant by having the repository name and the base DN as very similar but it is very clear you are configuring this repository and base for accessing and binding the AD portal server-defined users.
Note: The view presented in Figure 12 is only current with the configured TEPS/e values if the portal server service is recycled.
Figure 9 - Adding a base entry to your realm (associated with a repository)_
You must save your TEPS/e configuration work (Figure 10). Also, while configuring your Repository and Base settings you will need to press OK for verifying your configuration settings. Pressing OK or Apply, will connect/bind and query the AD LDAP using your configuration settings. If there is an issue, the configuration panel will return with a red formatted message like (Figure 11). Any issues must be corrected before saving your configuration.
Figure 10 - Save your TEPS/e configuration into the master configuration_
Figure 11 - OK/Apply returns error for setting the Login Properties to myAttribute. This attribute does not exist within the user objects of the LDAP_
Figure 12 - Portal server Administer Users window - Distinguished names resolved to the base names configured within TEPS/e for the configured repositories (compare the values presented here with those shown in Figure 1)_
The administrator's guide provides the steps required to associate the portal server IDs to distinguished names made available by the previous configurations steps performed within the TEPS/e. Be aware that as soon as the TEPS/e configuration is completed and saved, the portal server service must be recycled before you can see the TEPS/e configured users listed as distinguished names (Figure 12). The available distinguished names relate directly to the TEPS/e repository associated 'Base' configuration property ''.
To display all available distinguished names, first delete any entry contained in the 'Distinguished Name:' field and then select the Find button. All configured Realm - Repository - Base '' are displayed with the users that were returned by performing a query in Tivoli Monitoring against AD using the 'Login Properties' value. These users are displayed with their TEP/e CN format(Figure 12). The portal server 'Distinguished Name' drop down list can provide only 100 items. In cases where you have greater than 100 'Distinguished Names' to display, you can overtype the user DN for association of the desired DN.
Option: The AD LDAP configuration steps required that the portal server user IDs (not in AD) be created prior to the configuration of TEPS/e. Optionally, the creation of portal server user IDs can wait until after the AD user IDs and TEPS/e configuration is completed. The advantage here is that you can 'Create User' in the 'Administer Users' interface while having access to the Distinguished Names to ensure the User ID you assign matches the available Distinguished Name.
The administrator's guide provides the steps required to enable portal server LDAP user authentication. Additional comments are provided here for specific steps within this process.
Step #6 (Figure 13)
LDAP Base - Enter an LDAP Base that gives you visibility to all required OU hierarchies that contain your AD defined users.
LDAP bind ID - Enter an LDAP ID that can access your AD OU hierarchy for locating your AD-defined portal server users.
Figure 13 - Portal server LDAP enable configuration panel
This topic is outside the scope of this document. Additional information can be viewed in the documentation here (see step 10): Configuring SSL communications between the Tivoli Enterprise Portal Server and LDAP server.
The configuration for the monitoring server is completely separate from the portal server. TEPS/e is not involved. None of the portal server LDAP configuration or enablement affect the monitoring server LDAP configuration or enablement. Monitoring server users are not required to be created nor exist within the portal server 'Administer User' users. Tivoli Monitoring 'Administer User' monitoring server users are required only if you want to have monitoring server users that can be authenticated using (Step 3) Security:Validate User.
The documentation provides the steps required to enable monitoring server LDAP user authentication. Additional comments are provided here for specific steps within this process.
Monitoring server LDAP configuration allows only one LDAP base and one LDAP user filter (to query the LDAP for user ID attributes). AD OU planning is recommended for creating the base and OU hierarchy that best meets your requirements. Use a base that limits Directory subtree searches while maximizing AD LDAP user Authentication performance (Figure 1- ITMtemsUsers).
Step #5 _(Figure 14):
Enter required LDAP user filter - This defines the attributes that are queried and collected for monitoring server LDAP authentication. The monitoring server ID used for monitoring server login (tacmd login -s w2k31 -u Tabitha -ppassword) is checked against the matching AD-filtered user for authentication.
LDAP user filter - (Examples):
This filter queries the AD Directory collecting all User objects from the specified Base. The userPrincipalName attribute values returned by the query will be parsed by the string %firstname.lastname@example.org causing a comparison of the TEMS user ID with only the %v substitution portion of the userPrincipalName (where userPrincipalNameemail@example.com | userPrincipalNamefirstname.lastname@example.org == tabitha).
uid=tabitha | uid=%v == Tabitha
LDAP base - Enter an LDAP base that gives you visibility to the OU container that contains your AD-defined monitoring server users.
LDAP bind ID - Enter an LDAP ID that can access your AD OU hierarchy for locating your AD-defined portal server users.
LDAP bind password - The LDAP bind ID password
LDAP port name - This value is set for the default AD LDAP port. Enter your LDAP configured port number.
LDAP host name - A Domain Controller within the AD Forest that is hosting the User accounts you created earlier for monitoring server and portal server LDAP user authentication. Your choice here should be driven by the hierarchy level within your forest that owns the Tivoli Monitoring users OU. Give consideration to your selection here in light of possible issues with Tivoli Monitoring LDAP authentication because of AD connectivity or replication failures of your AD user objects.
Figure 14 - Monitoring server LDAP configuration panel
Use this tool for viewing your user object attributes and confirm that the attributes you are specifying for portal server 'Login properties' and monitoring server attributename=%v substitution parameter are defined and available.
Use this tool to validate monitoring server and portal server LDAP configuration base settings. This tool allows you to connect, bind, and query your LDAP (Figure 15).
Figure 15 - LDAP query results
This sample demonstrates verification of a configuration using:
LDAP filter object = (&(objectCategory=user)(uid=%v))
LDAP base = CN=ITMtepsUsers,OU=ITMUsers,DC=ad,DC=com
-- OR --
This sample demonstrates verification of a configuration using:
LDAP base = CN=ITMtepsUsers,OU=ITMUsers,DC=ad,DC=com
Login properties = uid