Oracle Internet Directory — LDAP 67 (ModifyDN), OU Move Failures, and ACI Pitfalls: a Practical Playbook You Can Run Today
If you operate Oracle Internet Directory (OID) and Directory Integration Platform (DIP) long enough, you’ll eventually hit the cluster of issues that make on-call shifts feel longer: LDAP 67 errors when a rename should have been a ModifyDN, OU moves that silently fail, and ACI rules that look fine until they don’t. This guide is the narrative I wish I’d had the first time I had to fix these under pressure. It explains why these problems happen, what to change first, and how to read the outcome so you can prove it’s truly fixed. By the end, you’ll have a working mental model, a few copy-paste snippets, and a clean routine for rolling changes through production without guesswork.
Disable → Change → Verify → Enable.
When restarts are necessary, keep the order predictable: Admin → Node Manager → OPMN (OID) → wls_ods1/2 (DIP), and reverse it to stop.
1) What breaks, and why it breaks
Most incidents start with an LDAP 67. The log line usually complains about changing a naming attribute without modifying the DN.
That’s your tell that the change went in as a regular modify when the directory expected a proper modrdn (a rename).
The second recurring pattern is an OU move that just refuses to land. In those cases, the permissions on the parents are often incomplete:
the new parent needs add, the old parent needs delete, and both sides must be browsable—otherwise DIP can’t legally perform the move.
When ACI rules are the culprit, it’s usually because one item from the real OID vocabulary—add/delete/write/read/search/compare/browse/proxy—is missing in exactly the spot you need it.
Finally, when nothing looks “wrong” but the data is obviously behind, you’re staring at a LACN↔USN mismatch: DIP missed a range of changes and needs a controlled rewind to catch up.
SSL confusion (ports, modes, or untrusted certs) and EM Agent time-zone drift round out the usual suspects; the former blocks the pipe, while the latter mostly warps your operational visibility.
2) The preflight that prevents late-night surprises
Before touching production, confirm you can represent the data you plan to sync.
If orclADUser, orclADGroup, or orclADObject are missing from cn=subschema, you’ll lose on the basics—map rules will reference attributes the directory doesn’t understand.
Verify that DIP talks to OID over the SSL listener (often 4141) with SSL_ENCRYPT, and that the OID server certificate is trusted in the DIP keystore/cacerts; a single untrusted chain link is enough to break the handshake.
Lastly, lint your profile before it bites you: run a map-rule validation to catch spacing and syntax, then run a profile connection test to surface permissions and connectivity hints.
ldapsearch -h <OID_HOST> -p 389 -D "cn=orcladmin" -w '<PW>' \ -b "cn=subschema" -s base "(objectClass=*)" "orclADUser" "orclADGroup" "orclADObject" manageSyncProfiles validateMapRules -p <ProfileName> manageSyncProfiles testProfile -p <ProfileName>
If validation fails, assume whitespace or stray tabs first; if the connection test fails, revisit SSL and ACI in that order.
3) The ACI that makes renames and moves safe
Renames under the same parent need two things: the entry must allow a write to the naming attribute (the RDN), and the parent must be browsable so the operation can be evaluated.
Cross-container moves add two more pieces: the new parent must allow add and the old parent must allow delete.
Expressing that in OID’s terms typically means granting a DIP Agents group an entry-level browse/proxy and attribute-level read/search/compare/write at each involved container, then layering in add/delete on the parents if you intend to move children across them.
dn: <TARGET_CONTAINER_DN> changetype: modify add: orclACI orclACI: access to entry by group="cn=odisgroup,cn=DIPAdmins,cn=Directory\20Integration\20Platform,cn=Products,cn=OracleContext" (browse,proxy) - add: orclACI orclACI: access to attr=(*) by group="cn=odisgroup,cn=DIPAdmins,cn=Directory\20Integration\20Platform,cn=Products,cn=OracleContext" (read,search,compare,write)
If the server throws INVALID ACI, inspect the DN carefully—spaces inside RDNs must be escaped as \20.
After applying changes, a quick ldapsearch at the target container should show the new rules in place.
ldapsearch -h <OID_HOST> -p 389 -D "cn=orcladmin" -w '<PW>' \ -b "<TARGET_CONTAINER_DN>" -s base "(objectClass=*)" orclACI
4) Put the DIT back in order—and keep a way back
Most drift I see in long-running directories comes from a missing middle layer—an OU that should exist but doesn’t.
When the physical DIT structure doesn’t match the DomainRules you configured in DIP, new users end up in the wrong branch, and renames go sideways.
The fix is mechanical but sensitive: create the missing parent, move the subtree with modrdn, and always prepare a reverse LDIF so that you can undo the change quickly if any dependent process misbehaves.
# create the missing OU dn: ou=yourdomain.com,cn=Users,dc=serv,dc=nossys,dc=net objectClass: top objectClass: organizationalUnit ou: yourdomain.com # move the subtree under the new OU dn: ou=CLGX,cn=Users,dc=serv,dc=nossys,dc=net changetype: modrdn newrdn: ou=CLGX deleteoldrdn: 0 newsuperior: ou=yourdomain.com,cn=Users,dc=serv,dc=nossys,dc=net # reverse LDIF (instant rollback) dn: ou=CLGX,ou=yourdomain.com,cn=Users,dc=serv,dc=nossys,dc=net changetype: modrdn newrdn: ou=CLGX deleteoldrdn: 0 newsuperior: cn=Users,dc=serv,dc=nossys,dc=net
Document a before/after DN map with counts and a handful of sample DNs; keep it next to the forward and reverse LDIF so rollback is deterministic.
5) Point DomainRules where the tree really is
Once the DIT is fixed, DomainRules should describe that reality.
If the AD base dc=infosolco,dc=net is supposed to land under ou=yourdomain.com,cn=Users,... in OID, say so explicitly and validate it before you upload.
Most profile breakage at this stage is still whitespace: invisible tabs and wrapped lines that sneak in during a copy/paste.
# domain mapping example DomainRules: dc=infosolco,dc=net : ou=yourdomain.com,cn=Users,dc=serv,dc=nossys,dc=net # pre-upload checks manageSyncProfiles validateMapRules -p <ProfileName> manageSyncProfiles testProfile -p <ProfileName>
6) Reconcile LACN with AD’s USN—and prove it numerically
To know whether you’re caught up, compare the profile’s last applied change number with AD’s highest committed USN. If LACN trails far behind, plan a staged rewind. Lower the number in bounded chunks, run an incremental sync, confirm that failures stay at zero and that LACN is climbing, then repeat. Big jumps are tempting under pressure, but they’re how duplicates and misses are born.
# AD high watermark repadmin /showrepl <DC-NAME> # OID profile metrics ldapsearch -D "cn=orcladmin" -w '<PW>' \ -b "orclodipagentname=<Profile>,cn=ODIP Agents,cn=Directory Integration Platform,cn=Products,cn=OracleContext" \ -s base "(objectClass=*)" \ orclOdipConDirLastAppliedChgNum orclOdipProfileMetric
If failure_count rises during a rewind, stop and revisit structure and permissions; you’re pulling old changes through a path that still isn’t legal.
7) Roll the change like a grown-up system
Production changes stay boring when you keep a tight loop. Disable the profile on all nodes so nothing races you. Fix the DIT, apply the ACI, and bring DomainRules into alignment, then lint and test the profile. If you discovered a gap, walk LACN up to present with staged rewinds; otherwise proceed. When config touches multiple layers, do a controlled restart in the same order every time so you can reason about what loaded when. Finally, re-enable the profile and trigger a single manual incremental run.
Within thirty minutes, you should be able to tell if the system is healthy. A newly created user ought to land under the standard OU. An attribute change such as UPN or mail should propagate cleanly. A rename or cross-parent move should complete without drama. In the logs, LDAP 50/65/67 errors should be conspicuously absent, and the profile’s failure counter should remain at zero while LACN climbs toward AD’s watermark.
If any of those signals go the wrong way, don’t hesitate to abort: restore the prior profile and mappings, roll back the ACI to the previous state, apply the reverse LDIF to put the tree back, and only then consider a service restart. Database or platform snapshot restores are last-resort measures; if you use them, plan for a clean re-sync afterward.
8) Keep your eyes honest (EM Agent & time zones)
DIP can sometimes keep working even when your EM Agent’s time zone is wrong, but your eyes will lie to you. Timestamps won’t line up, alerts will look late, and you’ll waste cycles second-guessing what happened when. Reset the agent’s time zone and re-secure it so your console reflects reality.
# time-zone alignment emctl resetTZ agent # re-establish status/security (varies by env) emctl stop agent emctl secure agent emctl start agent
9) Takeaways you can rely on
When in doubt, remember the three anchors that keep OID×DIP steady: express permissions in OID’s native ACI vocabulary and include the bits that make rename and move operations legal; make the DIT match the world your DomainRules describe and carry a reverse LDIF so you can back out without panic; and measure your progress with LACN and USN rather than hunches. With those in place, the simple cadence of Disable → Change → Verify → Enable will take you further than any heroic fix.
