Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible LDAP module issue in 1.6 #675

Open
tailz303 opened this issue Jan 8, 2025 · 1 comment
Open

Possible LDAP module issue in 1.6 #675

tailz303 opened this issue Jan 8, 2025 · 1 comment

Comments

@tailz303
Copy link

tailz303 commented Jan 8, 2025

I wanted to get some opinions on this before creating a bug report as this might be a skill issue on my end. When enabling the LDAP plugin on 1.6 you're able to set up everything pretty much right away.

The problem is: Now what...
There doesn't appear to be a way to use choose to the LDAP realm for auth, and trying a valid LDAP credential doesn't work either even if the account is pre made. It also keeps resetting to Active directory for the template in LDAP config even though we use openldap.

Me and our LDAP/DNS/Linux guru spent some time with no luck and there doesn't really seem to be a way to test the LDAP config or verify that it's doing anything at all.

I am using The same LDAP credentials I use for the proxmox server, and proxmox even let's you make realms and choose those realms on the login page, ie LDAP, Linux PAM, Proxmox VE auth.

We once used a tool called pgina on our windows machines for LDAP auth which is where the proxmox LDAP config came from. that allowed us to configure auth order, ie LDAP then local or local then LDAP and that was useful for say laptops which might not be able to access the LDAP server all the time, they would need local first whereas a desktop would always be LDAP first.

These are just some examples of solutions in my experience, is there something I missed or is it just a feature that hasn't been added yet?

Also please let me know if these reports are helping. This project is awesome and I want to be as helpful as possible, but not overwhelm you guys.

Thanks,
Cody

@mastacontrola
Copy link
Member

The way the LDAP plugin is coded, it will try ALL ldap's that you provide. So:

ldap1 - config
ldap2 - config

Users exists in ldap2 but not in ldap1 (or vice versa) it will check both, and as long as the user exists in either 1 or the other, it will allow them to login. (whichever has highest permissions will be used to drive the users permissions.)

For example:
user exists in both ldap1 and ldap2

On ldap1 the user is setup in the same group your admin is configured, but ldap2 they're read only, (or vice versa) the user will have administrative privileges.

This way you only have to configure and things should just work. maybe not pretty but this is still a plugin remember. FOG was never built for true access controls and has gotten so large that it's near impossible to add that "real" possibility without literally starting from scratch (which will eventually hopefully happen with what we have called fog-too/fog 2.0)

There is no knowledge of realms off the gate that I'm aware of. Nor am I fully familiar with them. I apologize, but hopefully that makes sense?

The "Template" resetting is because this is completely client facing.

There is no "column" where we store the "true" template of the type of configuration. Maybe there should be but ultimately it doesn't "Drive" anything. So it was decided the template was more or less suggestions for what "type" you're using. it doesn't actually tell LDAP plugin HOW to connect.

it's simply there to say: Oh you want to use Active Directory? Here's the "fields" for mapping (usually) to do that. Oh it's OpenLDAP, here's how to set that up. it's not stored anywhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants