[Deploying Sakai] [Building Sakai] Keeping access to graduated student's data

[Laura Gekeler]

David,
I understand Virginia Tech to have been a Sakai institution for several years. What has changed at VT? Do your requirements also include returning to view the records/data from students already removed from LDAP?

After 1 year, we (Notre Dame) are currently working with rSmart (our host) to convert our externally provisioned LDAP users into internal Sakai users provisioned by periodic file transfer. Our Notre Dame  IdM team will create the provisioning file and be able to track who is provisioned based on their database. We’re using CAS auth. An LDAP lookup will still be used to support WebDAV.

The only drawback in the user conversion scripting and our maintenance processes going forward is there doesn’t appear to be a straight forward way of re-assigning the already given Sakai Internal Id to an alternate ND id to support changes to the login ID.

Curious to know more,
Laura

From: production-bounces at collab.sakaiproject.org [mailto:production-bounces at collab.sakaiproject.org] On Behalf Of David Adams
Sent: Thursday, April 18, 2013 6:20 AM
To: Steve Swinsburg
Cc: production
Subject: Re: [Deploying Sakai] [Building Sakai] Keeping access to graduated student's data

Would it be possible to populate SAKAI_USER with the relevant data prior to the deprovisioning from LDAP?

David Adams
Director, Systems Integration and Support
Virginia Tech Learning Technologies

On Wed, Apr 17, 2013 at 11:31 PM, Steve Swinsburg <steve.swinsburg at gmail.com<mailto:steve.swinsburg at gmail.com>> wrote:
Whilst not ideal, msgcntr stores the user's name with a post, possibly for this reason (ie if students are removed) - gradebook could do the same and fall back to that info if the user is not available - there would need to be a way to fully purge a user from a site though.

Whilst I agree with Sam in that you could leave the users in LDAP and just disable their ability to login/be added to new sites, this can potentially be at odds with the normal deprovisioning practice of many institutions, so a Sakai specific solution might be required.


On Thu, Apr 18, 2013 at 4:19 AM, Sam Ottenhoff <ottenhoff at longsight.com<mailto:ottenhoff at longsight.com>> wrote:

We are looking for suggestions and ideas on how other schools are
dealing with this.


If you still want to access information related to graduated users, they should continue to live in your central user directory, LDAP.


If you keep graduated students in the ldap, do you
see any performance issues as the ldap database grows? How large is your
ldap database (i.e., number of students)?

I'm sure there are institutions and organizations with many millions of user records in their LDAP database.  Unless your institution is storing large amounts of binary data for each LDAP user, the records are extremely small.  LDAP was built for this use case, with its highly configurable structure and containers. I can't think of any better solution that continuing to store the users in LDAP.

--Sam

_______________________________________________
production mailing list
production at collab.sakaiproject.org<mailto:production at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/production
TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org<mailto:production-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"


_______________________________________________
production mailing list
production at collab.sakaiproject.org<mailto:production at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/production

TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org<mailto:production-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20130418/8a4b5286/attachment.html