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

Dietmar February 14, 2018

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]

2 answers

0 votes
Filip Håkansson September 11, 2020

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());

0 votes
Danyal Iqbal
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 14, 2018

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 February 14, 2018

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 14, 2018

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 February 16, 2018

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 May 23, 2018

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 September 14, 2019

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

Mike Lind September 16, 2019

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
}
}
Like Blake Manosh likes this
Blake Manosh September 18, 2019

Thank you Mike!

Dietmar September 21, 2019

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.

Like Blake Manosh likes this

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events