Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-20064

Cannot use CLI or URL with API token with Active Directory as the access control security realm

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • jenkins-1.534 on Ubuntu with Active Directory plugin 1.33, configured with just the domain (no bind DN or password).
      jenkins-1617 too

      I'm trying to use the Jenkins CLI for a server that is set up with AD as the access control security realm. Logged in users can perform any action.

      The Jenkins server is 1.534 on Ubuntu with Active Directory plugin 1.33, configured with just the domain (no bind DN or password).

      I've provisioned an SSH public key for my user. When I attempt to run CLI against Jenkins it fails 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:644)
              at hudson.cli.CLI._main(CLI.java:474)
              at hudson.cli.CLI.main(CLI.java:384)
      

      and the below is logged on the server. This is similar to JENKINS-12619 though in my case the behavior is consistent and always fails.

      Oct 13, 2013 12:23:35 PM WARNING hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider retrieveUser
      
      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=mycompany,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 org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator.authenticate(SshCliAuthenticator.java:44)
          at hudson.cli.CliManagerImpl$2.run(CliManagerImpl.java:109)
      
      Oct 13, 2013 12:23:35 PM WARNING hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider retrieveUser
      
      Credential exception tying to authenticate against mycompany.com domain
      org.acegisecurity.BadCredentialsException: Failed to retrieve user information for username; nested exception is 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=mycompany,DC=com'
          at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:309)
          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 org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator.authenticate(SshCliAuthenticator.java:44)
          at hudson.cli.CliManagerImpl$2.run(CliManagerImpl.java:109)
      Caused by: 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=mycompany,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)
          ... 7 more
      

          [JENKINS-20064] Cannot use CLI or URL with API token with Active Directory as the access control security realm

          David Resnick added a comment -

          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)
          

          David Resnick added a comment - 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?

          Walter Kacynski added a comment - You mentioned that you haven't entered a Bind DN? Why not?

          David Resnick added a comment -

          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.

          David Resnick added a comment - 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.

          Jeff Burke added a comment -

          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

          Jeff Burke added a comment - 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

          Jeff Burke added a comment -

          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.

          Jeff Burke added a comment - 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 Schneider added a comment - 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.

          Jeff Burke added a comment -

          @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 added a comment - @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.

          Angelo Schneider added a comment - - edited

          @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.

          Angelo Schneider added a comment - - edited @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.

          SCM/JIRA link daemon added a comment - 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

          SCM/JIRA link daemon added a comment - 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.

          Kohsuke Kawaguchi added a comment - Fix to JENKINS-9258 fixed this problem.

          dogfood added a comment -

          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

          dogfood added a comment - 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

          Eric Helgeson added a comment -

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

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

          Jesse Glick added a comment -

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

          Jesse Glick added a comment - Correcting a minor regression in 8423158: User.getAuthorities should not pass on the UsernameNotFoundException .

          Daniel Christophis added a comment - - edited

          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?

          Daniel Christophis added a comment - - edited 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
          

          Daniel Serodio added a comment - 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

          Sorin Sbarnea added a comment -

          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

          Sorin Sbarnea added a comment - 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

          Jesse Glick added a comment -

          Probably the subsequent comments are really about JENKINS-22346.

          Jesse Glick added a comment - Probably the subsequent comments are really about JENKINS-22346 .

          yann kerherve added a comment -

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

          yann kerherve added a comment - jglick You marked it as resolved, but where is the fix? Thanks

          Jesse Glick added a comment -

          Jesse Glick added a comment - http://jenkins-ci.org/commit/jenkins/0e339d7a454df119995b896eea14f09a099f99b5 as noted above.

            kohsuke Kohsuke Kawaguchi
            david_resnick David Resnick
            Votes:
            6 Vote for this issue
            Watchers:
            16 Start watching this issue

              Created:
              Updated:
              Resolved: