|
Last post on this here. So I work for a hospital primarily and then also do "IT Work" for a small clinic near the hospital off hours. "IT Work" meaning making sure their servers are updated and replaced, keeping their network up to date and somewhat secure, etc. However I've got a request now that is out of my wheelhouse and I want to make sure I'm doing it correctly, if it can even be done. The request is one of our scheduling teams wants access to the clinic's Allscripts systems to check on referrals and whatnot. The allscripts instance is hosted in-house and there's no direct external connection to the server or clients. The clinic is behind a Fortinet FGT-60F. The client they're looking for is housed on a windows virtual desktop via a link. What the physicians currently do to access this remotely is to log into the VPN, RDP to the VM desktop via IP, and open the client that way. I spoke to my NetSec super, and he suggested for our needs to have an SSL connection that they can open via a link on one of our desktop pools that would connect and open the client automatically. I've dug around in the firewall and see the settings, but I want to ensure that when they connect, they get to the specific desktop and not another one. It also looks like we'll need a certificate, of which we don't have, so I'm not sure if a self-signed certificate will work for this or if we're going to have to buy a trusted Cert and install. I'm probably missing vital information to get this to work correctly, help would be greatly appreciated. At this point I'm probably going to have to hire out to get this set up at least somewhat properly.
|
#
¿
Mar 28, 2024 13:49
|
|
|
|
| # ¿ May 6, 2024 02:43 |
|
|
Pile Of Garbage posted:Could you elaborate on the bolded section? I'm not entirely sure what is being suggested there. This is definitely out of my scope of experience, and I'm pretty sure what he's wanting isn't going to be (easily and/or cheaply) possible. Hospital has a pretty robust system in place with firewalls and security. I do not have access to the networking side as that is not my job and we're pretty heavily silo'd. We use VMWare (instead of Citrix), which is where access is going to originate. Creating a VPN (IPSec) is impractical and quite frankly gives too much access. Clinic is a much smaller clinic where we have a physical server for the Allscripts database. This clinic has never had a properly set up network, and just now I was able to get them on completely updated networking equipment. The way the inhouse people access the software now is primarily though a RDS setup (finally got them to upgrade from terminal services after their previous server died). There are a few fat client scattered around, but those are because of card readers and whatnot, and nobody wanted to deal with making them use the desktop pool. This clinic doesn't want to spend a lot of money because they just dropped a ton of money in the past two years on IT (which lol -- I told them that server was gonna crap itself) two years ago, and this year they dropped a ton of money on a new phone system for their 25 year old phone system (that lol the phone system operator told them they wouldn't be able to fix it if it failed). The clinic manager is terrible about putting things off until they're broke, and while I do get some leeway, they still balk when it comes to spending money to prevent issues. The request is that a group of people want access to a read-only view of Allscripts from hospital to clinic. Parts of this are kind of in place (the desktop pool, etc), but there is no other access other than a VPN connection (again, IPSec tunnel CURRENTLY only for physicians, Clinic manager and myself), RDP to the desktop and access the client. The NetSec manager is the one that mentioned the SSL VPN tunnel (probably so he doesn't have to do poo poo on his side), which is where we're at. My networking knowledge is pretty firmly in the basic camp, and much of this is still a mystery and well out of my wheelhouse. I just want to make sure I'm not missing something that someone who does this every day would find obvious that I wouldn't see at all. The other two clinics (who are much larger than the one I'm doing work for) have web-based access to their server, and I'm not sure if our Allscripts server can handle that as well (which WOULD simplify things, but I doubt it as it's something that probably needs to be paid for).
|
|
#
¿
Mar 28, 2024 17:35
|
|
|
Pile Of Garbage posted:That sounds like permission delegation within the Allscripts application itself which is dependent on the configured identity provider and RBAC architecture, none of which can be interrogated or altered by a FGT-60F (At least not in any way that would be secure). Correct, and Allscripts has it's own userbase outside of LDAP (Namely because LDAP didn't really exist outside of shared logins before I got there). So we'd have to A> get tunneled to the system, so they could B> log into Allscripts. quote:Network access for SSL-VPN users can be controlled in a granular fashion with user groups on a FortiGate but that only really covers you for Layer 3/4/7 network connectivity (e.g. users in "Group-A" can only connect to "RDS-Host-A", users in "Group-B" can only connect to "RDS-Host-B"). There's no mechanism where the FortiGate can inform an application of the connecting user's role-assignment or permission delegation, that has to be handled entirely within the application itself (And for something like this that is where it should be controlled). This would actually be functional and fit with what we're doing. All external access from x IPs would only be able to access x internal IP. "Group A" would be these users. "Group B" would still have the IPSec tunnel for full access. I guess the next question is where my ignorance really shows. What would be the medium for the tunnel itself? I know for our IPSec tunnels, we have to install the Fortinet VPN Client (not the full client since we don't use any of the other features), the hospital uses Cisco AnyConnect, which has to be activated and logged in to for RDP, etc to work. It's not an active site to site vpn or anything like that. The request would basically be the ability to click a desktop icon on the hospital side that would open the vpn, which would bring up the remote desktop, which would allow them to complete the request.
|
|
#
¿
Mar 28, 2024 19:12
|
|
|
Aware posted:This runs in a browser, so you still need a the FortiVPN client to connect via the Fortigate (IPSEC/SSL mode doesn't really matter much), and then fire wall down access to only the Guacamole web interface. This is the ultimate issue I believe that all of this is currently boiling down to: There's not an easy way bypass the need for the FortiVPN client.
|
|
#
¿
Mar 29, 2024 04:43
|
|