Ok. Recreating the instance apparently solves the problem. And the hash
migration works as well.

Thanks a lot.

Am Do., 4. Juli 2024 um 13:43 Uhr schrieb Ralf Spenneberg <
rspenneb...@gmail.com>:

> I will recreate the instance. Meanwhile here is the log
>
> Kind regards,
> Ralf
>
>
> Am Do., 4. Juli 2024 um 13:24 Uhr schrieb Viktor Ashirov <
> vashi...@redhat.com>:
>
>> Hi Ralf,
>>
>> On Thu, Jul 4, 2024 at 12:54 PM Ralf Spenneberg <rspenneb...@gmail.com>
>> wrote:
>>
>>> Hi Viktor,
>>>
>>> I do not see any errors. I attached the log but nothing stands out to me.
>>>
>> I don't see the log attached, could you please send it again?
>>
>>>
>>> It was not a fresh instance but the migrated instance.
>>>
>>> Then I removed the database:
>>> dsconf -D "cn=Directory Manager" -W ldap://localhost backend delete
>>> spenneberg_net --do-it
>>> Deleting Backend cn=spenneberg_net,cn=ldbm database,cn=plugins,cn=config
>>> :
>>> Type 'Yes I am sure' to continue: Yes I am sure
>>> The database, and any sub-suffixes, were successfully deleted
>>>
>> Please try on a fresh instance, not just the database. In the
>> documentation we warn that the old dse.ldif should not be used.
>> Thanks.
>>
>>>
>>> Recreated it:
>>> dsconf -D "cn=Directory Manager" -W ldap://localhost backend create
>>> --suffix="dc=spenneberg,dc=net" --be-name=spenneberg_net
>>> The database was sucessfully created
>>>
>>> Did the import again:
>>> dsconf -D "cn=Directory Manager" -Wi ldap://localhost backend import
>>> dc=spenneberg,dc=net /userRoot.ldif
>>> The import task has finished successfully
>>>
>>> If I try to authenticate again, it does not work:
>>> ldapsearch -h localhost -x -b dc=spenneberg,dc=net -D
>>> "uid=kolab-service,ou=Special Users,dc=spenneberg,dc=net" -W
>>> ldap_bind: Invalid credentials (49)
>>>
>>> The user has a SSHA password:
>>> {SSHA}+4ZcRhy2/7h5Du5x/1MO....
>>>
>>> If I check the password, pwdhash states OK:
>>> pwdhash -c {SSHA}+4ZcRhy2/7h5Du5x/1MO... qcG...
>>> pwdhash: password ok.
>>>
>>> If I reset the password using ldapmodify
>>> dn: uid=kolab-service,ou=Special Users,dc=spenneberg,dc=net
>>> changetype: modify
>>> replace: userPassword
>>> userPassword: qcG...
>>>
>>> Now the user may access the tree again. I do not know, why the SSHA
>>> passwords are not honored.
>>> Any ideas?
>>>
>>> KInd regards,
>>> Ralf
>>>
>>>
>>> Am Do., 4. Juli 2024 um 12:37 Uhr schrieb Viktor Ashirov <
>>> vashi...@redhat.com>:
>>>
>>>> Hi Ralf,
>>>>
>>>>
>>>> On Thu, Jul 4, 2024 at 11:29 AM Ralf Spenneberg <rspenneb...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Viktor,
>>>>> thanks a lot for the suggestion.
>>>>> So I did an export of the old tree running on 1.3.11 using db2dif:
>>>>> db2ldif -s "dc=xxx,dc=net" -a /tmp/userRoot.ldif
>>>>> And I did an import in the new tree running on 2.4:
>>>>>
>>>> Is it a fresh instance or migrated from the old install?
>>>>
>>>> dsconf -D "cn=Directory Manager" -W ldap://localhost backend import
>>>>> dc=...,dc=net /userRoot.ldif
>>>>> The import task has finished successfully
>>>>>
>>>> Do you see any errors in the errors log in
>>>> /var/log/dirsrv/slapd-your_instance/errors related to import or NSS?
>>>>
>>>> Directly afterwards the passwords stopped working again. I had to reset
>>>>> them again. Is there any additional step required?
>>>>>
>>>> It should work, I did a quick test with export/import and SSHA
>>>> passwords and the migrated users are able to bind with the old password.
>>>>
>>>> Please check the documentation:
>>>>
>>>> https://docs.redhat.com/en/documentation/red_hat_directory_server/12/html/installing_red_hat_directory_server/assembly_migrating-directory-server-10-to-directory-server-12_installing-rhds#proc_migrating-directory-server-10-to-version-12-using-the-replication-method_assembly_migrating-directory-server-10-to-directory-server-12
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>>
>>>>> Kind regards,
>>>>> Ralf
>>>>>
>>>>> Am Mi., 3. Juli 2024 um 18:26 Uhr schrieb Viktor Ashirov <
>>>>> vashi...@redhat.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 3, 2024 at 3:48 PM Ralf Spenneberg <rspenneb...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Actually I just upgrade the system from centos7 to almalinux9 using
>>>>>>> elevate. Essentially this is similar to a copy of the /etc/dirsrv and
>>>>>>> /var/lib/dirsrv directories and started the new ldapserver.
>>>>>>>
>>>>>> We don't support or test in-place upgrades (leapp/elevate) and
>>>>>> recommend using export/import or replication methods.
>>>>>>
>>>>>> Directly afterwards I was not able to login using the cn=Directory
>>>>>>> Manager. I checked the hashed password in the dse.ldif  file (cn=config)
>>>>>>> using pwdhash. It was ok.
>>>>>>> Once I changed the password of the directory manager in the dse.ldif
>>>>>>> file after stopping the 389ds using PBKDF2-SHA512 hash, the
>>>>>>> Directory Manager was able to login. Other users required a reset of 
>>>>>>> their password
>>>>>>> as well for successful login. But since I do not have access to all
>>>>>>> passwords I would rather reuse the old tree.
>>>>>>> The nsslapd-allow-hashed-passwords is set to on.
>>>>>>> Therefore I doubt that I have double hashed passwords. For the case
>>>>>>> of the Directory Manager I am positive.
>>>>>>> And yes, dsconf lists SSHA in my case as well. Any ideas why this is
>>>>>>> not working?
>>>>>>>
>>>>>> Do you see any errors regarding NSS in the errors log?
>>>>>> NSS in EL7 was using an old datbase format, and if you just copied it
>>>>>> to EL9, it's very likely to fail initialization.
>>>>>>
>>>>>>
>>>>>>> My passwordpolicy is quite open:
>>>>>>> Global Password Policy: cn=config
>>>>>>> ------------------------------------
>>>>>>> nsslapd-pwpolicy-local: off
>>>>>>> passwordstoragescheme: SSHA512
>>>>>>> passwordchange: on
>>>>>>> passwordmustchange: off
>>>>>>> passwordhistory: off
>>>>>>> passwordinhistory: 6
>>>>>>> passwordadmindn:
>>>>>>> passwordtrackupdatetime: off
>>>>>>> passwordwarning: 86400
>>>>>>> passwordisglobalpolicy: off
>>>>>>> passwordexp: off
>>>>>>> passwordmaxage: 8640000
>>>>>>> passwordminage: 0
>>>>>>> passwordgracelimit: 0
>>>>>>> passwordsendexpiringtime: off
>>>>>>> passwordlockout: off
>>>>>>> passwordunlock: on
>>>>>>> passwordlockoutduration: 3600
>>>>>>> passwordmaxfailure: 3
>>>>>>> passwordresetfailurecount: 600
>>>>>>> passwordchecksyntax: off
>>>>>>> passwordminlength: 8
>>>>>>> passwordmindigits: 0
>>>>>>> passwordminalphas: 0
>>>>>>> passwordminuppers: 0
>>>>>>> passwordminlowers: 0
>>>>>>> passwordminspecials: 0
>>>>>>> passwordmin8bit: 0
>>>>>>> passwordmaxrepeats: 0
>>>>>>> passwordmincategories: 3
>>>>>>> passwordmintokenlength: 3
>>>>>>> nsslapd-allow-hashed-passwords: on
>>>>>>> nsslapd-pwpolicy-inherit-global: off
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Ralf
>>>>>>>
>>>>>>>
>>>>>>> Am Mi., 3. Juli 2024 um 10:42 Uhr schrieb Viktor Ashirov <
>>>>>>> vashi...@redhat.com>:
>>>>>>>
>>>>>>>> Hi Ralf,
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 2, 2024 at 2:29 PM Ralf Spenneberg <
>>>>>>>> rspenneb...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi there,
>>>>>>>>> I am trying to update a ldap tree from 389ds 1.3.11 (centos7) to
>>>>>>>>> 2.4.5 (almalinux9). After migrating the tree all passwords stop 
>>>>>>>>> working
>>>>>>>>> including the Directory Manager. The old tree used SSHA. Setting the
>>>>>>>>> rootpwstoragescheme does not help for the Directory Manager. Only 
>>>>>>>>> manually
>>>>>>>>> resetting the passwords using pwdhash in the dse.ldif file and using a
>>>>>>>>> PBKDF2-SHA512 password works. Is there a way to enable the old SSHA 
>>>>>>>>> scheme?
>>>>>>>>>
>>>>>>>> SSHA is still supported in the latest 389-DS:
>>>>>>>> # dsconf localhost pwpolicy list-schemes | grep SSHA
>>>>>>>> SSHA
>>>>>>>> SSHA256
>>>>>>>> SSHA384
>>>>>>>> SSHA512
>>>>>>>>
>>>>>>>> How did you perform the migration? Via replication or export/import?
>>>>>>>> What is the value of nsslapd-allow-hashed-passwords in cn=config?
>>>>>>>> I suspect that your passwords after the migration might be doubly
>>>>>>>> hashed instead of imported as is.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>> Ralf
>>>>>>>>> --
>>>>>>>>> _______________________________________________
>>>>>>>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>>>>>>> To unsubscribe send an email to
>>>>>>>>> 389-users-le...@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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Viktor
>>>>>>>> --
>>>>>>>> _______________________________________________
>>>>>>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>>>>>> To unsubscribe send an email to
>>>>>>>> 389-users-le...@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-le...@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
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Viktor
>>>>>> --
>>>>>> _______________________________________________
>>>>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>>>> To unsubscribe send an email to
>>>>>> 389-users-le...@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-le...@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
>>>>>
>>>>
>>>>
>>>> --
>>>> Viktor
>>>> --
>>>> _______________________________________________
>>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>>>> To unsubscribe send an email to 389-users-le...@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-le...@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
>>>
>>
>>
>> --
>> Viktor
>> --
>> _______________________________________________
>> 389-users mailing list -- 389-users@lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-le...@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-le...@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

Reply via email to