Possible LDAP module issue in 1.6

[tailz303]

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]

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.

[darksidemilk]

@tailz303 do you know if you have ldaps configured in OpenLDAP. I am having trouble getting it working in a Microsoft AD environment, but I also know we've hardened the security requirements for signing ldaps requests. There might be something that needs to be added to the plugin to allow it to use newer security protocols.

[tailz303]

Well the fun part is I think something in the latest pull causes this. I cant see the previous server and adding a new server doesn't fix this either so I cant test if it works or not.

[mastacontrola]

I'm attempting to allow LDAP users to also access API as well. So I added a field.

This statement should fix that issue for you (from within mysql fog database)

ALTER TABLE LDAPServers ADD lsAllowAPI ENUM('0','1');

[tailz303]

Yeah dont know what im doing wrong but the DB password I set isnt working for root or fogstorage and so I tried with the fogstorage password it gave me in the gui and i get perm denied

[mastacontrola]

your fogmaster user password is stored on your FOG Servers /opt/fog/.fogsettings

I don't know about your root user.

[tailz303]

Okay using the fogmaster user in the .fogsettings worked. I ended up using the following command
UPDATE LDAPservers SET lsAllowAPI = 1;
I will try some more LDAP settings and see if maybe it not working is a skill issue on our end.