Jenkins CLI user gets locked in Active Directory
Locked
Jenkins CLI user gets locked in Active Directory
 
|
Hi
We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? Best regards, Eric |
AW: Jenkins CLI user gets locked in Active Directory
|
|
Anyone? :-)
-----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Lewis, Eric Gesendet: Dienstag, 5. Juni 2012 14:59 An: [hidden email] Betreff: Jenkins CLI user gets locked in Active Directory Hi We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? Best regards, Eric |
|
In reply to this post by Eric Lewis
Is this running on Linux? More information about your platforms and
such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric <[hidden email]> wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com |
AW: Jenkins CLI user gets locked in Active Directory
|
|
Sorry! :-)
Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: [hidden email] Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric <[hidden email]> wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com |
|
|
In reply to this post by Eric Lewis
Can you check the logs for authentication and see if AD is being tried
before the key based auth? Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 6:32 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Sorry! :-) Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: [hidden email] Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric <[hidden email]> wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com |
AW: Jenkins CLI user gets locked in Active Directory
|
|
Ok, I'll have to check (on Monday) with our Windows admins, since I don't have access to those logs.
Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:00 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory Can you check the logs for authentication and see if AD is being tried before the key based auth? Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 6:32 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Sorry! :-) Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: [hidden email] Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric <[hidden email]> wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com |
|
|
In reply to this post by Eric Lewis
I was meaning the logs on the Linux machine.
Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:06 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Ok, I'll have to check (on Monday) with our Windows admins, since I don't have access to those logs. Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:00 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory Can you check the logs for authentication and see if AD is being tried before the key based auth? Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 6:32 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Sorry! :-) Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: [hidden email] Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric <[hidden email]> wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com |
AW: Jenkins CLI user gets locked in Active Directory
|
|
Oh... :-)
Well, I'm not really a Linux guru, so could you tell me where I find those logs? (Also, I'm not root either) Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:23 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory I was meaning the logs on the Linux machine. Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:06 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Ok, I'll have to check (on Monday) with our Windows admins, since I don't have access to those logs. Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:00 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory Can you check the logs for authentication and see if AD is being tried before the key based auth? Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 6:32 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Sorry! :-) Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: [hidden email] Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric <[hidden email]> wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com |
|
|
In reply to this post by Eric Lewis
Usually they are in /var/log I believe. Look for auth.log or something
similar Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:33 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Oh... :-) Well, I'm not really a Linux guru, so could you tell me where I find those logs? (Also, I'm not root either) Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:23 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory I was meaning the logs on the Linux machine. Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:06 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Ok, I'll have to check (on Monday) with our Windows admins, since I don't have access to those logs. Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:00 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory Can you check the logs for authentication and see if AD is being tried before the key based auth? Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 6:32 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Sorry! :-) Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: [hidden email] Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric <[hidden email]> wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com |
AW: Jenkins CLI user gets locked in Active Directory
|
|
I don't see that file. I'll have to check with our Linux admin on Monday.
Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:45 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory Usually they are in /var/log I believe. Look for auth.log or something similar Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:33 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Oh... :-) Well, I'm not really a Linux guru, so could you tell me where I find those logs? (Also, I'm not root either) Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:23 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory I was meaning the logs on the Linux machine. Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:06 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Ok, I'll have to check (on Monday) with our Windows admins, since I don't have access to those logs. Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:00 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory Can you check the logs for authentication and see if AD is being tried before the key based auth? Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 6:32 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Sorry! :-) Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: [hidden email] Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric <[hidden email]> wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com |
AW: Jenkins CLI user gets locked in Active Directory
|
|
Ok, I checked with our sysadmin, but there's not more information in the logs.
However, another problem, which I postponed, may be the cause. As I mentioned, we're using Active Directory for authentification. In the Jenkins config, I'm using the Matrix-based security. Since we installed the new version, I always see errors in the GUI and in the log. For instance, for the mentioned Service_Build user, I see: Failed to test the validity of the user name Service_Build org.acegisecurity.BadCredentialsException: Failed to retrieve user information for Service_Build; nested exception is javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1]; remaining name 'DC=ipie,DC=ch' at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:231) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:130) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:95) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:27) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:551) at hudson.security.GlobalMatrixAuthorizationStrategy$DescriptorImpl.doCheckName_(GlobalMatrixAuthorizationStrategy.java:304) at hudson.security.GlobalMatrixAuthorizationStrategy$DescriptorImpl.doCheckName(GlobalMatrixAuthorizationStrategy.java:288) at sun.reflect.GeneratedMethodAccessor3018.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:61) 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:66) 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 winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at winstone.RequestDispatcher.forward(RequestDispatcher.java:331) at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1]; remaining name 'DC=ipie,DC=ch' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3107) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3013) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2820) at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1829) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1752) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:394) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:376) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) 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:191) ... 70 more The users however can very well log into Jenkins and are authenticated. Also the Active Directory test in the config works. I postponed this error because people can still work, but it's still an error. And I see the same whenever I try to do something with the Service_Build user. So maybe this is the root cause of my problems? It looks like it's a known issue: https://issues.jenkins-ci.org/browse/JENKINS-12619 Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Lewis, Eric Gesendet: Freitag, 8. Juni 2012 16:56 An: [hidden email] Betreff: AW: Jenkins CLI user gets locked in Active Directory I don't see that file. I'll have to check with our Linux admin on Monday. Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:45 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory Usually they are in /var/log I believe. Look for auth.log or something similar Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:33 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Oh... :-) Well, I'm not really a Linux guru, so could you tell me where I find those logs? (Also, I'm not root either) Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:23 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory I was meaning the logs on the Linux machine. Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:06 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Ok, I'll have to check (on Monday) with our Windows admins, since I don't have access to those logs. Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:00 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory Can you check the logs for authentication and see if AD is being tried before the key based auth? Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 6:32 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Sorry! :-) Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: [hidden email] Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric <[hidden email]> wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com |
AW: Jenkins CLI user gets locked in Active Directory
|
|
Ok, upgrading to the latest Active Directory plugin solves at least the problem in the Jenkins configuration page.
I'll check tomorrow about the rest of the problem. Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Lewis, Eric Gesendet: Montag, 11. Juni 2012 14:14 An: [hidden email] Betreff: AW: Jenkins CLI user gets locked in Active Directory Ok, I checked with our sysadmin, but there's not more information in the logs. However, another problem, which I postponed, may be the cause. As I mentioned, we're using Active Directory for authentification. In the Jenkins config, I'm using the Matrix-based security. Since we installed the new version, I always see errors in the GUI and in the log. For instance, for the mentioned Service_Build user, I see: Failed to test the validity of the user name Service_Build org.acegisecurity.BadCredentialsException: Failed to retrieve user information for Service_Build; nested exception is javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1]; remaining name 'DC=ipie,DC=ch' at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:231) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:130) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:95) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:27) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:551) at hudson.security.GlobalMatrixAuthorizationStrategy$DescriptorImpl.doCheckName_(GlobalMatrixAuthorizationStrategy.java:304) at hudson.security.GlobalMatrixAuthorizationStrategy$DescriptorImpl.doCheckName(GlobalMatrixAuthorizationStrategy.java:288) at sun.reflect.GeneratedMethodAccessor3018.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:61) 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:66) 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 winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at winstone.RequestDispatcher.forward(RequestDispatcher.java:331) at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1]; remaining name 'DC=ipie,DC=ch' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3107) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3013) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2820) at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1829) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1752) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:394) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:376) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) 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:191) ... 70 more The users however can very well log into Jenkins and are authenticated. Also the Active Directory test in the config works. I postponed this error because people can still work, but it's still an error. And I see the same whenever I try to do something with the Service_Build user. So maybe this is the root cause of my problems? It looks like it's a known issue: https://issues.jenkins-ci.org/browse/JENKINS-12619 Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Lewis, Eric Gesendet: Freitag, 8. Juni 2012 16:56 An: [hidden email] Betreff: AW: Jenkins CLI user gets locked in Active Directory I don't see that file. I'll have to check with our Linux admin on Monday. Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:45 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory Usually they are in /var/log I believe. Look for auth.log or something similar Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:33 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Oh... :-) Well, I'm not really a Linux guru, so could you tell me where I find those logs? (Also, I'm not root either) Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:23 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory I was meaning the logs on the Linux machine. Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:06 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Ok, I'll have to check (on Monday) with our Windows admins, since I don't have access to those logs. Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:00 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory Can you check the logs for authentication and see if AD is being tried before the key based auth? Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 6:32 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Sorry! :-) Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: [hidden email] Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric <[hidden email]> wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com |
AW: Jenkins CLI user gets locked in Active Directory
|
|
So, I tried again with the new Active Directory plugin.
When using our Service_Build user, there is no authentication request coming into Active Directory, which is how it should be. So the problem was the old, buggy Active Directory plugin. Thanks for the help & best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Lewis, Eric Gesendet: Montag, 11. Juni 2012 17:08 An: [hidden email] Betreff: AW: Jenkins CLI user gets locked in Active Directory Ok, upgrading to the latest Active Directory plugin solves at least the problem in the Jenkins configuration page. I'll check tomorrow about the rest of the problem. Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Lewis, Eric Gesendet: Montag, 11. Juni 2012 14:14 An: [hidden email] Betreff: AW: Jenkins CLI user gets locked in Active Directory Ok, I checked with our sysadmin, but there's not more information in the logs. However, another problem, which I postponed, may be the cause. As I mentioned, we're using Active Directory for authentification. In the Jenkins config, I'm using the Matrix-based security. Since we installed the new version, I always see errors in the GUI and in the log. For instance, for the mentioned Service_Build user, I see: Failed to test the validity of the user name Service_Build org.acegisecurity.BadCredentialsException: Failed to retrieve user information for Service_Build; nested exception is javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1]; remaining name 'DC=ipie,DC=ch' at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:231) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:130) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:95) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:27) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:551) at hudson.security.GlobalMatrixAuthorizationStrategy$DescriptorImpl.doCheckName_(GlobalMatrixAuthorizationStrategy.java:304) at hudson.security.GlobalMatrixAuthorizationStrategy$DescriptorImpl.doCheckName(GlobalMatrixAuthorizationStrategy.java:288) at sun.reflect.GeneratedMethodAccessor3018.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:61) 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:66) 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 winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at winstone.RequestDispatcher.forward(RequestDispatcher.java:331) at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1]; remaining name 'DC=ipie,DC=ch' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3107) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3013) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2820) at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1829) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1752) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1769) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:394) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:376) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) 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:191) ... 70 more The users however can very well log into Jenkins and are authenticated. Also the Active Directory test in the config works. I postponed this error because people can still work, but it's still an error. And I see the same whenever I try to do something with the Service_Build user. So maybe this is the root cause of my problems? It looks like it's a known issue: https://issues.jenkins-ci.org/browse/JENKINS-12619 Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Lewis, Eric Gesendet: Freitag, 8. Juni 2012 16:56 An: [hidden email] Betreff: AW: Jenkins CLI user gets locked in Active Directory I don't see that file. I'll have to check with our Linux admin on Monday. Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:45 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory Usually they are in /var/log I believe. Look for auth.log or something similar Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:33 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Oh... :-) Well, I'm not really a Linux guru, so could you tell me where I find those logs? (Also, I'm not root either) Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:23 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory I was meaning the logs on the Linux machine. Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 7:06 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Ok, I'll have to check (on Monday) with our Windows admins, since I don't have access to those logs. Best regards, Eric -----Ursprüngliche Nachricht----- Von: Alex Earl [mailto:[hidden email]] Gesendet: Freitag, 8. Juni 2012 16:00 An: Lewis, Eric; [hidden email] Betreff: RE: Jenkins CLI user gets locked in Active Directory Can you check the logs for authentication and see if AD is being tried before the key based auth? Sent from my Windows Phone From: Lewis, Eric Sent: 6/8/2012 6:32 AM To: [hidden email] Subject: AW: Jenkins CLI user gets locked in Active Directory Sorry! :-) Yes, Jenkins is running on Red Hat Linux (apparently Red Hat Enterprise Linux Server release 5.8 (Tikanga)) Best regards, Eric -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Slide Gesendet: Freitag, 8. Juni 2012 15:30 An: [hidden email] Betreff: Re: Jenkins CLI user gets locked in Active Directory Is this running on Linux? More information about your platforms and such would be useful. On Tue, Jun 5, 2012 at 5:58 AM, Lewis, Eric <[hidden email]> wrote: > Hi > > We have a user called Service_Build which is used for issuing Jenkins CLI commands (either in bash or in Jenkins). > This user is defined in Active Directory, which is what we use for authentication. So normally, I can log in as this user and I have administrator rights in Jenkins. > > I followed the documentation in the Jenkins wiki and (with help from Rob Mandeville) managed to authenticate the Service_Build user with public/private key credentials. So that part works well. > > However, it looks like Jenkins is still trying to authenticate that user with Active Directory, because the user is locked in Active Directory after a number of CLI commands (eight in our case). > Should I have created the private key using the Active Directory password? Or how can I prevent that Active Directory locking? > > Best regards, > Eric -- Website: http://earl-of-code.com |
«
Return to Jenkins users
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |