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
