6.3 pro : Group nesting and LDAP SYNC


#1

Hi @daniel.pan,

What are the impacts between the new group management and LDAP Group Syncing ?
https://manual.seafile.com/deploy_pro/ldap_group_sync.html

Can we sync departments from LDAP apart ? (is there any filter available)
Can we select LDAP group members to be department admins ?
Can we sync nested LDAP groups to nested Seafile groups ?


Separate management from existing groups to new deptements/subgroups may be confusing.

Only admins can create departments --> they can create nested groups too
Users can only create groups (as before) --> they can not create nested groups

Can we convert existing Seafile groups to new departments ?

Iā€™d like to know a little before getting this version in production

Regards,

Gautier


Seafile Professional Server 6.3 is ready for testing! Major new group functions
#2

LDAP groups can only be synced as flat groups in Seafile. But OU in LDAP can be synced as departments in Seafile. See https://manual.seafile.com/deploy_pro/ldap_group_sync.html (search OU).

It is also not possible to convert existing Seafile groups to nested groups in the current version.

I think the current workflow is:

  1. If people need group owned libraries, they ask admin to create a ā€œdepartmentā€
  2. The admin create the ā€œdepartmentā€ and set quote and add group admins.

Suggestions are welcome.


#3

Hi Daniel,

I think that this is a good model for group management between LDAP and Seafile.

But, il could be useful to get the departments admins from the LDAP by means of a specific filter based on a Person attribute.

This is already what we do when creating a group with the admin and share the libraries (Admin quota) to the group.

Now, we can delegate the departement management to other users, and set the quota directly to the departement.

The admin does not have to be a member of the group anymore (which caused some privacy issues).

Is that right ?

Regards


#4

The admin of a group still need to be a member of the group. In a later version, we will add the feature that a group admin can manage sub-groups of that group.


#5

Hi, looking at the manual, I have some more questions.

Is it possible to Sync Both GROUPS and DEPARTMENTS based on different GroupObjectClass (i suppose not) ?

When enabling Syncing OU to departments (GROUP_OBJECT_CLASS=organizationalUnit), is it still possible / accurate to use these options ?

  • GROUP_FILTER
  • GROUP_MEMBER_ATTR

Regards,

Gautier


#6

Hi @gauburtin,

We plan to allow syncing both groups and OUs from AD in later version.


#7

Hi Jonathan,
Thank you : i hope this will also work with OpenLdap :wink:

Regards


#8

Hi,

Is it supported in this version ?

Also,

Is it possible to have differents OU / Department mappings in the following configs ?

https://manual.seafile.com/deploy_pro/multi_tenancy.html
https://manual.seafile.com/deploy_pro/multi_institutions.html

regards


#9

Hi @gauburtin,

This feature is not implemented yet.

There seems to be some confusion among these 3 features:

  1. multi-tenancy
  2. multiple institutions
  3. departments

Multi-tenancy is more for SaaS providers. They can host many small customers within one Seafile instance. Each tenant is completely logically separated from each other. They cannot share folders with each other, except for using a link.

Multiple institutions is similar to multi-tenancy but with the exception that users in different institutions can share directly with users in other institution. Each institution can have its own admin, who can manage the users in its institution.

Both multi-tenancy and multi-institution is design for kind of ā€œpublicā€ hosting. While department is designed for internal management of an organization.

Currently the multi-institution feature is only used by hosting provider for universities. They usually assign new users to institutions based on Shibboleth login attributes. In the future there may be need for syncing this relation from LDAP or AD.


#10

Hi,

Thank you for reminding us the differences between the hosting options.

My questions are based on a specific use case.

As a university Campus, we will provide seafile hosting to different institutions, which could lead us to use Multi-institution feature

  • for users originating from different universities
  • but who need to share files between them and also create groups independant from the institutions.

We will not use shibboleth affiliation, because we already build a LDAP directory in which all users are separated between OU = institutions (organizationalUnit) and Groups = Laboratories (groupOfNames).
Laboratories do not depend from institutions, their members can belong to different instiitutions.

We already (since 2 years) have a Seafile instance for our institution, which must be separated from the others.

Instead of installing a new seafile instance, iā€™m thinking of one Multitenancy instance in which two tenant (the former and the new one) could share the program files, but with a logical split between the two.

In this case, we could have two LDAP for each one tenant.

As it seems to be difficult to implement, i suppose that installing two instances of seafile is the best way to achieve our goals.

  1. The former one with classic config and LDAP Syncing :
  • We already have former ā€œgroupsā€ for departments and iā€™m afraid it will be difficult to migrate these to departments.
  • Instead the nesting feature, i donā€™t really see the differnce between the two options.
  1. The new one, which could be a multi-intitutions instance, but we may need to
  • sync departments from LDAP in each institution
  • create groups between institutions

Which i think is quite complicatedā€¦

Regards


#11

Hi @gauburtin,

We would recommend you to setup two separate seafile instances. For the new Seafile instance which serves the universities, itā€™s simpler if you just use the ā€œdepartmentsā€ feature to organize the universities and the departments under them. There are still two missing features to make this setting possible:

  1. We need to support syncing both OUs and groups. We plan to add this support in 6.3 version in near future.
  2. A new interface for department admins to manage the user quotas and files in the departments under their administration. The concept is similar to multi-institution, but expanded to nested departments. Perhaps at the beginning you donā€™t need this feature, but just manage the users directly with the global system admin. This is still to be discussed.

UPDATE:
Another simple idea is to use multi-institution feature to separate the universities at the top level only. The departments and groups can still be imported to Seafile. For the users departments and LDAP groups are all just ā€œgroupsā€ in Seafile. The good thing of this solution is that there is not too many level of administration. And having any department admins to look into usersā€™s files may not be a good idea either. (This could be very desirable for companies though.)


#12

Hi @jonathan,

Thank you for your suggestions. We are still investigating many solutions.

One of them is based on our Identity / LDAP manager, from wich we could

  • create user accounts into seafile (with the LDAP pwd) ;
  • define user profile and quota (if the API allows to)
  • populate Group with users (from OU or any other LDAP structure)

This feature could be based ont a plugin that uses Seafile API.

We are not sure that synchronizing LDAP to Seafile is the most accurate way, because many operations are done in background and not controlled by a human. As identity management is quite a complex and risky field, we would like to know exactly what happens between LDAP and Seafile.

I will give you some feedback about this plugin if we achieve to make it work.

Multi-institutions could be a global solutions, but many structures (60) that will use our Campus cloud are ā€œlaboratoriesā€ in wich users depends on different ā€œuniversitiesā€ (10). It would then become too much difficult to build a collaborative space between close institutions.

Regards


#13

Users from different institutions can still be placed into groups.


#14

Thank you @Jonathan, iā€™ll keep this information in mind.