Junction Configuration Basics

The following discussion is a quick and dirty introduction to TAMeb junction configuration.  There are several chapters covering standard, transparent path, and virtualhost junctions in the WebSEAL Administration Guide.  In addition, there are a variety of switches not in the samples below, such as -s and -u for stateful junctions, and behaviors controlled via configuration files, such as inactivity and connection timeouts.  I recommend a thorough reading of the product documentation if you will have serious involvement with TAMeb.  Coming in at over 1100 pages for the WebSEAL Administration Guide alone, acceptance of my recommendation is not for the faint-of-heart.
Sample commands to create and manipulate server junctions follow.
server task <instance>-webseald-<servername>.company.com create -t tcp -A -F /opt/pdweb/etc/<name>.ltpa -Z <password> -x -h <host servername>.company.com  -p 80 -c iv-creds,iv-groups /sampleapp/secure –f

‘<instance>’ is the WebSEAL instance.  Unless changed, the first instance created is 'default'.
‘<servername>’ is the WebSEAL server.
'-t' is the type of junction (tcp, ssl)
‘-A’ and ‘-F’ are used for the LTPA key and password.
‘-x’ indicates this is a transparent path junction.
‘-h’ is for the host / target server.
‘-p’ is for the port.
‘-c iv-creds,iv-groups’ sets the TAMeb headers to be sent to the backend servers for fine-grained access decisions handled by the applications.
‘/<sampleapp>/secure’ is the junction, which for a transparent path junction must match the application server context.
‘-f’ is to force creation of the junction even if it already exists.

To add additional servers to a junction, follow the pattern of this command:

server task <instance>-webseald-<servername>.company.com add -h <host servername>.company.com  /sampleapp/secure

Creation of a virtualhost junction is similar:
server task <instance>-webseald-<servername>.bcbsnc.com virtualhost create -t tcp -h <host servername>.company.com -p 80 -z default -c iv-creds,iv-groups -v support.ibm.com vhost-ibm –f
Also similar is adding additional servers to the virtualhost junction:
server task <instance>-webseald-<servername>.company.com virtualhost add -h <host servername>.company.com vhost-ibm
Junction information can be viewed with ‘server task … show …’ and ‘object show …’ commands.
server task <instance>-webseald-<servername>.company.com show /sampleapp

object show /WebSEAL/<servername>.company.com-default/sampleapp

Enabling the TDS Group and Individual Password Policy

Tivoli Directory Server (TDS) is used to manage LDAP attributes for different systems. Among these services provided by TDS is password management. By default, Tivoli Directory Server has a global password policy which is called pwdpolicy. It controls the policy of the attribute userPassword. However, some systems require additional password policies to manage certain groups/individuals in their organization.

On default this is not enabled in TDS. The TDS password policy is disabled for group and individual specific policies. These must be configured in the TDS server to be used.

The following shows how to enable Tivoli Directory Server group and individual password policies.  

Login to the Tivoli Directory Server server command line as root
Run the following command:
For non SSL configurations:

idsldapmodify -D <adminDN> -w <adminPW> -h <hostname> -k

dn: cn=pwdpolicy,cn=ibmPolicies

ibm-pwdpolicy:true

ibm-pwdGroupAndIndividualEnabled:true



For SSL configurations:

idsldapmodify -D <adminDN> -w <adminPW> -h <hostname> -Z -K <keystore database location> -k

dn: cn=pwdpolicy,cn=ibmPolicies

ibm-pwdpolicy:true

ibm-pwdGroupAndIndividualEnabled:true

Password Policy to a Group or Individual in IBM Security Directory Server

In Tivoli Directory Server, different password policies may be employed to manage the passwords of your organization. A global password policy may be used to oversee all the passwords of the company. However, customers may want to customize their policies for specific individuals or groups. The customer might determine that some groups should have more access (e.g. administrators/staff) while others should be given less (e.g. vendors/external users). Custom TDS password policies may be associated to a groups and individuals for this purpose. The following shows how to associate a password policy to a group. Note that the same can be applied to an individual user by replacing the dn portion from the group dn to the individual’s dn.

Login to the TDS server as root
Run the following command:
For Non-SSL:

idsldapmodify -D <adminDN> -w <adminPW> -k

dn:cn=myGroup,cn=groups,dc=myCompany,dc=com

changetype:modify

add:ibm-pwdGroupPolicyDN

ibm-pwdGroupPolicyDN:cn=testPolicy,cn=ibmpolicies

For SSL:

idsldapmodify -D <adminDN> -w <adminPW> -h <hostname> -Z -K <keystore database location> -k

dn:cn=myGroup,cn=groups,dc=myCompany,dc=com

changetype:modify

add:ibm-pwdGroupPolicyDN

ibm-pwdGroupPolicyDN:cn=regpolicy,cn=ibmpolicies

Enabling Last Login and Last Password Change for Security Access Manager Users

Tivoli Access Manager users can be managed through the Web Portal Manager located in the IBM Integrated Solutions Console. When a TAM user profile is viewed in Web Portal Manager, there are two text boxes that show the Last Login and Last Password Change for a user. These are especially useful for audit purposes as they can show an administrator when the user last logged in and when his password was last changed. However, these are not automatically enabled and must be configured to be used.

Figure 1: Sample TAM User Page with Last Login and Last Password Change Enabled

To configure the Last Login and Last Password Change for users:

1. Login to the TAM Server as root
2. Edit the ivmgrd.conf file as follows:
   [ivmgrd]
   provide-last-login = yes
   provide-last-pwd-change = yes[ldap]
   enable-last-login = yes
3. Save the file
4. Restart TAM:
   pd_start restart
5. Login to WebSeal Server as root
6. Edit the webseald-default.conf file as follows:
   [ldap]
   enable-last-login = yes
7. Save the file
8. Restart WebSeal:
   pdweb restart

IBM Security Access Manager Issues with favicon.ico

Web applications are protected through junctions in Tivoli Access Manager. The application is protected behind WebSeal where its URL is configured to be accessed through the TAM junction. When a user tries to access an application protected by Tivoli Access Manager that requires authentication, the user is prompted to login. When this happens, the user is given a prompt by WebSeal to authenticate. While this happens, WebSeal stores the last URL the user was trying to access so that the browser is redirected to the correct site after login.

Most browsers are however configured to access the favicon.ico of each website first. Since the favicon.ico is located at a different URL, this would cause an error because there are no junctions configured to accommodate this. To circumvent this, a junction with unauthorized access on favicon.ico must be made in WebSeal. This is done by creating a junction for favicon.ico and associating an unauthenticated ACL to it.

Figure 1: favicon.ico junction creation

Figure 2: Example of an unauthenticated junction

Checking for the Tivoli Directory Server Effective Password Policy

Tivoli Directory Server (TDS) is used to administer LDAP for different systems. Among the TDS attributes that are managed is the user password. For this, Tivoli Directory Server has a global password policy which is called pwdpolicy. It controls the policy of the attribute userPassword.

However, other systems that work with TDS like Tivoli Access Manager (TAM) might also have their own mechanisms for password policies. The Tivoli Directory Server might also have other policies in place for specific groups and individuals. Therefore, when using multiple password policies, administrators/developers must be careful on ensuring the resulting effective password policy is accurate to their requirements as different password policies may overlap and create unexpected results.

Unfortunately, there is no way to view the policies collectively for a TDS group. There is only allowance to check for the effective password policy for a user. Nevertheless, this is still a useful tool in determining the effective password policy for Tivoli Directory Server users.

The following shows how to view the effective password policy on a given user.

1. Login to the Tivoli Directory Server (TDS) server as root
2. Run the following command (Linux):

For non-SSL:
idsldapexop -D <adminDN> -w <adminPW> -op effectpwdpolicy -d “<UserEntryDN>”
For SSL:
./idsldapexop -D <adminDN> -w <adminPW> -h <hostname> -Z -K <keystore database location> -op effectpwdpolicy -d “<UserEntryDN>”

1. View the results and confirm the correct policies are in effect

An example result is the following:

The effective password policy is calculated based on the following entries:

cn=pwdpolicy,cn=ibmpolicies

The effective password policy is:

ibm-pwdPolicyStartTime=20120214180114Z

pwdInHistory=5

pwdCheckSyntax=2

pwdGraceLoginLimit=0

pwdLockoutDuration=0

pwdMaxFailure=10

pwdFailureCountInterval=0

passwordMaxRepeatedChars=0

passwordMaxConsecutiveRepeatedChars=0