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

"Remember me" doesn't work with Active Directory plugin

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • None
    • Debian Squeeze on Linux qa01 2.6.26-2-vserver-amd64 #1 SMP Tue Jan 25 06:09:17 UTC 2011 x86_64 GNU/Linux
      Mac OS X 10.7.3 x86_64
      FC13, Tomcat 6, Jenkins 1.480.2

      When clicking the "Remember me on this computer" during login, after some time the user is logged out.

      I'm using Active Directory as Security Realm.

      Example protocol:

      I logged in at 09:19 and checked the "Remember me on this computer" checkbox.

      At 10:10 I freshly opened the jenkins front page again and I was logged it.

      At 11:38 again, and I found myself logged out.

      All tests were conducted with Firefox 4, accepting cookies and such.

      This is reproducible on an installation via Debian package. At the time of writing the version number is 1.405

          [JENKINS-9258] "Remember me" doesn't work with Active Directory plugin

          Ryan Murfitt added a comment -

          I also get this issue, using as a windows service

          Ryan Murfitt added a comment - I also get this issue, using as a windows service

          Simon Wiest added a comment -

          Are you running several Hudson instances on the same server, but on different ports (e.g. myserver:8080, myserver:8081, myserver:8082)?

          The browser cookies that are used to track your successful login unfortunately only store the server name of the URL (e.g. myserver), but not the port (e.g. 8080, 8081, 8082). Thus, if you log into the Hudson instance of server myserver:8080 and then into myserver:8081, the browser cookie for 'myserver' will now track your session on myserver:8081. This essentially logs you out of myserver:8080.

          Simon Wiest added a comment - Are you running several Hudson instances on the same server, but on different ports (e.g. myserver:8080, myserver:8081, myserver:8082)? The browser cookies that are used to track your successful login unfortunately only store the server name of the URL (e.g. myserver), but not the port (e.g. 8080, 8081, 8082). Thus, if you log into the Hudson instance of server myserver:8080 and then into myserver:8081, the browser cookie for 'myserver' will now track your session on myserver:8081. This essentially logs you out of myserver:8080.

          mfn added a comment -

          In my case, no, I'm only running on instance at one port on a given hostname.

          More specific, I'm running the Debian package on port 8081 but accessing it via apache on port 80 with mod_proxy, my virtualhost looks like this:

          <VirtualHost *:80>
              ServerName jenkins.qa01
              ServerAlias jenkins.qa01
              ProxyRequests Off
              <Proxy *>
                  Order deny,allow
                  Allow from all
              </Proxy>
              ProxyPreserveHost on
              ProxyPass / http://localhost:8081/ retry=1
          </VirtualHost>

          mfn added a comment - In my case, no, I'm only running on instance at one port on a given hostname. More specific, I'm running the Debian package on port 8081 but accessing it via apache on port 80 with mod_proxy, my virtualhost looks like this: <VirtualHost *:80> ServerName jenkins.qa01 ServerAlias jenkins.qa01 ProxyRequests Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPreserveHost on ProxyPass / http://localhost:8081/ retry=1 </VirtualHost>

          James Howe added a comment - - edited

          Firecookie (with Firebug) reports that the Expires date for ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE is invalid.

          Date: Mon, 03 Sep 2012 12:45:56 GMT
          Set-Cookie: ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE=****; Expires=Mon, 17-Sep-12 12:45:56 GMT; Path=/

          Note that the Expires date has hyphens in, which (unlike the Date header) is not valid according to RFC 822.

          James Howe added a comment - - edited Firecookie (with Firebug) reports that the Expires date for ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE is invalid. Date: Mon, 03 Sep 2012 12:45:56 GMT Set-Cookie: ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE=****; Expires=Mon, 17-Sep-12 12:45:56 GMT; Path=/ Note that the Expires date has hyphens in, which (unlike the Date header) is not valid according to RFC 822 .

          Nick Parrish added a comment -

          We see this a lot at our company, too. We are using Jenkins 1.458 and use the Active Directory plugin for authentication.

          We have seen it with clients on various OS / browsers.

          I, too, looked at the cookies on my machine with firecookie, and the "Expires" value for ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE seems valid (it expires a couple weeks from now).

          We run Jenkins on port 8080, but forward port 80 to 8080 using iptables, but no client uses 8080 (that I know of).

          Nick Parrish added a comment - We see this a lot at our company, too. We are using Jenkins 1.458 and use the Active Directory plugin for authentication. We have seen it with clients on various OS / browsers. I, too, looked at the cookies on my machine with firecookie, and the "Expires" value for ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE seems valid (it expires a couple weeks from now). We run Jenkins on port 8080, but forward port 80 to 8080 using iptables, but no client uses 8080 (that I know of).

          Stephane Odul added a comment - - edited

          We run our instance as a simple setup on a ubuntu 10.04 machine. Runs on port 8080 but forwarded from port 80. There is only one url that we use including the port (default, since we use 80 in practice).

          Apparently the trick would be to update web.xml to include this right after the description (or later):

              <session-config>
                <session-timeout>1440</session-timeout> 
              </session-config>

          This would tell WinStone (or Tomcat) to have a session expiration of 24h (24*60=1440). The problem is that it would require to extract jenkins.war, patch web.xml and re-zip jenkins.war. Not very automated to get the autoupdates.

          ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE is set when 'Remember Me' is checked, it seems valid and expire after 2 weeks.

          Stephane Odul added a comment - - edited We run our instance as a simple setup on a ubuntu 10.04 machine. Runs on port 8080 but forwarded from port 80. There is only one url that we use including the port (default, since we use 80 in practice). Apparently the trick would be to update web.xml to include this right after the description (or later): <session-config> <session-timeout>1440</session-timeout> </session-config> This would tell WinStone (or Tomcat) to have a session expiration of 24h (24*60=1440). The problem is that it would require to extract jenkins.war, patch web.xml and re-zip jenkins.war. Not very automated to get the autoupdates. ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE is set when 'Remember Me' is checked, it seems valid and expire after 2 weeks.

          Waldek M added a comment -

          Same here, Jenkins on Linux and different browsers on Win7. Is there a chance to have it fixed?
          Thanks if advance for your response.

          Waldek M added a comment - Same here, Jenkins on Linux and different browsers on Win7. Is there a chance to have it fixed? Thanks if advance for your response.

          Mark Schmitt added a comment -

          Same here too, Jenkins runs on Debian Linux - we always update to the latest version from the jenkins-repository.
          Jenkins is accessed via https on port 8443 (using the JENKINS_ARGS to supply the httpsPort argument, keystore et cetera) and use active directory for authentication.

          If there's any more information I can supply that'd help in analyzing the problem please let me know.

          Mark Schmitt added a comment - Same here too, Jenkins runs on Debian Linux - we always update to the latest version from the jenkins-repository. Jenkins is accessed via https on port 8443 (using the JENKINS_ARGS to supply the httpsPort argument, keystore et cetera) and use active directory for authentication. If there's any more information I can supply that'd help in analyzing the problem please let me know.

          gatrot added a comment -

          This is the most annoying thing about Jenkins at our company.

          I have a pull request that incorporates Stephane Odul's session timeout suggestion (with a default of two days). Please comment on the pull request if you'd like to see it approved. The more comments, the more popular, the better chance it has to make it in to the main line. Thanks!

          https://github.com/jenkinsci/jenkins/pull/674

          gatrot added a comment - This is the most annoying thing about Jenkins at our company. I have a pull request that incorporates Stephane Odul's session timeout suggestion (with a default of two days). Please comment on the pull request if you'd like to see it approved. The more comments, the more popular, the better chance it has to make it in to the main line. Thanks! https://github.com/jenkinsci/jenkins/pull/674

          James Howe added a comment -

          Stephane Odul's solution is just a hack though. The problem is not that the session expires, it's that the remember me feature does not do anything to make you a new one.

          I agree though that it is the most annoying thing about Jenkins and really needs proper dev attention ASAP.

          James Howe added a comment - Stephane Odul's solution is just a hack though. The problem is not that the session expires, it's that the remember me feature does not do anything to make you a new one. I agree though that it is the most annoying thing about Jenkins and really needs proper dev attention ASAP.

          gatrot added a comment -

          Agreed, but I'd prefer a hack over months and months of annoyance for hundreds of developers. Unfortunately, I don't have time to fix the underlying issue.

          gatrot added a comment - Agreed, but I'd prefer a hack over months and months of annoyance for hundreds of developers. Unfortunately, I don't have time to fix the underlying issue.

          Jon Hyman added a comment -

          We upgraded from Jenkins 1.494 to 1.498 and all of the sudden, Remember Me stopped working. The server is running on a small EC2 instance with Amazon's standard AMI. After a few days, I downgraded us back to 1.494 and Remember Me started working again.

          Jon Hyman added a comment - We upgraded from Jenkins 1.494 to 1.498 and all of the sudden, Remember Me stopped working. The server is running on a small EC2 instance with Amazon's standard AMI. After a few days, I downgraded us back to 1.494 and Remember Me started working again.

          Stephane Odul added a comment -

          John, the issue with 1.494 is different and tracked in JENKINS-16278.

          Stephane Odul added a comment - John, the issue with 1.494 is different and tracked in JENKINS-16278 .

          gatrot added a comment -

          Just FYI for those of you who would like to see an immediate fix for this merged into the next version. A debate is happening at https://github.com/jenkinsci/jenkins/pull/674 and chances are that nothing will be done soon if more people aren't interested in a quick solution. Please chime in if you have an opinion.

          gatrot added a comment - Just FYI for those of you who would like to see an immediate fix for this merged into the next version. A debate is happening at https://github.com/jenkinsci/jenkins/pull/674 and chances are that nothing will be done soon if more people aren't interested in a quick solution. Please chime in if you have an opinion.

          It seems to me, that this is related to the way winstone generates the Expires-field for cookies. When using tomcat as a conatiner I can not reproduce the problems described, only using winstone. The differenc is, tomcat uses a four digit year field and winstone uses 2 digits.

          Andreas Vogler added a comment - It seems to me, that this is related to the way winstone generates the Expires-field for cookies. When using tomcat as a conatiner I can not reproduce the problems described, only using winstone. The differenc is, tomcat uses a four digit year field and winstone uses 2 digits.

          Jesse Glick added a comment -

          Jesse Glick added a comment - https://github.com/jenkinsci/winstone/pull/6

          Danny Staple added a comment -

          We are having the same issue here with Tomcat too - or at least the same symptoms, on the current LTS version of Jenkins running on Fc13, Linux, x86_64.
          Browsers are accepting cookies - this is seen by all users.

          Danny Staple added a comment - We are having the same issue here with Tomcat too - or at least the same symptoms, on the current LTS version of Jenkins running on Fc13, Linux, x86_64. Browsers are accepting cookies - this is seen by all users.

          Release 1.502 contains https://github.com/jenkinsci/winstone/pull/6 as well as the fix for JENKINS-16278. Anyone still having problems with this on 1.502?

          Andreas Vogler added a comment - Release 1.502 contains https://github.com/jenkinsci/winstone/pull/6 as well as the fix for JENKINS-16278 . Anyone still having problems with this on 1.502?

          James Howe added a comment -

          No change in behaviour observed with 1.502.
          Still no persistence of login over browser sessions.
          It appears the cookie format was a red herring.

          Has anyone looked into the Active Directory plugin? That seems to be the constant factor for everyone that has this bug.

          James Howe added a comment - No change in behaviour observed with 1.502. Still no persistence of login over browser sessions. It appears the cookie format was a red herring. Has anyone looked into the Active Directory plugin? That seems to be the constant factor for everyone that has this bug.

          Danny Staple added a comment -

          I've not had a moment to try out 1.502 - so cannot confirm this. However - we do not use the active directory plugin in our installation.

          Danny Staple added a comment - I've not had a moment to try out 1.502 - so cannot confirm this. However - we do not use the active directory plugin in our installation.

          Upgraded to 1.502, Active Directory plugin is used.
          Have the same behaviour: "Remember me on this computer" checkbox doesn't work.

          Aleksandr Baramykov added a comment - Upgraded to 1.502, Active Directory plugin is used. Have the same behaviour: "Remember me on this computer" checkbox doesn't work.

          I'll see what I can do to fix this.

          Kenneth Endfinger added a comment - I'll see what I can do to fix this.

          James Howe added a comment -

          I just set a Bind DN in Configure Global Security, and now the feature appears to be working as designed.
          Looks like I was right about the AD plugin...

          James Howe added a comment - I just set a Bind DN in Configure Global Security, and now the feature appears to be working as designed. Looks like I was right about the AD plugin...

          Glen Little added a comment -

          If you don't mind, could you explain in more detail what I might be able to do to get this working? I'm technically literate, but not familiar with Jenkins and Java configuration files!

          Glen Little added a comment - If you don't mind, could you explain in more detail what I might be able to do to get this working? I'm technically literate, but not familiar with Jenkins and Java configuration files!

          James Howe added a comment -

          You go to "Configure Global Security" and set a "Bind DN" in the Advanced Active Directory settings (see the in-line help there). I'm not sure what else I can say.

          James Howe added a comment - You go to "Configure Global Security" and set a "Bind DN" in the Advanced Active Directory settings (see the in-line help there). I'm not sure what else I can say.

          Tim Bellis added a comment -

          I only see the fields 'Domain name' and 'Domain controller' in the Advanced Active Directory Settings (running v1.33 of the Active Directory plugin and Jenkins 1.515).

          Are either of those the fields that you mean?

          Tim Bellis added a comment - I only see the fields 'Domain name' and 'Domain controller' in the Advanced Active Directory Settings (running v1.33 of the Active Directory plugin and Jenkins 1.515). Are either of those the fields that you mean?

          James Howe added a comment - - edited

          No. I've got the same versions and I can see "Domain Name", "Domain controller", "Site", "Bind DN" and "Bind Password" on the "Configure Global Security" page in the "Security Realm" section with "Active Directory" selected, after pressing the "Advanced..." button (which I had to scroll right to find).

          James Howe added a comment - - edited No. I've got the same versions and I can see "Domain Name", "Domain controller", "Site", "Bind DN" and "Bind Password" on the "Configure Global Security" page in the "Security Realm" section with "Active Directory" selected, after pressing the "Advanced..." button (which I had to scroll right to find).

          Tim Bellis added a comment -

          I'm running a system on a single Site (with no slaves). Perhaps that's why I don't see the options.

          Tim Bellis added a comment - I'm running a system on a single Site (with no slaves). Perhaps that's why I don't see the options.

          Glen Little added a comment -

          I only see the two options as well.

          Glen Little added a comment - I only see the two options as well.

          Are those of you who see only the 2 options running your master on Windows? I see only the 2 options on Windows and I see all of the options James Howe mentioned on my Linux masters.

          Justin Harringa added a comment - Are those of you who see only the 2 options running your master on Windows? I see only the 2 options on Windows and I see all of the options James Howe mentioned on my Linux masters.

          Glen Little added a comment -

          Yes, I'm running it on Windows. FWIW, my Jenkins is at 1.516 and the Active Directory plug-in at 1.33. If I do not turn on "ENABLE AUTO REFRESH", then I have to log in frequently throughout the day. With auto refresh turned on, my session is extended all day.

          Is there a setting in the Jenkins "web server" that would simply create JSESSIONID cookies that last longer? That would alleviate the problem. The cookie is set to expire after the "Session" but the server must decide otherwise.

          Glen Little added a comment - Yes, I'm running it on Windows. FWIW, my Jenkins is at 1.516 and the Active Directory plug-in at 1.33. If I do not turn on "ENABLE AUTO REFRESH", then I have to log in frequently throughout the day. With auto refresh turned on, my session is extended all day. Is there a setting in the Jenkins "web server" that would simply create JSESSIONID cookies that last longer? That would alleviate the problem. The cookie is set to expire after the "Session" but the server must decide otherwise.

          Glen Little added a comment -

          Interestingly, doing a google search on "ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE" shows that many other tools and products, not just Jenkins, have been affected by this same issue.

          Glen Little added a comment - Interestingly, doing a google search on "ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE" shows that many other tools and products, not just Jenkins, have been affected by this same issue.

          Tim Bellis added a comment -

          Yes, I'm running my master on Windows. (And I don't see the options that James Howe mentions)

          Tim Bellis added a comment - Yes, I'm running my master on Windows. (And I don't see the options that James Howe mentions)

          James Howe added a comment -

          Assigning to Kohsuke, as active-directory lead.

          James Howe added a comment - Assigning to Kohsuke, as active-directory lead.

          Jens Rydholm added a comment - - edited

          We see this problem as well. Remember me simply doesn't work for us. Our Jenkins (1.519) installation runs on Linux, using our Active Directory for authentication.

          I set up logging for the remember me functionality as described here:
          https://issues.jenkins-ci.org/browse/JENKINS-16278?focusedCommentId=174193&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-174193

          When log in with the remember me checkbox checked, I get the following log record (anonymized MY USERNAME and MY ACTIVE DIRECTORY GROUPS).

          FINE: SecurityContextHolder not populated with remember-me token, as it already contained: 'org.acegisecurity.providers.UsernamePasswordAuthenticationToken@582818fa: Username: hudson.plugins.active_directory.ActiveDirectoryUserDetail@0: Username: [MY USERNAME]; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: [MY ACTIVE DIRECTORY GROUPS]; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@166c8: RemoteIpAddress: [MY WORKSTATION IP]; SessionId: 2F3D23A99F52702EC82F36BBBED3ED32; Granted Authorities: [MY ACTIVE DIRECTORY GROUPS]

          Jens Rydholm added a comment - - edited We see this problem as well. Remember me simply doesn't work for us. Our Jenkins (1.519) installation runs on Linux, using our Active Directory for authentication. I set up logging for the remember me functionality as described here: https://issues.jenkins-ci.org/browse/JENKINS-16278?focusedCommentId=174193&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-174193 When log in with the remember me checkbox checked, I get the following log record (anonymized MY USERNAME and MY ACTIVE DIRECTORY GROUPS). FINE: SecurityContextHolder not populated with remember-me token, as it already contained: 'org.acegisecurity.providers.UsernamePasswordAuthenticationToken@582818fa: Username: hudson.plugins.active_directory.ActiveDirectoryUserDetail@0: Username: [MY USERNAME] ; Password: [PROTECTED] ; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: [MY ACTIVE DIRECTORY GROUPS] ; Password: [PROTECTED] ; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@166c8: RemoteIpAddress: [MY WORKSTATION IP] ; SessionId: 2F3D23A99F52702EC82F36BBBED3ED32; Granted Authorities: [MY ACTIVE DIRECTORY GROUPS]

          aflat added a comment -

          Note that people only seeing 2 options for setting up AD, Kohsuke made a comment in this bug https://issues.jenkins-ci.org/browse/JENKINS-11948 which explains the difference. I do wish you would get all options all the time

          "The behaviour difference you are seeing between your development environment vs production instance is likely because of the OS difference. When Jenkins runs on 32bit Windows, we switch to native ADSI implementation that's better integrated with Windows that's running the user."

          aflat added a comment - Note that people only seeing 2 options for setting up AD, Kohsuke made a comment in this bug https://issues.jenkins-ci.org/browse/JENKINS-11948 which explains the difference. I do wish you would get all options all the time "The behaviour difference you are seeing between your development environment vs production instance is likely because of the OS difference. When Jenkins runs on 32bit Windows, we switch to native ADSI implementation that's better integrated with Windows that's running the user."

          Glen Little added a comment -

          As per the comment above, our server is running 64bit Windows Server 2008 R2.

          Glen Little added a comment - As per the comment above, our server is running 64bit Windows Server 2008 R2.

          m_broida added a comment - - edited

          This is becoming VERY annoying.
          Our Jenkins master (1.542) is a WinServer2008R2 box, has several Windows slaves (WinServer2003 + WinServer2008R2 + a couple Linux boxes). We "authenticate via custom script". Logins work fine.

          I'm using Chrome to view Jenkins. I do NOT close the browser; I don't even close all of the Jenkins tabs (only some of them).
          Every few hours, a page refresh shows I'm no longer logged in.
          Any suggestions? Polite ones, please.

          m_broida added a comment - - edited This is becoming VERY annoying. Our Jenkins master (1.542) is a WinServer2008R2 box, has several Windows slaves (WinServer2003 + WinServer2008R2 + a couple Linux boxes). We "authenticate via custom script". Logins work fine. I'm using Chrome to view Jenkins. I do NOT close the browser; I don't even close all of the Jenkins tabs (only some of them). Every few hours, a page refresh shows I'm no longer logged in. Any suggestions? Polite ones, please.

          James Howe added a comment -

          Move the master to linux, or write a fix for the active directory plugin.

          James Howe added a comment - Move the master to linux, or write a fix for the active directory plugin.

          Chris Bush added a comment - - edited

          I can also confirm that I have this problem on Jenkins 1.509.4, Active Directory 1.33, running on a Windows Server 2012 master node. Most testing was done with the latest version of Chrome. The natives are starting to get restless, so a fix for the Active Directory plugin would be great. And just "moving the master to linux" isn't an option for a lot of people.

          Chris Bush added a comment - - edited I can also confirm that I have this problem on Jenkins 1.509.4, Active Directory 1.33, running on a Windows Server 2012 master node. Most testing was done with the latest version of Chrome. The natives are starting to get restless, so a fix for the Active Directory plugin would be great. And just "moving the master to linux" isn't an option for a lot of people.

          Jens Rydholm added a comment -

          Moving the master to Linux is not an option for us, since our master is the company's main Exchange server.

          What we're doing instead is allowing lots of things to be done in Jenkins without being logged in, but that is far from optimal. Still, it prevents the annoyance of having to log in every time you want to do something, so that is the workaround we ended up choosing.

          Jens Rydholm added a comment - Moving the master to Linux is not an option for us, since our master is the company's main Exchange server. What we're doing instead is allowing lots of things to be done in Jenkins without being logged in, but that is far from optimal. Still, it prevents the annoyance of having to log in every time you want to do something, so that is the workaround we ended up choosing.

          Same on Jenkins 1.544, Active Directory 1.33 on SLES 11. Now I'm using "--sessionTimeout=sane_number_of_minutes" jenkins cmdline switch as a workaround, but still it is a hack.

          Andrey Regentov added a comment - Same on Jenkins 1.544, Active Directory 1.33 on SLES 11. Now I'm using "--sessionTimeout=sane_number_of_minutes" jenkins cmdline switch as a workaround, but still it is a hack.

          James Howe added a comment - Did you try this, Andrey? https://issues.jenkins-ci.org/browse/JENKINS-9258?focusedCommentId=179274&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-179274

          m_broida added a comment -

          Linux is not an option.
          And we do -NOT- use ActiveDirectory.
          We authenticate with a Ruby script. AD is not involved at all.

          Yet Jenkins logs me out after some period of time. Usually a couple of hours, whether inactive or not.
          Note: =I= am the only user of our buildserver that is experiencing the periodic logouts. (Or no-one else is complaining.) At least one other user NEVER gets logged out.

          m_broida added a comment - Linux is not an option. And we do - NOT - use ActiveDirectory. We authenticate with a Ruby script. AD is not involved at all. Yet Jenkins logs me out after some period of time. Usually a couple of hours, whether inactive or not. Note: =I= am the only user of our buildserver that is experiencing the periodic logouts. (Or no-one else is complaining.) At least one other user NEVER gets logged out.

          @James, no I did not because logins worked as supposed (with short usernames) with empty "Bind DN" field and I didn't want to store and update password in one more place (though it is stored not in plaintext).

          Now I tried to do set "Bind DN" and removed the "--sessionTimeout" crutch. WHOAA now it works as supposed, I'm happy, thanks.

          So we can say that (at least for my case) it logins well, but bails out without "bind DN"; logins well and remembers well with "bind DN" set. But how could it be explained?

          Andrey Regentov added a comment - @James, no I did not because logins worked as supposed (with short usernames) with empty "Bind DN" field and I didn't want to store and update password in one more place (though it is stored not in plaintext). Now I tried to do set "Bind DN" and removed the "--sessionTimeout" crutch. WHOAA now it works as supposed, I'm happy, thanks. So we can say that (at least for my case) it logins well, but bails out without "bind DN"; logins well and remembers well with "bind DN" set. But how could it be explained?

          The same problem with LDAP plugin - we are being logged ~ out every hour. No errors in Jenkins log file. It is very annoying! Please find a way to fix this problem!

          Alexander Artemov added a comment - The same problem with LDAP plugin - we are being logged ~ out every hour. No errors in Jenkins log file. It is very annoying! Please find a way to fix this problem!

          Alexander Artemov added a comment - - edited

          Still reproduceble

          Alexander Artemov added a comment - - edited Still reproduceble

          Waldek M added a comment -

          Yes, it still is. And recently, when accessing e.g. job site, users aren't even redirected to login page - they just get an error message.

          Waldek M added a comment - Yes, it still is. And recently, when accessing e.g. job site, users aren't even redirected to login page - they just get an error message.

          Discovering my own comment in JENKINS-11643 that this is disabled in Active Directory plugin when Jenkins cannot load details of users by name. That is, either it needs to be running on Windows (where Jenkins can obtain information about other users through ADSI that uses the host computer's credential) or bind DN/password would have to be provided, where Jenkins can obtain information about other users by using this credential.

          So the cause is at least known.

          Kohsuke Kawaguchi added a comment - Discovering my own comment in JENKINS-11643 that this is disabled in Active Directory plugin when Jenkins cannot load details of users by name. That is, either it needs to be running on Windows (where Jenkins can obtain information about other users through ADSI that uses the host computer's credential) or bind DN/password would have to be provided, where Jenkins can obtain information about other users by using this credential. So the cause is at least known.

          m_broida added a comment - - edited

          What about setups where we do NOT use AD at all?
          We don't even have the ActiveDirectory plugin.

          We validate logins via a local script.
          Yet Jenkins still logs me out several times/day.
          Jenkins 1.542 on Windows.

          m_broida added a comment - - edited What about setups where we do NOT use AD at all? We don't even have the ActiveDirectory plugin. We validate logins via a local script. Yet Jenkins still logs me out several times/day. Jenkins 1.542 on Windows.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          src/main/java/hudson/plugins/active_directory/ActiveDirectorySecurityRealm.java
          http://jenkins-ci.org/commit/active-directory-plugin/4f65a3f926aa857e94ea18b687c806eaabaff270
          Log:
          [JENKINS-11643 JENKINS-9258]

          Revisiting the defensive check needed for JENKINS-11643 in light of making remember me service works (JENKINS-9258)

          I've made changes in the core so that the TokenBasedRememberMeService2.autoLogin consults
          the LastGrantedAuthoritiesProperty of the User object in Jenkins 1.556. So when used with
          newer version of Jenkins, I can making remember me work with AD.

          This fix makes AD plugin behave gracefully with earlier versions, while still allowing me
          to leverage new additions in 1.556.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/java/hudson/plugins/active_directory/ActiveDirectorySecurityRealm.java http://jenkins-ci.org/commit/active-directory-plugin/4f65a3f926aa857e94ea18b687c806eaabaff270 Log: [JENKINS-11643 JENKINS-9258] Revisiting the defensive check needed for JENKINS-11643 in light of making remember me service works ( JENKINS-9258 ) I've made changes in the core so that the TokenBasedRememberMeService2.autoLogin consults the LastGrantedAuthoritiesProperty of the User object in Jenkins 1.556. So when used with newer version of Jenkins, I can making remember me work with AD. This fix makes AD plugin behave gracefully with earlier versions, while still allowing me to leverage new additions in 1.556.

          Changing the title to make sure people don't conflate this with other remember me problems.

          Kohsuke Kawaguchi added a comment - Changing the title to make sure people don't conflate this with other remember me problems.

          Implemented this in Active Directory plugin 1.35 in conjunction with core changes scheduled for 1.556.

          A work around in the mean time is to make sure you have bind DN and password.

          Kohsuke Kawaguchi added a comment - Implemented this in Active Directory plugin 1.35 in conjunction with core changes scheduled for 1.556. A work around in the mean time is to make sure you have bind DN and password.

          aflat added a comment -

          That workaround doesn't work if your master is on a windows 2008 machine, since you can't enter a bind DN/password, since those fields are hidden.

          aflat added a comment - That workaround doesn't work if your master is on a windows 2008 machine, since you can't enter a bind DN/password, since those fields are hidden.

          m_broida added a comment -

          The workaround also won't work if you're not using AD.
          We don't use AD, we use a local script for login.
          Yet Jenkins keeps logging me out, several times each day.
          Why?

          m_broida added a comment - The workaround also won't work if you're not using AD. We don't use AD, we use a local script for login. Yet Jenkins keeps logging me out, several times each day. Why?

          Hari Dara added a comment -

          @Kohsuke We have Jenkins 1.577 installation with AD and have this issue, but I see that your fix went into 1.556 itself. Could I be seeing a corner case?

          Hari Dara added a comment - @Kohsuke We have Jenkins 1.577 installation with AD and have this issue, but I see that your fix went into 1.556 itself. Could I be seeing a corner case?

            kohsuke Kohsuke Kawaguchi
            mfn mfn
            Votes:
            75 Vote for this issue
            Watchers:
            76 Start watching this issue

              Created:
              Updated:
              Resolved: