[389-users] Re: Wrong password hash algorithm returned

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