Group vs OU storage quotas

[alexgrutza]

I'm familiar in the sense that a group would supersede the OU in which the user(s) are in. However, we have a specific configuration that we're looking to accomplish.

• student ou in ad
• student ou in google
• student ou in google authenticates to our sso platform
• student ou in google has a storage quota applied (50gb)

What we're looking to do

• create an alumni group in ad
• *note that a user in the ad alumni group will never be removed
• create an alumni group in google
• sync users from ad alumni group to google alumni group
• members of this alumni group will be located in the student ou in google (same place as active students) so they authenticate to our sso platform
• apply a X-gb storage quota to the alumni google group

Where my confusion is this

• I am an active student, I have 50gb
• I graduate, I become a member of the alumni student group, in which I will never be removed from
• I no longer am taking classes so I am solely an alumni (active student status is removed)
• I am only an alumni in google so I have X-gb quota applied (I still reside in OU with 50gb quota), but I get less because I'm in the alumni group
• Time goes by and I come back as an active student
• I as an active student should be given the 50gb quota, but I am being limited because I am an alumni (and always will be)

How do we handle this situation? Do we do the inverse and...

• set smaller quota for the student ou in google, then have users in an "active student" group have a higher level?
• we want only one ou for students/alumni so that they're all behind our sso platform and managed via ad/sso platform

[Kim_Nilsson]

Without touching on the actual issue... Alumni is a concept that should absolutely never have been allowed by Google. Such users are no longer part of the organisation (not staff nor student) and should not be allowed to keep or have accounts in the organisation.

[alexgrutza]

I would not disagree, and I wish it were as simple as "you have 90 days to move your stuff", but unfortunately, we have alumni who are still part of the community and require access as such (think work on behalf of student groups). So they are technically still active members of the community, but not enrolled in classes. I get your point and agree they should not exist, but in reality impossible to accomplish

[Kim_Nilsson]

Here it would be illegal to keep the accounts. GDPR doesn't allow it.

Data privacy laws only allow data of existing students or staff to exist in our systems, unless there's a legal requirement to keep the data longer, where user accounts is not such a requirement, only graduation grades. Not even medical records or pedagogical investigations. All such information is to be passed on to the next level of education (for example primary to secondary) or purged after a certain amount of time.

[Kim_Nilsson]

Back to the actual issue. You have a logical problem.

A person can't ever be both a student and alumni at the same time. Those are exclusive statuses.

[alexgrutza]

You and I have similar logical processes, but again unfortunately in reality/practice incorrect.

*Edit: the terminology (student and alumni) are just visual representations of access required. I agree if you're active you're not an alumni, but that is related to logical thought, not based on access

A student has access to specific student apps - ie SIS and learning tools

Alumni retain access to specific apps (not student apps) - ie google

[icrew]

Maybe do sub-ous under your “students” ou, like

/Students/Current (with the 50GB quota)

/Students/Alumni (with the lower alumni quota)

Then have people moved into /Students/Alumni with the criteria “if alum, but not current student or employee” and have people moved into /Students/Current with the criteria “if current student (regardless of alumni status)”.

I’m really not familiar with Active Directory, but I know that many group management tools (like InCommon Grpuper, for example) can easily do that sort of Boolean logic on groups. 

Hope that helps,

Ian

[alexgrutza]

That begs the question of supersedence of groups: if employee group and student group have 100gb and 50gb respectively, which group wins? The one with the higher threshold?

Because we do have students whom are also employees (actual employees, not student workers) (ie. they were students first). We also have the opposite, employees first then started a degree or classes.

[Kim_Nilsson]

When you have more than one group (and are able to set more than one for the same OU - not always the case!), you should be able to decide order.

[icrew · Accepted solution]

You set the precedence of the configuration groups in the admin console….see https://support.google.com/a/answer/9224126?hl=en#zippy=%2Csetting-priority-for-configuration-groups

[alexgrutza]

I think this will be the route thanks Ian!

Group related quota policies

• Employee groups (staff or faculty) #1/2 - large-GB quota
• Active or Incoming student groups #2/3 - large-GB quota
• Alumni group #4 - small-GB quota
• Bypass groups that need to clean up their accounts (eg. an alumni over the alumni quota that doesn't meet the any other criteria) - large-GB quota

OU related quota policies 

• employee ou (staff and faculty reside) - small-GB quota 
• student ou (incoming, active, alumni reside) - small-GB quota