I was searching for an alternative solution to Jupyterhub and after spending some time on Google, I’ve found the Open OnDemand platform. The solution seems to be pretty nice and highly focused on HPC/AI environments.
It turns out that I’m struggling with OOD setup for three days, absolutely with no success. I’ve followed the docs, but the part of authentication is tough to get working. I’ve tried DEX with LDAP, just LDAP, and PAM configuration, and I simply cannot move forward from the very annoying “have to configure authentication” page.
I would like to suggest the maintainers to allow a basic configuration first, even using a default username/password, just to get the application working with basic functionalities, instead of forcing us to configure the authentication method at first glance. Several applications work like that.
The portal (and the idea) seems to be very interesting, but I suspect that many professionals will give up on it just because of this complicated authentication setup. Indeed, we can see many topics here asking for help or complaining about the authentication setup.
Sorry to hear about your frustrations. Authentication is often the main aspect of configuration people have some difficulty with, mainly because it seems everybody has their own unique approach / configuration to it.
We used to have a very basic authentication option, but we removed it several years ago. The main reasoning behind that was far too many people were doing exactly what you are trying to do: setup a quick initial system to play around with. The main issue was they often quickly turned that ‘sandbox’ into a full fledged production system and didn’t get back around to properly configuring the authentication.
This leaves open significant security holes in any installation, which was a huge issue. As such, we made the concerted effort to remove basic authentication to force sys admins to configure some sort of serious authentication from the get-go. It makes it a bit more difficult to stand-up a system from scratch, but it pays off in the long run immensely.
As one having struggled with this very issue, I can tell you that in hindsight it’s easy, but it feels very hard (and it is very time consuming) while you do it. My suggestions are the following
Important Preliminaries
make sure you understand as much as possible your own LDAP/AD server (and I say that while I don’t with mine, but I try)
use ldapsearcha lot checking its content and how users are reported in it. For example I typically search simply -x "(objectclass=*)" to get as much information as possible from it
study your sssd.conf (and/or your /etc/sssd/conf.d/*) and again try to understand as much as possible what’s in there and how it works
Essential
make sure you have the INFO level of logging
figure out where OnDemand or its LDAP logging things place the relevant logs (in my case it’s /var/log/message not sure why not /var/log/secure YMMV
find in said logs the lines that have level=INFO msg="performing ldap search" and see what they are searching
compare the previous step with what you have learned in the preliminaries – this is typically self-explanatory
Example
For example in my case I noticed in the log that the filter contained (userPrincipalName=my_username) instead of what my LDAP server wanted which is (userPrincipalName=my_username@domain.lab) (as reported by the regular sssd logs which were working). The easy solution was for users to login with their full domain, and that allowed me to move forward. I wanted to fix that, but couldn’t without the help of the fine folks in this list, as described at Simplify login for users using LDAP/DEX but of course it’s one thing to ask “it doesn’t work” it’s another to go with the specific query that you need vs the one that OnDemand/Dex/whatever creates based on your config.
