If you cannot log in to OpenSSO Enterprise, verify that you are using the correct userid and password. The Directory Administrator who reset your password should have communicated to you the temporary password for the user account.
Monitor the Directory Server's access log, during login. You should see successful SRCH and BIND operations, for the user. Example:
[15/Jul/2009:09:32:12 -0700] conn=158 op=9 msgId=269 - SRCH base="dc=sun,dc=com" scope=2 filter="(uid=idmuser1)" attrs="dn uid" [15/Jul/2009:09:32:12 -0700] conn=158 op=9 msgId=269 - RESULT err=0 tag=101 nentries=1 etime=0 [15/Jul/2009:09:32:12 -0700] conn=160 op=5 msgId=270 - BIND dn="uid=idmuser1,dc=sun,dc=com" method=128 version=3 [15/Jul/2009:09:32:12 -0700] conn=160 op=5 msgId=270 - RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=idmuser1,dc=sun,dc=com"
The string err=0 in the entries above indicates success for that operation.
After you log in to OpenSSO Enterprise , if you are not redirected to the Identity Manager page, check the following :
Be sure that your OpenSSO Enterprise web-container is using the changed or new files, that you configured above. The web-container may be using an old pre-compiled version of the default JSP files.
Be sure the IDM URLs that you embedded in the JSP files are accurate and don't contain typographic errors.
Browse through the OpenSSO Enterprise web-container logs and look for any reported errors.
Browse through the OpenSSO Enterprise debug logs, especially the Authentication and IdRepo logs, to check for any reported errors or exceptions.
Browse through the OpenSSO Enterprise Authentication debug log to determine which LDAP.xml file is being looked up, and be sure that specific file was actually modified by you. Depending upon your browser configuration for localization, OpenSSO Enterprise might be looking for LDAP.xml in a different directory. For example, you may have modified just the config/auth/default/LDAP.xml file, but OpenSSO Enterprise might be using the /config/auth/default_en/LDAP.xml file.