Roland Gruber <[email protected]> le mardi 9 septembre 2014 à 21:18 +0200 a écrit: > Hi Rolland, > >do you manually upload the LDIF file? Yes > If yes, does the same problem >happen when LAM creates the users itself. Yes >The LDIF is more to check >attribute generation and not to upload it manually. I understand and never does normally; I just wanted to check the syntax of the ldif file was correct. >
>Are there any special characters in the affected passwords? No, we removed the special characters in passwords to ensure that our problem was not of this. > > >Please check in tree view if the password hash matches the original >password. There is a "check password" link next to user password. I have already done this test in Apache Directory Studio, there is also a feature to verify the password (userPassword attribute). I just do it at the moment in tree view. Result : " Passwords match." for affected passwords. > >When you click on "Show internal attributes" on such a user, is the >modifyTimestamp the time of upload? Yes. The modifyTimestamp attribute displays the same setting for all accounts including those imported with affected passwords. > > >We need to reproduce the issue to be able to fix it. I understand. I await your instructions for further testing. Thank you Pascal > > > > >On 09.09.2014 16:49, PASCAL CASSAGNES wrote: >> Hi Rolland, >> I saw my CSV file multiple times including the password: I think it is >> correct. >> I do not use Excel to generate the CSV but LibreOffice. >> I have no error in Lam message during upload. The addition of the LDIF >> file (generated by Lam) directly the DB openLDAP (ldapmodify) is quite >> normal. >> This problem is random, ie that for the same CSV file downloaded, >accounts >> for which the password problem is not systematically the same. >> Therefore there he has no problem with the hash of the password, or when >> generating LDIF file Lam, either when writing the userPassword attribute >> in OpenLDAP bd ? >> (I dot not use ppolicy or outlook.) >> >> Thank you. >> Best regards >> Pascal >> >> Roland Gruber <[email protected]> le lundi 8 septembre 2014 à 18:44 >> +0200 a écrit: >>> Hi Pascal, >>> >>> >>> please verify that the CSV file contains the correct password. Maybe >your >>> spreadsheet application does some reformatting. Especially, MS Excel is >>> known to have all sorts of formatting. >>> Please also check that there are no extra spaces at the beginning or >end >>> of the password in your file. >>> >>> >>> If you use PPolicy please check that the account was not locked by it. >>> Often, there are problems with copy+paste from email. E.g. Outlook >often >>> adds an extra space. >>> >>> >>> Best regards >>> >>> >>> Roland >>> >>> >>> >>> >>> Sent from my mobile >>> >>> -------- Ursprüngliche Nachricht -------- >>> Von: PASCAL CASSAGNES <[email protected]> >>> Datum:08.09.2014 15:39 (GMT+01:00) >>> An: [email protected] >>> Cc: [email protected] >>> Betreff: [Lam-public] hash password >>> >>> openSUSE 12.3 >>> Lam Pro 4.6 >>> OpenLDAP 2.4.33 >>> Setting hash Lam Pro and openLDAP = SSHA >>> >>> Hello, >>> >>> We import the user accounts in the bd openLDAP with Lam Pro from a CSV >>> file (created with LibreOffice). >>> For some of these accounts, the hash of the password does not seem to >do >>> it properly though the syntax of the ldif file generated by Pro Lam >from >>> the CSV file looks just fine. >>> Import command line (ldapmodify) of ldif file generated by Lam goes >>> smoothly. >>> >>> For example, for two alam1 alam4 accounts created during the import: >>> >>> ldapwhoami -vvv -h 127.0.0.1-D uid = alam1, ou = users, dc = >>> organization.fr, dc = local-x w nsh67yAB >>> ldap_initialize (ldap: //127.0.0.1) >>> dn: uid = alam1, ou = users, dc = organisation.fr, dc = local >>> Result: Success (0) >>> >>> ldapwhoami -vvv -h 127.0.0.1-D uid = alam4, ou = users, dc = >>> organization.fr, dc = local-x w NBHU_tGH >>> ldap_initialize (ldap: //127.0.0.1) >>> ldap_bind: Invalid credentials (49) >>> >>> For alam4 account, then it is sufficient to correct this problem, >reenter >>> via Lam password "Unix" for get everything in order. >>> >>> This issue is completely random : when reimport the same CSV file >(prior >>> removal of these accounts in Lam) it may be that this is the password >>> (userPassword) of alam1 problem account or another account or more. >>> >>> In these circumstances, using the import function is not satisfactory. >>> >>> Thank you for your help. >>> Best regards. >>> Pascal >> >> >> >> >> >------------------------------------------------------------------------------ >> Want excitement? >> Manually upgrade your production database. >> When you want reliability, choose Perforce. >> Perforce version control. Predictably reliable. >> >http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> >> >> >> _______________________________________________ >> Lam-public mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/lam-public >> > > >------------------------------------------------------------------------------ >Want excitement? >Manually upgrade your production database. >When you want reliability, choose Perforce. >Perforce version control. Predictably reliable. >http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >_______________________________________________ >Lam-public mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/lam-public ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Lam-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lam-public
