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(a)lists.fedoraproject.org
>>>>>> To unsubscribe send an email to
>>>>>> 389-users-leave(a)lists.fedoraproject.org
>>>>>> 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@lists.fedoraproje...
>>>>>> Do not reply to spam, report it:
>>>>>>
https://pagure.io/fedora-infrastructure/new_issue
>>>>>
>>>> _______________________________________________
>>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>>>> To unsubscribe send an email to
>>>> 389-users-leave(a)lists.fedoraproject.org
>>>> 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@lists.fedoraproje...
>>>> Do not reply to spam, report it:
>>>>
https://pagure.io/fedora-infrastructure/new_issue
>>>
>>
>