No, the default password policy is set to SSHA, but it also was set to
this before and then the hash had been upgraded to PBKDF2_SHA256. I
don't quite know what to make of this, because when I look at the source
code for version 1.4.4 in 389-ds-base/ldap/servers/slapd/pw.c lines 3520
and 3550 it would seem to me that the hash should never have been
updated to the wrong setting. But it defenitly did, else the radius
server would have continued working.
I install my servers with an Ansible Playbook that contains the
following task:
command: dsconf -D "cn=Directory Manager" -w '{{
vault_dirsrv_directory_manager_password }}' ldap://localhost pwpolicy
set --pwdscheme=SSHA
And when I checked using cockpit it was set to SSHA, but still some
accounts were set to PBKDF2_SHA256.
Julian
Am 24.11.22 um 12:19 schrieb Thierry Bordaz:
That looks weird, it should update the user password. Is PBKDF2_SHA256
the default password policy ?
thierry
On 11/24/22 11:48, Julian Kippels wrote:
What exactly are the requirements for the hash upgrade to trigger? I
have set up a test server, nsslapd-enable-upgrade-hash is set to "on"
but I cannot get the hashes to convert from SSHA to PBKDF2_SHA256.
I do a bind with directory manager and search for testuser, which
gives me the SSHA-Hash. Ihen I bind as testuser and perform a search.
Then I bind as directory manager again and search for testuser again.
The hash still remains as SSHA.
Julian
Am 22.11.22 um 15:30 schrieb Thierry Bordaz:
On 11/22/22 10:28, Julian Kippels wrote:
Hi Thierry,
that's a nasty catch…
On the one hand I think this is a nice feature to improve security,
but on the other hand PBKDF2_SHA256 is the one algorithm that
freeradius cannot cope with.
I suppose there is no way to revert all changed hashes after I set
"nsslapd-enable-upgrade-hash" to "off"? Other than to reinitialize
all affected suffixes from the export of the old servers?
Indeed this is a bad side effect of the default value :(
If you need to urgently fix those new {PBKDF2_SHA256}, then reinit is
the way to go. Else you could change the default password storage to
SSHA and keep nsslapd-enable-upgrade-hash=on. So that it will revert,
on bind, to the SSHA hash.
thierry
Julian
Am 22.11.22 um 09:56 schrieb Thierry Bordaz:
Hi Julian,
This is likely the impact of
https://github.com/389ds/389-ds-base/issues/2480 that was
introduced in 1.4.x.
On 1.4.4 default hash is PBKDF2, this ticket upgrade hash of user
entries during the user bind (enabled with
nsslapd-enable-upgrade-hash).
best regards
thierry
On 11/22/22 09:25, Julian Kippels wrote:
Hi,
We have a radius server that reads the userPassword-attribute from
ldap to authenticate users. There is a strange phenomenon where
sometimes the answer from the ldap-server gives the wrong password
hash algorithm. Our global password policy storage scheme is set
to SSHA. When I perform a ldapsearch as directory manager I see
that the password hash for a given user is
{SSHA}inserthashedpasswordhere. But when I run tcpdump to see what
our radius is being served I see {PBKDF2_SHA256}someotherhash
around 50% of the time. Sometime another request from radius a few
seconds after the first one gives the correct {SSHA} response.
This happened right after we updated from 389ds 1.2.2 to 1.4.4.
I am a bit stumped.
Thanks in advance,
Julian
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to
389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
---------------------------------------------------------
| | Julian Kippels
| | M.Sc. Informatik
| |
| | Zentrum für Informations- und Medientechnologie
| | Heinrich-Heine-Universität Düsseldorf
| | Universitätsstr. 1
| | Raum 25.41.O1.32
| | 40225 Düsseldorf / Germany
| |
| | Tel: +49-211-81-14920
| | mail: kippels@xxxxxx
---------------------------------------------------------
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
