Role Mapping UCS @School > BigBlueButton

UCS@school
#1

Hi Folks,

installation & ldap configuration of BigBlueButton is straight forward and works like a charm. Could someone advise how UCS@school stores the role information (student, teacher, staff) and how to mapp this to accordingly created BBB Greenlight Roles?

Sorry, but I’n not very familiar with ldap…

thx

Mat

#2

There are three things that you can use to identify the users role:

  1. The attribute ucsschoolRole starts with the users role. There will be one entry per role and school of the user:
  • ucsschoolRole: staff:school:DEMOSCHOOL
  • ucsschoolRole: student:school:DEMOSCHOOL
  • ucsschoolRole: teacher:school:DEMOSCHOOL
  1. The objectClass of a user object:
  • staff: ucsschoolStaff
  • student: ucsschoolStudent
  • teacher: ucsschoolTeacher
  • staff and teacher: both ucsschoolStaff and ucsschoolTeacher
  1. The user objects position in LDAP - deprecated, try to avoid relying on this:
  • staff: cn=mitarbeiter,cn=users,ou=$OU,$LDAP-BASE
  • student: cn=schueler,cn=users,ou=$OU,$LDAP-BASE
  • teacher: cn=lehrer,cn=users,ou=$OU,$LDAP-BASE
  • staff and teacher: cn=lehrer und mitarbeiter,ou=$OU,$LDAP-BASE

Greetings
Daniel

1 Like
#3

Hi Daniel,

appreciate your swift reply! But I don’t get how to solve my task :frowning:
So I have a teacher with two UCS@schook options ticked on:

UCS@school-Administrator
UCS@school-Lehrer

Based on this I can find using ldap browser objectClass

  • ucsschoolStudent
  • ucsschoolTeacher

ucsschoolRole is staff:school:DEMOSCHOOL

But two things I don’t understand: why ucsschoolRole is only set to staff and how to use objectClass für Greenlight field LDAP_ROLE_FIELD

#4

Hi!

The UCS@school-Options UCS@school-Administrator and UCS@school-Lehrer are currently mapped to LDAP object classes (e.g. ucsschoolTeacher, ucsschoolStudent, ucsschoolAdministrator). But we are in the middle of a migration to a new, more flexible mechanism which uses the LDAP attribute ucsschoolRole. Hint: if the migration is completed, it is likely that the objectclasses will be removed. So the LDAP attribute ucsschoolRole should be used for new implementations.

The objectclass and ucsschoolRole are currently kept in sync by the UMC modules Benutzer (Schulen) and the UCS@school importer. If the UMC module Benutzer is used directly, there might be inconsistencies, that should be checked and fixed to avoid problems.
So if ucsschoolRole does not match the LDAP object classes, please investigate the reason for this inconsistency.

Regarding Greenlight/BigBlueButton:
the last time I tested BigBlueButton, Greenlight only added the LDAP attribute specified in LDAP_ROLE_FIELD to the existing Greenlight user
This means that if in the Greenlight configuration LDAP_ROLE_FIELD is set to e.g. univentionFreeAttribute2 and on the LDAP user foo the attribute univentionFreeAttribute2 is set to admin, then the role admin is added to the Greenlight user (univentionFreeAttribute2 is only an example, it may be any other LDAP attribute that just contains the name of the Greenlight role).
It should be noted, however, that only new roles have been added in Greenlight. This means that if foo is downgraded from adminto user, the role admin at the corresponding Greenlight user is not removed again.
So far I don’t know of any workaround or fix for this.

Greetings,

Sönke

#5

BTW: this combination of user roles is not allowed in UCS@school:

A user can only be one of student, staff, teacher, teacher and staff, teacher and admin or staff and admin.
Please use only the UCS@school UMC modules to create school users. They will take care you have consistent users and they are in all required groups.

#6

sorry, copy / paste typo - I have the objectc for admin and teacher

but I guess I will go with the approach to create a univentionFreeAttribute

Mastodon