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
>>