Cloudron Forum

nj

@ianhyzy I finally managed to run Keycloak on Cloudron after a few days of trying. Most of the code is from this repository. The author seemed to have used a heavily modified configuration file, tailored to fit their needs. Also they had a two-step build system, where they pushed a customized Keycloak image to the hub, then the actual Cloudron app made use of the previously pushed image. That didn't seem necessary.

So, I wrote a simple build script that would:

spawn a fresh installation of Keycloak
export the default master realm configuration
adds LDAP and SMTP configuration for Cloudron to the exported file

The app I put together is based on cloudron/base:3.2 and makes use of the freshly exported and customized configuration file, which IMO is more compatible with Keycloak updates.

I'll publish the code on Github this weekend. I'm planning to use this instance to install Outline because it now supports a custom OIDC auth provider.

Cheers!

nj

Re: Swagger Editor - define REST api

I have been using Postman with my team for developing and publishing APIs for our services, but the costs are adding up pretty quickly ($15/user/month), and still no support for SSO.

I am moving to Swagger Editor, Swagger Codegen & Swagger UI, but it would be great if I could install it inside my Cloudron instance instead of paying for another server.

I noticed that your documentation makes use of Swagger, so I am sure it would be fairly easy to add support for the same.

Please don't forget to upvote if you think it's a good idea.

nj

I once added an wildcard A Record for *.mydomain that pointed to my box. It would show the message You found a Cloudron out in the wild! message whenever I tried to open a non-existent subdomain, like foobarbaz.mydomain.

Non-existent app:

File /home/yellowtent/box/dashboard/dist/splash.html
Message: You found a Cloudron out in the wild!
To test, point foobarbaz.yourdomain to the box and visit the url.

Non-responding app:

File /home/yellowtent/boxdata/custom_pages/app_not_responding.html
Message: ...app is not responding...
To test, stop the app and visit the url.

I am not sure if those files will be replaced during upgrade, but I have the following content in both of those files.

<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
<!-- no such app / app not working -->
</body>
</html>

It would be cool to be able to add a custom file app_not_installed.html alongside app_not_responding.html.

nj

Gitlab supports adding custom gitlab.yml file (add to the Home of File Manager in the Cloudron dashboard). I am sharing a few custom configurations which I think are really important.

Adding the IP address of the reverse proxy 172.18.0.1 will show the real IP address of the client in Gitlab's logs. The IP address set using X-Forwarded-For by the reverse proxy. For that purpose production/gitlab/trusted_proxies parameter can be set.
For compliance reasons, we cannot allow users to change their username in the Gitlab instance. A setting is not available in the Admin area to prevent users from changing their usernames, but a custom flag production/gitlab/username_changing_enabled can be set.
While configuring 2FA with current default Gitlab installation in gitlab.example.com, the account name in authenticator apps will be shown as localhost:someone@gilab.example.com. To fix this, we can add the production/gitlab/host parameter. After this fix, authenticator apps will show the gitlab instance's domain name instead of localhost.
Current default Gitlab installation wills show the git-clone URL as ssh://git@localhost:port/user/repo. To fix this, we should add a custom production/gitlab/ssh_host parameter.
I would like to have my brand name set on the Branding -> Cloudron Name from my dashboard on Gitlab's LDAP log-in page instead of Cloudron. Simply changing the LDAP server's label production/ldap/servers/main/label did not work. So I simply copied the entire production/ldap configuration block.

Here is my custom gitlab.yml file, that fixes all the above issues.

production:
  <<: *base

  gitlab:
    host: gitlab.mydomain
    ssh_host: gitlab.mydomain
    trusted_proxies:
      - 172.18.0.1
      
    username_changing_enabled: false


  ldap:
    enabled: true
    prevent_ldap_sign_in: false
    servers:
      main:
        label: 'My Domain Login'
        host: '172.18.0.1'
        port: 3002
        uid: 'username'
        bind_dn: 'cn=**************************,ou=apps,dc=cloudron'
        password: '****************************'
        encryption: 'plain'
        verify_certificates: false
        ca_file: ''
        ssl_version: ''
        timeout: 10
        smartcard_auth: false
        active_directory: false
        allow_username_or_email_login: false
        block_auto_created_users: false
        base: 'ou=users,dc=cloudron'
        user_filter: ''
        group_base: ''
        admin_group: ''
        external_groups: []
        sync_ssh_keys: false
        attributes:
          username: ['username']
          email:    ['mail']
          name:       'displayname'
          first_name: 'givenName'
          last_name:  'sn'
        lowercase_usernames: false

In my opinion, Gitlab Cloudron package could add the custom file gitlab.yml to the file manager home by default, and set the the above fields in that file instead of modifying the default config file.

nj

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?

nj

@girish I think I didn’t make it clear enough earlier. The Keycloak app itself doesn’t support working as a LDAP server, but makes use of Cloudron LDAP to federate users from Cloudron. It works as a OIDC server. So it’s a pretty trivial setup..

nj

The comment thread on this post seems to have diverted from the original topic. I would like to comment on @marcusquinn's request for 2FA for LDAP apps. As @girish has said, we have had a long discussion about it, and the team couldn't come up with a one-size-fits-all solution. I was expecting the PASSWORD;TOTP feature in version 6 too. Here's my understanding and proposed solution:

1. Apps that have their own 2FA system, like Gogs, Gitlab, Wiki.JS, etc.
NOTE: I have used this trick in quite a few apps to save myself from having dozens of 2FA secrets. I simply replace the app's mfa_secret value with the secret from Cloudron (Hint: while setting up 2FA on your Cloudron account, select to enter code manually, and write the displayed secret in a piece of paper so you can copy it elsewhere).

Cloudron has access to the database so Cloudron could automate this process:

enabling 2FA for that user in the app by authenticating as that user.
replacing the TOTP secret in the app with the TOTP secret from the Cloudron user account.

The 2FA code from Cloudron will also work on the app, so no need to have per-app 2FA codes. But this approach has downsides:

The maintainer of this feature needs to keep things updated when the app's database schema changes!
The apps usually create a new account when the user logs in using LDAP. For the above approach to work, Cloudron should make those changes before the user's account is created on the app.

I have only done this with my own account because it's quite time consuming to replace the TOTP Secret for all users of my Cloudron instance; a script would certainly help.

2. Apps that do note have native support for 2FA
Proposed solutions:

Cloudron adds a feature to support PASSWORD;TOTP as password, and validate TOTP by extracting it from the input. For this to work, all users must be informed. I wish password managers and authenticator apps had a feature to make it easier to auto-fill 2FA codes as well...
can't think of another way, will add if I can come up with something

Enabling 2FA for all apps is an important feature for some users like me, because of compliance reasons & a bit of paranoia. I can't trust everyone to not fall for phishing attacks, so I really wish Cloudron team kept this feature in priority. For the time being, I'm enabling 2FA in per-app basis, and avoiding apps that don't have 2FA built in.

nj

After around a year of using Cloudron, I have installed many apps, and now the admin interface needs scrolling. I have a really wide screen but the layout won't adjust to fill the available space (4 cols only).

If only there was a way to fit more items on the screen it would be easier. For now, supporting upto 6 or 8 rows would do.

PS: The design of the App Store would do too.

nj

I'm in for this too. I haven't packaged an app yet, but only because of lack of confidence. It would be awesome to see someone do it, and later be able to help others do the same!

nj

@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.

nj

A surprisingly simple, user-friendly and free help desk software with an integrated knowledgebase. It's a simple LAMP app though, so posting it here for everyone even if it does not get packaged. https://www.hesk.com/

Caveat: You can only "download" it; no docker images and such, so it's best suited to be installed in a folder as a LAMP application. You can see it in action at https://www.yarsahost.com/support/.

Context:
I discovered Hesk after testing dozens of other helpdesk software because according to this issue on Github, FreeScout team is not going to have any decent homepage. Custom homepage and knowledgebase come out of the box. I quite regret purchasing so many "modules" for Freescout because I decided to switch to Hesk. That's the reason why I shared it here. Cheers!

nj

I am starting a new topic to keep the discussion to the point. Previous discussions are linked at the bottom of this post. This is to request Cloudron to support inline TOTP code with LDAP Password in the form password;2FCODE.

;TLDR User Stories

Admin can choose to opt-in for password:2fcode feature from Settings.
During authentication, Cloudron checks for the setting, and if enabled, splits password and 2fcode.
Cloudron performs authentication based on password and the 2fa code.

The last discussion with @girish ended with him mentioning that there's some standardization going on in the field of 2FA in custom fields of LDAP. Out of curiosity, I looked at the roadmaps of many open source projects and found that very few have any plans to standardize or even support TOTP secret through LDAP fields. I have no hopes of any standardization in the near future that Cloudron can look forward to.

I am serious about security, and mandate everyone in my team to enable 2FA whenever possible. We're also using more and more new apps, and I'm seeing mandatory 2FA in individual apps a lot of trouble to go through.

I already have 13 different entries for individual apps' 2FA codes, and the list is growing. Then there are the recovery codes of all apps written on dozens of pieces of paper - The situation is the same across the team, and it's only going to be worse when we stop using apps.

Please do something about it! Pretty, please?

More discussion on this topic:
https://forum.cloudron.io/topic/3285/2fa-for-all-ldap-apps/39
https://forum.cloudron.io/topic/2433/the-real-sso-with/1
https://forum.cloudron.io/topic/1972/i-am-missing-real-sso/1

nj

@humptydumpty Cloudron asks for the TOTP code on the same page, no?

Some websites show two steps in the UI, but actually send the username, password and code in a single request. Some websites ask for your username first, then display the password field, such as Google and Apple ID web. Some companies use the most common method of asking username and password at once, such as Facebook and Apple ID mobile app interface.

I don't think there's more security risk in one method than the other. If that was the case, all of them would be using the most secure way. That's exactly the same case for the TOTP code. Personally I prefer the username+password+totp in a single page because it "feels" more secure.

nj

@fbartels The repo seems to have gone, or is it a private repo? I was looking to package Drone, and found this thread.

nj

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!

nj

@girish I don't remember creating any folder myself, so I can't tell how it got created there. None of my other Cloudron instances had this issue so it might have happened somehow. I don't have any custom nginx config.

Maybe removing the tmp folder could have solved the issue without the -r flag. The error cp: -r not specified; omitting directory '/home/yellowtent/boxdata/certs/tmp' meant it couldn't copy the tmp folder because -r flag was missing. Also, I added -r because the error message hinted me to do so and it fixed the issue.

nj

@humptydumpty I like your idea of educating the users on the login page itself. You could also add something like This code protects your account even if someone stole your password. Or a better wording would make an impact, really!

nj

I think I am a little too paranoid here. Once I had to recover data deleted from the Gitea instance a month before. Since then I have this backup strategy:

Frequency: 01:00 AM daily
Retention: 7 daily, 4 weekly, 12 monthly
Method: Full snapshot (not incremental)

At all times I use around 23x180GB = ~4TB space only for backup.

nj

@girish, is there a way to import only active users when syncing users with LDAP?
After setting up Keycloak, only the "active" users could log in to Keycloak. But when I try to import active users to Keycloak, all users were imported, including those who were marked as not active in my Cloudron Users dashboard.

nj

So quick! It works, thanks! @girish!

nj

I have come across these problem after installing Matomo.

After first-time logging in with admin:changeme, I opened the personal settings page. I changed the default email admin@server.local to admin@mydomain. Then, I tried to change the default password, which told me that LDAP users cannot change their passwords. Maybe because admin conflicts with existing LDAP user. Problem: **I could continue to log in with admin:changme as well as with admin:MyLDAPpassworld.
The file manager runs into a problem while trying to view/edit matomo.js. The issue repeats with all all *.js files. Other files with different extention, like php.ini are good to view/edit.
This is a minor one - new version is available - 4.1.0.

nj

I just installed osTicket. I was checking the "System Logs" section on the admin panel of osTicket, where it showed the IP address of the reverse proxy server instead of the original IP of the client's device.

Looking at the docs, I discovered a setting called TRUSTED_PROXIES which was supported by osTicket. Setting the IP address of the reverse proxy there would fix the problem.

The config file is located at /app/data/ost-config.php and accessible from the app's file manager. Cloudron could set that variable when the app is configured for the first time.

#define('TRUSTED_PROXIES', '');
define('TRUSTED_PROXIES', '172.18.0.1');

Impact of the issue: Recording the reverse proxy's IP address could result in delayed or unsuccessful forensics in case of trouble.

nj

@subven The docs say we should not change this settings in this particular app. But the FROM address would be changed in all other apps if the email is configured on the app's settings on the Cloudron dashboard. In my case the email change was not honored by osTicket. I'm not entirely sure what went wrong.

I didn't make any changes to the SMTP server. I restarted the app every time I made any changes. I enabled 2FA (not a plugin, but built-in feature of osTicket) because that's the obvious thing to do for an admin account.

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Best posts made by nj