Systems: The first few sentences refer directly to long-standing policies and principles held by the Library faculty & staff, but the document itself is not presented on behalf of the faculty & staff. We’re happy to rephrase the document to make that distinction clearer. There are no new policies proposed in the document, only the descriptions of tools and behaviors needed to bring daily practices in line with legal and policy requirements that have existed for several years.
Bob: At our meeting John indicated that the individual unit should do this through AD Group Editor, but in addition to pushing systems security work out to individual units, it was unclear whether this was what John had in mind.
Systems: The “Active Directory Group Editor” is available from the Systems web page. Authorized employees in the unit can use this tool to manage such access instantly. Using the BEL example, currently Becky, Carissa, and Zoe have the ability to add and remove any user from the BEL groups. Such changes typically take effect in the campus Active Directory within a few seconds (a lag exceeding a couple of minutes is considered abnormal).
It’s important to understand that the AD Group Editor tool was developed by Systems in order to empower Library units to directly manage access to the computers in their location(s), their file server directories, and their web server directories. This does not represent a transferal of systems security work to the units, but a more streamlined process. Previous to the availability of such a tool, it was their responsibility to notify the Systems Office of changes in their personnel, and then wait for Systems to enact those changes.
Systems: Good question. There are a couple of workable solutions, depending on the training scenario.
Scenario 1: Using the Voyager Training instance. That system’s accounts are completely independent of those in the production Voyager. Because the training system does not have sensitive information in it (patron records & financial data), it has been common practice to create accounts used specifically for the training sessions. Sharing those accounts presents no real security concern.
Scenario 2: Staff & faculty trained in the labs using the Production Voyager instance. In this situation, the attendees will simply start the appropriate Voyager client(s) and log in using their own Voyager accounts. This would afford them exactly the same Voyager permissions as they have at their usual workplace.
Scenario 3: Students trained in the labs using the Production Voyager instance. We need to do some one-time preparations for this to work, as follows. The workstations can be configured with the same Voyager AutoLogon software that we’ve developed for regular workstations. We can also configure those machines to log in using Operator IDs with whatever profiles are necessary for the training.
Systems: This question is self-contradictory. The supposed need for every employee to have a dedicated PC in such areas is based on the claim that logging off when one leaves the PC is so annoying that one can’t be expected to do so, thus everyone will need to keep “ their” PC logged in all day. This is exactly the problem with current behaviors that must change, especially when logged in with a Voyager Circulation client running. So, providing additional PCs would make the problem worse than it is currently.
Systems: Potentially, but it actually presents an additional argument in favor of utilizing the system we’ve developed. If a student performs an illegal or inappropriate activity that is so severe that it causes the University or Dean of Students to disable their campus network authorizations, then that student would be barred from student employment anyway. (A common situation like downloading copyrighted media in a dorm would result in the disabling of the Ethernet port feeding the dorm room, or filtering of the computer in question. Recurring violations may result in further discipline. See http://www.cio.uiuc.edu/policies/copyright/act.html)
Systems: While true, this is neither recommended practice, nor is it anything new. The shared accounts that have been provided in the past were not created for staff use (despite their frequent misuse), but for situations where the number of students made management of individual accounts impractical. All staff have individual network access (Active Directory) and Voyager accounts with privileges according to their position, neither of which were ever authorized to be shared with others, including students. If a staff member logs in anywhere and then leaves the immediate area, then they are misusing their account.
Systems: Regardless of the administrative desirability of such auditability, it is not the purpose of this change. However, improved (admittedly imperfect) auditability is a side-effect benefit.
Systems: That's wonderful! Unfortunately, most of the circulation locations can not guarantee that.
Systems: [We’re assuming that your point was that Office, and file server access is not appropriate on circ workstations.] This is an interesting notion from one unit’s perspective. It's interesting because the staff and unit heads of many other units have expressed the exact opposite. Specifically, over the last 4-5 years, so many units have claimed the need for MS Office and access to G: and H: drives at circulation workstations that it became the standard configuration. Given the obvious security concerns, license costs, and additional complexity, Systems would be thrilled to revert to simple low-function circulation desk PCs. Due to demand by the Library, that’s no longer an option.
However, this statement, in combination with our earnest work toward mitigating legal and security exposure with the minimum feasible impact on efficiency has led us to a further refinement on the proposed configuration.
Systems: It will definitely prevent the high-turnover student workers from doing so. Timely deactivation of access for terminated staff and faculty employees will continue to depend on
Systems: Not if staff log off as directed, when they are no longer in control of the computer.
Systems: Not if staff log off as directed, when they are no longer in control of the computer. Most of the computers in the Library, including those that are routinely shared by multiple people, have required individual Active Directory logins for a long time. This sort of mistake is easily recovered from, but so rare that it is not a concern. It’s definitely not an argument in favor of not securing patron data.
Systems: Actually, we do understand the public service workflow concerns. We’re also working against the disregard and apathy for or ignorance of computer security that is prevalent among the Library’s employees. This is not “a waste of time,” as it will significantly decrease the Library’s liability for and likelihood of exposing private patron data.
We have "gone back to the drawing board on this" yet again, and we now have a multiple-option configuration that addresses virtually every concern about inefficiency real or imagined.
The following questions regard reference workstations, rather than circulation desks (except in Undergrad where they’ve mixed the two). Poor stewardship of patron data (via circulation clients) is at the heart of the concern, and our latest plan addresses that as well as the reference desk concerns.