That will teach me - I failed testing the removal of the group from the user. It turns out the ldap_search return is True but doesn’t seem to find the same as what the ldapsearch CLI finds…..
On 5/05/2021, at 11:22, Pieter De Wit via observium observium@observium.org wrote:
Hi Guys,
I have Google Secure LDAP working with Observium, but it requires a hack and hopefully the devs can implement this into the code base (after fixing my even more of my hacky hacks :) )
In config.php:
$config['auth_ldap_server']="ldap://127.0.0.1:1636 ldap://127.0.0.1:1636”; // We using the stunnel method $config['auth_ldap_port'] = 1636; // Not needed - at least, not that I could find $config['auth_ldap_starttls']=false; // Implemented with stunnel
$config['auth_ldap_suffix'] = ",ou=Secure_LDAP,ou=Users,dc=example,dc=com”; // Fix this for your domain
unset ($config['auth_ldap_groups']); $config['auth_ldap_groups']['cn=observium']['level'] = 10; // Google does something funky with “groups"
In html/includes/authentication/ldap.inc.php:
After line 932:
else { $filter="(&(".$dn.")".ldap_filter_create ($attribute, $value).")"; $ret=ldap_search ($ds,”dc=example,dc=com",$filter); // TODO : We need to figure out if ($ret !==FALSE) { $compare=TRUE; } }In a nutshell, ldap_compare doesn’t work for Google Secure LDAP - pretty much like https://jira.observium.org/browse/OBS-3611 https://jira.observium.org/browse/OBS-3611 but then, if the ldap_read fails, we fallback to just doing a search for the “group” and where memberUid is the username provided. It might be worthwhile to look into setting a LDAP type variable and reacting to that.
Hopefully this makes sense :)
Cheers,
Pieter _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium