Hey guys,


I am having a bit of a problem setting up a bedside terminal environment. Let me tell you what my setup is :

I have a Debian-based bedside terminal, kind of like a kiosk PC where a specially designed GUI runs on X, that patients in a hospital use to watch TV, call, dim the lights,...
When an MD comes he can swipe his RFID card and the system automatically (perl script!) executes an rdesktop command to a Windows server where the medical applications run.

As of now we stored the login and password in a textfile on the bedside terminal but the idea is to use AD (or another users directory?) to authenticate the MDs. Problem is that I can't just extract the passwords from AD and use them in the rdesktop command, which is normal ofcourse.


I'm open for any ideas, this project is not yet in production so I can change most of the architecture (except for the medical app server, has to be Windows).


Thanks in advance,

Eric

Eric

Let's see ... how do I explain the problem without sounding like a stick in the mud.... If I understand you correctly ... of course.

There are several issues at hand here regarding what you want to do. Medical systems use secured Radius Servers for large Intranets. All of the computers that log on to these intranets; set up user permissions so that whom ever logs on only has access to information based on a need to know , or need to access basis.
Doctor-patient confidentiality needs to be maintained on these systems so that this trust isn't lost.
The fact that the Doctors are using card swipes is part of that security system; and the digital ID is sent to the radius server then to the server holding the passwords card coding, [The Active Directory - AD - server]. This allows the terminal at your locale to be unlocked.
If you are adding another PC to another room at your locale for this purpose, you need to contact the administrator in your IMIT department and have that PC added to the radius servers list for that Intranet leg.

It's not a matter of getting passwords off of a list. Passwords and such are hashed and are not kept on any of the client PC's on any properly set-up Intranet.

As for what I think your issue is, you would need to contact your IMIT department and explain the situation to them and have them set it up. But as I said before, access would be on a need to access basis. IMIT could then set up each user with new or same access rights to patient medical files. Generally these rights are granted to the facility medical administrators and the RN's and Doctors . My advice, go talk to the powers that be and let the query climb the ladder in a normal fashion. meaning cover your ass. Don't go trying to do something that can get you into a legal loophole or worse. ok

And... of course if you know all this and I haven't hit upon what you meant, then try rephrasing the problem
and repost it.

thx

L-R

Hi lab-rat,


First of all, thank you for your interest in my problem.


I forgot to specifiy how our RFID cards are managed because this is quite relevant to the situation.
We don't use RADIUS to authenticate but Evidian ESSO. It's basically an SSO application that extends
the AD and adds more functionality (eg. RFID cards management). Normally we install the controller
next to the AD and on Windows hosts we deploy the ESSO Agent but unfortunately there is no agent
for Linux available.

Also, I don't have an IMIT department I can go to, as me and my colleague are the only ones here
in our (IT) company working on this project. IMIT = yours truly :-)
I don't work for a hospital/medical company but we are trying to make this project fit the needs
of them.


Best regards,
Eric

Anyone else has any ideas?

//Shameless self bump

You could use Samba with Kerberos and LDAP to allow authentication against the AD system. The LDAP would take the place of having password files on each system and Kerberos would provide the trust relationship to authenticate the machines with the AD server. Samba, of course brings Windows networking capability to Linux allowing your Linux machines to communicate with your AD Domain Controller.