 |
 |
Thanks for the suggestions, but our access permissions (for everything) are already all "grouped up" already, so we are all set there. I also already rejigger the permissions for the Addons directory (which is safer than for the entire ILLiad folder) at the end of the ILLIad install using: C:\Windows\System32\icacls.exe "C:\Program Files (x86)\ILLiad\Addons" /grant "<SecurityGroupName>":(OI)(CI)M Erich On Thursday, December 14, 2023 at 13:17, Augusto Consing eloquently inscribed: > Erich, > > If your ILLiad implementation is hosted by your university, you could > implement Kaleb's suggestion by making the Windows shortcut point to a > location on the ILLiad server itself. Your generic ILL Windows login has > permissions to access file locations on your ILLiad server (this is > necessary for the ILLiad client and server applications to work), so to > duplicate this you could assign your ILL workers' Windows accounts to > the same Windows user group as your generic account. In this scenario > you would need to make sure that your ILL workers' Windows accounts have > full control (administrative rights) on the C:\Program Files > (x86)\ILLiad folder on their workstations, so that your ILLiad addons > will work. > > Best, > > Gus > > On Thu, Dec 14, 2023 at 11:21 AM Sove67 <[log in to unmask]> wrote: > >> Hi Elrich, >> >> Can't say I have any wisdom on securing shared workstations, but that >> might not be the path of least resistance here? >> >> If the ONLY issue with seperate accounts is saving in a specified location, >> there are a two ways I can think of to automate that. >> >> The easy: Create a shortcut to the correct saving location inside the >> default saving location. Users will need to double click each time the save >> system kicks them back to the default (which sounds like once-per-session) >> >> The advanced: Create a symlink ( >> >> https://www.howtogeek.com/16226/complete-guide-to-symbolic-links- >> symlinks-on-windows-or-linux/ ) for each user, between the default >> prompted save location, and the desired save location. This way, any >> files placed in either place should show up in both places. Think of it >> like knocking down a wall between two storage rooms. >> >> Of course, if there are other reasons your library needs this generic >> login, this won't address them. >> >> Best of luck with your setup! >> - Kaleb A (Langara LIT Student) >> >> On Thu., Dec. 14, 2023, 6:36 a.m. Hammer, Erich F, <[log in to unmask]> >> wrote: >> >>> All, >>> >>> First, I apologize because this is much more of an IT question than a >>> coding question, but I come from an IT/desktop support background with >>> a particular interest in security. >>> >>> How are larger, academic libraries securing your employee-used, shared >>> workstations -- specifically, the circulation desk machines and the >>> back-end, ILL scanning stations? I have been trying mightily for a >>> few years to eliminate the shared-password generic accounts because >>> they present a real security/privacy concern. I am running into some >>> real road-blocks though, and I'm wondering if anyone here has found >>> solutions that work. >>> >>> Having viewed the chaotic state of the circulation desk with the >>> constant churn of employees using the stations, I have conceded that >>> it is better to use a generic login than to have folks log in/out >>> constantly. >>> >>> The ILL employees who do a lot of scanning don't have the rapid-fire >>> turnover at their workstations, but they (or their manager) is >>> insisting on a generic login because the scans need to be saved in a >>> specific, network location and Acrobat has no mechanism to set the >>> default save location for all users. (I hate Adobe!) When we have >>> tried using personal logins, folks forget, don't notice, or don't know >>> about watching that the PDFs are saved in the proper location, and >>> those scans have to be redone by someone else or are inaccessible >>> within the particular employee's private user profile until they >>> return to work (which could be days-weeks with student employees). >>> >>> In both cases, users still need to sign into services as themselves >>> (the LSP -- Alma --, scheduling, wiki documentation, ILLiad, etc.), so >>> I'm not really sure what the security advantages are with the generic >>> account (especially for ILL scanning). I've had to push settings to >>> prevent the browsers (Edge, Chrome and FireFox) from saving passwords. >>> I also have automated scripts running to regularly blow away the MS >>> Teams configuration to prevent users from using it as someone else. >>> (Teams "helpfully" remembers credentials for one-click login even >>> after logging out of it and rebooting.) I have not been able to find >>> a way to do the same with MS Office, so I have been forced to >>> uninstall it completely. Otherwise, everyone who uses it while logged >>> onto the computer with the generic account is signed into/owns all the >>> M365 documents as the user who first used it (and had to sign into >>> M365). >>> >>> The lack of Microsoft Office is the particular issue that I'm being >>> pressed on to prompt me to post this. I should add that I can't use >>> device licenses for M365 (where login/registration isn't required) >>> because they only work with Azure Active Directory which we do not >>> have. What are you all doing? I've been considering trying to set >>> circ desk systems up as mulit-app, auto-login kiosks so at least we >>> don't need to share the generic password, but the other problems still >>> remain. >>> >>> Any feedback is appreciated. >>> >>> Thanks, >>> Erich >>> >>> >>> >>> -- >>> Erich Hammer Head of Library Systems >>> [log in to unmask] University Libraries >>> 518-442-3891 University @ Albany >>> >>> "Faith is the unflagging determination to remain ignorant >>> in the face of any and all evidence that you're ignorant." >>> -- Shaun Mason >>