Posts made by nj

@murgero thanks for the hint, but I'm afraid, I need to authenticate through LDAP only.

Is there a way to prevent normal Cloudron users from changing their username and email? That's because Gitlab, for instance, recommends against using LDAP authentication if the LDAP server supports changing username/email because that can lead to account takeover.

Is there any way to achieve this, or is there a possibility to add this feature in the admin panel?

Any plans to add the facility to append 2FA Token in LDAP Passwords?

My Gitlab instance (v13.0.5) on cloudron 5.2.4 displays the following warning:

Note that PostgreSQL 11 will become the minimum required PostgreSQL version in GitLab 13.0 (May 2020). PostgreSQL 9.6 and PostgreSQL 10 will no longer be supported in GitLab 13.0. Please consider upgrading your PostgreSQL version (10.12) soon.

@girish please look into it.

@girish after giving some more thoughts, I don't see a reason to go through all the apps to see if they support 2FA? This only makes stuff more complicated. Even if the app supports 2FA, the Cloudron 2FA will make it redundant; so we can skip that. If someone would like to skip Cloudron 2FA they're free to use the app's own 2FA if it supports.

There could be a choice of ["Use Cloudron 2FA / Let the app handle it"] just like the choice of user management. If the first option is selected, TOTP is checked, otherwise it is not.

If a rogue client is an attack vector, the app-specific password doesn't really save from the damage on that particular app. App-specific password have a long lifetime, so they can be silently misused without your knowledge for a relatively long time.

Whereas, the TOTP tokens are refreshed every 30 seconds or so. Even if someone stole your password, they must (MUST) brute-force the TOTP code after 30 seconds, which is going to trigger the brute-force detection mechanism. With immediate session revocation, the damage can be contained.

Hence I believe the only savior is 2FA if that particular app supports. Unfortunately, not all apps support 2FA; even if they did, it's not really fun to enable 2FA, manage backup codes, and in case the authenticator & backup codes are lost, it's not easy to have the admin bypass 2FA on all services. For example, RocketChat admins should do that by directly changing the user's data using the mongo shell.

I haven't looked into the source code of Cloudron yet, but I'm sure we can also have the app-specific passwords to be appended with a TOTP code if 2FA is enabled on the account. The app-specific password and TOTP will be validated by Cloudron in the same way it would validate the account password.

I believe this system reduces friction:

• users don't fall into a victim of silent misuse of passwords
• users don't need to configure multiple 2fa
• users don't need to print even more backup codes
• admins don't don't need to disable 2fa for individual accounts in worst cases
• Cloudron will have a solid mechanism of authentication
• we can start using more apps [that don't support 2FA yet] as well as custom apps in Cloudron without worrying about 2FA

I'm sorry if this comment sounded like a marketing pitch, but I genuinely believe we should pull this off. I'm fascinated by Cloudron because it has saved me a lot of hassle, and by @girish's support, which is by far the best I've ever received from any service provider!

So quick! It works, thanks! @girish!

Where do I run the mongorestore command from? The RocketChat instance does not have mongorestore available. I cannot access the shell of Cloudron's mongo addon instance to upload the dump & run the mongorestore command.

I intend to import data from existing RocketChat installation in another server to my Cloudron's RocketChat instance. The preferred way is to use mongodump command to export the data, and mongorestore to restore that data to a new server.

I don't find a way to import the database backup to the mongo instance. There's a Upload to /tmp option in the console for RocketChat, but I need to upload the database dump to the mongodb container.

How can I import the existing database to my Cloudron RocketChat instance?

@girish I think creating separate passwords for individual apps is against what I'm trying to achieve using SSO. The TOTP 2FA is actually more secure, unlike yet another password saved in the same password manager. App passwords stored in the same password manager only protect the password from rogue clients that may leak passwords. But adding the dynamic password feature protects even if the password is compromised.

Re: I am missing (real) SSO

I onboarded my entire team to Cloudron; signed up, mailboxes set up, 2FA enabled, and more. Then I realized that the 2FA setting enabled on Cloudron is useless for other apps. Some apps don't have a 2FA option yet; for example, Taiga, which we use to manage all the projects. Also, Bookstack, where all our internal docs go, supports 2FA.

I have understood how Cloudron works, and that this topic has already been discussed in the forum. I started looking for ways to leverage 2FA settings of Cloudron to protect access to other apps. I have thought of a possible solution.

After researching for a while I discovered a solution. Cloudron itself has an active directory server. We could have the users append/prepend the 2FA token with their password every time they log in; the Cloudron LDAP server would see if 2FA is enabled on the account, and if enabled, it will extract the password & 2FA code from the password input and perform authentication. This is pretty trivial because the Cloudron login page has an optional 2FA token field, and the token is only looked required if the user has enabled 2FA.

One of the service offerings I came across has a simple but complete description of this method of using 2FA with LDAP with a dynamic password. https://www.protectimus.com/blog/active-directory-two-factor-authentication/.

This feature is absolutely necessary for me, and I believe there are other people like me. Do you think we could pull this off?