bypassing two-factor authentication

Keith Graham schrieb:

We have a roadmap item to include 2FA at the broker, thus supporting 2FA in AppPortal in a future release.

Hi Keith,

in principal that's good news. however, wouldn't it be a better idea to include 2FA into the (rewrite of) web access, so that my connection broker isn't exposed to the internet?

so for example, the web access is in the dmz accepting connections from users who have authenticated directly in web access or from appportal via 2FA. also, all rdp (eop) connections are relayed first through web access server to the connection broker only after users have authenticated successully. so the only instance the connection broker is accepting rdp-connctions from is from web access and not directly from clients...!

P.S.: Can you give at least a rough estimate when 2FA will be implemented?

kind regards,

Tim

 as far as i could gather from this and other treads, the aim is to make the different apportals (windows, mac, ios etc.) 2FA-capable so that they do not have to go the route via logging-in to web access fiirst, but directly to the connection broker bypassing the web access completely. 

correct

in principal this is good idea to further simplify a secure connection to your corporate lan, but doesn't that somehow imply to expose your cb directly to the internet?

correct, you wouldn't use it like that. This is for use in on-network situations where 2FA is required *inside* the LAN, e.g. healthcare, legal, military, ...

therefore, i suggested to enhance web access (which is in the dmz anyway) to intercept the requests from 2FA-aware-appportals relaying it to the actual cb.
so a future (rewritten) web access (or, to be more precise, vworkspace web access role) could inlclude that capability instead of the actual cb...

That's what our Secure Gateway is for. You put it in the DMZ to relay between the client and the broker in the LAN. Again, that works today. The connectors all know how to talk direct with our Secure Gateway without going through Web Access.

 logging-in to web access fiirst (which isn't possible with the ipad-client at all?!),

We'll add Web Access support to the iPad Connector in the next few months.

Hi Tim. I think you misunderstood Keith's answer. Keith is saying that Web Access supports 2FA today, and you can restrict access so users can *only* go through Web Access.

You can already put Web Access in the DMZ and the broker in the LAN so the broker is not exposed to the Internet, as you described. All that works already.

The only thing we don't do yet is support 2FA direct from a Connector to the broker, but that isn't required in your case, since you shouldn't expose the broker to the Internet.

Hi Tim,

Just looking through this thread I haven't seen any mention of the Secure-IT/SSL Gateway component?

If you want to keep things secure that is the component that typically sits in the DMZ and looks after the termination of the SSL connection.

This is how the Connection Broker is kept behind the DMZ in the Corporate LAN while allowing what looks like direct access - I hope that helps? ;-)

Cheers,

Dave Caddick

Hi Jon,

thanks for your answer...

i'm well aware of the first part - this corresponds to our current setup.

however, as far as i could gather from this and other treads, the aim is to make the different apportals (windows, mac, ios etc.) 2FA-capable so that they do not have to go the route via logging-in to web access fiirst (which isn't possible with the ipad-client at all?!), but directly to the connection broker bypassing the web access completely.

in principal this is good idea to further simplify a secure connection to your corporate lan, but doesn't that somehow imply to expose your cb directly to the internet?

therefore, i suggested to enhance web access (which is in the dmz anyway) to intercept the requests from 2FA-aware-appportals relaying it to the actual cb.

so a future (rewritten) web access (or, to be more precise, vworkspace web access role) could inlclude that capability instead of the actual cb...

hope this brings my point across.

then again, i might have missed freeks point...;-)

kind regards.

Hi Keith,

"...It seems that you can secure your virtual desktops/published apps using a client assignment based upon device IP Addresses, where the scope is an allowable IP range and your Web Access server(s) are within that range. This will prevent users from using AppPortal to circumvent any 2FA that you put in place on Web Access..."

That would be a workable solution, I will give that a try in my test-lab. Thanks for the suggestion!

Kind regards,
Freek Berson
http://microsoftplatform.blogspot.com/

Hi Keith,

I've ran some tests on this.

When I create a IP-range with just the IP-address of my Win7 client in it and assign a managed application to it. The application only shows up when I open the AppPortal from that Win7 workstation. Even when I open up the webportal from that Win7 workstation the app does not show. So far so good.

But when I create a IP-range with just the IP-address of my WebAccess server in it and open up the webportal from my Win7 client, the application does not show up, nor does it show up when using the Appportal from the Win7 client.

I have also tried using the OU where the WebAccess Server resides and using the devicename of the WebAccess Server to assign the application. It does not show up.

Kind regards,
Freek Berson
http://microsoftplatform.blogspot.com/

Did you enable client identification, in WA admin - under Global Settings > Authentication?

Ah. I think you need to enable it to have WA filter based on the client-IP (for example).

No, that setting is disabled.

Hi Frank. Not sure why that isn't working, but I think the real solution here is to put the broker inside the LAN and deploy the Secure Gateway in the DMZ. That way you never expose the broker to the Internet.  Jon

We have been able to build a workarround for this using ISA server. The scenario in which we implemented this was based on RD WebAccess and RD Gateway but I think it's generic and can be used in a Quest environment as well.

more details here:http://microsoftplatform.blogspot.com/2011/05/force-use-of-rd-webaccess-block-direct.html

Kind regards,
Freek Berson
http://microsoftplatform.blogspot.com/

Thanks for posting this Frank. I finally found time to read it and this a great tip.

Jon