markwilfan Posted December 9, 2019 Posted December 9, 2019 Anybody managed to get Veyon to connect via LDAPS either SSL or TLS? Spent a good hour playing with settings and can't figure it out. LDAPS is definitely working everywhere else When using TLS with cert set to system defaults I get 2019-12-09T14:51:28.484: [DEBUG] [KLDAP] connection closed! 2019-12-09T14:51:28.484: [DEBUG] [KLDAP] ldap url: "ldap://sch4304.internal:636" 2019-12-09T14:51:28.487: [DEBUG] [KLDAP] setting version to: 3 2019-12-09T14:51:28.487: [DEBUG] [KLDAP] setting timeout to: 0 2019-12-09T14:51:28.487: [DEBUG] [KLDAP] setting security to: 1 2019-12-09T14:51:28.487: [DEBUG] [KLDAP] start TLS 2019-12-09T14:51:28.490: [DEBUG] [KLDAP] connection closed! 2019-12-09T14:51:28.490: [WARN] LdapClient::reconnect(): LDAP connect failed: "" Obvious thing that stands out here is it is still attempting an ldap and not an ldaps connection Anybody else had any luck?
markwilfan Posted December 10, 2019 Author Posted December 10, 2019 Just turned on LDAPS and enforced it. Playing with the veyon settings I have found that the following still works LDAP server and port: DC works but Domain Name doesn't so have specified a DC. Port 389 works however 636 does not Encryption protocol: TLS TLS certificate verification: Custom Custom CA certificate file: Exported CA cert in CER format, changed extension to PEM and plonked onto a share Hope this helps somebody
StephenPink Posted February 19, 2025 Posted February 19, 2025 Resurrecting an old thread as related to this - just updated/reconfiguring Veyon; 636 still doesn't appear to work - still need to leave on 389 which is annoying. Can't get the automatic location identification to work either; the "Filter for computer containers" won't recognise either (objectClass=organizationalUnit) or (objectCategory=organizationalUnit); but will recognise (objectClass=container). Leaving blank it just breaks; using the container means if the PC is in container (e.g default Computers) then it works, but breaks again if PC is in an actual OU. Anyone got this working? Cheers
StephenPink Posted February 19, 2025 Posted February 19, 2025 Is this any better to impero or senso ? I can't comment on that - we're only using it for classroom control, not in a monitoring/safeguarding capacity. Also - in case anyone else gets the OU issue Veyon responded much quicker than expected via Git: LDAP Basic - Filter for computer containers won't recognise OU · Issue #1009 · veyon/veyon (the solution was "This is a common problem if the location name attribute is empty or set to "cn", since OUs do not have this attribute. Can you try setting this attribute to "name"?") Setting the location name attribute in the Veyon Configurator resolved the issue.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now