If you are using a custom interception script for update, there is also a scripts log. Most of the logging is controlled from log4j. Did you check `/opt/tomcat/webapps/identity/WEB-INF/classes/log4j.xml` Also, you might want to check the code in Github for that error message and see if you can get a better idea of what's going on.

Also there is useful information about script loading and script console output in in 'oxtrust_script.log'.

You should also check wrapper.log, some java error traces may appear there instead.

Seeing something new in the oxtrust_cache_refresh.log, 2015-12-17 08:37:23,655 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Attempting to load entries from source server 2015-12-17 08:37:23,678 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Found '99' entries in source server 2015-12-17 08:37:23,678 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Found '99' unique entries in source server 2015-12-17 08:37:23,701 DEBUG [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Found '99' entries in inum objects disk cache 2015-12-17 08:37:23,702 DEBUG [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Count actual inum entries '99' after updating inum server 2015-12-17 08:37:23,707 DEBUG [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Count actual source entries '99' after calculating hash code 2015-12-17 08:37:23,709 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Found '0' changed entries 2015-12-17 08:37:23,709 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Loaded '99' problem entries from problem file 2015-12-17 08:37:23,731 ERROR [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Skipping target entries update. Destination server shema doesn't has next attributes: '[samaccountname]' 2015-12-17 08:37:23,731 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Updated '0' entries 2015-12-17 08:37:23,731 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Failed to update '99' entries 2015-12-17 08:37:23,734 DEBUG [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Keep external persons: 'true' 2015-12-17 08:37:23,734 DEBUG [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Count entries '0' for removal from target server 2015-12-17 08:37:23,735 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Removed '0' persons from target server 2015-12-17 08:37:23,735 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) There are '99' entries before updating inum list 2015-12-17 08:37:23,735 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) There are '99' entries after removal '0' entries 2015-12-17 08:37:23,735 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) There are '99' entries after adding '0' entries 2015-12-17 08:37:23,858 DEBUG [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Allowing to run new process exclusively Tried to look for oxTrustCacheRefresh.properties under /opt/apache-tomcat-7.0.55/conf/ but it is missing. Is it generated by oxTrust or we have to create it manually?

All filesystem properties have been moved to ldap under `ou=oxtrust,ou=configuration,inum=<appliance-inum>,ou=appliances,o=gluu` I see the problem 2015-12-17 08:37:23,731 ERROR [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-2-thread-2) Skipping target entries update. Destination server shema doesn't has next attributes: '[samaccountname]' You might want to map this attribute to uid. Either that, or you'll need to follow the procedure to create the attribute in oxTrust first. - Mike

I do have "sAMAccountName -> uid" under Source attribute to destination attribute mapping and still getting that error. Is there an example of successful integration of Active Directory that we can reference?

Almost all our customers are using AD. We'll try to replicate the problem. Maybe its a bug in the mapping. Perhaps leave the attribute out. Can you use uid instead? Sometimes AD populates UID with the same value as samaccountname. Or perhaps use the update interception script to transform samaccount name as a workaround if it is a bug in the mapping.

Is there a way to flush inum cache? I'd like to discard the previous cache refresh and start over.

> I do have "sAMAccountName -> uid" I think this may be a known issue. I reported it before, but haven't been tracking its status since then. Rex, please make sure you are using lower case letters in all LDAP attributes names in CR's configuration tabs. I have a suspicion this will resolve your issue.

> Is there a way to flush inum cache? That depends on what you are aiming at. If you need to force a complete update of all Gluu's internal user records, you need just remove everything from your CR's snapshot directory - this will effectively force it to rewrite all attributes of these records with one acquired from the source backend, regardless of whether they were changed recently, or not, at the next pulling iteration. If you need to completely remove all user information from the ou=people and inumdb, there is no straightforward way, as far as I know. You have 2 options: 1) Edit internal LDAP directory directly with console tools like ldapdelete, removing these entries 2) Use this trick: a) Add a new attribute to pull from the backend to your current list, and map it to something. This will effectively invalidate all internal user entries and will lead to their removal at next pull iteration; a new user entries will be created instead, containing this new mapped attribute b) Wait for the next pulling, when this deletion/recreation will happen c) Remove that attribute (if you don't need it) and its mapping; this will again lead to deletion/recreation phase d) Wait for the next pulling, when this deletion/recreation will happen May be others will be able to suggest an easier method.

There is one easy way to flush the inum cache... 1. # service opendj stop 2. # rm -rf /opt/opendj/db/site 3. # service opendj start 4. # /opt/opendj/bin/ldapmodify -h localhost -p 1389 -D "Cn=directory manager" \ -j ~/.pw -a -f /opt/opendj/ldif/o_site.ldif (Put the DM password in ~/.pw... remove after you run the command, especially if this is a prod system!)

Using lower case letters for all LDAP attributes names in CR's configuration did the trick. Thank you, Aliaksandr.

Michael, Thank you for the tip. I'll give that a go.