Re: Kolab User Passwords

Mihai Badici <[email protected]> Sat, 28 Dec 2024 10:53:09 +0200
Newsgroups gmane.comp.kde.devel.kroupware
Message-ID <059432bb-8cdc-4a46-aa80-6ddbcdfc7835__41425.7486628898$1735376439$gmane$org@badici.ro>
This is a multi-part message in MIME format.
--===============6452815493945736062==
Content-Type: multipart/alternative;
 boundary="------------ldVa89bTx0WUF8LNGjxn4ujZ"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------ldVa89bTx0WUF8LNGjxn4ujZ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

But the problem is the authentication should not be dependent on hash 
type. Authentication is binding the ldap server with user and password. 
If all the utilities ( server and client tools) are compatible the 
authentication should work with any supported hash type.

So I guess the problem is when you create a new user ( with kolab 
webadmin I assume) the password is hashed outside the ldap tools and 
inserted as text. I don't use kolab webadmin but I suspect if the ldap 
server is not supporting ssha512 you can change the hash algoritm either 
from config file or directly in the code.

To be more specific: you can change an user password in ldap using 
ldappasswd  (from openldap-client) :

ldappasswd -D cn=Manager,dc=****** -x -w $rootpass -S "$DN"

This will use the default hashing in ldap server.

But you can also use ldapmodify and change the password as a text - 
hashed with any algorithm you choose. If you use that way - and for some 
legitimate reasons I think  is the way kolab webadmin is acting - the 
hash can be or can't be supported. So probably you can upgrade ldap 
server or change the hash algorithm. Also you can try to change the 
password from console as in my example to validate my assumption.

Mihai



On 12/28/24 01:30, Valentin Laskov wrote:
> Hello,
>
> brute force method:
>
> 1. Make an archive using this method:
>
> http://web.archive.org/web/20240524220349/https://docs.kolab.org/administrator-guide/backup-and-restore.html 
>
>
> You will get text files in which the password will look like this:
>
> userPassword:: 
> e1NTSEE1MTJ9MTRGcXZpbE5ScU1mdGNGMFhyYkFZdy9tUkNQcGp5bHZmQ09VTFp
>  kcWJwQ2FXY2ZtN2Y0NWptZnJsRnVSeVpLOVk1eHJ4U25wRTA1WFNQajhYYk0vQnR4dzUrN05rMlVz 
>
>
> 2. Copy and paste a password from another user whose password you know 
> to a user whose password doesn't work. Don't tell any user about this! :)
>
> 3. Restore the backup using the description above. It is probably 
> possible to improvise to perform a partial restore.
>
> 4. Cheers and Happy New Year! :)
>
> Valentin Laskov
>
> На 25.12.24 г. в 14:40 ч., Reitelbach, Thomas написа:
>> Hello list,
>>
>> I'm running Kolab 16 on CentOS 7 with multi domain support (4 
>> Domains) for some years now.
>>
>> Today I added a new Kolab User and set the password. But the new user 
>> can't login with roundcube ("Login failed" says roundcubemail). And 
>> the logs also say failed login.
>>
>> Old users can still login as usual with their password.
>>
>> After some investigation I found that "kolab user-info user@domain" 
>> shows a "userpassword:" with
>>
>> u'{SSHA512}................'
>>
>> and old users are encrypted like this:
>> u'{SSHA}................'
>>
>> I guess that with some system update something in the underlying 
>> system has changed and new passwords are beeing stored as SHA512 now, 
>> which makes roundcube or ldap fail to check the password.
>>
>> Has anyone help for me? Can I setup how roundcube webadmin will 
>> encode the password in LDAP?
>> Can I manually set the password in LDAP?
>> I'm not familiar with LDAP queries and need help with that.
>>
>> Have a nice Christmas :)
>>
>> Thomas
>> _______________________________________________
>> users mailing list
>> [email protected]
>> https://lists.kolab.org/mailman/listinfo/users
> _______________________________________________
> users mailing list
> [email protected]
> https://lists.kolab.org/mailman/listinfo/users
--------------ldVa89bTx0WUF8LNGjxn4ujZ
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>But the problem is the authentication should not be dependent on
      hash type. Authentication is binding the ldap server with user and
      password. If all the utilities ( server and client tools) are
      compatible the authentication should work with any supported hash
      type.<br>
    </p>
    <p>So I guess the problem is when you create a new user ( with kolab
      webadmin I assume) the password is hashed outside the ldap tools
      and inserted as text. I don't use kolab webadmin but I suspect if
      the ldap server is not supporting ssha512 you can change the hash
      algoritm either from config file or directly in the code. <br>
    </p>
    <p>To be more specific: you can change an user password in ldap
      using ldappasswd  (from openldap-client) :</p>
    <p><span style="font-family:monospace"><span
          style="color:#000000;background-color:#ffffff;">ldappasswd -D
          cn=Manager,dc=****** -x -w $rootpass -S "$DN"</span></span></p>
    <p>This will use the default hashing in ldap server<span
        style="font-family:monospace">.</span></p>
    <p>But you can also use ldapmodify and change the password as a text
      - hashed with any algorithm you choose. If you use that way - and
      for some legitimate reasons I think  is the way kolab webadmin is
      acting - the hash can be or can't be supported. So probably you
      can upgrade ldap server or change the hash algorithm. Also you can
      try to change the password from console as in my example to
      validate my assumption.</p>
    <p>Mihai<span style="font-family:monospace"><br>
      </span></p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 12/28/24 01:30, Valentin Laskov
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:[email protected]">Hello,
      <br>
      <br>
      brute force method:
      <br>
      <br>
      1. Make an archive using this method:
      <br>
      <br>
<a class="moz-txt-link-freetext" href="http://web.archive.org/web/20240524220349/https://docs.kolab.org/administrator-guide/backup-and-restore.html">http://web.archive.org/web/20240524220349/https://docs.kolab.org/administrator-guide/backup-and-restore.html</a>
      <br>
      <br>
      You will get text files in which the password will look like this:
      <br>
      <br>
      userPassword::
      e1NTSEE1MTJ9MTRGcXZpbE5ScU1mdGNGMFhyYkFZdy9tUkNQcGp5bHZmQ09VTFp
      <br>
 kcWJwQ2FXY2ZtN2Y0NWptZnJsRnVSeVpLOVk1eHJ4U25wRTA1WFNQajhYYk0vQnR4dzUrN05rMlVz
      <br>
      <br>
      2. Copy and paste a password from another user whose password you
      know to a user whose password doesn't work. Don't tell any user
      about this! :)
      <br>
      <br>
      3. Restore the backup using the description above. It is probably
      possible to improvise to perform a partial restore.
      <br>
      <br>
      4. Cheers and Happy New Year! :)
      <br>
      <br>
      Valentin Laskov
      <br>
      <br>
      На 25.12.24 г. в 14:40 ч., Reitelbach, Thomas написа:
      <br>
      <blockquote type="cite">Hello list,
        <br>
        <br>
        I'm running Kolab 16 on CentOS 7 with multi domain support (4
        Domains) for some years now.
        <br>
        <br>
        Today I added a new Kolab User and set the password. But the new
        user can't login with roundcube ("Login failed" says
        roundcubemail). And the logs also say failed login.
        <br>
        <br>
        Old users can still login as usual with their password.
        <br>
        <br>
        After some investigation I found that "kolab user-info
        user@domain" shows a "userpassword:" with
        <br>
        <br>
        u'{SSHA512}................'
        <br>
        <br>
        and old users are encrypted like this:
        <br>
        u'{SSHA}................'
        <br>
        <br>
        I guess that with some system update something in the underlying
        system has changed and new passwords are beeing stored as SHA512
        now, which makes roundcube or ldap fail to check the password.
        <br>
        <br>
        Has anyone help for me? Can I setup how roundcube webadmin will
        encode the password in LDAP?
        <br>
        Can I manually set the password in LDAP?
        <br>
        I'm not familiar with LDAP queries and need help with that.
        <br>
        <br>
        Have a nice Christmas :)
        <br>
        <br>
        Thomas
        <br>
        _______________________________________________
        <br>
        users mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
        <br>
        <a class="moz-txt-link-freetext" href="https://lists.kolab.org/mailman/listinfo/users">https://lists.kolab.org/mailman/listinfo/users</a>
        <br>
      </blockquote>
      _______________________________________________
      <br>
      users mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
      <br>
      <a class="moz-txt-link-freetext" href="https://lists.kolab.org/mailman/listinfo/users">https://lists.kolab.org/mailman/listinfo/users</a>
      <br>
    </blockquote>
  </body>
</html>

--------------ldVa89bTx0WUF8LNGjxn4ujZ--

--===============6452815493945736062==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
users mailing list
[email protected]
https://lists.kolab.org/mailman/listinfo/users

--===============6452815493945736062==--