Jump to content

Recommended Posts

Posted

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?

Posted

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

  • 5 years later...
Posted

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

Posted
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.

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 account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...