Hi Viktor, thanks a lot for testing and finding that. I did not catch that. Thanks for the support. I will try to use the recreated instance. Kind regards, Ralf
Am Do., 4. Juli 2024 um 14:08 Uhr schrieb Viktor Ashirov < [email protected]>: > Hi Ralf, > > > On Thu, Jul 4, 2024 at 1:43 PM Ralf Spenneberg <[email protected]> > wrote: > >> I will recreate the instance. Meanwhile here is the log >> > I don't see errors in your log. > > I tried to reproduce your issue by copying /etc/dirsrv and > /var/lib/dirsrv/slapd-localhost from EL7 to EL9 and on startup I see in the > logs: > # grep ERR /var/log/dirsrv/slapd-localhost/errors > [04/Jul/2024:07:49:42.546119501 -0400] - ERR - Security Initialization - > SSL failure: NSS initialization failed (Netscape Portable Runtime error > -8015 - The certificate/key database is in an old, unsupported format or > failed to open.): certdir: /etc/dirsrv/slapd-localhost > [04/Jul/2024:07:49:42.552851778 -0400] - ERR - force_to_disable_security - > ERROR: NSS Initialization Failed. Disabling NSS. > [04/Jul/2024:07:49:42.567427797 -0400] - ERR - PBKDF2_SHA256 - Unable to > generate algorithm ID. > [04/Jul/2024:07:49:42.571365661 -0400] - ERR - PBKDF2_SHA256 - Could not > generate pbkdf2_sha256_hash! > > And migrated user can't bind: > # ldapsearch -xLLL ldap://localhost -D cn=user,ou=People,dc=example,dc=com > -w password -b "cn=user,ou=People,dc=example,dc=com" dn > ldap_bind: Invalid credentials (49) > > After I removed /etc/dirsrv/slapd-localhost/{cert8.db,key3.db,secmod.db}, > and started the server again, NSS was initialized successfully. And the > user was able to bind: > # ldapsearch -xLLL ldap://localhost -D cn=user,ou=People,dc=example,dc=com > -w password -b "cn=user,ou=People,dc=example,dc=com" dn > dn: cn=user,ou=People,dc=example,dc=com > > Having said that, I still recommend recreating the instance from scratch > when migrating from one major version to another. > Thanks. > >> >> Kind regards, >> Ralf >> >> >> Am Do., 4. Juli 2024 um 13:24 Uhr schrieb Viktor Ashirov < >> [email protected]>: >> >>> Hi Ralf, >>> >>> On Thu, Jul 4, 2024 at 12:54 PM Ralf Spenneberg <[email protected]> >>> 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 < >>>> [email protected]>: >>>> >>>>> Hi Ralf, >>>>> >>>>> >>>>> On Thu, Jul 4, 2024 at 11:29 AM Ralf Spenneberg <[email protected]> >>>>> 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 < >>>>>> [email protected]>: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 3, 2024 at 3:48 PM Ralf Spenneberg < >>>>>>> [email protected]> 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 < >>>>>>>> [email protected]>: >>>>>>>> >>>>>>>>> Hi Ralf, >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jul 2, 2024 at 2:29 PM Ralf Spenneberg < >>>>>>>>> [email protected]> 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 -- [email protected] >>>>>>>>>> To unsubscribe send an email to >>>>>>>>>> [email protected] >>>>>>>>>> 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/[email protected] >>>>>>>>>> Do not reply to spam, report it: >>>>>>>>>> https://pagure.io/fedora-infrastructure/new_issue >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Viktor >>>>>>>>> -- >>>>>>>>> _______________________________________________ >>>>>>>>> 389-users mailing list -- [email protected] >>>>>>>>> To unsubscribe send an email to >>>>>>>>> [email protected] >>>>>>>>> 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/[email protected] >>>>>>>>> Do not reply to spam, report it: >>>>>>>>> https://pagure.io/fedora-infrastructure/new_issue >>>>>>>>> >>>>>>>> -- >>>>>>>> _______________________________________________ >>>>>>>> 389-users mailing list -- [email protected] >>>>>>>> To unsubscribe send an email to >>>>>>>> [email protected] >>>>>>>> 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/[email protected] >>>>>>>> Do not reply to spam, report it: >>>>>>>> https://pagure.io/fedora-infrastructure/new_issue >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Viktor >>>>>>> -- >>>>>>> _______________________________________________ >>>>>>> 389-users mailing list -- [email protected] >>>>>>> To unsubscribe send an email to >>>>>>> [email protected] >>>>>>> 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/[email protected] >>>>>>> Do not reply to spam, report it: >>>>>>> https://pagure.io/fedora-infrastructure/new_issue >>>>>>> >>>>>> -- >>>>>> _______________________________________________ >>>>>> 389-users mailing list -- [email protected] >>>>>> To unsubscribe send an email to >>>>>> [email protected] >>>>>> 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/[email protected] >>>>>> Do not reply to spam, report it: >>>>>> https://pagure.io/fedora-infrastructure/new_issue >>>>>> >>>>> >>>>> >>>>> -- >>>>> Viktor >>>>> -- >>>>> _______________________________________________ >>>>> 389-users mailing list -- [email protected] >>>>> To unsubscribe send an email to >>>>> [email protected] >>>>> 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/[email protected] >>>>> Do not reply to spam, report it: >>>>> https://pagure.io/fedora-infrastructure/new_issue >>>>> >>>> -- >>>> _______________________________________________ >>>> 389-users mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> 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/[email protected] >>>> Do not reply to spam, report it: >>>> https://pagure.io/fedora-infrastructure/new_issue >>>> >>> >>> >>> -- >>> Viktor >>> -- >>> _______________________________________________ >>> 389-users mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> 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/[email protected] >>> Do not reply to spam, report it: >>> https://pagure.io/fedora-infrastructure/new_issue >>> >> -- >> _______________________________________________ >> 389-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> 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/[email protected] >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> > > > -- > Viktor > -- > _______________________________________________ > 389-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
-- _______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
