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

LDAP Manager DN and password are REQUIRED (security risk)

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • _unsorted
    • None
    • Platform: All, OS: Linux

      Using the 1.301 Hudson war under glassfish v2 with LDAP enabled results in
      Hudson supplying erroneous manager DN and manager password if these fields are
      left blank. When filling in the form all is well with the auto verification
      that taks place while one is filing in the form. However, after hitting the
      save button, then coming back to the LDAP configuration area of the Manage
      Hudson form, both the Manager DN and the Manager Password will have default
      values. The value are incorrect and seem to be drawn from the Authorization Matrix.

      The net result is that I have to fill in correct values despite my LDAP
      configuration not requiring BINDING prior to querying.

      I tried placing correct values in those two fields and saving the form then
      logging out then back in to make sure all is well then clearing those fields and
      saving the form. My intent was perhaps to reset some internal flag. This did
      not work. The same erroneous values popped back into the form upon navigating
      back to the form after having saved the form with the empty entries in those two
      fields.

      This is a security risk. I do not want to have to supply the admin DN and password.

          [JENKINS-3586] LDAP Manager DN and password are REQUIRED (security risk)

          remke added a comment -

          I think I am experiencing the same issue in Hudson 1.313.

          My setup is:
          <version>1.313</version>
          <numExecutors>2</numExecutors>
          <mode>NORMAL</mode>
          <useSecurity>true</useSecurity>
          <authorizationStrategy
          class="hudson.security.FullControlOnceLoggedInAuthorizationStrategy"/>
          <securityRealm class="hudson.security.LDAPSecurityRealm">
          <server>x.x.x.x</server>
          <rootDN>yyyyyy</rootDN>
          <userSearchBase></userSearchBase>
          <userSearch>cn=

          {0}

          </userSearch>
          </securityRealm>

          Now, I execute the following scenario:

          • go to Hudson
          • log in with a valid account
          • go to 'Configure Hudson' (I have a Dutch version, I am not sure of the English
            menu entry)
          • go to 'Configure System'
          • the page shows up, but in the LDAP section there is an error: Unable to
            connect to 172.20.0.10: javax.naming.InvalidNameException: [LDAP: error code 34
          • Invalid DN Syntax]
          • I click on the 'Uitgebreid...' (Advanced...?) button in the LDAP section
          • now the Manager DN field contains my login name and the manager password field
            contains asterisks (probably representing my password), both fields also show
            the same error: Unable to connect to 172.20.0.10:
            javax.naming.InvalidNameException: [LDAP: error code 34 - Invalid DN Syntax]

          If I save the config page without changing the LDAP settings (possibly changing
          other settings), my LDAP config becomes invalid and I cannot log back in. I then
          need to manyally modify config.xml and restart hudson to make things work again.

          If I save the config page after emptying the Manager DN and Manager
          passwordsfields, everything works fine.

          At the moment, my workaround is:
          Whenever changing something on the 'Configure System'-page, make sure the
          Manager DN and Manager password fields are emptied.

          remke added a comment - I think I am experiencing the same issue in Hudson 1.313. My setup is: <version>1.313</version> <numExecutors>2</numExecutors> <mode>NORMAL</mode> <useSecurity>true</useSecurity> <authorizationStrategy class="hudson.security.FullControlOnceLoggedInAuthorizationStrategy"/> <securityRealm class="hudson.security.LDAPSecurityRealm"> <server>x.x.x.x</server> <rootDN>yyyyyy</rootDN> <userSearchBase></userSearchBase> <userSearch>cn= {0} </userSearch> </securityRealm> Now, I execute the following scenario: go to Hudson log in with a valid account go to 'Configure Hudson' (I have a Dutch version, I am not sure of the English menu entry) go to 'Configure System' the page shows up, but in the LDAP section there is an error: Unable to connect to 172.20.0.10: javax.naming.InvalidNameException: [LDAP: error code 34 Invalid DN Syntax] I click on the 'Uitgebreid...' (Advanced...?) button in the LDAP section now the Manager DN field contains my login name and the manager password field contains asterisks (probably representing my password), both fields also show the same error: Unable to connect to 172.20.0.10: javax.naming.InvalidNameException: [LDAP: error code 34 - Invalid DN Syntax] If I save the config page without changing the LDAP settings (possibly changing other settings), my LDAP config becomes invalid and I cannot log back in. I then need to manyally modify config.xml and restart hudson to make things work again. If I save the config page after emptying the Manager DN and Manager passwordsfields, everything works fine. At the moment, my workaround is: Whenever changing something on the 'Configure System'-page, make sure the Manager DN and Manager password fields are emptied.

          remke added a comment -

          Today I upgraded Hudson from 1.314 to 1.342.
          Then I checked the 'Configure System' page to see if I still got the same error.
          The situation as described in my previous comment was still there.
          The strange thing is: even though I had not specified a Manager DN and manager password in my previous save (they were also not present in config.xml) my old entries kept popping up in the gui.
          Nowing about more about LDAP DN's now, I realized that the entry I had once given in the Manager DN field was indeed invalid. It only contained my login name, not a full DN.

          What I did was:
          Fix the entry under Manager DN to contain my full DN. Entered the correct password under manager password. Saved the Hudson config.
          After these actions, everything worked.

          Since our LDAP also works without specifying Manager DN and Manager password, the next thing I did was:

          • go to 'configure system'
          • check the 'advanced' LDAP section
          • clear the Manager DN and Manager password fields
          • save config

          Now logging in still works.

          Next:

          • go to 'configure system'
          • check the 'advanced' LDAP section
          • et voila: the Manager DN and Manger password fields are empty! This is what I expected, because I submitted empty fields on the previous save.

          To sum up:
          1) I originally entered incorrect values myself in Manager DN. My fault.
          2) I discovered I did not need a Manager DN and password at all, so I cleared them.
          3) Log in works! Manager DN and password are cleared in the config.xml
          4) The next time I entered System config the old incorrect values showed up again. They must have been cached somewhere...

          I think number 4 indicates a bug. After clearing the fields the old incorrect values should not show up again. However, since it is a bug that only shows up after the administrator makes an invalid entry, I think it is a minor bug.

          remke added a comment - Today I upgraded Hudson from 1.314 to 1.342. Then I checked the 'Configure System' page to see if I still got the same error. The situation as described in my previous comment was still there. The strange thing is: even though I had not specified a Manager DN and manager password in my previous save (they were also not present in config.xml) my old entries kept popping up in the gui. Nowing about more about LDAP DN's now, I realized that the entry I had once given in the Manager DN field was indeed invalid. It only contained my login name, not a full DN. What I did was: Fix the entry under Manager DN to contain my full DN. Entered the correct password under manager password. Saved the Hudson config. After these actions, everything worked. Since our LDAP also works without specifying Manager DN and Manager password, the next thing I did was: go to 'configure system' check the 'advanced' LDAP section clear the Manager DN and Manager password fields save config Now logging in still works. Next: go to 'configure system' check the 'advanced' LDAP section et voila: the Manager DN and Manger password fields are empty! This is what I expected, because I submitted empty fields on the previous save. To sum up: 1) I originally entered incorrect values myself in Manager DN. My fault. 2) I discovered I did not need a Manager DN and password at all, so I cleared them. 3) Log in works! Manager DN and password are cleared in the config.xml 4) The next time I entered System config the old incorrect values showed up again. They must have been cached somewhere... I think number 4 indicates a bug. After clearing the fields the old incorrect values should not show up again. However, since it is a bug that only shows up after the administrator makes an invalid entry, I think it is a minor bug.

          Alan Harder added a comment -

          Can someone test to determine if the data in those fields comes from Hudson, or from the browser doing some auto-filling of form fields? (I suspect the latter)
          You can do "view source" of the page and see if those fields actually have value="..." with those values.. you can also test with a different browser or disable auto-form-filling in your browser to see if that changes the behavior. Thanks.

          Alan Harder added a comment - Can someone test to determine if the data in those fields comes from Hudson, or from the browser doing some auto-filling of form fields? (I suspect the latter) You can do "view source" of the page and see if those fields actually have value="..." with those values.. you can also test with a different browser or disable auto-form-filling in your browser to see if that changes the behavior. Thanks.

          Code changed in hudson
          User: : mindless
          Path:
          trunk/hudson/main/core/src/main/resources/hudson/security/LDAPSecurityRealm/config.jelly
          trunk/hudson/main/core/src/main/resources/lib/form/password.jelly
          trunk/www/changelog.html
          http://jenkins-ci.org/commit/31540
          Log:
          [FIXED JENKINS-3586] add autocomplete="off" for LDAP managerDN and managerPassword fields,
          to avoid unintended data being saved there.
          Convert f:password to use MorphTagLibrary (like f:textbox does) so it can accept
          arbitrary fields, like autocomplete.

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/main/core/src/main/resources/hudson/security/LDAPSecurityRealm/config.jelly trunk/hudson/main/core/src/main/resources/lib/form/password.jelly trunk/www/changelog.html http://jenkins-ci.org/commit/31540 Log: [FIXED JENKINS-3586] add autocomplete="off" for LDAP managerDN and managerPassword fields, to avoid unintended data being saved there. Convert f:password to use MorphTagLibrary (like f:textbox does) so it can accept arbitrary fields, like autocomplete.

          Thanks, mindless. Will this be part of 1.361?

          Touch Ungboriboonpisal added a comment - Thanks, mindless. Will this be part of 1.361?

          Alan Harder added a comment -

          correct

          Alan Harder added a comment - correct

          Jirong Hu added a comment -

          I resolve my problem with this approach:http://forum.spring.io/forum/spring-projects/data/ldap/63263-active-directory-ldap-authentication-ldap-error-32

          Below is my setting:

          <useSecurity>true</useSecurity>
          <authorizationStrategy class="hudson.security.FullControlOnceLoggedInAuthorizationStrategy"/>
          <securityRealm class="hudson.security.LDAPSecurityRealm" plugin="ldap@1.1">
          <server>office.adroot.xxx.net:389</server>
          <rootDN></rootDN>
          <inhibitInferRootDN>false</inhibitInferRootDN>
          <userSearchBase>DC=office,DC=adroot,DC=xxx,DC=net</userSearchBase>
          <userSearch>sAMAccountName=

          {0}

          </userSearch>
          <groupSearchBase>DC=office,DC=adroot,DC=xxx,DC=net</groupSearchBase>
          <managerDN>cn=svnldapuser,ou=service accounts,ou=domain administration,DC=office,DC=adroot,DC=xxx,DC=net</managerDN>
          <managerPassword>MUJtb1BhOTl3b3JkTA==</managerPassword>
          </securityRealm>

          Jirong Hu added a comment - I resolve my problem with this approach: http://forum.spring.io/forum/spring-projects/data/ldap/63263-active-directory-ldap-authentication-ldap-error-32 Below is my setting: <useSecurity>true</useSecurity> <authorizationStrategy class="hudson.security.FullControlOnceLoggedInAuthorizationStrategy"/> <securityRealm class="hudson.security.LDAPSecurityRealm" plugin="ldap@1.1"> <server>office.adroot.xxx.net:389</server> <rootDN></rootDN> <inhibitInferRootDN>false</inhibitInferRootDN> <userSearchBase>DC=office,DC=adroot,DC=xxx,DC=net</userSearchBase> <userSearch>sAMAccountName= {0} </userSearch> <groupSearchBase>DC=office,DC=adroot,DC=xxx,DC=net</groupSearchBase> <managerDN>cn=svnldapuser,ou=service accounts,ou=domain administration,DC=office,DC=adroot,DC=xxx,DC=net</managerDN> <managerPassword>MUJtb1BhOTl3b3JkTA==</managerPassword> </securityRealm>

            mindless Alan Harder
            jesterfred jesterfred
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: