Consider the following scenarios:
Scenario 1:
DIP Import Sync from Active Directory (AD) to OID works for most entries, but fails when a new organizationalunit (ou) entry is added in AD.
The $ORACLE_HOME/ldap/odi/log/<PROFILE_NAME>.trc file shows the following error:
javax.naming.directory.SchemaViolationException: [LDAP: error code 65 – sn attribute not found. Mandatory Attribute missing.]; remaining name ‘ou=<OU2>,cn=users,dc=<COMPANY>,dc=com’
The above error seems odd because the sn attribute is typically associated with user type entries rather than ou entries.
Examining this ou entry attribute in AD does not reveal any user type attributes/objectclasses, i.e.:
>ldapsearch -h <ADhost> -p <port> -D “administrator@<DOMAIN>.com” -w <password> -L -b “ou=<OU2>,ou=<OU>,dc=<COMPANY>,dc=com” -s sub “objectclass=*”
dn: OU=<OU2>,OU=<OU>,DC=<COMPANY>,DC=COM
objectClass: top
objectClass: organizationalUnit
ou: <OU2>
distinguishedName: OU=<OU2>,OU=<OU>,DC=COMPANY>,DC=COM
instanceType: 4
whenCreated: 20100202150820.0Z
whenChanged: 20100202150820.0Z
uSNCreated: 487906
uSNChanged: 487907
name: <OU2>
objectGUID:: <OBJECTGUID_VALUE>
objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=<COMPANY>,DC=com
dSCorePropagationData: 16010101000000.0Z
To troubleshoot this further:
1. Set the Sync Profile debug level to 63, restart odisrv process for sync, and let the sync cycle occur to reproduce the problem.
2. Examine the resulting trace file mappings translation section, being careful to review every attribute and objectclass being evaluated. For example, in this case scenario the trace file shows:
———–
Source ChangeRecord Created
MAPPING : Source Change Record : ChangeRecord : ———-
Changetype: ADDRMODIFY
ChangeKey: OU=<OU2>,OU=<OU>,DC=COMPANY>,DC=COM
Attributes:
Class: null Name: objectsid Type: null ChgType: DELETE Value: [ ]
Class: null Name: description Type: null ChgType: DELETE Value: [ ]
Class: null Name: objectguid Type: nonbinary ChgType: REPLACE Value: [[<ORCLGUID>]
Class: null Name: objectclass Type: nonbinary ChgType: REPLACE Value: [top, organizationalUnit]
Class: null Name: ou Type: nonbinary ChgType: REPLACE Value: [<OU2>]
———–
MAPPING: Attributes – Start
MAPPING: Processing Map Rule : 7
MAPPING: Processing Map Rule : 6
MAPPING: Processing Map Rule : 7
MAPPING: Processing Map Rule : 6
MAPPING: Processing Map Rule : 7
MAPPING: DstChangeRecord after Attribute Mapping : ChangeRecord : ———-
Changetype: ADDRMODIFY
ChangeKey: OU=<OU2>,OU=<OU>,DC=COMPANY>,DC=COM
Attributes:
Class: null Name: objectclass Type: null ChgType: REPLACE Value: [person, organizationalunit]
Class: null Name: orclobjectguid Type: null ChgType: REPLACE Value: [<GUID>]
Class: null Name: orclObjectSID Type: null ChgType: DELETE Value: []
Class: null Name: ou Type: null ChgType: REPLACE Value: [<OU2>]
Class: null Name: description Type: null ChgType: DELETE Value: [ ]
———–
All the attribute mapping processing look correct, but note on the highlighted items above that initially the objectclasses listed were top,organizationalunit, but after the mapping rules processing, one of objectclasses changed from top to person. This explains why the sync is looking for user type attributes mapped that belong to the person objectclass.
3. Since it’s already known that the AD entry does not have the objectclass person, next to review is the sync profile mapping rules, which can be obtained with the following search:
ldapsearch -h <OID_HOSTNAME> -p <PORT> -D cn=orcladmin -w <PASSWORD> -b “orclodipagentname=<PROFLE_NAME>,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory” -s sub “objectclass=*”
Then carefully review each and everyone of the attributes/objectclasses shown in the mappings evaluation section of the trace file, i.e. for this case they are:
objectclass
orclobjectguid
orclObjectSID
ou
description
Note: It helps to have another working sample of mappings to compare against what is loaded into the sync profile. Sample mappings can be found in $ORACLE_HOME/ldap/odi/conf/*.map.master files.
For this case scenario, all the mappings are as per the default/sample mappings, except for the mapping for description attribute, which is:
description: : :top:description: :person
-
Concentrating on the descriptionattribute, reviewing the OID schema definitions shows that the description attribute is an optional attribute of both the person and the organizationalunit objectclasses. But since the profile mapping rules only has one mapping rule for description, and it only references the person objectclass, when DIP sync processes this mapping, it finds the person objectclass and starts to look for attributes that belong to the person objectclass accordingly.
Since the person objectclass has sn as a mandatory attribute in OID, but there is nothing in the ou entry that can be mapped to sn, then sync fails with the trace log file error [LDAP: error code 65 – sn attribute not found. Mandatory Attribute missing.]
5. To resolve this problem:
a) The description attribute is typically optional, so remove its mapping rule from the mapping file, i.e., remove the following line:
description: : :top:description: :person
Then reload the mapping file into the profile with dipassistant and restart odisrv process for sync.
Or:
b) If description attribute mapping is required for ou entries only, edit the above attribute mapping rule in the mapping file to reference the organizationalunit objectclass instead of person, i.e.:
description: : :top:description: :organizationalunit
Then reload the mapping file into the profile with dipassistant and restart odisrv process for sync.
Or:
c) (Note: This option has not been tested) If description is required for both user and ou type entries, then try leaving the existing mapping rule for user entries, and add the mapping rule from b) above as a new mapping rule under the container mapping section of the mapping file. Then reload the mapping file into the profile with dipassistant and restart odisrv process for sync.
Scenario 2:
New import sync of a database (DB) user entries into OID via DIP fails.
The <PROFILE_NAME>.aud file shows the following error:
20100127084424 : Success : ADDRMODIFY : * : Attempt to synchronize deletion. Entry is not found. Ignore.
The <profilename>.trc file shows the following error:
Not able to construct DN
And:
Can’t find DN for entry to delete.
Synchrozing a deletion, entry to delete is not found. Ignore.
To troubleshoot this further:
1. Set the Sync Profile debug level to 63, restart odisrv process for sync, and allow the sync cycle to reoccur and reproduce the problem.
2. Examine the resulting trace file mappings translation section, being careful to review every attribute and objectclass being evaluated. For example, in this case scenario the trace file section of interest shows:
———–
MAPPING : Source Change Record : ChangeRecord : ———-
Changetype: ADDRMODIFY
ChangeKey: nonldap
Attributes:
Class: null Name: LAST_UPDATE Type: null ChgType: REPLACE Value: [xxxxxxxxxxxxx]
Class: null Name: ACCOUNT_STATUS Type: null ChgType: REPLACE Value: [Enabled]
Class: null Name: FIRSTYEAR Type: null ChgType: REPLACE Value: [N]
Class: null Name: FINALYEAR Type: null ChgType: REPLACE Value: [N]
Class: null Name: DEFAULTGROUP Type: null ChgType: REPLACE Value: [cn=<GROUP_NAME>,cn=groups,dc=<COMPANY>,dc=com]
Class: null Name: DOB Type: null ChgType: REPLACE Value: [1981-08-20 00:00:00.0]
– USERPASSWORD –**********–Class: null Name: GIVENNAME Type: null ChgType: REPLACE Value: [<GIVENNAME>]
Class: null Name: SNAME Type: null ChgType: REPLACE Value: [<LASTNAME>]
Class: null Name: FNAMES Type: null ChgType: REPLACE Value: [<FIRSTNAME>]
Class: null Name: MYID Type: null ChgType: REPLACE Value: [<ID>]
———–
MAPPING: Attributes – Start
MAPPING: Processing Map Rule : 7
MAPPING: Processing Map Rule : 7
MAPPING: Processing Map Rule : 7
MAPPING: Processing Map Rule : 7
MAPPING: Processing Map Rule : 7
MAPPING: Processing Map Rule : 7
MAPPING: Processing Map Rule : 7
MAPPING: Processing Map Rule : 7
MAPPING: Processing Map Rule : 7
MAPPING: DstChangeRecord after Attribute Mapping : ChangeRecord : ———-
Changetype: ADDRMODIFY
ChangeKey: nonldap
Attributes:
Class: null Name: objectclass Type: null ChgType: NOCHANGE Value: [inetorgperson, person, orcluserv2]
Class: null Name: accountstatus Type: null ChgType: REPLACE Value: [Enabled]
Class: null Name: firstyear Type: null ChgType: REPLACE Value: [N]
Class: null Name: finalyear Type: null ChgType: REPLACE Value: [N]
Class: null Name: orclDefaultProfileGroup Type: null ChgType: REPLACE Value: [cn=<GROUP_NAME>,cn=groups,dc=<COMPANY>,dc=com]
Class: null Name: birthday Type: null ChgType: REPLACE Value: [<BIRTHDAY>]
– userPassword –**********–Class: null Name: givenName Type: null ChgType: REPLACE Value: [<GIVENNAME>]
Class: null Name: sn Type: null ChgType: REPLACE Value: [<LASTNAME>]
Class: null Name: uid Type: null ChgType: REPLACE Value: [<UID_VALUE>]
———–
Not able to construct DN
MAPPING : Dst Change Record : ChangeRecord : ———-
Changetype: ADDRMODIFY
ChangeKey: *
Attributes:
Class: null Name: objectclass Type: null ChgType: NOCHANGE Value: [inetorgperson, person, orcluserv2]
Class: null Name: accountstatus Type: null ChgType: REPLACE Value: [Enabled]
Class: null Name: firstyear Type: null ChgType: REPLACE Value: [N]
Class: null Name: finalyear Type: null ChgType: REPLACE Value: [N]
Class: null Name: orclDefaultProfileGroup Type: null ChgType: REPLACE Value: [cn=<GROUP_NAME>,cn=groups,dc=<COMPANY>,dc=com]
Class: null Name: birthday Type: null ChgType: REPLACE Value: [<BIRTHDAY>]
– userPassword –**********–Class: null Name: givenName Type: null ChgType: REPLACE Value: [<GIVENNAME>]
Class: null Name: sn Type: null ChgType: REPLACE Value: [<LASTNAME>]
Class: null Name: uid Type: null ChgType: REPLACE Value: [<UID_VALUE>]
———–
Output ChangeRecord ChangeRecord : ———-
Changetype: ADDRMODIFY
ChangeKey: *
Attributes:
Class: null Name: objectclass Type: null ChgType: NOCHANGE Value: [inetorgperson, person, orcluserv2]
Class: null Name: accountstatus Type: null ChgType: REPLACE Value: [Enabled]
Class: null Name: firstyear Type: null ChgType: REPLACE Value: [N]
Class: null Name: finalyear Type: null ChgType: REPLACE Value: [N]
Class: null Name: orclDefaultProfileGroup Type: null ChgType: REPLACE Value: [cn=<GROUP_NAME>,cn=groups,dc=<COMPANY>,dc=com]
Class: null Name: birthday Type: null ChgType: REPLACE Value: [<BIRTHDAY>]
– userPassword –**********–Class: null Name: givenName Type: null ChgType: REPLACE Value: [<GIVENNAME>]
Class: null Name: sn Type: null ChgType: REPLACE Value: [<LASTNAME>]
Class: null Name: uid Type: null ChgType: REPLACE Value: [100071374]
———–
DN : *
Changetype is 5
Can’t find DN for entry to delete.
Synchrozing a deletion, entry to delet is not found. Ignore.
All the attribute mapping processing look correct, but notice that following entry (bold, italicized and underlined above):
Class: null Name: FNAMES Type: null ChgType: REPLACE Value: [<FIRSTNAME>]
Disappears from the next section after all the mapping rules are applied/evaluated (after the MAPPING: Processing Map Rule section) and no attribute is listed/mapped for the FNAMES column.
3. So, next review the sync profile mapping rules, which can be obtained with the following search:
ldapsearch -h <OID_HOSTNAME> -p <PORT> -D cn=orcladmin -w <PASSWORD> -b “orclodipagentname=<PROFILE_NAME>,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory” -s sub “objectclass=*”
-
Concentrating on the FNAMESmapping rule that is getting dropped in this case, check the following section of the profile for the DB SQL query and verify the FNAMESis correctly shown:
orclodipagentconfiginfo=[DBQUERY]
SELECT: SELECT \
MYID, \
FNAMES, \
…<etc,etc>….
Then in the attribute mapping section below, check the mapping for the DB column FNAMES. In this case, it is incorrectly listed as FNAME, i.e., it is missing the “S” at the end:
fname: : : :cn: :person
This causes this mapping rule to fail and nothing to be mapped to CN. Since the CN is also the RDN which is a key portion of the DN, DIP is not able to build the DN without it, resulting in the sync failure with error “Not able to construct DN.”
5. To resolve this problem:
a) Stop odisrv for synchronization process.
b) Doublecheck the table’s column name, which in this example is correctly named FNAMES.
c) Doublecheck the profile attribute mapping rule for fname to cn accordingly, and ensure there are no typos, i.e. for this example it should be:
fnames: : : :cn: :person
- d) Upload the corrected mapping file to the profile with dipassistant, and restart odisrv for sync.
Reference : 1060014.1
