02/17/2009
11 am, N42-286, CSS Managers
Agenda
- Review of the IS&T User Accounts Policy (McGovern). Last year we wrote down what we currently do in creating, managing and deactivating normal accounts. This topic stems from a discussion several weeks ago, and is intended to provide a time to read through, discuss and answer questions about what our current policy is. This version of the policy does not yet address identity management at its broadest extent, or services like Touchstone.*
- CSS Managers Meeting Calendar and Agendas Visibility Review (Hunt, if we have time)
- Quick overview of RT Enhancement project underway. Pat Sheppard, Oliver and Steve Turner have been in conversation with Best Practical on steps to both get us up to a more current version of RT and carry out some much needed performance enhancements. I've asked Oliver to give us all a quick overview of this project and where it stands. (goguen)
Some notes from the discussion:
(Tim could do a far better job than I at capturing the current situation, issues, etc. But I will try to capture something relevent here to remind us of what we discussed.)
Kerberos accounts provide an electronic identity. They also provide ability to get certificates, email, filespace. They do not in and of themselves act as a tool for access control. Additional authorizations to restricted products/services/facilities must be requested from relevent administrators and are not granted nor revoked as part of the lifecycle of the kerberos account. And our policies around who can get kerberos accounts and whe/if they ever go away are a bit loose. With that said, our current loose practices in reality lead to very few problems.
Kerberos accounts come in 2 flavors - normal and special. Normal are those given to folks with official MIT affiliations (current faculty, staff, students). Special accounts can be granted to pretty much anyone else with any sort of looselly defined affiliation with the Institute. They must be sponsored, or requested by a current member of the faculty/staff. Regular accounts remain inn effect through the time that the individual retains their official affiliation with MIT. There is an annual account deactivation that occurs around the start of the calendar year that deactivates accounts for students who graduated the prior June as well as all other accounts tagged for deactivation.
Much of the discussion then centered around the desire to have a way for managers/supervisors to have better control over accounts/authorizations for staff they are responsible for, especially since there is no centralized access control. We discussed pulling together a checklist for managers/supervisors to use not only when bringing someone on board who will need a variety of authorizations, but also when someone is leaving and we need to revoke those authorizations. (Kate was going to dig up some materials that the old CG had pulled together.) The checklist, accompanied by doing a periodic review that we might put on the Managers' calendar would go a long way to making sure we better manage this stuff.