Could it be that the user with upgraded password have non default
password policy ?
If there are nothing logged in error logs, then an option, as you can
reproduce on demand, is to gdb ns-slapd with a breakpoint on
update_pw_encoding just before the user authenticate/search.
thierry
On 11/24/22 13:15, Julian Kippels wrote:
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
_______________________________________________
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