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

Saving the security configuration form changes the Active Directory password in config.xml

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • None
    • Jenkins Version 2.479.3 running on Debian Bookworm.

      When saving the security configuration, the already encrypted Active Directory password of the Jenkins config.xml was re-encrypted. As a result, the account could no longer connect to the domain and all users no longer had access to the Jenkins Server. In addition, a port was added to the address.
      We had to import a backup to be able to use Jenkins again.

          [JENKINS-75237] Saving the security configuration form changes the Active Directory password in config.xml

          Steffen created issue -
          Steffen made changes -
          Description Original: When adding the groups on the Matrix based UI, the already encrypted password of the Jenkins config.xml was re-encrypted. As a result, the account could no longer connect to the domain and all users no longer had access to the Bronco. In addition, a port was added to the address.
          We had to import a backup to be able to use jenkins again.
          New: When adding the groups on the Matrix based UI, the already encrypted password of the Jenkins config.xml was re-encrypted. As a result, the account could no longer connect to the domain and all users no longer had access to the Jenkins Server. In addition, a port was added to the address.
          We had to import a backup to be able to use jenkins again.

          Daniel Beck added a comment -

          When saving a configuration form, not just actual changes, but everything is saved. Based on the description, this looks like a problem in the unspecified security realm configuration form. Without more details, it's impossible to help you; it's however very unlikely that matrix-auth is the culprit, it's just what motivated you saving the configuration.

          Given https://en.wikipedia.org/wiki/Bronco_(disambiguation) reveals no useful technology-related terms: Please note that you're reporting this issue to the Jenkins project. This is not an issue tracker internal to your organization.

          Daniel Beck added a comment - When saving a configuration form, not just actual changes, but everything is saved. Based on the description, this looks like a problem in the unspecified security realm configuration form. Without more details, it's impossible to help you; it's however very unlikely that matrix-auth is the culprit, it's just what motivated you saving the configuration. Given https://en.wikipedia.org/wiki/Bronco_(disambiguation) reveals no useful technology-related terms: Please note that you're reporting this issue to the Jenkins project. This is not an issue tracker internal to your organization.

          Daniel Beck added a comment -

          While there may be a bug here, it's extremely unlikely to be in matrix-auth, so closing this issue.

          Daniel Beck added a comment - While there may be a bug here, it's extremely unlikely to be in matrix-auth , so closing this issue.
          Daniel Beck made changes -
          Resolution New: Not A Defect [ 7 ]
          Status Original: Open [ 1 ] New: Closed [ 6 ]
          Steffen made changes -
          Attachment New: Bild (2).png [ 63913 ]

          Steffen added a comment -

          Bronco is the name of our Jenkins server, I changed it in the text shortly after it was created.
          Where should we put the bug if not on matrix-auth?

          Steffen added a comment - Bronco is the name of our Jenkins server, I changed it in the text shortly after it was created. Where should we put the bug if not on matrix-auth?

          Daniel Beck added a comment -

           Where should we put the bug if not on matrix-auth?

          I don't know, you haven't provided enough information yet. As I mentioned in my first comment, it's not even clear what your security realm is. The screenshot indicates there's a problem with the current configuration already before you submit the form.

          I suggest you find someone to assist you with narrowing down the cause of this problem if you don't know how to do that yourself. The forum at community.jenkins.io or Gitter/Matrix chat might be good locations to get started.

          Daniel Beck added a comment -  Where should we put the bug if not on matrix-auth? I don't know, you haven't provided enough information yet. As I mentioned in my first comment, it's not even clear what your security realm is. The screenshot indicates there's a problem with the current configuration already before you submit the form. I suggest you find someone to assist you with narrowing down the cause of this problem if you don't know how to do that yourself. The forum at community.jenkins.io or Gitter/Matrix chat might be good locations to get started.

          Steffen added a comment -

          It's as simple as it sounds, as soon as I add a group to the matrix, all groups lose their access.
          By saving and reloading this page, you can see the error in the image. 
          Before adding a new group there was of course no error.
          If you then log out, you cannot log in again. Neither can any other user.

          Reason for this:
          In the Jenkins config.xml not only the added group is added, but also the encrypted password, which establishes the communication with the domain, is changed. As a result, access is lost for all user groups.

          Workaround for us:
          Add groups manually in config.xml. Do not use the matrix-auth.

          Steffen added a comment - It's as simple as it sounds, as soon as I add a group to the matrix, all groups lose their access. By saving and reloading this page, you can see the error in the image.  Before adding a new group there was of course no error. If you then log out, you cannot log in again. Neither can any other user. Reason for this: In the Jenkins config.xml not only the added group is added, but also the encrypted password, which establishes the communication with the domain, is changed. As a result, access is lost for all user groups. Workaround for us: Add groups manually in config.xml. Do not use the matrix-auth.

          Daniel Beck added a comment -

          It's as simple as it sounds, as soon as I add a group to the matrix, all groups lose their access.
          By saving and reloading this page, you can see the error in the image. 
          Before adding a new group there was of course no error.
          If you then log out, you cannot log in again. Neither can any other user.

          Could you confirm that the same problem does not occur when you don't change groups, but still save/submit the configuration form?

          What is the config.xml content

          • before submission
          • after submission (no changes)
          • after submission (add a group)

          ?

          Daniel Beck added a comment - It's as simple as it sounds, as soon as I add a group to the matrix, all groups lose their access. By saving and reloading this page, you can see the error in the image.  Before adding a new group there was of course no error. If you then log out, you cannot log in again. Neither can any other user. Could you confirm that the same problem does not occur when you don't change groups, but still save/submit the configuration form? What is the config.xml content before submission after submission (no changes) after submission (add a group) ?

            fbelzunc FĂ©lix Belzunce Arcos
            tea_steffen Steffen
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: