Scriptrunner LDAPs query works on JIRA 6.4, but throws ClassNotFoundException in JIRA 7.4

[Dietmar]

I use Scriptrunner to run an LDAP query against the underlying "AuthoritativeDirectory" defined for a JIRA User directory with delegated LDAP authentication.

The following code works on JIRA 6.4.x, but fails on 7.4 (on a different machine) with 
ClassNotFoundException: com.atlassian.crowd.directory.ssl.LdapHostnameVerificationSSLSocketFactory 

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.crowd.embedded.api.CrowdDirectoryService
import com.atlassian.crowd.embedded.api.Directory

// https://docs.atlassian.com/atlassian-crowd/3.1.2/com/atlassian/crowd/directory/RemoteDirectory.html
import com.atlassian.crowd.directory.RemoteDirectory // interface
import com.atlassian.crowd.search.builder.QueryBuilder
import com.atlassian.crowd.search.builder.Restriction
import com.atlassian.crowd.search.query.entity.restriction.constants.UserTermKeys
import com.atlassian.crowd.search.EntityDescriptor
import com.atlassian.crowd.embedded.api.User

// https://docs.atlassian.com/atlassian-crowd/3.1.2/com/atlassian/crowd/directory/GenericLDAP.html
import com.atlassian.crowd.directory.GenericLDAP

// https://docs.atlassian.com/atlassian-crowd/3.1.2/com/atlassian/crowd/directory/DelegatedAuthenticationDirectory.html
import com.atlassian.crowd.directory.DelegatedAuthenticationDirectory
import com.atlassian.crowd.directory.loader.DelegatedAuthenticationDirectoryInstanceLoader // interface
import com.atlassian.crowd.directory.ssl.LdapHostnameVerificationSSLSocketFactory


def dirsvc = ComponentAccessor.getComponent(CrowdDirectoryService)
def dirs = dirsvc.findAllDirectories()
Directory mydirdef = dirs[0] // top-most one is mydir

def dir = ComponentAccessor.getComponent(DelegatedAuthenticationDirectoryInstanceLoader)
RemoteDirectory mydir = dir.getDirectory(mydirdef)
mydir.getClass() // -> DelegatedAuthenticationDirectory
mydir.getKeys() // all config-keys (from the directory definition)

def qry = QueryBuilder.queryFor(User.class, EntityDescriptor.user()).with(
 Restriction.on(UserTermKeys.LAST_NAME).startingWith("berg")
 ).returningAtMost(10)
def users = mydir.searchUsers(qry) // searches ONLY within the directory, not in LDAP :-(
def ldap = mydir.getAuthoritativeDirectory() // com.atlassian.crowd.directory.GenericLDAP
def users2 = ldap.searchUsers(qry) // searches in underlying LDAP directory

org.springframework.transaction.CannotCreateTransactionException: Could not create DirContext instance for transaction; 
nested exception is org.springframework.ldap.CommunicationException: hostname.some.corp:636; 
nested exception is javax.naming.CommunicationException: hostname.some.corp:636 
[Root exception is java.lang.ClassNotFoundException: com.atlassian.crowd.directory.ssl.LdapHostnameVerificationSSLSocketFactory]

[Filip Håkansson]

I solved the problem with the missing class by adding this code:

import com.atlassian.crowd.directory.ssl.LdapHostnameVerificationSSLSocketFactory

Thread currentThread = Thread.currentThread();
ClassLoader classLoader= currentThread.getContextClassLoader();
currentThread.setContextClassLoader(LdapHostnameVerificationSSLSocketFactory.class.getClassLoader());

[Danyal Iqbal]

Are you using java 7?

com.atlassian.crowd.directory.ssl.LdapHostnameVerificationSSLSocketFactory  is not present in the jira api.

 import package com.atlassian.crowd.directory.ssl should resolve this, if the class really exists.

[Dietmar]

I am using jdk1.8.0_91, Java 8 being required for JIRA 7.4 (or possibly just tomcat)

The API doc is at https://docs.atlassian.com/atlassian-crowd/2.10.2/com/atlassian/crowd/directory/ssl/LdapHostnameVerificationSSLSocketFactory.html

The additional import statement does not change anything;  I already imported the class LdapHostnameVerificationSSLSocketFactory from that package.

It is really strange, because JIRA correctly authenticates against the LDAPs server! It is just Groovy which bails out. Worse, I have identified  ./atlassian-jira/WEB-INF/lib/crowd-ldap-2.10.2-rc04.jar as containing this package along with others which do import without a hitch.

Could it be something entirely different, the "Root Exception" not being the root cause? Configuration to verify (or not) LDAP server identity?

[Danyal Iqbal]

I guess  the import package statement should be in the crowd plugin. update the plugin and try again.

So you can successfully test the AD connection from jira?

[Dietmar]

Google found some useful bits of information:

This issue appeared first as https://jira.atlassian.com/browse/JRASERVER-27347 (fixed in 6.0.0) and later as https://jira.atlassian.com/browse/JRASERVER-42868 ("resolved" but not fixed in 6.2.6). For me it works in 6.4.4, but not in 7.4.2 -- kind of ON/OFF story.

It seems that it is still lurking somewhere....

I filed a support request with Atlassian to find out if it is possible to replace just the crowd plugin (mind you, this is embedded crowd) and from where would I get the plugin.

[Mike Lind]

Did you get this working?

I get the same error when trying to remove a user from a group with Groovy/Scriptrunner. Also using LDAPS. 

Root exception is java.lang.ClassNotFoundException: com.atlassian.crowd.directory.ssl.LdapHostnameVerificationSSLSocketFactory

[Blake Manosh]

I'm seeing the same problem too. Did you ever find a solution for this?

[Mike Lind]

Check out this, I have it running in my code.

List liste = []

try {
listGrupperNavn = ComponentAccessor.getGroupManager().getGroupNamesForUser(appUser)


listGrupperNavn.each {
try {
log.debug "ITSOS 2.0 - Group to remove: " + it.toString()
Group fjernGruppe = groupManager.getGroup(it.toString())
if(groupManager.groupExists(it.toString()) == false) {
log.debug "ITSOS 2.0 - Gruppen finnes ikke."
} else {
if (it.toString() == "S4B-IncludeGroup" || it.toString() == "S4B-UserContainingGroup") { // 
log.debug "ITSOS 2.0 - Fjerner ikke denne gruppen: " + it.toString() 
} else {
//log.debug "ITSOS 2.0 - Fjerner denne gruppen: " + it.toString() 
liste.add(it.toString())
}
}
} catch (com.atlassian.crowd.exception.runtime.GroupNotFoundException gnfe) {
log.error "ITSOS 2.0 - Finner ikke gruppen i AD - Feil i fjernTilganger: " + gnfe.toString()
}
} // End each

log.debug "ITSOS 2.0 - Grupper som skal fjernes fra bruker: " + liste.toString()
mapper = new GroupRemoveChildMapper()// listGrupper
mapper.register(SAM, liste)

context = new JiraServiceContextImpl(sysUser); // user which removes another user to a group

resultRemoveUserFromGroups = groupService.validateRemoveUserFromGroups(context, liste, SAM)

if (resultRemoveUserFromGroups == true) {
log.debug "ITSOS 2.0 - Skal fjerne gruppemedlemskap..."
groupService.removeUsersFromGroups(context, mapper)
log.debug "ITSOS 2.0 - Gruppemedlemskap fjernet OK."
UserMessageUtil.success("Tilgangene på bruker " + appUser + " er fjernet i AD.")
resultFjernTilganger = true
}
}

[Blake Manosh]

Thank you Mike!

[Dietmar]

I got slightly further, but no solution yet.

For my external directory provider defined as "GenericLDAP" (some commercial enterprise product I do not know), the code fails. But  I have another one based on OpenLDAP, and that works!

The difference is that the method `mydir.getAuthoritativeDirectory()` in the code of my first post returns a `com.atlassian.crowd.directory.GenericLDAP` object in the first case, and `OpenLDAP` in the latter.  Surprisingly "GenericLDAP" is actually a subclass of "OpenLDAP" (I would have expected the other way round).

I will check if the directory definition for the corporate LDAP also works when I base it on OpenLDAP, that would then be a work-around.