Uploaded image for project: 'Crowd Data Center'
  1. Crowd Data Center
  2. CWD-2713

USNChangedMapper throws NPEs if AD does not return the uSNChanged attribute

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Low Low
    • 2.6
    • 2.3.3
    • Directory - LDAP, Embedded
    • None

      Customers have seen this error in their logs JIRA:

      2011-11-25 09:50:16,614 pool-20-thread-1 WARN ServiceRunner     [directory.ldap.mapper.UserContextMapper] Failed to map attribute <uSNChanged> from context with DN <cn=Delete ME. User,ou=scratch,dc=ad,dc=atlassian,dc=com>
java.lang.NullPointerException
	at com.atlassian.crowd.directory.ldap.mapper.attribute.USNChangedMapper.getValues(USNChangedMapper.java:28)
	at com.atlassian.crowd.directory.ldap.mapper.UserContextMapper.mapFromContext(UserContextMapper.java:57)
	at org.springframework.ldap.core.ContextMapperCallbackHandler.getObjectFromNameClassPair(ContextMapperCallbackHandler.java:67)
	at org.springframework.ldap.core.CollectingNameClassPairCallbackHandler.handleNameClassPair(CollectingNameClassPairCallbackHandler.java:50)
	at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:297)
	at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:237)
	at com.atlassian.crowd.directory.SpringLDAPConnector.pageSearchResults(SpringLDAPConnector.java:300)
	at com.atlassian.crowd.directory.SpringLDAPConnector.searchEntitiesWithRequestControls(SpringLDAPConnector.java:366)
	at com.atlassian.crowd.directory.SpringLDAPConnector.searchEntities(SpringLDAPConnector.java:351)
	at com.atlassian.crowd.directory.SpringLDAPConnector.searchUserObjects(SpringLDAPConnector.java:541)
	at com.atlassian.crowd.directory.SpringLDAPConnector.searchUsers(SpringLDAPConnector.java:910)
	at com.atlassian.crowd.directory.ldap.cache.UsnChangedCacheRefresher$1.call(UsnChangedCacheRefresher.java:181)
	at com.atlassian.crowd.directory.ldap.cache.UsnChangedCacheRefresher$1.call(UsnChangedCacheRefresher.java:176)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:680)
2011-11-25 09:50:16,615 pool-20-thread-1 INFO ServiceRunner     [directory.ldap.cache.UsnChangedCacheRefresher] found [ 2 ] remote users in [ 20ms ]

      It is occurring because the user used in the sync does not have permission to see the uSNChanged attribute.

      This is kinda interesting because it indicates that "incremental sync" will not work because the user does not have the correct permission.

            [CWD-2713] USNChangedMapper throws NPEs if AD does not return the uSNChanged attribute

            shihab added a comment -

            That's correct:

            Obtaining AD object deletions requires administrator access. Active Directory stores deleted objects in a special container called cn=Deleted Objects. By default, to access this container you need to connect as an administrator and so, for Crowd to be aware of deletions, you must use administrator credentials. Alternatively, it's possible to change the permissions on the cn=Deleted Objects container. If you wish to do so, please see this Microsoft KB Article.

            http://confluence.atlassian.com/display/CROWD/Configuring+Caching+for+an+LDAP+Directory#ConfiguringCachingforanLDAPDirectory-Notes

            Perhaps we should also add that the LDAP user used to connect to the AD server must have permissions to read the usnchanged attribute (as well as see cn=Deleted Objects).

            You can't use incremental sync if you don't have perms to read this information from the LDAP server - as that's the only way to detect deletes.

            shihab added a comment - That's correct: Obtaining AD object deletions requires administrator access. Active Directory stores deleted objects in a special container called cn=Deleted Objects. By default, to access this container you need to connect as an administrator and so, for Crowd to be aware of deletions, you must use administrator credentials. Alternatively, it's possible to change the permissions on the cn=Deleted Objects container. If you wish to do so, please see this Microsoft KB Article. http://confluence.atlassian.com/display/CROWD/Configuring+Caching+for+an+LDAP+Directory#ConfiguringCachingforanLDAPDirectory-Notes Perhaps we should also add that the LDAP user used to connect to the AD server must have permissions to read the usnchanged attribute (as well as see cn=Deleted Objects). You can't use incremental sync if you don't have perms to read this information from the LDAP server - as that's the only way to detect deletes.

              jwalton joe
              bbain bain
              Affected customers:
              1 This affects my team
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: