• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Trivial Trivial
    • ldap-plugin
    • None
    • Platform: All, OS: All

      Would it be possible to add the following feature: have users in both LDAP and
      the the local Hudson database?

      We currently have most of our users in LDAP, but a few are not in AD (student
      employees, people in other OUs). For these users, we would like to add them as
      local Hudson users, while maintaining the LDAP users. Basically, we want to mix
      the two: LDAP and local Hudson users. Thanks in advance.

      Also, the subcomponent for this issue is not correct; but it wouldn't let me
      submit this without choosing one. Sorry!

          [JENKINS-3404] mix LDAP and local Hudson users

          abrowne created issue -
          Alexander Dvorsky made changes -
          Component/s New: ldap-plugin [ 17122 ]
          Component/s New: security [ 15508 ]

          This would make sense as well to have e.g. a user for automation, which doesn't need to exist in the active directory/ldap directory.
          i would very welcome this as well...

          Alexander Dvorsky added a comment - This would make sense as well to have e.g. a user for automation, which doesn't need to exist in the active directory/ldap directory. i would very welcome this as well...

          This bug have any estimated date?
          As Alexander say make sense, for example I have external user that not exists in the active directory but I want that they can be logged.
          Also, and most important, if my LDAP is down I can't use Jenkins, is really useful have a local account for this circumstance.

          Federico Soria Galvarro added a comment - This bug have any estimated date? As Alexander say make sense, for example I have external user that not exists in the active directory but I want that they can be logged. Also, and most important, if my LDAP is down I can't use Jenkins, is really useful have a local account for this circumstance.

          Another important - at least I think so - use case is, that in case there is an LDAP problem, that needs a config update, I cannot login to jenkins to fix the problem.
          So a "standard" account (the admin or root), that is NOT tied to the configured LDAP is needed.

          Jens Rosenthal added a comment - Another important - at least I think so - use case is, that in case there is an LDAP problem, that needs a config update, I cannot login to jenkins to fix the problem. So a "standard" account (the admin or root), that is NOT tied to the configured LDAP is needed.
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 133477 ] New: JNJira + In-Review [ 174033 ]

          I also would like to add some "Technical SCM Trigger User" that is used when the SCM creates a trigger. Such a user shall not be part of LDAP but just be part of Jenkins user database. This avoids an anonymous account inside Jenkins with Discover+Read privileges.

          This involves either only changing the ldap-plugin or being able to iterate over a list of AbstractPasswordBasedSecurityRealm implementations (as far as I understand).

          This would probably also involve that getSecurityRealm() has to be replaced by some getSecurityRealms() (returning a list of realms).

          The same for setSecurityRealm(SecurityRealm securityRealm).

          Heiko Nardmann added a comment - I also would like to add some "Technical SCM Trigger User" that is used when the SCM creates a trigger. Such a user shall not be part of LDAP but just be part of Jenkins user database. This avoids an anonymous account inside Jenkins with Discover + Read privileges. This involves either only changing the ldap-plugin or being able to iterate over a list of AbstractPasswordBasedSecurityRealm implementations (as far as I understand). This would probably also involve that getSecurityRealm() has to be replaced by some getSecurityRealms() (returning a list of realms). The same for setSecurityRealm(SecurityRealm securityRealm) .

          Sam Zhao added a comment -

          Very appreciate for these features.
          As a system admin, to keep Jenkins platform to high availability is very important.
          If LDAP is down , users will not login Jenkins to do any job.

          Sam Zhao added a comment - Very appreciate for these features. As a system admin, to keep Jenkins platform to high availability is very important. If LDAP is down , users will not login Jenkins to do any job.

          I too would like to have the ability to define a couple of static local users on a Jenkins server, for pretty much the same reasons stated above - automated processes accessing Jenkins, accessing the dashboard when LDAP/AD are down, etc. This would be very helpful.

          Kevin Phillips added a comment - I too would like to have the ability to define a couple of static local users on a Jenkins server, for pretty much the same reasons stated above - automated processes accessing Jenkins, accessing the dashboard when LDAP/AD are down, etc. This would be very helpful.
          Félix Belzunce Arcos made changes -
          Link New: This issue duplicates JENKINS-39065 [ JENKINS-39065 ]
          Félix Belzunce Arcos made changes -
          Assignee New: Félix Belzunce Arcos [ fbelzunc ]
          Resolution New: Duplicate [ 3 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

            Unassigned Unassigned
            abrowne abrowne
            Votes:
            64 Vote for this issue
            Watchers:
            61 Start watching this issue

              Created:
              Updated: