Recently, we configured OIM 11.1.1.5 with MTS (Multiple Trusted Sources) by making AD the authoritative source for the email address attribute. As per requirements, we also added an additional domain attribute to the AD reconciliation process and provisioned additional attributes to AD.
Shortly thereafter our email address updates from AD stop propagating and our AD Trusted Recon job started throwing the following exception…….
[2012-04-19T17:56:23.032-04:00] [oim_server1] [ERROR] [] [OIMCP.ADCS] [tid: OIMQuartzScheduler_Worker-10] [userId: oiminternal] [ecid: 0000JRBfdRo7y0lqwsFg6G1F^4pi000002,0] [APP: oim#11.1.1.3.0] com.thortech.xl.integration.ActiveDirectory.tcADUtilLDAPController : searchResultPageEnum
[2012-04-19T17:56:23.032-04:00] [oim_server1] [ERROR] [] [OIMCP.ADCS] [tid: OIMQuartzScheduler_Worker-10] [userId: oiminternal] [ecid: 0000JRBfdRo7y0lqwsFg6G1F^4pi000002,0] [APP: oim#11.1.1.3.0] Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
[2012-04-19T17:56:23.032-04:00] [oim_server1] [ERROR] [] [OIMCP.ADCS] [tid: OIMQuartzScheduler_Worker-10] [userId: oiminternal] [ecid: 0000JRBfdRo7y0lqwsFg6G1F^4pi000002,0] [APP: oim#11.1.1.3.0] Description : Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
[2012-04-19T17:56:23.032-04:00] [oim_server1] [ERROR] [] [OIMCP.ADCS] [tid: OIMQuartzScheduler_Worker-10] [userId: oiminternal] [ecid: 0000JRBfdRo7y0lqwsFg6G1F^4pi000002,0] [APP: oim#11.1.1.3.0] javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial[[
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.ldap.InitialLdapContext.getDefaultLdapInitCtx(InitialLdapContext.java:146)
at javax.naming.ldap.InitialLdapContext.getResponseControls(InitialLdapContext.java:190)
at com.thortech.xl.integration.ActiveDirectory.tcADUtilLDAPController.searchResultPageEnum(Unknown Source)
at com.thortech.xl.schedule.tasks.ActiveDirectoryReconTask.performReconciliation(Unknown Source)
at com.thortech.xl.schedule.tasks.ActiveDirectoryReconTask.execute(Unknown Source)
at com.thortech.xl.scheduler.tasks.SchedulerBaseTask.execute(SchedulerBaseTask.java:384)
at oracle.iam.scheduler.vo.TaskSupport.executeJob(TaskSupport.java:145)
at sun.reflect.GeneratedMethodAccessor1271.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at oracle.iam.scheduler.impl.quartz.QuartzJob.execute(QuartzJob.java:196)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:529)
A quick check of Metalink yielded Bug 12353920: TRUSTED RECON THROWS NOINITIALCONTEXTEXCEPTION IF USER IN AD TARGET HAS MANAGER. Apparently, part of the issue is the provisioning of the manager attribute from OIM to AD, but it’s not clear why. Patch 12353920 is available, but it’s basically the contents of the 9.1.1.7.1 AD UM Connector, which didn’t help as we are using the 9.1.1.7.4. Subsequently, we noted in the bug contents is that Lookup.AD.Domains must be empty for this error to occur. This led us to believe that the Lookup.AD.Domains was a requirement if you do have multiple domains and you want to provision the manager attribute.
Therefore, the fix for this issue with AD UM 9.1.1.7.1 (and above) is to populate the Lookup.AD.Domains (see below) with a Code Key of the root context of the AD domains and a Decode of its corresponding IT Resource name. More info on this can be found in section 4.13.1 of the AD UM Connector Guide 9.1.1
