Unicorn 7 user separation requires manual intervention in a network user environment

Since we are operating our Äkta Avant in a multiuser environment, we need to separate the methods and results of the different users. By default, every network user is at the moment able to see every method and every result that has been generated on the machine by any other network user. This is a considerable privancy and security issue as a malicious user could delete (or even worse: modify) methods and results.

Our Äkta is set up in a way that allows users to log into the Unicorn 7 computer with their university login/password via the regular Windows network authentication mechanism. However, if several people share the responsibility of a run, this setup becomes impossible as they would need to devulge their passwords to each other. Hence we have created a local account which can be used by users who wish to share the operation of the Äkta.

After logging into Winodws, users still have to log into the Unicorn 7 software, which users do with their university login and password ("Windows authentication"). Using this setup, every user is able to see all methods and results, which is not acceptable.

When setting up a new user with Unicorn version <6, one could set the User properties ("User>Access>Folders") and exactly which folders were accessible by that user and the user would see only his/her own methods and results. Since the folder structure under Unicorn 5 was a folder structure of the Windows file system, users could always copy methods and results from one folder to another and thereby make them available despite the limitations set by the Unicorn 5 program.

When I first read that Unicorn 7 supports Windows network authentication, I had hoped that we would be able to avoid the painful user setup which we had to go thru for each user on the Äkta Explorer. However, the pain continues as setting up the user privileges once for a group doesn't give us user isolation.

Firstly, one cannot restrict access of individual users in Unicorn 7, but only access of groups. We had to create one Access Group for each network user, add the network user to this group, create a separate home folder for the group and then restrict the folder access to this home folder. Hundreds of clicks were required for a handful of users since the default is no access to anything and every single privilege check box needs to be enabled except for the admin privileges.

In that respect, Windows (and every other OS) is way smarter than Unicorn. If a university employee logs into a machine that he or she has never been logging into before, it creates all the necessary default local folder structure automatically and mounts that users private home folder without granting access to everything other employees have been doing on that specific machine. I think that should be an option on Unicorn as well. Maybe it is and I just can't figure it out?

Another big drawback of the above described method of separating each user into an own access group is that login into the Unicorn program becomes a major ordeal: In addition to writing user name and password the user has to select the correct access group for the login to be successful. And even worse: In our setup we cannot avoid that every university employee belongs to two access groups: A manually created access group for each user for user separation and the "default" which works via the Windows network authentication - maybe Kerberos?). Hence, if users do choose the default access group (which is called "Users" in our case), they are able to log in, but they don't see their methods and results.

There are two reasons we cannot delete the "Users" access group: One is the mandate of the faculty and secondly (and we have tried), we cannot delete it anymore as many people have already created methods and generated results being in the access group "Users". Thus UNICORN prevents us from deleting this account. I am working on this problem: I should be able to access directly the underlying MS-SQL database in order to change the ownership of the methods and results. However, GE was not exactly forthcoming when I was asking about access right handling. The answer was:

The DB access credentials in a standalone UNICORN solution are encrypted and are not public. If you had an enterprise solution (hosting your own (SQL server) DB) you would have control of the credentials and in theory you could extract the wanted information (the format is something that you have to figure out by yourself and is not supported by us). You can upgrade your solution to an enterprise if you want.

This sounds worse than it is, because we have physical access to the MS-SQL server and pulling out the access credentials seems not very difficult. But it takes my time to find the exploit to "break into our own system" and that is what annoys me. However, according to Lisa Bromark from GE, the 7.0.2 update seems to correct this issue:

UNICORN can be configured to use a new database password. It is possible to generate an encrypted password or to enter an already encrypted password. This is done by running the UNICORN Service Tool after UNICORN installation.

However, it is unbelievably difficult to get the update (at least it seems to take weeks). Distribution is apparently still via optical media and snail mail. I think the last time I got myself software via a CD/DVD was more than 10 years ago. However, GE told me that they are just moving UNICORN software updates to "electronic distribution". Welcome to the 21 century!