LDAP/AD Server

Trankery

Hello.

I would really love to see an LDAP Server be integrated into Cloudron, where Users can either be selected from Cloudron, or created independently.

nebulon

Cloudron already comes with an LDAP server built-in, however it is only exposed to the apps installed. More information on how to use it with apps can be found at https://cloudron.io/documentation/custom-apps/addons/#ldap

Is this what you were looking for?

Trankery

@nebulon I'm looking for an LDAP Server that works outside of cloudron too, or at least an option to manage the users on it.

nebulon

I see, that is indeed then basically a separate app. Lets see if others are interested as well and we can discuss that here then.

yusf

I’d be interested in connecting external services to the Cloudron LDAP!

NCKNE

An LDAP server would be great. I would vote for an identity provider (with LDAP, Oauth, etc.)!
I think @jimcavoli is already working one something along these lines: https://forum.cloudron.io/topic/2320/scaling-high-availability-cloudron-setup/5

imc67

It would be extremely convenient to have Cloudron as a LDAP server (app) and contains "the one and only truth" about usermanagement (all users/groups etc) so external systems (like local NAS) can make use of it.

Is that feasible, easy to do, safe ...?

yusf

I know @murgero prototyped an LDAP-app a while back.

girish

@imc67 Yes, agreed. we will investigate this as part of our roadmap for next release.

nebulon

Some more info about this at https://forum.cloudron.io/topic/2559/cloudron-ldap-access-for-external-apps/7 lets discuss further in this thread.

Both concepts are possible, either expose the built-in ldap server or provide an app, which exposes the ldap functionality. Not sure which ones is better or worse for which use-cases.

yusf

@nebulon I guess one feature of an app based approach can take advantage of the app level access controls, so that the external use of the LDAP easily can be limited to certain groups and users.

nebulon

That is a good point. In that case the app could also contain a small UI to configure ldap admin bind credentials for searches I guess.

alexanderkings

Hello, I have been redirected from a support email...

I think my concern is similar to that of other users who need this feature.

Looking on github i found this:
https://github.com/mitchellurgero/cloudron-ldap-proxy

Security Warnings
THIS CAN POTENTIALLY EXPOSE YOUR CLOUDRON'S INTERNAL LDAP SERVER TO THE WORLD. DO NOT USE THIS APP IN PRODUCTION IN ANY WAY!!!!

I have not tried it yet, but think that with some precautions it can be implemented...

iamthefij

@alexanderkings I haven't finished the step of migrating this to a Cloudron app, but I've been using mole to securely forward ports between networks using SSH Private/Public keys. My Docker implementation is Dockamole.

I'm using it already outside of Cloudron to allow my VPS to scrape metrics generated on my home NAS.

The workflow would require a Server container running on Cloudron and then a Client container running on whatever machine you'd like to access the forwarded port. All services on that machine access the service through the local container and it's forwarded to the server container.

Like I said... I haven't gotten it running on Cloudron yet though.

friep2

just came here to add my +1 for this. i'm currently looking into cloudron for our tech-focused NPO with over 1000 volunteers and it'd be great to have some (at least basic) LDAP server to integrate with "from the outside". we self-host some more specialized tools (partially other open source tools, partially self-developed) which are not on Cloudron - rightfully so - and it'd be super convenient if we could integrate with Cloudron's LDAP.
The "one login for a lot of services" and permission management (certain apps can only be accessed by certain people) is definitely one of the main attractions of cloudron I see for us and it'd be great if this would be extensible to external apps. This would radically reduce the workload for us full-time employees: right now we have to add volunteers to 5+ different services if we want to properly onboard them.

infogulch

@friep2 As a fellow regular user, could I ask you to elaborate a bit on why it would be inappropriate to package up the "open-source / self-developed" apps to run inside Cloudron directly? This is an honest question, I'm quite curious about how different people perceive the limits of Cloudron. I'm sure you have considered many different options for deployment.

atridad

LDAP to the world would be interesting. I could also see a usecase for something like a SAML provider to redirect apps to a cloudron instance for SSO.

marcusquinn

Big for this from me. What can we do to get this happening?

First use would be with Unify apps and devices, so Cloudron could be a single source of logins, and single place to decommissions logins too for those moving on.

atridad

I think the only way this could be better is adding support for custom external apps added to the dashboard (they just link out).

marcusquinn

Just noting a link to a comment from @luckow on a similar post I made before seeing this one, with some alternative solution links: https://forum.cloudron.io/topic/4933/have-a-cloudron-instance-as-an-ldap-provider/6?_=1618906250553

I think this thread has the right ultimate goal - but that might be something I have to investigate an intermediary solution for if this doesn't get on the roadmap.

girish

I wanted to explain a bit why we have not exposed the LDAP: Cloudron has a minimal user database. This is exposed with LDAP protocol for the sake of app authentication. But it's not a real directory server. A real directory server requires storing a LOT more user information (well atleast that's what people expect from a real LDAP server) like say phone numbers, photos etc.

The other aspect is, of course, security. It's not a good idea to expose the LDAP server straight to the internets. We have to make some mechanisms to only allow specific IPs to connect to LDAP server etc. This is easily doable.

Are you ok with living the minimal user database limitation? If so, we can look into it.

robi

VPN to Cloudron for LDAP is reasonable.

LDAP should only work for auth'd users, so externally it just needs an interface to do that.

One thing that comes up is that external LDAP users only should exist which means not allowing them to log in to the Cloudron dashboard is a thing.

marcusquinn

@girish Absolutely, it really is just for having a master User record & Password for all the peripheral apps that support connection and then Cloudron could be a master on & off switch for each too.

@nebulon IF we get this, maybe worth considering making the Surfer user icon configurable, as I'd use some Surfer instances with .htaccess redirects to the 3rd-party apps, in the spirit of Cloudron being the gateway to all.

marcusquinn

Custom Image installation for UCS for anyone looking into that option:

girish

@robi said in LDAP/AD Server:

VPN to Cloudron for LDAP is reasonable.

I think that would then mean that the external app has to be in the VPN, no?

robi

@girish said in LDAP/AD Server:

@robi said in LDAP/AD Server:

VPN to Cloudron for LDAP is reasonable.

I think that would then mean that the external app has to be in the VPN, no?

Kind of.. the app just needs to know to use the VPN interface for that need.

marcusquinn

For interest, Hetzner will add the ISO to your account "Project(s)" as an available image to mount from, if you just email their support with the ISO url, ie:

https://updates.software-univention.de/download/images/UCS-Installation-amd64.iso

Contabo will too - you just need to specify it in the notes on the checkout and add €25 for a Custom build setup in the options.

Having only just discovered this UCS from @luckow 's nice recommendation. I now find myself quite interested in the KVM Apps too:

We're just setting all this up now, so will report back on any discoveries.

fbartels

@marcusquinn Don't get to excited about the uvmm app. Its discontinued for their next release. But most Univention users are using Proxmox for it anyways.

https://www.univention.com/blog-en/2020/12/ucs-5-0-discontinued-features/

marcusquinn

@fbartels said in LDAP/AD Server:

Proxmox

Oh, thanks for the headsup. Is that this? https://www.univention.com/products/univention-app-center/app-catalog/sep-sesam/

I only started looking at USC for LDAP services for 3rd party apps to integrate with like Unify. Now I'm down a rabbit hole of what else it can solve

fbartels

@marcusquinn No, this is Proxmox. https://proxmox.com/en/

Sesam is a backup application, not a machine management solution.

marcusquinn

@fbartels Nice! You like it?

Would it be naive thinking to try building a HA cluster based on multiple VPS instances across multiple providers?

fbartels

@marcusquinn Installing Proxmox on an already virtual server to create a ha cluster: yes, i think that would be naive.

Installing Proxmox on real hardware, spread over multiple data centers: that is what it was made for.

marcusquinn

@fbartels Cool - for performance, certainly agreed.

I was just thinking for testing purposes, I like to have a sandbox / staging version of everything we do, so not much point firing up 4 x bare metal racks with setup charges and minimum contracts just for that.

I guess the only way, as with everything is just try it and see what happens.

Back to the original thing with the need for LDAP. Do you or @luckow have any pointers on how we get UCS to see the outside world?

Looks like we need to expose port 636 but not found where yet. Anything else to be aware of?

fbartels

@marcusquinn personally i would try to connect to port 7636 instead as this is where their openldap is always listening (if you install their samba 4 ad mode, then samba would be listening at 636 instead).

Ucs has a firewall locally where these ports may need to be allowed for outside access, although on my test system they are generally open Soni don't think there is a default rule in place to close it down.

Then i would create a machine account for the cloudron host and use this account for the cloudron sided configuration.

marcusquinn

@fbartels Thanks, I'm running completely blind on this as I've not really found any documentation that gives any certainty on what's necessary or not, as one imagines every field has a reason and necessary action to create and highlight each value at the UCS end.

https://docs.cloudron.io/user-management/#external-ldap

fbartels

@marcusquinn I can imagine that the fields do not make much sense, if one has not really worked with ldap before.

Something like the following should work:

Server URL: ldaps://$your-univention-fqdn:7636
[x] Accept Self-signed certificate (since the univention ldap has a certificate from the ca on the univention system, better would of course be to import the univention ca on the cloudron host)
Base DN: cn=users,dc=your-univention,dc=fqdn
Filter: (objectClass=inetOrgPerson)
Username Field: uid

For the bind user I would again recommend to create a machine account on UCS. This is done from their management ui -> devices -> computers.
Click "add" select "Computer: Linux" as type and give the entry a name (for example "Cloudron"). After the item has been created open it and go to "Advanced settings" and unfold the "Account" entry. Here you can specify a password for your user.

Bind DN/Username (optional):  cn=Cloudron,cn=computers,dc=your-univention,dc=fqdn
Bind Password (optional): your choosen password

Now you can click on save on Cloudron and hit that sync button. If all worked out you should now see your ucs users (like their default administrator user) in the user list of your cloudron. These external entries have then a small addressbook picture behind their name to differentiate them from the native Cloudron users.

@nebulon feel free to use the above in your instructions at https://docs.cloudron.io/user-management/#external-ldap

edit: since were on the topic. I am using the following settings to sync groups as well:

Group Base DN: cn=groups,dc=your-univention,dc=fqdn
Group Filter: (objectClass=univentionGroup)
Groupname Field: cn

This then also gets some internal groups like "computers" and "printer-admins", but that does not bother me much.

marcusquinn

@fbartels Thanks - so far UCS is a long way from intuitive. I feel like I got invited around for dinner and pointed at the kitchen while everyone else already ate.

It seems strange to have to install an App for Lets Encrypt, as in that should just be a standard feature enabled for all to use or ignore.

I have a feeling we're going to have to start again with reimagine this VPS because guesswork setups and issues are costing way more time that expected.

The world really doesn't like solving the obvious needs in obvious ways.

Really appreciate the instructions as I'm tearing my hair out with now over a day on something that I really don't think should be this complicated.

It's like we have to deal with developers that think: "Well, we could make that possible, but since no-one has explicitly campaigned for it, lets just say its possible but not actually solve it, so everyone has to either learn everything we already know, or spend more time convincing us to make something obvious, then we might think about."

My only sanctuary in persevering with all this, is that with Microsoft, Google & AWS they'd also try and sell you some certified course nonsense as well before allowing you to play their specifically different ways.

marcusquinn

@girish Classic example of platform gatekeeping decisions costing every user the same inordinate amount of time.

Option 1: Cloudron does not block external LDAP access. We can then use that with non Cloudron apps and get on with our lives.

Option 2: Find someone that knows another platform that might do what could already be done with Option 1, if we are "allowed", then learn all the curiosities of that other platform and maintain it, just for one tiny single feature, that we could have with Option 1, if your discretion allows.

So far option 2 has cost myself and another person the last 2 days work lost from doing anything else that we would have otherwise been progressing.

OK, so we will learn another platform, and it might have some other useful features - but it is a forced situation based on platform owner decisions more than user needs.

Sorry to share the frustrations upstream, but I just see extraordinary value from the simplicity of this being solved, versus vast amounts of unnecessary time from every Admin that might want to solve these time costs for their group or organisation Users.

I cannot think of a single reason why anyone would not want this to be just a basic standard features. It's not as if the world didn't already agree LDAP is a solution. Now we have to get every LDAP platform to agree to allow it to talk to every other LDAP support platform too it seems.

fbartels

@marcusquinn said in LDAP/AD Server:

so far UCS is a long way from intuitive

Yes, I can imagine if you have no experience with windows domain administration there are a lot of foreign concepts in ucs. Plus its a system that has evolved over more than a decade by now so it lacks a few more modern approaches that Cloudron serves very well.

On the other hand I always get too much already when only seeing a Wordpress login form

girish

@marcusquinn said in LDAP/AD Server:

@fbartels Thanks - so far UCS is a long way from intuitive. I feel like I got invited around for dinner and pointed at the kitchen while everyone else already ate.

A bit off topic but I love your analogies

marcusquinn

@fbartels I keep trying to forget my Windows years but it seems the rest of the world is still there

We'll keep plugging away at this. Considering all we're looking for is just one master LDAP server. It seems a ripe opportunity for Cloudron to be that. Having a whole other VPS, OS & Platform for a single feature is kinda inefficient, but then the other options all look like vendor-lockin options.

friep2

@infogulch to be fair i did not look too much into the process of wrapping up apps in cloudron. if it's quite easy and flexible that could be an alternative for us

Still, sometimes i guess it's just easier / more convenient to keep things separated and integrate via LDAP. E.g. in cases where you might not want to give people access to the cloudron server (which i suppose they'd need to deploy the app).

friep2

uff just having read the whole thread: i didn't want to open up a Pandoras box with my comment for anyone, especially @marcusquinn. Thanks for looking into it!!
it's definitely more a nice-to-have feature for our organisation, so its absence won't keep me from pursuing cloudron

marcusquinn

@friep2 haha, someone has to be the lucky person to start any thread.

Just happens to be one I need to get to a "once and for all" solution now as it's a PITA without, nothing more frustrating than time wasted that doesn't need to be.

Making progress with the UCS setup alternative, and will try and post a step-by-step guide once we've gathered all those good pointers and followed it all through to working.

marcusquinn

OK, so we have Cloudron and Univention Corporate Server (UCS) connected and seemingly working.

A couple of questions:

"Automatically create users when they login to Cloudron" - is this just creating Cloudron Users when someone tries to login that has a USC login/pass but not yet a Cloudron User?
Is there any way to sync Cloudron Users upstream to UCS?
Does this support SSO?
- https://www.univention.com/blog-en/2018/06/one-password-for-all-services-and-networks-with-single-sign-on/

luckow

@marcusquinn

It's only creates users in Cloudron, if the user exists in UCS. This is where the self-service platform comes in.
No. (not in my understanding of the external LDAP connection from Cloudron side).
good question If you've tried it out, please share your wisdom with us.

Attention:

The allowed characters for UCS & Cloudron users are different. You can create UCS users which never allowed to login into Cloudron because of the character limitations in Cloudron. https://docs.cloudron.io/user-management/#valid-usernames
Sorry I never managed a kind of policy to disallow special characters on UCS.
The email address which Cloudron needs (without an email, the user doesn't exist) is labeled primary email addresson UCS side.

fbartels

@marcusquinn said in LDAP/AD Server:

Does this support SSO?

That is why I suggested to run UCS in your local network. You could SSO with Kerberos from your workstation and then be directly signed into configured saml and oidc applications (and Kerberos of course as well). This only has two downsides:

their sso clashes with their lets encrypt app, which requires manual work after the first certificate has been retrieved.
this all does not touch Cloudron anymore, except you mod applications on Cloudron for one of the above auth methods

marcusquinn

Thank you both @luckow & @fbartels I feel this thread is a useful repo for gathering all the experience and getting this it's own Cloudron documentation.

We'll add anything we've learned and steps along the way to get whatever we can working.

Something I'm not sure that anyone knew before was that both Hetzner and Contabo will offer access to the custom ISO to install from if you ask them nicely and send them the correct public link to it.

Hetzner I know we can create a Network within, I've not needed to try that with Contabo yet though.

I've also learned about Proxmox, and that could be worthy of it's own dedicated how-to thread and documentation here, given the utility it can offer self-hosting on bare metal on premises or leased.

The community experience here is priceless!

fbartels

Replying here since this is the largest collection of ldap specific topics on this forum.

My cloudron installation is around longer than the cloudron external ldap support. When configuring an external ldap users with a conflicting username (same username already exists on cloudron) get skipped on synchronisation. Which is generally a good thing. But I still wanted to transfer password management for some of these users to my ldap.

This can be done by running the following command from the shell of the cloudron host (only change the-user-i-want-to-change to the actual user):

mysql -uroot -ppassword -e 'update users set source="ldap" where username="the-user-i-want-to-change";'

fbartels

I have also made a writeup of this on my blog

Lonkle

@girish said in LDAP/AD Server:

@robi said in LDAP/AD Server:

VPN to Cloudron for LDAP is reasonable.

I think that would then mean that the external app has to be in the VPN, no?

I'll be releasing my VPN Client for Cloudron over summer if that helps.

luckow

@fbartels Top post. Thank you.
One (maybe) last question: do you have a solution for the different allowed characters in UCS and Cloudron usernames? My idea is to have some kind of profile with only allowed characters on the UCS side. See https://docs.cloudron.io/user-management/#valid-usernames for characters allowed in Cloudron.

fbartels

Thanks @luckow

Yes, I have seen the question that @BrutalBirdie posted at https://help.univention.com/t/restrict-username-allowed-characters/17280 as well. But no, I am not aware of a way to limit characters with the ucs self registration.

marcusquinn

Related: https://forum.cloudron.io/topic/5636/quite-urgent-accessing-cloudron-ldap-from-an-external-instance-of-espocrm

fbartels

Not sure if it was already mentioned here, but there is https://github.com/mitchellurgero/cloudron-ldap-proxy by @murgero. It's downside is however that the connection is not encrypted.

A potential improvement over this would be to have a small app, that generates a custom ssl ca and serves its root cert over a small webserver. Then you use the same ca to provide a certificate to stunnel, which simply passes through the otherwise internal Cloudron ldap.

Then at least the communication would be secured, but it may still be an idea to limit who can actually reach that port through your firewall.

As a custom build this is quite easily doable, as an official app its probably too special.

marcusquinn

@fbartels Thank you kindly! @vladimir-d is working on this issues, and we may try pulling in extra help too.

All ideas are welcome as we are heads-deep in plugging the knock-on consequences if these still unsolved things.

I wish I could find the time to show more people what they will get back from us in development investment, but I can't do any of these things while blocker issues have become day & night urgencies.

robi

It looks like my friends at Aporeto.com got acquired by PaloAlto Networks. They have an OSS projects called Trireme - https://github.com/aporeto-inc

Trireme, an open-source library curated by Aporeto to provide cryptographic isolation for cloud-native applications. Trireme-lib is a Zero-Trust networking library that makes it possible to setup security policies and segment applications by enforcing end-to-end authentication and authorization without the need for complex control planes or IP/port-centric ACLs and east-west firewalls.

Trireme-lib supports both containers and Linux processes as well user-based activation, and it allows security policy enforcement between any of these entities.

A good tool for Cloudron as well as securing LDAP across machines.

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

LDAP/AD Server