Data problems

This section describes solutions to problems with data.

If ISIM data is transferred from one location to another location and the root suffix or tenant value case sensitivity is not maintained it causes problems

Cause:Any time ISIM data is transferred from one place to another location a possibility exists that the root suffix or the tenant values are defined in a different case. When this situation occurs, the result is strange, extraordinarily undesirable behavior. Unfortunately, the behavior is not consistent. The effects of this problem produce different results that depend on the situation..

Data confusion begins with inconsistent case. It usually happens when a different case is used when you define the root suffix or tenant settings. This causes a data integrity issue..

For example, some records might specify the root suffix as dc=customer,dc=com and as dc=Customer,dc=com.

erglobalid=4428535020820737843,ou=0,ou=accounts,erglobalid=00000000000000000000,ou=customer,dc=customer,dc=com
erService=erglobalid=916002417090758505,ou=services,erglobalid=00000000000000000000,ou=customer,dc=Customer,dc=com 

Unfortunately, this same problem appears to produce different symptoms..

In one case, accounts were incorrectly deprovisioned, and removed when they must not. The root cause of this problem, is that the cases of some service dn's that are stored in accounts' erService attributes are not the same dn's that are stored in provisioning policy erTarget or erEntitlement attributes. During policy enforcement, you get the service dn's of a user's accounts and do case-sensitive compares with the services that were targets of policies that are applied to the user.

The case-sensitive compare does not see a match, so you delete the account..

In another case, some user's services or accounts are not displayed in ISIM even though they have valid, active accounts on those platforms..

It is not possible to determine how many different symptoms can appear because of this type of problem. There are many different places in ISIM data where a DN is stored. In every situation that might compare that stored DN with an object's actual DN, there is potential for trouble..

Solution: Apply the same case to the root suffix and tenant values when you transfer data from one location (IBM Security Directory Server) to another..

If this problem has already happened, where the data is in mixed case, it can be corrected, but some effort is required. This task is best accomplished by using a tool that is created by a member of the IBM consulting team. Contact Second-Level Support for further assistance.

Error message: An integer field contains a non-integer value

We cannot enter a value greater than 2147483647 in the UID number field of the Account information window. This problem is a Java™ limitation. The following message is displayed:

CTGIMU656E: An integer field contains a non-integer value.

The message can be misleading when you enter an integer greater than 2147483647.

Cannot read library files

If ISIM Server does not have permission to read library files, verify the files have the correct permission. If necessary, make the appropriate changes to the file permission.

Data input problems

Data input problems typically occur when users define custom data structures, such as new service types, in the directory structure, or when users install new adapters. If we cannot enter data for a custom class such as a service type, check ISIM Server and the IBM Security Directory Server logs. LDAP messages such as object error 32 are typical. They indicate missing data for required fields or problems interpreting the schema.

Passwords cannot contain leading or trailing spaces

Security Identity Manager trims leading and trailing spaces for passwords. If the root user password for a managed resource includes a leading or trailing space, Security Identity Manager cannot connect to it.

The root password to access the associated managed resource must not have any leading or trailing spaces. The password cannot be a single blank space.

Cannot delete an organizational unit (OU)

When deleting an organizational unit (any unit in the organization), you must delete all dependent units before deleting the OU. Sometimes, dependent units might exist even though they are not displayed in the organizational tree. If we do not delete the dependent units, the system displays the following message:

Dependent Unit(s) exists. Remove all dependent Unit(s) first, then Delete.

Complete these steps:

1. Search the IBM Security Directory Server for dependencies using the following command:

   erparent=OU-DN

   where OU-DN is the distinguished name (DN) of the OU.
2. Remove any discovered dependencies.

3. Delete the OU using the user interface.

Users cannot obtain their new passwords

If the following settings and conditions apply, the affected users cannot receive passwords reset by an administrator in the user interface:

• Some users and their supervisors do not have email addresses.
• Users cannot change their passwords.
• Challenge-response authentication is enabled.

If these conditions apply and a user clicks the Forgot a password? link to reset a password:

• The user cannot obtain the password through email or from the help desk assistant.

• The help desk assistant can reset the password, but the password cannot be delivered to the recipient.

• The user must contact the help desk to obtain the new password.

To avoid this problem, ensure that the email notification function is working and that all affected users and their supervisors have email addresses. As an alternative, users can change their passwords according to the applicable password policy.

User cannot change a password and the TRANSACTION_ROLLEDBACK error is displayed

If a user receives the TRANSACTION_ROLLEDBACK error when changing a reset password, stop and start ISIM. If it does not correct the problem, ensure that both IBM Security Identity Manager and the DB2 Universal Database servers are running. To stop and start ISIM, do these steps:

1. Log on to th IBM Security Identity Manager virtual appliance console.

2. From the Server Control widget on the Appliance Dashboard, do these steps:

   1. Select Security Identity Manager server and click Stop.

   2. Select Security Identity Manager server and click Start.

Cannot determine if data synchronization is running or the status of the last synchronization

We cannot determine if data synchronization is running or determine the status of the last synchronization. When we select a report type in the administrative console, the status is displayed as the Data Validity field in the Options window. The following possible values determine the state of the data synchronization:

• No Data synchronized
• In progress
• Invalid
• Date and time when last synchronization completed

Import backup directory information with LDIF fails

Using LDAP Data Interchange Format (LDIF) files to import backup directory information can experience problems if the system is not stopped or workflows are incomplete.

When we use LDIF files to import backup directory information, stop the application servers. If the LDIF import modifies workflows or operations, complete all workflows before you perform an LDIF import.

For more information about LDIF files, see the IBM Security Directory Server documentation.

Multiple access control items are ignored if the first 255 characters are the same

If you define more than one access control item (ACI) on the same target and at the same organizational level and the first 255 characters of every ACI name are identical, only one ACI is staged into the ACI table. Reporting ignores the remainder of the ACIs. An ACI report shows only one ACI . The trace.log file displays the following error message:

com.ibm.websphere.ce.cm.DuplicateKeyException: ORA-00001: unique constraint 
(ENROLE.SYS_C003110) violated

Do not define multiple ACIs with the same first 255 characters on the same target and at the same organizational level.

The Requestee column displays an unexpected value of the common name in a person during self registration

During self registration, the Requestee column of the common name in a person does not display an expected value.

To correct this problem, complete these steps. The value of Name Attribute in Configuration > Entities > Person must be set to sn. If the value of Name Attribute is changed back to cn, remove the script node.

1. Log on as itim manager.

2. Click Configuration.

3. Click Entity Type.

4. Select Person in the menu.

5. Click selfRegister as the operation.

6. On the selfRegister workflow, insert a uniquely named script node between the Start and the selfRegister Approval nodes.

7. Double-click the new script node to display Properties: Script Node window.

8. Enter the following Java script:

   var personData = person.get(); 
   var snValue = personData.getProperty("sn")[0]; 
   process.setRequesteeData(snValue);

9. Click OK.

Parent topic: Troubleshooting ISIM Server problems