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

LDAP Manager DN and password are REQUIRED (security risk)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Fixed
    • Component/s: _unsorted
    • Labels:
      None
    • Environment:
      Platform: All, OS: Linux
    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            remke 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.

            Show
            remke 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.
            Hide
            remke 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.

            Show
            remke 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.
            Hide
            mindless 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.

            Show
            mindless 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.
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            Hide
            ungborib Touch Ungboriboonpisal added a comment -

            Thanks, mindless. Will this be part of 1.361?

            Show
            ungborib Touch Ungboriboonpisal added a comment - Thanks, mindless. Will this be part of 1.361?
            Hide
            mindless Alan Harder added a comment -

            correct

            Show
            mindless Alan Harder added a comment - correct
            Hide
            hujirong 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>

            Show
            hujirong 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>

              People

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

                Dates

                Created:
                Updated:
                Resolved: