12:32 a.m.
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.
8:04 a.m.
--On Thursday, March 18, 2021 8:32 AM +0000 Dario García Díaz-Miguel
<dgdiaz(a)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>
8:13 a.m.
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(a)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(a)noaa.gov
9:06 a.m.
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(a)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(a)noaa.gov <mailto:Dale.J.Thompson@noaa.gov>
9:36 a.m.
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.
9:44 a.m.
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.
8:47 a.m.
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...
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.
12:20 a.m.
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(a)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:...
https://urldefense.com/v3/__https://download.opensuse.org/repositories/ho...
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.
8:08 a.m.
--On Monday, March 22, 2021 8:20 AM +0000 Dario García Díaz-Miguel
<dgdiaz(a)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>
12:02 a.m.
New subject: Antw: [EXT] RE: SHA-256 Password Support and OpenLDAP2-2.4.46 SLES15SP2
>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am
22.03.2021 um 16:08 in
Nachricht <0F2233BBFC3A030E35FD7AD5(a)[192.168.1.156]>:
--On Monday, March 22, 2021 8:20 AM +0000 Dario García Díaz-Miguel
<dgdiaz(a)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>
10:29 a.m.
On 3/23/21 8:02 AM, Ulrich Windl wrote:
>>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am
22.03.2021 um 16:08 in
Nachricht <0F2233BBFC3A030E35FD7AD5(a)[192.168.1.156]>:
> --On Monday, March 22, 2021 8:20 AM +0000 Dario García Díaz-Miguel
> <dgdiaz(a)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.
10:34 a.m.
New subject: Antw: [EXT] RE: SHA-256 Password Support and OpenLDAP2-2.4.46 SLES15SP2
--On Tuesday, March 23, 2021 9:02 AM +0100 Ulrich Windl
<Ulrich.Windl(a)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>
8:22 a.m.
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.
12:44 a.m.
New subject: Antw: [EXT] SHA-256 Password Support and OpenLDAP2-2.4.46 SLES15SP2
>> Dario García Díaz-Miguel <dgdiaz(a)gmv.com> schrieb am
18.03.2021 um 08:32
in
Nachricht <6581b10d292b40fab6f224a594febb5c(a)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.
739
days inactive
744
days old
openldap-technical@openldap.org
13 comments
6 participants
participants (6)
-
Dale Thompson - NOAA Federal -
Dario García Díaz-Miguel -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl -
Uwe Sauter