From 4efb1f33391497f9c3c73ebad4359cd469e8cc90 Mon Sep 17 00:00:00 2001 From: Bryan Lima Date: Tue, 18 Jun 2024 10:22:32 -0300 Subject: [PATCH 1/3] Add LDAP upgrade instructions from users coming from 4.19.0 --- source/releasenotes/about.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/source/releasenotes/about.rst b/source/releasenotes/about.rst index 52eb76610f..8a3e13d941 100644 --- a/source/releasenotes/about.rst +++ b/source/releasenotes/about.rst @@ -118,3 +118,17 @@ After identifying the snapshots with a backing store and the related templates, .. parsed-literal:: qemu-img convert -O qcow2 -U --image-opts driver=qcow2,file.filename= -converted + +Issue regarding LDAP authentication on version 4.19.0 +===================================================== + +In version 4.19.0, the encryption of scoped configurations of Accounts and Domains was changed to only encrypt if there were sensitive data (e.g, they belonged to the Hidden or Secure category) as the all configurations for Accounts and Domains were encrypted. However, when using the encrypted values from these scopes, ACS did not correctly decrypt these values. For this reason, a simple solution was to update these configurations to their plain values with manual DB intervention, as reported in issue `#8637`. + +For users that manually set the configurations ``ldap.bind.password`` and ``ldap.truststore.password`` to a plain value in order to fix the faulty behaviour, it is required to store them encrypted. It will not be possible to update the configuration via UI, as an exception will be thrown when ACS tries to decrypt the plain value. To fix this, it is required to set the password again for ACS to encrypt it. There are two options: + +#. Manually set the configuration via CloudMonkey, for example ``update configuration domainid= name="ldap.bind.password" value="password"``; +#. Or, removing the defined configuration through the database via the query ``DELETE from cloud.domain_details WHERE name like "%ldap%password%"``, and setting the configuration via UI for the affected domains. + +After updating these configurations, LDAP authentication should be working as expected. + +.. _`#8637`: https://github.com/apache/cloudstack/pull/8637 \ No newline at end of file From f65730f726ae0e0fbc0b99d3690883e68beffe5d Mon Sep 17 00:00:00 2001 From: Bryan Lima Date: Wed, 19 Jun 2024 08:29:46 -0300 Subject: [PATCH 2/3] Add description that the issue has been fixed and fix some typos --- source/releasenotes/about.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/releasenotes/about.rst b/source/releasenotes/about.rst index 8a3e13d941..f242dc9b02 100644 --- a/source/releasenotes/about.rst +++ b/source/releasenotes/about.rst @@ -122,9 +122,9 @@ After identifying the snapshots with a backing store and the related templates, Issue regarding LDAP authentication on version 4.19.0 ===================================================== -In version 4.19.0, the encryption of scoped configurations of Accounts and Domains was changed to only encrypt if there were sensitive data (e.g, they belonged to the Hidden or Secure category) as the all configurations for Accounts and Domains were encrypted. However, when using the encrypted values from these scopes, ACS did not correctly decrypt these values. For this reason, a simple solution was to update these configurations to their plain values with manual DB intervention, as reported in issue `#8637`. +In version 4.19.0, the encryption of scoped configurations of Accounts and Domains was changed to only encrypt if there were sensitive data (e.g, they belonged to the Hidden or Secure category) as all configurations for Accounts and Domains were encrypted in previous versions. However, when using the encrypted values from these scopes, ACS did not correctly decrypt these values. For this reason, a simple solution was to update these configurations to their plain values with manual DB intervention, as reported in issue `#8637`. -For users that manually set the configurations ``ldap.bind.password`` and ``ldap.truststore.password`` to a plain value in order to fix the faulty behaviour, it is required to store them encrypted. It will not be possible to update the configuration via UI, as an exception will be thrown when ACS tries to decrypt the plain value. To fix this, it is required to set the password again for ACS to encrypt it. There are two options: +This issue has been fixed in Apache CloudStack 4.19.1.0. However, for users that manually set the configurations ``ldap.bind.password`` and ``ldap.truststore.password`` to a plain value in order to fix the faulty behaviour, it is required to store them encrypted. It will not be possible to update the configuration via UI, as an exception will be thrown when ACS tries to decrypt the plain value. To fix this, it is required to set the password again for ACS to encrypt it. There are two options: #. Manually set the configuration via CloudMonkey, for example ``update configuration domainid= name="ldap.bind.password" value="password"``; #. Or, removing the defined configuration through the database via the query ``DELETE from cloud.domain_details WHERE name like "%ldap%password%"``, and setting the configuration via UI for the affected domains. From 02fd29808be1e454b7a817e9590a58d80d2cc833 Mon Sep 17 00:00:00 2001 From: Bryan Lima Date: Wed, 19 Jun 2024 08:31:35 -0300 Subject: [PATCH 3/3] Add more context --- source/releasenotes/about.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/releasenotes/about.rst b/source/releasenotes/about.rst index f242dc9b02..3b57dbbb38 100644 --- a/source/releasenotes/about.rst +++ b/source/releasenotes/about.rst @@ -124,7 +124,7 @@ Issue regarding LDAP authentication on version 4.19.0 In version 4.19.0, the encryption of scoped configurations of Accounts and Domains was changed to only encrypt if there were sensitive data (e.g, they belonged to the Hidden or Secure category) as all configurations for Accounts and Domains were encrypted in previous versions. However, when using the encrypted values from these scopes, ACS did not correctly decrypt these values. For this reason, a simple solution was to update these configurations to their plain values with manual DB intervention, as reported in issue `#8637`. -This issue has been fixed in Apache CloudStack 4.19.1.0. However, for users that manually set the configurations ``ldap.bind.password`` and ``ldap.truststore.password`` to a plain value in order to fix the faulty behaviour, it is required to store them encrypted. It will not be possible to update the configuration via UI, as an exception will be thrown when ACS tries to decrypt the plain value. To fix this, it is required to set the password again for ACS to encrypt it. There are two options: +This issue has been fixed in Apache CloudStack 4.19.1.0. However, for users that manually set the configurations ``ldap.bind.password`` and ``ldap.truststore.password`` to a plain value in order to fix the faulty behaviour, it is required to store them encrypted after upgrading to version 4.19.1 and onwards. It will not be possible to update the configuration via UI, as an exception will be thrown when ACS tries to decrypt the plain value. To fix this, it is required to set the password again for ACS to encrypt it. There are two options: #. Manually set the configuration via CloudMonkey, for example ``update configuration domainid= name="ldap.bind.password" value="password"``; #. Or, removing the defined configuration through the database via the query ``DELETE from cloud.domain_details WHERE name like "%ldap%password%"``, and setting the configuration via UI for the affected domains.