Use Resources with SOGo

Since version 1.3.7 SOGo supports the management of resources like meeting rooms or beamers. A resource has, just like a person, a calendar, an email address and may be invited to events. The big difference is that resources auto accept invitations.

Configure resources with OpenLDAP

LDAP needs a new scheme for resources: calendarResource which is defined in this IETF draft. (It is not final right now) You also need the parent class for it calEntry which is defined in RFC 2739.

Martin Lehman contributed a calendarResource.schema file on the mailinglist (or use the attached version of calresource.schema). There is a modified schema for calEntry from openLDAP, which allows to use Unicode URLs instead of ASCII URLs only (or use the attached version of it calentry.schema). Configure your LDAP server to use these schema files. Then use your favorite LDAP tool to add some resources:

  dn: uid=meetingroom,ou=resources,dc=example,dc=com
  objectClass: inetOrgPerson
  objectClass: organizationalPerson
  objectClass: person
  objectClass: top
  objectClass: CalendarResource
  objectClass: calEntry
  cn: Big Meetingroom
  sn: Meetingroom
  displayName: Example Big Meetingroom
  givenName: Big
  Kind: location
  mail: meetingroom@example.com
  Multiplebookings: 1
  uid: meetingroom

There are several things to note:

In case you are using the same LDAP container (e.g. ou=people,dc=example,dc=com) as for your users (which is recommended because Lightning may only use one of SOGo's address sources for auto completion) you do not need to change anything in your configuration as SOGo will automatically detect a resource by objectClass: CalendarResource.

Be sure that the resource has set at MINIMUM "View Time and Date" for "All Authenticated Users" is set in ACL.

Configure resources with Active Directory

It is possible to put CalendarResource objects into an Active Directory, since it is essentially just another LDAP server. On the SoGo Configuration side, all notes in the OpenLDAP section above apply to Active Directory. However, extending the LDAP schema to include the necessary object types works differently. The schema definitions from RFC 2739 and draft-cal-resource-schema-03 clash with the default Microsoft schema in more than just one way. Additionally, AD wants schema extensions in the form of LDIF files - so the OpenLDAP schema files are not very helpful.

Before you start

Adding the CalEntry schema

RFC2739 defines calendar attributes for vCard and LDAP. For unknown reasons, it uses OID values from the ISO USA Microsoft tree (1.2.840.113556) that clash with existing OIDs used within Active Directory. However there is a newer IETF draft that propses a differend OID range which resolves the conflict.

This LDIF file (calentry-schema.ldif) contains the necessary changes, all you need to do is fill in the correct root DN for your domain and import the file on the commandline using ldifde -i -j . -f calentry-schema.ldif

Adding the CalendarResource schema

The Calendar Resource IETF Draft defines an Attribute called "Categories". Being a rather generic name, it's not surprising an attribute object by that name already exists in the AD schema. Since both are essentially text fields in different encoding formats, we could try and re-use Microsofts attribute - but since SoGo does not use this field anyways, we're on the safer side to either remove or rename it.

This LDIF file (calresource-schema.ldif) contains a Calendar Resource schema extension which has the "Categories" attribute renamed to "CalCategories" to work around the conflict. This may cause incompatibilities with other tools, so use it with care. Again, all you need to do is fill in the correct root DN for your domain and import the file on the commandline using ldifde -i -j . -f calresource-schema.ldif

Adding a new Resource

We should now be ready to add the resources we need now. This example ((add-resource.ldif) adds an extra organisational unit "Resources", and a meeting room. You can view Resources in the ADSI Editor, but you will only be able to view and edit the fields corresponding to the User class. If you want to edit the Resource-Specific attributes, you will have to use LDP or any other LDAP editor.

Configure resources with SQL databases