LDAP/AD Server
-
I think the only way this could be better is adding support for custom external apps added to the dashboard (they just link out).
-
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.
-
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.
-
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.
-
@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.
-
Custom Image installation for UCS for anyone looking into that option:
- https://docs.hetzner.com/robot/dedicated-server/operating-systems/installing-custom-images/
- https://www.univention.com/downloads/download-ucs/
- https://www.univention.com/blog-en/2020/05/register-your-own-account-new-self-service-for-suse-and-ucs/
- https://docs.software-univention.de/quickstart-en.html
-
@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.
-
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:
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:
- https://www.univention.com/products/univention-app-center/app-catalog/kvm/
- https://www.univention.com/products/univention-app-center/app-catalog/uvmm/
We're just setting all this up now, so will report back on any discoveries.
-
@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/
-
@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
-
@marcusquinn No, this is Proxmox. https://proxmox.com/en/
Sesam is a backup application, not a machine management solution.
-
@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.
-
@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?
-
@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.
-
@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
-
@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.
-
@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.
-
@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.