Hello,
We have a question related with the pw-sha2 module. We have deployed OpenLDAP2.4.46-9.31.1 on SLES15 SP2 from the official Suse Repository and we are able to use {CRYPT} {MD5} {SMD5} {SSHA} and {SHA}.
We are awared that in order to support SHA-256 we have to load the contrib module named pw-sha2 which it was included on SLES12SP5 but is totally missing on SLES15SP2 package. This means that we would need to compile it, but due to limitations of the project we are working on we are not allowed to compile anything external.
So I checked the changelog and I found that support was added on 2.4.32 release.
Is it possible that the openldap2 package could have been compiled with the module features itself and I just need to add some kind of attribute or entry to my LDAP directory in order to enable it?
We have tried to use Apache Directory Studio instead of slappasswd and we have set up a password to SHA256 but the bind won't work. Instead, CRYPT-SHA256 works so I can't figure out why.
I suppose I'm totally misunderstanding this and the compilation of the module is required, but a little light ray of hope is there.
Thank you so much. Regards.
P Please consider the environment before printing this e-mail.
--On Thursday, March 18, 2021 8:32 AM +0000 Dario García Díaz-Miguel dgdiaz@gmv.com wrote:
Is it possible that the openldap2 package could have been compiled with the module features itself and I just need to add some kind of attribute or entry to my LDAP directory in order to enable it?
We have tried to use Apache Directory Studio instead of slappasswd and we have set up a password to SHA256 but the bind won't work. Instead, CRYPT-SHA256 works so I can't figure out why.
I suppose I'm totally misunderstanding this and the compilation of the module is required, but a little light ray of hope is there.
The SHA2 password module is a contrib module, so it is not built by default. At this point, it's advised to use the ARGON2 module available in current releases of OpenLDAP 2.4 instead. In OpenLDAP 2.5, the argon2 module is a mainline module that I'd expect all distributions to package.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
There is a slightly sneaky way to get openldap to support any crypt the native OS will support with the {CRYPT} option. Change the openldap option password-crypt-salt-format. On my servers the value is set to "$6$%.8s" which gives the result of using sha512 (one of several sha2 choices). This trick will depend on which choices are built into your native OS crypt function. In theory look at the crypt(5) man page to find this information. We've been doing this locally for probably a decade and it works well.
On Thu, Mar 18, 2021 at 9:59 AM Dario García Díaz-Miguel dgdiaz@gmv.com wrote:
Hello,
We have a question related with the pw-sha2 module. We have deployed OpenLDAP2.4.46-9.31.1 on SLES15 SP2 from the official Suse Repository and we are able to use {CRYPT} {MD5} {SMD5} {SSHA} and {SHA}.
We are awared that in order to support SHA-256 we have to load the contrib module named pw-sha2 which it was included on SLES12SP5 but is totally missing on SLES15SP2 package. This means that we would need to compile it, but due to limitations of the project we are working on we are not allowed to compile anything external.
So I checked the changelog and I found that support was added on 2.4.32 release.
Is it possible that the openldap2 package could have been compiled with the module features itself and I just need to add some kind of attribute or entry to my LDAP directory in order to enable it?
We have tried to use Apache Directory Studio instead of slappasswd and we have set up a password to SHA256 but the bind won't work. Instead, CRYPT-SHA256 works so I can't figure out why.
I suppose I'm totally misunderstanding this and the compilation of the module is required, but a little light ray of hope is there.
Thank you so much. Regards.
P Please consider the environment before printing this e-mail.
Am 18.03.21 um 16:13 schrieb Dale Thompson - NOAA Federal:
There is a slightly sneaky way to get openldap to support any crypt the native OS will support with the {CRYPT} option. Change the openldap option password-crypt-salt-format. On my servers the value is set to "$6$%.8s" which gives the result of using sha512 (one of several sha2 choices). This trick will depend on which choices are built into your native OS crypt function. In theory look at the crypt(5) man page to find this information. We've been doing this locally for probably a decade and it works well.
This solution gives you the nice opportunity to create shadow files from LDAP entries if needed. Some systems still work better with local accounts and with above configuration you can keep them synchronized with the rest ouf your organisation by a simple cronjob.
On Thu, Mar 18, 2021 at 9:59 AM Dario García Díaz-Miguel <dgdiaz@gmv.com mailto:dgdiaz@gmv.com> wrote:
Hello, We have a question related with the pw-sha2 module. We have deployed OpenLDAP2.4.46-9.31.1 on SLES15 SP2 from the official Suse Repository and we are able to use {CRYPT} {MD5} {SMD5} {SSHA} and {SHA}. We are awared that in order to support SHA-256 we have to load the contrib module named pw-sha2 which it was included on SLES12SP5 but is totally missing on SLES15SP2 package. This means that we would need to compile it, but due to limitations of the project we are working on we are not allowed to compile anything external. So I checked the changelog and I found that support was added on 2.4.32 release. Is it possible that the openldap2 package could have been compiled with the module features itself and I just need to add some kind of attribute or entry to my LDAP directory in order to enable it? We have tried to use Apache Directory Studio instead of slappasswd and we have set up a password to SHA256 but the bind won't work. Instead, CRYPT-SHA256 works so I can't figure out why. I suppose I'm totally misunderstanding this and the compilation of the module is required, but a little light ray of hope is there. Thank you so much. Regards. P Please consider the environment before printing this e-mail.-- Dale James Thompson, NWS NEXRAD Radar Operations Center IT Specialist, Configuration Management Team
Voice (405) 573-3472 Fax (405) 573-3480 Dale.J.Thompson@noaa.gov mailto:Dale.J.Thompson@noaa.gov
On 3/18/21 5:06 PM, Uwe Sauter wrote:
Am 18.03.21 um 16:13 schrieb Dale Thompson - NOAA Federal:
There is a slightly sneaky way to get openldap to support any crypt the native OS will support with the {CRYPT} option.>
This solution gives you the nice opportunity to create shadow files from LDAP entries if needed.
Beware this requires to give read access to userPassword values to whatever syncs local /etc/shadow! Regarding security this is a real anti-pattern!
Only replicas should have read access to userPassword.
Some systems still work better with local accounts
Whatever issues you might have to address in your deployment you should rather fix your LDAP integration instead of making your LDAP-based /etc/shadow remotely accessible.
Ciao, Michael.
Am 18.03.21 um 17:36 schrieb Michael Ströder:
On 3/18/21 5:06 PM, Uwe Sauter wrote:
Am 18.03.21 um 16:13 schrieb Dale Thompson - NOAA Federal:
There is a slightly sneaky way to get openldap to support any crypt the native OS will support with the {CRYPT} option.>
This solution gives you the nice opportunity to create shadow files from LDAP entries if needed.
Beware this requires to give read access to userPassword values to whatever syncs local /etc/shadow! Regarding security this is a real anti-pattern!
In my case the script generating and distributing the shadow file is running on the LDAP server which already has all the required authority.
Only replicas should have read access to userPassword.
Some systems still work better with local accounts
Whatever issues you might have to address in your deployment you should rather fix your LDAP integration instead of making your LDAP-based /etc/shadow remotely accessible.
This is sadly out of my reach.
Uwe
Ciao, Michael.
On 3/18/21 8:32 AM, Dario García Díaz-Miguel wrote:
We are awared that in order to support SHA-256 we have to load the contrib module named pw-sha2 which it was included on SLES12SP5 but is totally missing on SLES15SP2 package.
Note that SUSE announced not to support OpenLDAP server packages anymore. This might be a fallout of this decision.
This means that we would need to compile it, but due to limitations of the project we are working on we are not allowed to compile anything external.
You should challenge this stupid policy. Not only because of password hashing, but also because release 2.4.46 is three years old. Newer OpenLDAP releases have many important fixes.
Thus for my customers I'm maintaining own builds e.g. for SLE15SP2 which install in a different prefix. Feel free to use that or branch from that to your own OBS project:
https://build.opensuse.org/package/show/home:stroeder:openldap24/openldap-ms
https://download.opensuse.org/repositories/home:/stroeder:/openldap24/SLE_15...
More important you should be aware that {SHA256} password hash scheme is really weak. Because SHA-2 are fast and only one hash round is applied.
Another option you should be able to directly use is {CRYPT} as Dale already mentioned in his answer.
In my Æ-DIR's default config I'm currently using
password-hash {CRYPT} password-crypt-salt-format "$6$rounds=20000$%.16s"
See man page crypt(5) to find that $6$ is sha512crypt and I'm using 20000 rounds. This is better than a simple SHA-2 hash.
Caveat: {CRYPT} hashes are not portable. But most modern Linuxes support this since several years.
Ciao, Michael.
Hi everybody,
Thank you for your answer.
You should challenge this stupid policy. Not only because of password hashing, but also because release 2.4.46 is three years old. Newer OpenLDAP releases have many important fixes.
Well we are not allowed to challenge any policy due to the sensitive nature of the project.
Thus for my customers I'm maintaining own builds e.g. for SLE15SP2 which install in a different prefix. Feel free to use that or branch from that to your own OBS project:
Thank you, appreciated. But as I told you, we are not allowed to use any external source that is not included and audited previously by a special security entity.
The current version from SUSE is 2.4.46-9.48.1, BTW. If you have support, why not ask SUSE?
Yes, we have asked but we are still waiting for an answer.
password-hash {CRYPT} password-crypt-salt-format "$6$rounds=20000$%.16s"
Thank you so much for the tip, we will evaluate it.
There is a slightly sneaky way to get openldap to support any crypt the native OS will support with the {CRYPT} option. Change the openldap option password-crypt-salt-format. On my servers the value is set to "$6$%.8s" which gives the result of using sha512 (one of several sha2 choices). This trick will depend on which choices are built into your native OS crypt function. In theory look at the crypt(5) man page to find this information. We've been doing this locally for probably a decade and it works well.
Thank you so much for this. It seems it's working flawlessly.
Regards!
-----Mensaje original----- De: Michael Ströder [mailto:michael@stroeder.com] Enviado el: jueves, 18 de marzo de 2021 16:47 Para: openldap-technical@openldap.org Asunto: Re: SHA-256 Password Support and OpenLDAP2-2.4.46 SLES15SP2
On 3/18/21 8:32 AM, Dario García Díaz-Miguel wrote:
We are awared that in order to support SHA-256 we have to load the contrib module named pw-sha2 which it was included on SLES12SP5 but is totally missing on SLES15SP2 package.
Note that SUSE announced not to support OpenLDAP server packages anymore. This might be a fallout of this decision.
This means that we would need to compile it, but due to limitations of the project we are working on we are not allowed to compile anything external.
You should challenge this stupid policy. Not only because of password hashing, but also because release 2.4.46 is three years old. Newer OpenLDAP releases have many important fixes.
Thus for my customers I'm maintaining own builds e.g. for SLE15SP2 which install in a different prefix. Feel free to use that or branch from that to your own OBS project:
https://urldefense.com/v3/__https://build.opensuse.org/package/show/home:str...
https://urldefense.com/v3/__https://download.opensuse.org/repositories/home:...
More important you should be aware that {SHA256} password hash scheme is really weak. Because SHA-2 are fast and only one hash round is applied.
Another option you should be able to directly use is {CRYPT} as Dale already mentioned in his answer.
In my Æ-DIR's default config I'm currently using
password-hash {CRYPT} password-crypt-salt-format "$6$rounds=20000$%.16s"
See man page crypt(5) to find that $6$ is sha512crypt and I'm using 20000 rounds. This is better than a simple SHA-2 hash.
Caveat: {CRYPT} hashes are not portable. But most modern Linuxes support this since several years.
Ciao, Michael.
P Please consider the environment before printing this e-mail.
--On Monday, March 22, 2021 8:20 AM +0000 Dario García Díaz-Miguel dgdiaz@gmv.com wrote:
Thank you, appreciated. But as I told you, we are not allowed to use any external source that is not included and audited previously by a special security entity.
Given there have been a number of security and remote crasher issues fixed since that release, one would have to seriously question the efficacy of company's system.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 22.03.2021 um 16:08 in
Nachricht <0F2233BBFC3A030E35FD7AD5@[192.168.1.156]>:
--On Monday, March 22, 2021 8:20 AM +0000 Dario García Díaz-Miguel dgdiaz@gmv.com wrote:
Thank you, appreciated. But as I told you, we are not allowed to use any external source that is not included and audited previously by a special security entity.
Given there have been a number of security and remote crasher issues fixed since that release, one would have to seriously question the efficacy of company's system.
To be fair, one should add that SUSE is backporting security fixes to their version. For example for the most recent update: - bsc#1182408 CVE-2020-36230 - an assertion failure in slapd in the X.509 DN parsing in decode.c ber_next_element, resulting in denial of service. * 0218-ITS-9423-ldap_X509dn2bv-check-for-invalid-BER-after-.patch - bsc#1182411 CVE-2020-36229 - ldap_X509dn2bv crash in the X.509 DN parsing in ad_keystring, resulting in denial of service. * 0220-ITS-9425-add-more-checks-to-ldap_X509dn2bv.patch - bsc#1182412 CVE-2020-36228 - integer underflow leading to crash in the Certificate List Exact Assertion processing, resulting in denial of service. * 0221-ITS-9427-fix-issuerAndThisUpdateCheck.patch - bsc#1182413 CVE-2020-36227 - infinite loop in slapd with the cancel_extop Cancel operation, resulting in denial of service. * 0222-ITS-9428-fix-cancel-exop.patch - bsc#1182416 CVE-2020-36225 - double free and slapd crash in the saslAuthzTo processing, resulting in denial of service. * 0216-ITS-9412-fix-AVA_Sort-on-invalid-RDN.patch - bsc#1182417 CVE-2020-36224 - invalid pointer free and slapd crash in the saslAuthzTo processing, resulting in denial of service. * 0215-ITS-9409-saslauthz-use-slap_sl_free-in-prev-commit.patch * 0214-ITS-9409-saslauthz-use-ch_free-on-normalized-DN.patch - bsc#1182415 CVE-2020-36226 - memch->bv_len miscalculation and slapd crash in the saslAuthzTo processing, resulting in denial of service. * 0217-ITS-9413-fix-slap_parse_user.patch - bsc#1182419 CVE-2020-36222 - assertion failure in slapd in the saslAuthzTo validation, resulting in denial of service. * 0211-ITS-9406-9407-remove-saslauthz-asserts.patch * 0212-ITS-9406-fix-debug-msg.patch - bsc#1182420 CVE-2020-36221 - slapd crashes in the Certificate Exact Assertion processing, resulting in denial of service (schema_init.c serialNumberAndIssuerCheck). * 0210-ITS-9404-fix-serialNumberAndIssuerCheck.patch * 0219-ITS-9424-fix-serialNumberAndIssuerSerialCheck.patch - bsc#1182418 CVE-2020-36223 - slapd crash in the Values Return Filter control handling, resulting in denial of service (double free and out-of-bounds read). * 0213-ITS-9408-fix-vrfilter-double-free.patch
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 3/23/21 8:02 AM, Ulrich Windl wrote:
Quanah Gibson-Mount quanah@symas.com schrieb am 22.03.2021 um 16:08 in
Nachricht <0F2233BBFC3A030E35FD7AD5@[192.168.1.156]>:
--On Monday, March 22, 2021 8:20 AM +0000 Dario García Díaz-Miguel dgdiaz@gmv.com wrote:
Thank you, appreciated. But as I told you, we are not allowed to use any external source that is not included and audited previously by a special security entity.
Given there have been a number of security and remote crasher issues fixed since that release, one would have to seriously question the efficacy of company's system.
To be fair, one should add that SUSE is backporting security fixes to their version.
While I sometimes backport patches not yet released in 2.4.x series I think backport patching imposes higher risks and should generally be avoided for various reasons.
It's also not clear to me how closely SUSE maintainers are monitoring upstream changes or whether backport patches are only added in case a SUSE customer sent in a suffcientely specific support request. They will definitely add a patch for a security issue with CVE-Ids assigned, but not everyone had one.
Moreover at least one customer-fix patch, also added to openSUSE package, was so obscure that I've branched openSUSE package openldap2 and maintain that without obscure backport patches.
BTW: You can check how package openldap2 is built for upcoming SLE15SP3 in the openSUSE Leap 15.3 repo because both will be binary-compatible from that version on:
https://build.opensuse.org/package/show/openSUSE:Leap:15.3/openldap2
Ciao, Michael.
--On Tuesday, March 23, 2021 9:02 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
To be fair, one should add that SUSE is backporting security fixes to their version. For example for the most recent update:
They already stated that they are not using the most recent SuSE build package, in addition to the issues raised by Michael. So what SUSE is doing is immaterial given their security process is clearly flawed.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 3/22/21 8:20 AM, Dario García Díaz-Miguel wrote:
You should challenge this stupid policy. Not only because of password hashing, but also because release 2.4.46 is three years old. Newer OpenLDAP releases have many important fixes.>
Well we are not allowed to challenge any policy due to the sensitive nature of the project.
I'm often involved in sensitive projects with really strict regulations. Be assured you can challenge such a stupid policy by just making clear that the OS packages are not fully maintained anymore which pretty likely violates some of the security regulations.
And if you have an audit team in place you just have to follow a well-defined change management process. Well, most times you have to define such a process yourself and explain it to the audit team. ;-)
Ciao, Michael.
Dario García Díaz-Miguel dgdiaz@gmv.com schrieb am 18.03.2021 um 08:32
in Nachricht 6581b10d292b40fab6f224a594febb5c@gmv.com:
Hello,
We have a question related with the pw‑sha2 module. We have deployed OpenLDAP2.4.46‑9.31.1 on SLES15 SP2 from the official Suse
The current version from SUSE is 2.4.46-9.48.1, BTW. If you have support, why not ask SUSE?
Repository and we are able to use {CRYPT} {MD5} {SMD5} {SSHA} and {SHA}.
We are awared that in order to support SHA‑256 we have to load the contrib module named pw‑sha2 which it was included on SLES12SP5 but is totally
missing
on SLES15SP2 package. This means that we would need to compile it, but due
to
limitations of the project we are working on we are not allowed to compile anything external.
So I checked the changelog and I found that support was added on 2.4.32 release.
Is it possible that the openldap2 package could have been compiled with the
module features itself and I just need to add some kind of attribute or
entry
to my LDAP directory in order to enable it?
We have tried to use Apache Directory Studio instead of slappasswd and we have set up a password to SHA256 but the bind won't work. Instead, CRYPT‑SHA256 works so I can't figure out why.
I suppose I'm totally misunderstanding this and the compilation of the module is required, but a little light ray of hope is there.
Thank you so much. Regards.
P Please consider the environment before printing this e‑mail.
openldap-technical@openldap.org
-
Dale Thompson - NOAA Federal -
Dario García Díaz-Miguel -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl -
Uwe Sauter