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

Details

    Description

      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.

      Attachments

        Issue Links

          Activity

            danielbeck Daniel Beck added a comment -

            Issue title makes no sense.

            danielbeck Daniel Beck added a comment - Issue title makes no sense.
            danielbeck 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.

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

            danielbeck 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.
            akostadinov 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 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.

            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_at_cisco 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.
            teilo 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)

            teilo 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)

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

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

            fbelzunc 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
            dapoppa Harry Johnson added a comment -

            As a comment to this, JIRA allows this sort of authentication - you can log in with both external LDAP and an internal user - whatever you need. This is useful if you need to edit the LDAP definition in JIRA, by logging in using the internal user.

            As I was trying to set up Jenkins recently as a new install, I kept having issues with LDAP/AD in Jenkins and kept getting locked out. Had to turn off security constantly while I worked out the issues. Would have been nice to have an internal login available.
            btw, I eventually abandoned the LDAP/AD plugins as non-functioning and went with the CROWD2 plugin for JIRA.

            dapoppa Harry Johnson added a comment - As a comment to this, JIRA allows this sort of authentication - you can log in with both external LDAP and an internal user - whatever you need. This is useful if you need to edit the LDAP definition in JIRA, by logging in using the internal user. As I was trying to set up Jenkins recently as a new install, I kept having issues with LDAP/AD in Jenkins and kept getting locked out. Had to turn off security constantly while I worked out the issues. Would have been nice to have an internal login available. btw, I eventually abandoned the LDAP/AD plugins as non-functioning and went with the CROWD2 plugin for JIRA.
            bjoern_martin Björn Martin added a comment -

            Just voted - specifically for dapoppa s proposal: I had the exact same issue while trying to get LDAP working with a test installation.

            bjoern_martin Björn Martin added a comment - Just voted - specifically for dapoppa s proposal: I had the exact same issue while trying to get LDAP working with a test installation.

            Same problem here with Active Directory with Kerberos as external realm.

            If the user could not be found in keberos or sso with kerberos configuration is wrong a fall back to Jenkins’ own user database should be used.

            OpenNMS uses a hybrid security provider with spring security for this approach.

            grueni Andreas Grüninger added a comment - Same problem here with Active Directory with Kerberos as external realm. If the user could not be found in keberos or sso with kerberos configuration is wrong a fall back to Jenkins’ own user database should be used. OpenNMS uses a hybrid security provider with spring security for this approach.
            stefanrink Stefan Rink added a comment -

            I would also need the possibility of fallback to Jenkins' own user database, or at least to a single fallback user (like the AD plugin does). 

            If I implemented this, could I expect the respective pull request to be merged in? Which conditions / coding guidelines would I have to adhere to?

            stefanrink Stefan Rink added a comment - I would also need the possibility of fallback to Jenkins' own user database, or at least to a single fallback user (like the AD plugin does).  If I implemented this, could I expect the respective pull request to be merged in? Which conditions / coding guidelines would I have to adhere to?
            faucherb94 Ben Faucher added a comment -

            I'll add another voice to the pile for this. I need failover to internal specifically for the admin account, and bot accounts for API keys for automation.

            faucherb94 Ben Faucher added a comment - I'll add another voice to the pile for this. I need failover to internal specifically for the admin account, and bot accounts for API keys for automation.
            kdushyant02 Dushyant K added a comment -

            Even we are looking failover realm functionality which help to login via admin account if we have any LDAP authentication user issue/ credential changes. At least we should have admin user login alone with other realm authentication mechanism.
            So I would like know, is there anyone who can help/guideline for above requirements.  

            kdushyant02 Dushyant K added a comment - Even we are looking failover realm functionality which help to login via admin account if we have any LDAP authentication user issue/ credential changes. At least we should have admin user login alone with other realm authentication mechanism. So I would like know, is there anyone who can help/guideline for above requirements.  
            orzechszek orzech szek added a comment -

            Any news with such requirement?

            orzechszek orzech szek added a comment - Any news with such requirement?
            romanz Roman Zwi added a comment -

            Active Directory Plugin has an option for a fallback user since V2.5

            romanz Roman Zwi added a comment - Active Directory Plugin has an option for a fallback user since V2.5
            bogey Bogdan added a comment -

            romanz Am I missing something? The latest release for AD plugin is v.2.25

            bogey Bogdan added a comment - romanz  Am I missing something? The latest release  for AD plugin is v.2.25
            danielbeck Daniel Beck added a comment -

            2.5 was released in 2017.

            Just in case, these version numbers are based on numeric segments, so the version after 2.9 is 2.10.

            danielbeck Daniel Beck added a comment - 2.5 was released in 2017. Just in case, these version numbers are based on numeric segments, so the version after 2.9 is 2.10.
            romanz Roman Zwi added a comment -

            Mixing Security Realm Plugin might get interesting in this context...

            romanz Roman Zwi added a comment - Mixing Security Realm Plugin might get interesting in this context...
            peachy_devops Loren Alatan added a comment -

            Hi romanz Good Day! It looks like https://plugins.jenkins.io/mixing-security-realm/ does not work on latest Jenkins Jenkins 2.346.2. Would you know to contact for this? Thank you.

            peachy_devops Loren Alatan added a comment - Hi romanz Good Day! It looks like https://plugins.jenkins.io/mixing-security-realm/ does not work on latest Jenkins Jenkins 2.346.2 . Would you know to contact for this? Thank you.
            romanz Roman Zwi added a comment -

            Hi peachy_devops
            I'm sorry I don't know anything about it, I just stumbled over it in the search.
            But there seems to be an open pull request in GitHub for a while.

            romanz Roman Zwi added a comment - Hi peachy_devops I'm sorry I don't know anything about it, I just stumbled over it in the search. But there seems to be an open pull request in GitHub for a while.

            Yes, this feature is also dearly needed by us.

            robertschulze Robert Schulze added a comment - Yes, this feature is also dearly needed by us.

            People

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

              Dates

                Created:
                Updated: