Note: Questions and comments received via Bob Burger from AC are shown with the bullet points.
- I would like to add a request that we discuss the document that was made available to us on Monday at a future AC meeting. There are some policy and principles set forth in it that I think deserve further discussion and endorsement. I’m not necessarily disagreeing with the content of the document, but since it is presented on behalf of the faculty & staff of the Library, it will be good to have the open review of it. Thanks – Karen
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.
- Who will maintain the list of AD usernames that are tied to particular happening locations? (I.e. that a given student is a student worker in BEL?) How long will it take to activate such access after hiring? Who will be responsible for removing this access when a person leaves library employment and how long will that take?
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.
- How will logins to the client software be handled in UGL 291 and ACES 509 for training sessions?
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.
- Who will bear the cost for additional workstations needed at a public service desk or staff workrooms where more than one person currently share a workstation? Even at 20 seconds per login/logoff – it will be pretty annoying to do this 50-60 times per day or more in order to do call slip processing etc. So, each staff member will need their own terminal and a terminal per person at the desk.
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 isexactly 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.
- Is it possible for a student to have their AD access removed for a student discipline infraction (e.g. illegal downloading in the dorms) and thus end up not able to work? How will we handle this?
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. Seehttp://www.cio.uiuc.edu/policies/copyright/act.html)
- If a staff member logs in to a computer and then allows students to use it, the students would then potentially have more privileges in Voyager than we would intend them to have because they would have the staff member’s privileges and would also have access to g:/drive and h:/drive files (which is of course problematic for a variety of reasons but includes that there are documents etc. that students should not have access to – and currently do not). How would we deal with these issues of students having “excess” Voyager privileges and also prevent the students from accessing g:/drive and h:/drive files if we use the approach of a staff member logging in and then letting a student use the computer.
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.
- After discussing a usual scenario at the circ desk, the unit head that sent this to me continues by saying: The net result is that real, reliable traceability as to who is using the circ PCs at any precise moment in time in most public units is not going to happen with this plan. It’s absurd to think it would.
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.
- … Currently, I can guarantee with confidence that only authorized Library staff and ILL/DD staff are using my Library’s circ terminals during hours the Library is open. And that should be good enough.
Systems: That’s wonderful! Unfortunately, most of the circulation locations can not guarantee that.
- … Shared Circ workstations (in spite of the presence of MS Office) are not where staff are authorized to do private, confidential work.
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.
- Eliminating generic unit logons as a way to prevent former staff from accessing Voyager from somewhere else might work.
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
- … Trouble is that in making this change you will have staff using shared PCs logged on under some other staff’s name. That will allow access to network shares that should be confidential. That creates it’s own problems.
Systems: Not if staff log off as directed, when they are no longer in control of the computer.
- …This change will also create some periodic headaches trying to find a file one of the staff saved (by mistake) under their own My Documents instead of under one of the shared folders. LSO will have to be retrieving such “lost” files for us all the time when a staff member is on vacation or otherwise unavailable for several days and we need to recover a critical file that staff member was working on.
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.
- … Practically, I’m not too worried about this change – the units will deal with it and make it work — mostly by corrupting the intent. It’ll cause some pain, but not a lot. Mostly I object because it’s a waste of time, because it shows LSO doesn’t understand public service unit workflows, and because I think it’ll create more problems than it will really solve. they should go back to the drawing board on this.
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.
- Will Systems script access logs for other things that are needed to be tied to multiple AD names rather than just one user? E.g. Archiving IM and chat transcripts?
- Recommendations for Systems on how to handle the “hand-off” of a patron in chat/IM during a shift switch. If the one librarian logs off, we lose the patron. If the person stays logs on and just lets the next person take over the machine, it violates the whole principle.