8

I have a vendor stating that they won't support the Microsoft Server 2008 R2 Terminal Server they are installing unless all users login using the same username and password. They claim this is to make things easier for the endusers.

Server is standalone and runs both the application (EMR) and the backend databse (MySQL). Each of our offices will get one of these servers. My concerns are 1) security and 2) possible issues with all users using the same user account. Security is an issue as we fall under HIPAA and the DB and all stored documents, which contain PHI, are stored on the TS unencrpyted and without any ACLs limiting access from the generic user account. Vendor says that the DB requires a password to login, so this setup is secure.

I have always required users to have their own accounts when using an RDP, Citix, etc server or server farm, so I don't have any real world experience with a setup like this. Wondering what everyone thinks about this type of setup.

7
  • 12
    I think it is a disaster waiting to happen and you should run, not walk, away from that vendor.
    – Cry Havok
    Aug 19, 2011 at 14:59
  • 2
    Sounds like a bad design and bad guidance from the vendor.
    – joeqwerty
    Aug 19, 2011 at 15:03
  • 1
    Wait a second, am I thinking correctly that you can't have the same user logging into a terminal server, or it'll take over that session?
    – Nixphoe
    Aug 19, 2011 at 15:23
  • 6
    Shared usernames/passwords = zero accountability for any action done on the server. If someone trashes everything out of spite, how do you know who it was?
    – growse
    Aug 19, 2011 at 16:22
  • 2
    Would the users use separate credentials for the application? If not, that is definitely against HIPPA. HIPPA requires UAC, and that would be tough with a single login. The EMR software I use now and the EHR we're switching to are hosted on 2008 R2 with no problems.
    – gtaylor85
    Aug 19, 2011 at 21:03

3 Answers 3

12

If the files are stored at the filesystem level without user-based encryption and with no ACLs then yes, run away. If ALL data was stored within the database then I would feel slightly less hesitant but even still, any vendor that says it's ok (especially when HIPPA is in the mix) to use shared ID's is suspect in my book. If you join the machine to a domain then there is nothing confusing from the end user's standpoint about using their own individual ID. Rather, it would be more confusing for them to have the additional shared ID.

2
  • 1
    ...unless the database files are accessible to that shared user account, at which point the existence of any passwords controlling access to the database are effectively moot. Aug 19, 2011 at 19:37
  • Right. I made the assumption they wouldn't be accessible to the shared user, which is probably a gross mistake given the already poor design of this solution...
    – squillman
    Aug 19, 2011 at 19:47
7

Agreed, with profile sharing comes a whole host of issues - not the least of which is the inability to have good accountability (or even ANY accountability) for exactly who did exactly what and exactly when it happened. Find another vendor - one that adheres to basic security principals. Try to find someone with a SAS 70 type II certification if possible. I'll guarantee those organizations won't allow profile sharing. Thanks for asking before jumping into this one and regretting it later.

3

Concur. This is a disaster waiting to happen. If they are this lackadaisical with something you can see (requiring shared logins), what on earth are they doing that you can't see?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .