Up-take of digital

if (sCase == UPPER_CASE)

secondAttribute = secondAttribute.toUpperCase(locale);

else if (sCase == LOWER_CASE)

secondAttribute = secondAttribute.toLowerCase(locale);

}

baseidentity = firstAttribute + secondAttribute;

}

if ((baseidentity == null) || (baseidentity.length == 0)) { var givenname = subject.getProperty("givenname");

if (((givenname != null) && (givenname.length > 0))) givenname = givenname[0];

if (givenname == null || givenname.length == 0) givenname = "";

else

givenname = givenname.substring(0, 1);

baseidentity = givenname + subject.getProperty("sn")[0];

}

tf = IdentityPolicy.userIDExists(baseidentity, false, false);

if (!tf) {

return baseidentity;

}

while (tf) { counter+=1;

identity = baseidentity + counter;

tf = IdentityPolicy.userIDExists(identity, false, false);

}

return identity;

}

return createIdentity();

If the identity policy generates a user ID with a null value, Tivoli Identity Manager attempts to form a user ID by using the first letter of the user’s given name, concatenated with the value of the user’s family name, retaining the existing case.

4.5.2 Password policy

All accounts have passwords. Account passwords can be centrally managed by their owners or administrators using the Tivoli Identity Manager Web interface.

Also, passwords can be synchronized. The synchronization can be applied to all accounts associated with a user or selected accounts. For most passwords, this is a one-way synchronization. Tivoli Identity Manager sets the password and pushes it to the managed targets. Tivoli Identity Manager cannot accept a

Chapter 4. Implementation 117 password change request from a target and push this to all associated accounts.

The exception to this is the Microsoft Windows NT and Active Directory password synchronization function, the Reverse Password Synchronization for Tivoli Access Manager WebSEAL agent, which intercepts a password change and passes it through Tivoli Identity Manager and any LDAP with its changelog enabled.

A password policy sets parameters (password rules) that all passwords must meet, such as length and type of characters allowed and disallowed. Just as certain platforms have strict login ID creation requirements, these platforms can also have strict password requirements. Your organization might also have a strict password policy. Tivoli Identity Manager provides several built-in password rules that can be enabled or disabled when creating a password policy for a particular platform. In addition to the built in password rules, a Tivoli Identity Manager administrator can create a new customized rule, a customized generator, or a combination of both.

A customized rule for generating passwords using the Tivoli Identity Manager Server can be accomplished by creating a Java class by implementing the com.ibm.passwordrules.Rule interface. The class must be registered in passwordrules.properties. Optionally, a label for the customized rule name can be add in CustomLabels.properties. If the customized label is not defined in CustomLabels.properties, the fully qualified name of the customized java class is shown on the interface forms.

A customized password generator for creating passwords using the Tivoli Identity Manager Server can be accomplished by creating a Java class by implementing com.ibm.passwordrules.PasswordGenerator interface. Again, the class must be registered in passwordrules.properties.

After users are granted access, they can change their passwords in Tivoli Identity Manager. The new password must conform to the rules of the password policy.

Users can view the rules of the password policy for each system by clicking the View Password Rules button.

Based on the needs of the organization, password policies can be applied for any of the following items:

򐂰 Only one service instance or more than one service instance

򐂰 All service instances of only one service type or multiple service types

򐂰 All services, regardless of service type

Similar to identity policies, a password policy should be placed at the same level or higher in the org tree than the services to which they will be applied, and the scope can be set as single level or subtree.

If a password policy exists for all services, other policies can still be added.

However, only one password policy can be specified for each service type or each instance of a service type. If a password policy exists for a service type, as well as password policies for different instances of that service type, the more specific password policy overrides all others (for example, a password policy for a Windows AD service instance overrides a password policy for the Windows AD service).

It is possible to have two or more services that have very different password requirements. You might be able to come up with one password policy that will meet all of the requirements, but it might be too weak for your corporate security guidelines. In this case, you need to create a password policy that applies only to this “weak” service, and users will have to pick a different password for this specific service.

If users have accounts on multiple systems that have differing password policies, they can select all of their accounts and view the combined password rules. This will show the user what components will make a password that is acceptable across all systems. If the policies are very different, it is possible that there will be no common password rule that can work for the selected accounts. In that case, the user has to select them individually to change the passwords.

In addition, when password synchronization is enabled, Tivoli Identity Manager combines policies for all accounts that are owned by the user to determine the password to be used. If conflicts between password policies occur, the password might not be set.

Password dictionary

An password dictionary contains a list of words, stored in the directory server, that cannot be used as passwords.

This dictionary can be modified through an LDAP browser by creating erDictionaryItem entries under the erDictionaryName=<password> entry or by importing an LDIF file with the entries listed into the directory server. For more details, refer to the IBM Tivoli Identity Manager Information Center:

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=

/com.ibm.itim.doc/welcome.htm

After the password dictionary is populated with the desired words, the password policies must be modified to use the dictionary. Upon importing the LDIF file, select the “Do not allow in dictionary” option on the Rules page of password policies.

Chapter 4. Implementation 119

Forgotten password settings

Tivoli Identity Manager uses a Forgotten Password Settings challenge or response function to verify users’ identities if they have forgotten their Tivoli Identity Manager passwords. The challenge questions can be:

򐂰 User-defined: The user can create a unique Password Challenge Response questions and answers.

򐂰 Admin-defined: The user can create Password Challenge Response answers to predefined questions that are determined by the Tivoli Identity Manager administrator.

When a user logs in to Tivoli Identity Manager for the first time, the user enters the challenge questions (if configured) and responses. On subsequent logins to Tivoli Identity Manager, the user can select a “Forgot password” option and a subset of the challenge responses are used to verify the user.

Also, Tivoli Identity Manager can be configured to respond to lost password behavior in two ways:

򐂰 Reset and e-mail password

Select this option to configure the system to send a new password to the e-mail address associated with the account.

򐂰 Log in to system

Select this option to configure the system to log the user in to the system.

Responses (answers) are saved in the directory server as non case-sensitive by default, if you want answers to be case-sensitive, change the value for

enrole.challengeresponse.responseConvertCase from lower to upper. Also the answer can be preserved in original writing if the value is set to none.