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

Jenkins internal user in order to be able to log-in under an authentication failure with LDAP AD, ...

XMLWordPrintable

      Having Jenkins administration completely dependent on the availability of an external LDAP server might be a real problem/risk. Jenkins could be accessible even if LDAP/AD/.. server becomes unavailable.

      Basically, this will try to avoid to configure LDAP in Jenkins only to find out it is not working and then no longer be able to login to Jenkins.

      Maybe this can be done as a plugin.

          [JENKINS-29162] Jenkins internal user in order to be able to log-in under an authentication failure with LDAP AD, ...

          Félix Belzunce Arcos created issue -

          Daniel Beck added a comment -

          Issue title makes no sense.

          Daniel Beck added a comment - Issue title makes no sense.

          Daniel Beck added a comment -

          Could probably implemented by caching auth realm data and using that as fallback if there is an error connecting to the live auth realm.

          Daniel Beck added a comment - Could probably implemented by caching auth realm data and using that as fallback if there is an error connecting to the live auth realm.

          Daniel Beck added a comment -

          Not a core issue as authentication is completely done in plugins.

          Adding LDAP plugin component as the issue description specifically refers to that.

          Daniel Beck added a comment - Not a core issue as authentication is completely done in plugins. Adding LDAP plugin component as the issue description specifically refers to that.
          Daniel Beck made changes -
          Component/s New: ldap-plugin [ 17122 ]
          Component/s Original: core [ 15593 ]

          akostadinov added a comment -

          I'd advocate for support of non-LDAP users. Sometimes one needs a machine account to just access jenkins. Setting up an LDAP account might be an issue with IT.

          akostadinov added a comment - I'd advocate for support of non-LDAP users. Sometimes one needs a machine account to just access jenkins. Setting up an LDAP account might be an issue with IT.
          Steven Christenson made changes -
          Rank New: Ranked higher

          Steven Christenson added a comment -

          Good points. We were burned by this issue just recently when our corporate LDAP server experienced issues. Our build and deploy pipeline became invisible since no log in is possible. The maximum cache currently allowed by the LDAP plugin is 1 hour. We need something like 3 days, or a way to have a local login in addition to the LDAP authenticated login.

          Steven Christenson added a comment - Good points. We were burned by this issue just recently when our corporate LDAP server experienced issues. Our build and deploy pipeline became invisible since no log in is possible. The maximum cache currently allowed by the LDAP plugin is 1 hour. We need something like 3 days, or a way to have a local login in addition to the LDAP authenticated login.

          James Nord added a comment -

          You can configure the plugin with multiple LDAP servers so to failover to a backup if the primary goes down. If you only have one LDAP server then I would recommend getting another one - (Steven - your company is not short of LDAP servers).

          There are current non Jenkins workarounds like using a service like MS AD LDS - solutions from other vendors apply also - but this does indeed add to the complexity of getting something like this working adds to support and are less than ideal.
          An API token should still work for script based access in order to reset some configuration - but there appears to be no API for Configure System or Configure Global Security that I could find that would allow you to change this.

          As for the 1 hour maximum (worth a different JIRA - but 3 days sounds a little excessive to me from a security perspective) - PRs welcome to this code

          danielbeck LDAP plugin should already cache this data (assuming you have already authenticated)

          James Nord added a comment - You can configure the plugin with multiple LDAP servers so to failover to a backup if the primary goes down. If you only have one LDAP server then I would recommend getting another one - (Steven - your company is not short of LDAP servers). There are current non Jenkins workarounds like using a service like MS AD LDS - solutions from other vendors apply also - but this does indeed add to the complexity of getting something like this working adds to support and are less than ideal. An API token should still work for script based access in order to reset some configuration - but there appears to be no API for Configure System or Configure Global Security that I could find that would allow you to change this. As for the 1 hour maximum (worth a different JIRA - but 3 days sounds a little excessive to me from a security perspective) - PRs welcome to this code danielbeck LDAP plugin should already cache this data (assuming you have already authenticated)

          Félix Belzunce Arcos added a comment -

          I think the best solution here might be to support multiple security realms with failover.

          https://issues.jenkins-ci.org/browse/JENKINS-15063

          Félix Belzunce Arcos added a comment - I think the best solution here might be to support multiple security realms with failover. https://issues.jenkins-ci.org/browse/JENKINS-15063

            Unassigned Unassigned
            fbelzunc Félix Belzunce Arcos
            Votes:
            46 Vote for this issue
            Watchers:
            36 Start watching this issue

              Created:
              Updated: