We use a Juniper SSL vpn for our remote users that does the following: 1. Determines the client connecting in (PC, MAC, Linux, smartphone, iphone) 2. For the smartphones\iphones it checks policy for the user and if there in the approved group it allows them to access our internal apps via there client app only IF they have our security toolset (Junos) installed. Otherwise it boots them off. 3. For pc\macs, it checks for our internal certificate (along with their login in credentials) and if it has the proper cert, it passes them over to go through our network connect policy, which verifies that they are running one of our approved AV programs, that the defs are not more than 1 day old (if they are it tells the client virus program to update, and waits for up to 3 minutes to update and checks again), and that there firewall on the laptop is up and running. If that's all good, they get assigned network access based on their ad group info, and it works very well. If it does not have our cert (such as a home pc) direct network access is denied, and all that we allow is a proxied terminal server session that is run in a browser session (so no remote disks, or any direct connection from the client. Only the SSL vpn device talks to the connected RDP session). What lists of machines they can connect to via the proxied rpd is determined by group access in AD and shows as a bookmark on their web page.
This also works well for contractors as we can give them just the access they require and nothing more. If they need to upload files for example, they get a web browser with a upload link to the share that we defined. They can't go anywhere else. So it makes for a great Extranet setup. The great thing about this setup is the client piece. It's really easy on the end user. And being ssl it gets us past many of the old challenges using ipsec or PPTP, etc. Not the cheapest, but we'll worth it. Good luck! -Greg -----Original Message----- From: Phil Brutsche [mailto:[email protected]] Sent: Wednesday, December 08, 2010 6:18 PM To: NT System Admin Issues Subject: Re: Remote access - Allow employees work from home If you're talking about RDP (TS/RDS) or ICA (Citrix) bandwidth on the users' end is only an issue if they are on dial-up. Any kind of wired broadband connection is more than enough. Even a 256kbit line is fine. Home satellite might be an issue; the problem is more latency than bandwidth. On 12/8/2010 6:01 PM, Gary Whitten wrote: > I'm not sure of all the reasons involved, but logmein and GotoMyPC are > banned by our security group for use in connectivity. We use a VPN > solution from company laptops into the network. For other users, a > Citrix solution is used. > > Until a few minutes ago, I was keeping an eye on this thread just on general > interest. I've just been asked to provide a comprehensive list of what is > needed for people to work at home. While this thread has generally > concentrated on the actual solutions involved, which we generally have > set up, something I don't think that has come up with is the > requirements from the user's end. > > If it's a company laptop, we can generally control the specs of the machine > and the software and policies on it. If it's a home machine going to a > terminal server, Citrix farm, etc., it's less so but as a rule, most > machines sold in the last several years can handle that, unless the > user has turned it into sludge with their computing habits. Still, I > think a minimum CPU and RAM requirement may not be a bad idea. > > Another big variable is bandwidth and connectivity. I think it would > be prudent to not support wireless connections for several reasons, primarily > that supporting them is rather hellish should something go wrong. In terms > of providers, I'm most familiar with cable (Comcast). Do satellite > internet providers for the home give enough bandwidth pull this kind of thing > off? > I believe FiOS is definitely capable of the level of bandwidth needed. > Would you require a speed test with one of the sites out there that do > that, specifying a destination near your connection point, which > wouldn't necessarily be conclusive. > > What other considerations on this line of thought are there? > > Gary Whitten > > -----Original Message----- > From: Fergal O'Connell [mailto:[email protected]] > Sent: Wednesday, December 08, 2010 6:25 PM > To: NT System Admin Issues > Subject: RE: Remote access - Allow employees work from home > > Jim, > A user will pretty much RDP into their desktop and therefore have full > access to the full development environment - all other core services > that are not public lie OWA etc. > > Another option that is management and I have to consider is using a > 3rd party vendor to provide the solution for us - like logmein.com etc > > Win2008 R2 TS is something else that I have too look into but have > very little knowledge or experience in that area. > > > > > -----Original Message----- > From: Jim McAtee [mailto:[email protected]] > Sent: 08 December 2010 20:08 > To: NT System Admin Issues > Subject: Re: Remote access - Allow employees work from home > > How many of these suggestions are being given in the context of a > software development environment? What do the remote developers > actually need access to? In many cases it's only to code > repositories. Do they need RDP access to their desktops? What about > build systems? Can Citrix be used effectively in either case without > introducing a billion other headaches? > > > ----- Original Message ----- > From: "Fergal O'Connell" <[email protected]> > To: "NT System Admin Issues" <[email protected]> > Sent: Wednesday, December 08, 2010 10:51 AM > Subject: RE: Remote access - Allow employees work from home > > > That's the plan - > However I just wanted to bounce this off to see what other folks are > doing - > > I might go with the Citrix solution but I will need to get pricing to > see what the overall costs are. > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > > The information in this email is confidential and may be legally privileged. > It is intended solely for the addressee. Access to this email by > anyone else is unauthorized. If you are not the intended recipient, > any disclosure, copying, distribution or any action taken or omitted > to be taken in reliance on it, is prohibited and may be unlawful. If > you are not the intended addressee please contact the sender and dispose of > this e-mail. Thank you. > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin -- Phil Brutsche [email protected] ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
