After Upgrading OID 10g Metadata Repository DB, Unable To Add New OID Users Or Update Users Passwords / Can't contact LDAP server / Error / Cannot modify user : <host:sslport>; socket closed
(Doc ID 1524667.1)
Last updated on OCTOBER 17, 2019
Applies to:
Oracle Internet Directory - Version 10.1.2.3 and laterOracle E-Business Suite Technology Stack - Version 12.1.3 to 12.1.3 [Release 12.1]
Information in this document applies to any platform.
Symptoms
Oracle Internet Directory (OID) 10g, e.g., 10.1.2.3 or 10.1.4.
After upgrading the OID Metadata Repository (MR) Database (DB) to 11g, everything works correctly except modifying any user's userpassword or creating a new OID user entry returns the error:
Modifying a userpassword via ldif file and ldapmodify command line:
Adding new user entry via ldif file and ldapadd command line:
Attempting to modify a user's userpassword via Oracle Directory Manager (ODM/oidadmin) appears work and returns no errors, but a subsequent ldapbind fails indicating the change did not take effect, e.g.:
ldap_bind: Invalid credentials
Trying via OIDDAS url returns:
Cannot modify user : <OID_HOSTNAME>:<PORT>; socket closed
Able to modify any other attribute without error, such as telephoneNumber, mail, etc., just not able to modify userpasswords or add new users entries (with userpassword attribute added).
Additional information/troubleshooting:
An oiddiag report shows no problems or inconsistencies.
No meaningful errors in ssoServer.log or OC4J~OC4J_SECURITY~default_island~1 log.
OID debugged log shows the following errors:
2013/01/07:10:32:12 * DispatcherController:0 * Starting OIDLDAPD Server, PID=xxxxx
2013/01/07:10:32:12 * DispatcherController:0 * Starting OIDLDAPD Server, PID=xxxxx
2013/01/07:10:55:08 * ProcessDispatcher:1 * SendPort: Error while writing to the other end of communication endpoint
2013/01/07:10:55:08 * DispatcherController:0 * Starting OIDLDAPD Server, PID=xxxxx
2013/01/07:10:56:24 * ProcessDispatcher:1 * SendPort: Error while writing to the other end of communication endpoint
2013/01/07:10:56:24 * DispatcherController:0 * Starting OIDLDAPD Server, PID=xxxxx
2013/01/07:11:01:14 * DispatcherListener:2 * WARNING : DispatcherListener : Shutting down
2013/01/07:11:01:20 * DispatcherController:0 * WARNING : DispatcherController : OiD LDAP server exiting with status 0
......
Most oidstack files generated are empty (0 bytes), but a couple include unreadable / nonprintable characters (seems garbled), for example:
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
------------------ -------- -------------------- ----------------------------
<unreadable / garbled characters>
cn=common group attributes,cn=groups,cn=oraclecontext,dc=<COMPANY>,dc=com
<unreadable / garbled characters>
cn=common group attributes,cn=groups,cn=oraclecontext,dc=<COMPANY>,,dc=com
Note: The DN referenced may be different, such as cn=odisgroup,cn=dipadmins,cn=directory integration platform,cn=products,cn=oraclecontext.
The corresponding oidldapd01s<PID>.logs shows no errors.
Comparing the entire schema and oiddiag configuration entries with a working OID shows no differences.
Disabling OID password policy for both realm and root, or setting orclpwdencryptionenable to 0, and restarting OID makes no difference.
Workaround:
Deleting the orclcommonusersearchbase from under the realm configuration entry DN of "cn=Common,cn=Products,cn=OracleContext,,dc=<COMPANY>,dc=com", then restarting OID resolves the problem. However, unable to login to SSO or OIDDAS url's afterwards, so this is not a feasible workaround. (Adding the entry back then allows SSO logins to work again.)
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
| Symptoms |
| Cause |
| Solution |
| References |