The problem is not specific to using the CLI; a similar error is logged when trying to perform remote execution using an API token.

 Oct 27, 2013 9:48:33 AM hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider retrieveUser
WARNING: Failed to retrieve user information for username
javax.naming.NamingException: [LDAP: error code 1 - 00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece^@]; remaining name 'DC=company,DC=com'
        at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3072)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2978)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2785)
        at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1839)
        at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1762)
        at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1779)
        at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:412)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:394)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:376)
        at hudson.plugins.active_directory.LDAPSearchBuilder.search(LDAPSearchBuilder.java:52)
        at hudson.plugins.active_directory.LDAPSearchBuilder.searchOne(LDAPSearchBuilder.java:42)
        at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:263)
        at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:193)
        at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:137)
        at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:30)
        at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:584)
        at hudson.model.User.impersonate(User.java:255)
        at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:52)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
        at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
        at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
        at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:46)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482)
        at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
        at org.eclipse.jetty.server.Server.handle(Server.java:370)
        at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
        at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949)
        at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
        at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
        at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:679)

You mentioned that you haven't entered a Bind DN? Why not?

It's because I haven't had to. Setting it up would require an AD account with the attendant password and headaches. I haven't needed it until now.

I'm unclear on why it should be needed here. I'm using the API token or configured private key to authenticate myself to Jenkins instead of using AD. AFAIK Jenkins doesn't use the AD session for anything but authentication, so when I use the API token Jenkins shouldn't need to perform AD authentication.

Jenkins 1.519 and Active Directory plugin 1.33 have the same/similar issue. I'm on Windows 2008 R2, and I see that the REST API access doesn't work w/the apiToken. I have to supply the user's username and password in the REST API request. From here: https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients when I run the wget request sample, it fails w/a clear message that it is querying AD for the wrong username.

Here is a wget debug trace of a failed request:

============================ start of trace

C:\gnuwin32\bin> .\wget.exe --auth-no-challenge --http-user=user --http-password=apiToken http://myserver.com:8080/job/Experiment-Main-Build/build?token=1715b88bfba6717fadee72f5d5ecd17a
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\gnuwin32/etc/wgetrc
-2013-11-13 16:10:34- http://myserver.com:8080/job/Experiment-Main-Build/build?token=1715b88bfba6717fadee72f5d5ecd17a
Resolving myserver.com... 172.19.72.148
Connecting to myserver.com|172.19.72.148|:8080... connected.
HTTP request sent, awaiting response... 401 Authorization Required
Authorization failed.
PS C:\gnuwin32\bin> .\wget.exe --auth-no-challenge --http-user=user --http-password=apiToken http://myserver.com:8080/job/Experiment-Main-Build/build?token=1715b88bfba6717fadee72f5d5ecd17a --debug
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\gnuwin32/etc/wgetrc
DEBUG output created by Wget 1.11.4 on Windows-MinGW.

-2013-11-13 16:11:07- http://myserver.com:8080/job/Experiment-Main-Build/build?token=1715b88bfba6717fadee72f5d5ecd17a
Auth-without-challenge set, sending Basic credentials.
Resolving myserver.com... seconds 0.00, 172.19.72.148
Caching myserver.com => 172.19.72.148
Connecting to myserver.com|172.19.72.148|:8080... seconds 0.00, connected.
Created socket 300.
Releasing 0x0056b108 (new refcount 1).

--request begin--
GET /job/Experiment-Main-Build/build?token=1715b88bfba6717fadee72f5d5ecd17a HTTP/1.0
User-Agent: Wget/1.11.4
Accept: /
Authorization: Basic dXNlcjphcGlUb2tlbg==
Host: myserver.com:8080
Connection: Keep-Alive

--request end--
HTTP request sent, awaiting response...
--response begin--
HTTP/1.0 401 Authorization Required
Server: Winstone Servlet Engine v0.9.10
WWW-Authenticate: Basic realm="Jenkins"
Content-Length: 505
Connection: Keep-Alive
Content-Type: text/html;charset=ISO-8859-1
Date: Wed, 13 Nov 2013 23:11:07 GMT
X-Powered-By: Servlet/2.5 (Winstone/0.9.10)

--response end--
401 Authorization Required
Registered socket 300 for persistent reuse.
Skipping 505 bytes of body: [<html><head><title>Error 401</title></head><body bgcolor="#ffffff"><h1>Status Code: 401</h1>Exception: Either no such user 'user@myserver.com' or incorrect password; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1] done.
Authorization failed.

============================ end of trace

and here is a successful request using username and password:

============================ start of trace

C:\gnuwin32\bin> .\wget.exe --auth-no-challenge --http-user=jburke --http-password="mypassword" http://myserver.com:8080/job/Experiment-Main-Build/build?token=1715b88bfba6717fadee72f5d5ecd17a --debug
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\gnuwin32/etc/wgetrc
DEBUG output created by Wget 1.11.4 on Windows-MinGW.

-2013-11-13 17:25:39- http://myserver.com:8080/job/Experiment-Main-Build/build?token=1715b88bfba6717fadee72f5d5ecd17a
Auth-without-challenge set, sending Basic credentials.
Resolving myserver.com... seconds 0.00, 172.19.72.148
Caching myserver.com => 172.19.72.148
Connecting to myserver.com|172.19.72.148|:8080... seconds 0.00, connected.
Created socket 300.
Releasing 0x0049ef78 (new refcount 1).

--request begin--
GET /job/Experiment-Main-Build/build?token=1715b88bfba6717fadee72f5d5ecd17a HTTP/1.0
User-Agent: Wget/1.11.4
Accept: /
Authorization: Basic amJ1cmtlOmEsTWlydGg7OA==
Host: myserver.com:8080
Connection: Keep-Alive

--request end--
HTTP request sent, awaiting response...
--response begin--
HTTP/1.0 200 OK
Server: Winstone Servlet Engine v0.9.10
Expires: 0
Cache-Control: no-cache,must-revalidate
X-Hudson-Theme: default
Content-Type: text/html;charset=UTF-8
X-Hudson: 1.395
X-Jenkins: 1.519
X-Jenkins-Session: 856997c2
X-Hudson-CLI-Port: 57801
X-Jenkins-CLI-Port: 57801
X-Jenkins-CLI2-Port: 57801
X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhlCXIc6uKeJnpA9CrN4yn1VCxNIfxOdrZyRvc+PPWwgPUPwIBKaQNlfmJXxCtwRT3Op8SNWdjp+rGj1m+MiG4eDtzXgedm3g+0HJi1yh2V2wJj9ZhYrybCu6b899xd6zPoCoWRPZvwITxp0ngvVxlCYshq9Anjniygwi8KVbS0BG8KRgHsfVWZVPmLfXhkKS+LuA3o4Uhf2n6rQvdd3vliBkWrH4ovDgLbYnvbN8t0gSiQgEey7o6BaDVuxuVdB6fSstPGP1LxlSRxB5Vnn8/UI7rOnPV/251UP3RrD28mtx4k0eBtbyogTKR705mU8k8xwrcNh6uToHLE+j/ApnSQIDAQAB
X-SSH-Endpoint: myserver.com:57800
Content-Length: 7162
Connection: Keep-Alive
Date: Thu, 14 Nov 2013 00:25:42 GMT
X-Powered-By: Servlet/2.5 (Winstone/0.9.10)
Set-Cookie: JSESSIONID.91be6b77=88251c6f0bd5cff37e8dc5161c326a07; Path=/; HttpOnly

--response end--
200 OK
Registered socket 300 for persistent reuse.

Stored cookie myserver.com 8080 / <session> <insecure> [expiry none] JSESSIONID.91be6b77 88251c6f0bd5cff37e8dc5161c326a07
Length: 7162 (7.0K) [text/html]
Saving to: `build@token=1715b88bfba6717fadee72f5d5ecd17a'

100%[=============================================================================> ] 7,162 --.-K/s in 0.06s

2013-11-13 17:25:42 (111 KB/s) - `build@token=1715b88bfba6717fadee72f5d5ecd17a' saved [7162/7162]

============================ end of trace

My thought on how this should work is that the authentication should be done w/o Active Directory when the apiToken is supplied. HOWEVER... the Active Directory plugin should still verify that the user account is not locked, disabled or deleted... which I assume is possible without the user's password.

Can you please clarify on this:
C:\gnuwin32\bin> .\wget.exe --auth-no-challenge --http-user=user --http-password=_apiToken_ http://myserver.com:8080/job/Experiment-Main-Build/build?token=1715b88bfba6717fadee72f5d5ecd17a

The word "apiToken", is that ment as a keyword so that the final "?token=1715b88bfba6717fadee72f5d5ecd17a" is interpreted correctly or is that a placeholder for the users api token??

@Jeff imho no AD/LDAP request is needed at all. Jenkins should bypass what ever auth scheme it has as long as the user and his apikey is correct.

@angelo, take a look at https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients. It shows how the apitoken is supplied. apitoken is being used as a keyword to tell the CLI/SSH to use the token as an account lookup.

On the topic of whether CLI w/API token should verify the account is active w/the underlying security realm... I standby that it needs to do this. It doesn't need to authenticate the credentials, but it does need to verify that the user account hasn't been disabled. Not performing this would, for example, allow previous employees of a company a backdoor into internal Jenkins systems. Long after their AD, LDAP, or PAM account has been disabled, Jenkins SSH would continue to give them access to resources that administrators clearly didn't want them to continue to have.

I'd be fine w/it being a configurable option w/in the SSH CLI.

@Jeff Burke, thanx for the link, I know it. But the link is competely unclear regading the fact that "apiToken" should be used as a literal wrd, but I guessed it schould. However as it does not work in conjunction with LDAP/AD I never was certain about it.
Anyway regarding the check you propose (check if the user is deactiated) it is a bit tricky to decide what is right. I guess a checkbox in the LDAP plug to define what behaviour we want is better.
My thoughtprocess is this:

• if the user is deactivated he can not logon on any machine in the cluster anyway
• usually a "technical user" is used anyway, and it should be unlikely that that one is ever deactivated
• if the user is deactivated but there are still scripts running that use him via API tokens, then very likely the organization might want those scripts still running

Well, for my personal problems I don't care if the LDAP plugin checks if the user is still active (it should definitely check if the user exists). Perhaps it is best that way, as I of course understand your concerns. I only want this bug fixed as soon as possible. Unfortunately I feel not competent in "Plugin Development" to do that my self.

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
changelog.html
core/src/main/java/hudson/model/User.java
core/src/main/java/jenkins/security/LastGrantedAuthoritiesProperty.java
test/src/test/java/jenkins/security/LastGrantedAuthoritiesPropertyTest.groovy
http://jenkins-ci.org/commit/jenkins/0e339d7a454df119995b896eea14f09a099f99b5
Log:
JENKINS-20064

Jenkins now remembers the authorities (read group memberships) that the user had carried when he/she last time interactively logged in.
This information is exposed via User.impersonate(), which is used when using Jenkins SSH, Jenkins CLI, or access via API tokens.

Previously this was impossible for a subset of SecurityRealms that does not allow us to read group membership information without
successful login (such as Active Directory, OpenID, etc.)

For security reasons, if the backend determines that the user does not exist (as opposed to the backend who cannot tell if the user
exists or not), then the impersonation will fail.

I need to check AD plugin is reporting a failure correctly in this case, before marking as JENKINS-20064 fixed.

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
src/main/java/hudson/plugins/active_directory/ActiveDirectoryUnixAuthenticationProvider.java
http://jenkins-ci.org/commit/active-directory-plugin/5664c65fc9c96a03ed20bfe42f8f67e72097a4b2
Log:
JENKINS-20064

Need to report a failure correctly

Fix to JENKINS-9258 fixed this problem.

Integrated in jenkins_main_trunk #3223
JENKINS-20064 (Revision 0e339d7a454df119995b896eea14f09a099f99b5)

Result = UNSTABLE
kohsuke : 0e339d7a454df119995b896eea14f09a099f99b5
Files :

• core/src/main/java/jenkins/security/LastGrantedAuthoritiesProperty.java
• core/src/main/java/hudson/model/User.java
• changelog.html
• test/src/test/java/jenkins/security/LastGrantedAuthoritiesPropertyTest.groovy

This may have caused a regression in JENKINS-22346 with ssh key auth. Workes in 1.555 and below.

Correcting a minor regression in 8423158: User.getAuthorities should not pass on the UsernameNotFoundException.

Also broken in LTS Version 1.565.1.

I get the following LDAP error when trying to use CLI commands:

Exception in thread "Thread-XX" org.acegisecurity.userdetails.UsernameNotFoundException: User XXXXX not found in directory.
	at org.acegisecurity.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:126)
	at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.loadUserByUsername(LDAPSecurityRealm.java:787)
	at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.loadUserByUsername(LDAPSecurityRealm.java:738)
	at jenkins.security.ImpersonatingUserDetailsService.loadUserByUsername(ImpersonatingUserDetailsService.java:32)
	at hudson.model.User.impersonate(User.java:266)
	at org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator.authenticate(SshCliAuthenticator.java:44)
	at hudson.cli.CliManagerImpl$2.run(CliManagerImpl.java:109)

And of course related with this:

Exception in thread "main" java.io.EOFException
	at java.io.DataInputStream.readBoolean(DataInputStream.java:244)
	at hudson.cli.Connection.readBoolean(Connection.java:95)
	at hudson.cli.CLI.authenticate(CLI.java:634)
	at hudson.cli.CLI._main(CLI.java:474)
	at hudson.cli.CLI.main(CLI.java:384)

Any suggestions for temporary workarounds?

Please forgive if this it not the same issue. I'm running Jenkins 1.575 w/ Active Directory plugin 1.37 and using an API token to authenticate using the HTTP API works fine, but when I try to authenticate jenkins-cli with an API token like this:

java -jar jenkins-cli.jar -s http://jenkins.intranet:8080/jenkins who-am-i --username dserodi --password MY_API_KEY

I get this stracktrace:

org.acegisecurity.BadCredentialsException: Either no such user 'dserodi@intranet' or incorrect password; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1]
    at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl.bind(ActiveDirectorySecurityRealm.java:385)
    at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:248)
    at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:193)
    at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:137)
    at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.authenticate(ActiveDirectorySecurityRealm.java:602)
    at hudson.security.AbstractPasswordBasedSecurityRealm.doAuthenticate(AbstractPasswordBasedSecurityRealm.java:114)
    at hudson.security.AbstractPasswordBasedSecurityRealm.access$100(AbstractPasswordBasedSecurityRealm.java:39)
    at hudson.security.AbstractPasswordBasedSecurityRealm$1.authenticate(AbstractPasswordBasedSecurityRealm.java:81)
    at hudson.cli.CLICommand.main(CLICommand.java:228)
    at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:92)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:309)
    at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:290)
    at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:249)
    at hudson.remoting.UserRequest.perform(UserRequest.java:118)
    at hudson.remoting.UserRequest.perform(UserRequest.java:48)
    at hudson.remoting.Request$2.run(Request.java:328)
    at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
    at hudson.cli.CliManagerImpl$1.call(CliManagerImpl.java:63)
    at hudson.remoting.InterceptingExecutorService$2.call(InterceptingExecutorService.java:95)
    at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:744)
Caused by: javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1]
    at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3087)
    at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033)
    at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2835)
    at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2749)
    at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2635)
    at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2622)
    at com.sun.jndi.ldap.LdapCtx.reconnect(LdapCtx.java:2618)
    at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl.bind(ActiveDirectorySecurityRealm.java:454)
    at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl.bind(ActiveDirectorySecurityRealm.java:370)
    ... 27 more

I can confirm the the issue, tried to use API_TOKEN as a password for the CLI usage and I got the error below from a jenkins instance that is configured to accept LDAP logins:

org.acegisecurity.AuthenticationServiceException: Application name and/or password are not valid.; nested exception is com.atlassian.crowd.exception.InvalidAuthenticationException: Account with name <svcacct_scale> failed to authenticate
	at de.theit.jenkins.crowd.CrowdSecurityRealm.authenticate(CrowdSecurityRealm.java:394)
	at hudson.security.AbstractPasswordBasedSecurityRealm.doAuthenticate(AbstractPasswordBasedSecurityRealm.java:114)
	at hudson.security.AbstractPasswordBasedSecurityRealm.access$100(AbstractPasswordBasedSecurityRealm.java:39)
	at hudson.security.AbstractPasswordBasedSecurityRealm$1.authenticate(AbstractPasswordBasedSecurityRealm.java:81)
	at hudson.cli.CLICommand.main(CLICommand.java:231)
	at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:92)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:326)
	at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:301)
	at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:260)
	at hudson.remoting.UserRequest.perform(UserRequest.java:121)
	at hudson.remoting.UserRequest.perform(UserRequest.java:49)
	at hudson.remoting.Request$2.run(Request.java:325)
	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
	at hudson.cli.CliManagerImpl$1.call(CliManagerImpl.java:63)
	at hudson.remoting.CallableDecoratorAdapter.call(CallableDecoratorAdapter.java:18)
	at hudson.remoting.CallableDecoratorList$1.call(CallableDecoratorList.java:21)
	at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: com.atlassian.crowd.exception.InvalidAuthenticationException: Account with name <svcacct_scale> failed to authenticate
	at com.atlassian.crowd.exception.InvalidAuthenticationException.newInstanceWithName(InvalidAuthenticationException.java:50)
	at com.atlassian.crowd.integration.rest.service.RestCrowdClient.handleInvalidUserAuthentication(RestCrowdClient.java:1187)
	at com.atlassian.crowd.integration.rest.service.RestCrowdClient.authenticateUser(RestCrowdClient.java:128)
	at de.theit.jenkins.crowd.CrowdSecurityRealm.authenticate(CrowdSecurityRealm.java:376)
	... 24 more

Probably the subsequent comments are really about JENKINS-22346.

Jesse Glick You marked it as resolved, but where is the fix? Thanks

http://jenkins-ci.org/commit/jenkins/0e339d7a454df119995b896eea14f09a099f99b5 as noted above.