IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Administrator's Guide > Enable user authentication > LDAP user authentication using Microsoft Active Directory > User scenarios
IBM Tivoli Monitoring, Version 6.3 Fix Pack 2
Authenticate portal server userids with Microsoft Active Directory
In this scenario, you configure the portal server to use server to authenticate users because you want to use single signon with other applications or you want the Tivoli Enterprise Portal users to login with userids longer than 10 characters.
The site attempted to use the portal sever's Manage Tivoli Enterprise Monitoring Services utility or itmcmd command line interface to configure the LDAP authentication. This proved unsuccessful because the built-in authentication mechanism expects to look up an LDAP field named uid; this customer's Active Directory LDAP records have no uid field.
The rest of this section documents the user authentication steps you should follow via the TEPS/e Administration Console, the portal sever's built-in eWAS server that defines the custom LDAP user mappings for Tivoli Enterprise Portal access at this company.
Required LDAP environment information
To authenticate users against the customer's Active Directory LDAP user registry, several pieces of information are required:
- The type and location of the LDAP information store.
- The retrieval method for that information—notably whether or not to use SSL.
- A Bind ID and Password, a userid/password combination that the system will use to log into the LDAP store and look up user accounts.
This ID must be in full LDAP Distinguished Name format.
- The Login Properties to use—namely which LDAP field to look up. This field needs to be something within the LDAP information store that uniquely identifies a user in the environment.
The instructions in LDAP user authentication through the portal server assume you have the uid field available; this proved not to be the case with this customer's LDAP directory.
- An LDAP Base, the full LDAP Distinguished Name of a Base entry in the LDAP user registry.
In this example, your site's Active Directory administrator provided the following LDAP information:
- LDAP type: Microsoft Active Directory Server version 2003; location: Hostname adhost.company.com
- Port to use: 636 (which indicates that SSL is required for connection)
- Bind ID of svc.tivolisec@company.com, along with the appropriate password
- The Login Properties field to use: the user's email address
- The LDAP Base: DC=US,DC=GLOBAL,DC=company,DC=COM
Despite having all the necessary connection information, every attempt to connect to the LDAP user registry fails. You can use the LDAP utilities described in Active Directory LDAP verification tools to look up and verify your connection information and determine why every connection attempt failed.
In this example, two utilities are used: LDP.exe and ldapbrowser. These utilities show you that SSL communication is not required in this customer's environment; thus, connecting at the normal unencrypted LDAP port of 389 is valid. The tools also reveal that the full LDAP Distinguished Name associated with the svc.tivolisec@company.com address is CN=svc.tivolisec,OU=ServiceAccount,DC=us,DC=global,DC=company,DC=com.
Once all these entries have been validated, it is time to use the TEPS/e Administration (eWAS) tools to define the LDAP lookup parameters for Tivoli Monitoring user administration.
- Enable TEPS/e administration
- Define the LDAP user registry in the Integrated Solutions Console
- Add your LDAP user registry to the eWAS realm
- (Optionally) test the LDAP lookup within TEPS/e
- Define a test userid using portal server user administration
Parent topic:
User scenarios