[THIN] Re: CAG AAC 4.2 fallback connection policies
- From: "Jeff Pitsch" <jepitsch@xxxxxxxxx>
- To: thin@xxxxxxxxxxxxx
- Date: Wed, 5 Apr 2006 18:22:35 -0400
But if something is causing the continuous filter to fail, wouldn't you want
to err on the side of caution and reauthenticate the user? Isn't the fact
that the watermark you have chosen has been compromised mean you may want to
be extra cautious? They would have access to minimal resources based upon
when they authenticate again. Does that make sense? To me, if a watermark
fails (in this case a continuous scan filter) i wouldn't trust that the
person who logged in is still the person at the console. Why did it fail?
I've always been burned by 'assuming' and in this case your assuming the
watermark failing is nothing to worry about.
As for you scenario of going from valid workstation to kiosk, that's what
the EPA's are for. I guess I'm confused as to why you wouldn't have a
failsafe access policy that ONLY gives the bare minimum if nothing can be
validated.
Again, if our continuous scan is failing why is it failing? Why are you
getting so many helpdesk calls? Is it possible your watermark is not the
best possible choice? As well, why not simply put an EPA on the policy if
that is what will make it work?
I'm not trying to be argumentative but really trying to understand the
reasoning and maybe, just possibly, maybe it will help you.
Jeff Pitsch
Microsoft MVP - Terminal Server
Forums not enough?
Get support from the experts at your business
http://jeffpitschconsulting.com
On 4/5/06, Pavlo Ignatusha <Pavlo.Ignatusha@xxxxxxxxxxxxx> wrote:
>
> See comments inline
>
>
>
> Thanks,
>
> Pavlo Ignatusha
> Systems Network Coordinator
> Pembroke Regional Hospital
> tel. +1 (613) 732-3675 ext.6150
> fax. +1 (613) 732-9986
> ------------------------------
>
> *From:* thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] *On
> Behalf Of *Jeff Pitsch
> *Sent:* April 5, 2006 12:01 PM
>
> *To:* thin@xxxxxxxxxxxxx
> *Subject:* [THIN] Re: CAG AAC 4.2 fallback connection policies
>
>
>
> That makes a little more sense. NavUI within a VPN connection. Logically
> it makes sense as well, if the scan fails, do you want them having access?
> (Yes,
> of course you do. Picture a user, working from a home access or an external
> site. They've installed all the proper protection and everything that we
> ask for (or, see it as a company system that we've setup and deployed to
> their home/satellite site) to access their applications, network shares and
> network resources. All of a sudden, they go to an internet café (or some
> other kiosk that is locked down), and they just want to jump on and check
> their email. We don't want the kiosk blindly having access to all sorts of
> resources that they shouldn't have access to, nor do we want them accessing
> these things if the system is not protected the way we want. So why would
> we just tell them too bad so sad? We wouldn't. We'd give them minimal
> access, ability to jump on, check their email, and get off, no hassle.) If
> they are a node on the network, why would you give them the external address
> for the AAC? (Well, what happens when the continuous scan that's setup
> fails? Then your VPN fails and your user is out of luck. We want them to
> still be able to hit the portal, and like we mentioned above, check their
> email or access MINIMAL company resources. This is not the route we are
> taking anymore though, as simply using the EPA scans to figure whether or
> not to bring up the VPN is our main tool, and continuous scans are not being
> used anymore.) Why give them NavUI if they are VPN'd in? (This question
> is throwing us for a loop. When you connect to the fqdn of the appliance,
> the VPN connection (if your user has the associated connection policy) turns
> on, and then your put through to the portal to access published apps, email,
> network shares, etc… Why would we make users login through the portal page,
> and then close that Window, open this and that, just to get what they can
> get from the portal? It's completely redundant and makes for n number of
> extra helpdesk calls that we wouldn't need to deal with if we keep it
> simple.) Is it for email and WI or are you doing more? (Email, published
> apps (WI), network shares, and selected users network resources) In other
> words, if they are already a node on the network, why do they need NavUI? (It
> gives the user a nice and easy central area to access all the published
> apps, email, and network shares.)
>
>
>
> Jeff Pitsch
> Microsoft MVP - Terminal Server
>
> Forums not enough?
> Get support from the experts at your business
> http://jeffpitschconsulting.com
>
>
>
>
>
> On 4/5/06, *Pavlo Ignatusha* <Pavlo.Ignatusha@xxxxxxxxxxxxx> wrote:
>
> Jeff,
>
>
>
> You are correct in saying "Even with a continuous scan filter on the
> Connection policy, it fails over just fine if the EPA is not met."
>
>
>
> We think the problem is that you are having the same trouble we had in
> recognizing the difference between continuous scans, EPA's, the different
> filters, access policies and connection policies. It is all about timelines
> when each thing happens during logon to AAC. We believe that when you log in
> this is what happens:
>
>
>
> 1. User opens browser and types URL on the appliance.
> 2. EPA scans are performed and logon page is displayed to user
> 3. User type in username and password.
> 4. IF Connection Policy associated to that user:
>
>
> 1. IF the VPN client is told to launch (selecting 'Launch Secure
> Access Client if access allowed').
>
> i.
> Continuous
> Scan begins
>
> ii. IF
> there are Continuous Scan Filters associated with that Connection Policy
> (these are different then normal Filters)
>
> 1. User passes Continuous Scan, NavUI page is displayed using
> http://acc_server_name and works as normal
>
> 2. User fails Continuous Scan, VPN fails, NavUI page tries to
> connect to http://acc_server_name STILL, but fails due to no VPN
> connection being made, so, you get a 404
>
> 1. IF the VPN client is NOT to launch
>
> i. NavUI
> acts as no VPN is up and works as if no connection policy is associated (if
> you actually create a connection policy like this, it will indeed inform you
> that your Connection Policy is useless and does nothing, but in fact, doing
> nothing is still doing something).
>
> ii. NavUI
> is displayed using https://appliance_fqdn and everything works.
>
> 1. IF there is no Connection Policy associated to that user
>
>
> 1. NavUI is displayed using https://appliance_fqdn and everything
> works.
>
>
>
> You can easily see that if you assign multiple connection policies with
> EPA scans to the user there is a fallback because EPAs happen before NavUI.
> If you have multiple connection policies with continuous scans they happen
> after the login when NavUI link in the browser is already pointed to
> http://aac_server_name. Sure in this case if your continuous scan fails,
> VPN fails and subsequently NavUI link to http://aac_server_name fails as
> well.
>
>
>
> How about we tell you what we did and what was the result of this?
>
>
>
> 1. Set up network resource and associated access policy granting
> access (don't bother with EPA scans like IE versions).
> 2. Create continuous scan for a registry entry (and filter).
> 3. Create connection policy to bring up VPN client. And include this
> filter as condition.
> 4. Create second connection policy that brings up the VPN client but
> do not include the filter.
> 5. Make connection policy with filter (created in step 3) higher
> priority.
> 6. Add your test user to access and both connection policies. Add
> this user to other policies for accessing the AAC NavUI.
> 7. Connect from PC with registry entry. Watch NavUI and VPN working
> well. NavUI will be connected using
> http://AAC_server_name<http://aac_server_name/>
> ...
> 8. Being connected, delete the registry entry and watch being denied
> from both VPN and portal. Close the browser.
> 9. Now try to connect back using same PC without registry entry.
> Connection policy with continuous registry scan filter will be processed
> first (as it has higher priority). Since the watermark is not there this
> connection policy will fail and the next connection policy (without
> continuous registry scan) will not be processed. This will essentially
> leave
> user without both VPN and NavUI (as the portal doesn't know that the VPN
> failed, so it's acting as if you have that network resource).
>
>
>
> The conclusion we made after extensive testing is that to guarantee users
> with VPN privilege at least minimal NavUI access in case they came from
> non-trusted device we needed to set up the very basic connection policy that
> just brings up VPN client, abandon using any continuous scans (to make sure
> users will not fail this policy under ANY circumstances) and manage access
> to network resources through access policies with EPA scans.
>
>
>
> Thanks,
>
> Pavlo Ignatusha/Curtis Brunet
> Pembroke Regional Hospital
> tel. +1 (613) 732-3675 ext.6150
> fax. +1 (613) 732-9986
> ------------------------------
>
> *From:* thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] *On
> Behalf Of *Jeff Pitsch
> *Sent:* April 4, 2006 1:29 PM
>
>
> *To:* thin@xxxxxxxxxxxxx
> *Subject:* [THIN] Re: CAG AAC 4.2 fallback connection policies
>
>
>
> I'm not seeing the problem. Even with a continuous scan filter on the
> Connection policy, it fails over just fine if the EPA is not met.
>
>
>
> Jeff Pitsch
> Microsoft MVP - Terminal Server
>
> Forums not enough?
> Get support from the experts at your business
> http://jeffpitschconsulting.com
>
>
>
>
>
> On 4/3/06, *Jeff Pitsch* < jepitsch@xxxxxxxxx> wrote:
>
> Got it. I'll definately be testing this out. That's definately going in
> next weeks presentation ;)
>
>
>
> Jeff
>
>
>
> On 4/3/06, *Pavlo Ignatusha* < Pavlo.Ignatusha@xxxxxxxxxxxxx > wrote:
>
> Jeff,
>
>
>
> I think I know what's happening.
>
>
>
> You have a connection policy that does NO continuous scans. You are using
> connection policy only to invoke the VPN client. This is why in your
> scenario your user never failed the connection policy simply because you are
> not checking for anything in the connection policy. All your checks are EPA
> checks in the access policies. There you can Allow or Deny access to the
> network resources.
>
> Thanks,
>
> Pavlo Ignatusha
> Systems Network Coordinator
> Pembroke Regional Hospital
> tel. +1 (613) 732-3675 ext.6150
> fax. +1 (613) 732-9986
> ------------------------------
>
> *From:* thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] *On
> Behalf Of *Jeff Pitsch
> *Sent:* April 3, 2006 11:29 AM
>
>
> *To:* thin@xxxxxxxxxxxxx
> *Subject:* [THIN] Re: CAG AAC 4.2 fallback connection policies
>
>
>
> I'm still confused on that because I've had that situation working or my
> understanding of what your saying. Maybe we are doing it differently. I
> have a connection and access policy that gives users access to VPN if they
> are able. i also have a another access policy that is the exact opposite of
> the above (using the NOT operator) and that gives them the NavUI if they are
> not eligible for full VPN. Is that what your talking about?
>
>
>
> Jeff
>
>
>
> On 4/3/06, *Pavlo Ignatusha* < Pavlo.Ignatusha@xxxxxxxxxxxxx> wrote:
>
> Jeff,
>
>
>
> IE checks are the EPA scans not the continuous scans and you use them in
> access policies. If you don't assign any continuous scans in the connection
> policies users are fine.
>
>
>
> Let's say you have a user that has connection policy applied with filter
> containing a continuous scan that checks for a registry entry (your
> watermark). If user connects from a PC with watermark, VPN client comes up,
> checks the watermark and user is into the NavUI (note that NavUI url in this
> case in http://aac_server....). If user connects from PC without the
> watermark VPN client comes up checks for the watermark, fails the connection
> policy and NavUI is not coming up at all (mostly because IE is trying to
> connect to http://aac_server... Address and not https://appliance_fqdn...
> ).
>
>
>
> Citrix promised to get us a workaround that in the scenario above user
> will still get NavUI.
>
> Thanks,
>
> Pavlo Ignatusha
> Systems Network Coordinator
> Pembroke Regional Hospital
> tel. +1 (613) 732-3675 ext.6150
> fax. +1 (613) 732-9986
> ------------------------------
>
> *From:* thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] *On
> Behalf Of *Jeff Pitsch
> *Sent:* April 3, 2006 10:33 AM
>
>
> *To:* thin@xxxxxxxxxxxxx
> *Subject:* [THIN] Re: CAG AAC 4.2 fallback connection policies
>
>
>
> #2 I'm confused on. I can get a user to a portal if they do not fall into
> the connection policy. for example, they need IE version 6 but connect with
> IE version 5.5, they will get portal page (portal as in NavUI) instead of
> VPN. Are we talking about the same thing?
>
>
>
> Jeff
>
>
>
> On 4/3/06, *Pavlo Ignatusha* < Pavlo.Ignatusha@xxxxxxxxxxxxx> wrote:
>
> Hi group,
>
>
>
> Just wanted to finalize this thread with information I obtained from
> latest conference call with Citrix support. I will go by each question we
> asked earlier.
>
>
>
> 1. Citrix confirmed that connection policies were not cumulative. If
> a user has 2 connection policies assigned (ex. With different endpoint
> scans) only the policy with highest priority is processed.
> 2. Citrix promised a workaround so user can get portal when
> connection policy fails. I'll keep you posted.
> 3. Continuous scans are coming from Net6 appliance and EPA scans are
> coming with Citrix MSAM. That is why you need VPN client up to do
> continuous
> scans (thanks Carl).
> 4. Citrix will only continue to support a few major AV vendors in
> their EPA scans. The rest is given away as an opportunity for partners like
> www.epafactory.com. These scans from partners are not cheap though.
> Or you can use SDK from Citrix at your own risk.
>
>
>
> Long story short AAC turned out to be an uncompleted marriage of Net6
> appliance and Citrix MSAM. Citrix rushed it to the market without a lot of
> testing. Along the way we encountered some other interesting confirmed bug
> when AAC portal login is case sensitive for home directory share access. We
> are waiting for a hotfix for that as well. That's all the story for now.
>
>
>
> Thanks,
>
> Pavlo Ignatusha
> Systems Network Coordinator
> Pembroke Regional Hospital
> tel. +1 (613) 732-3675 ext.6150
> fax. +1 (613) 732-9986
> ------------------------------
>
> *From:* thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] *On
> Behalf Of *Jeff Pitsch
> *Sent:* March 21, 2006 1:15 PM
> *To:* thin@xxxxxxxxxxxxx
> *Subject:* [THIN] Re: CAG AAC 4.2 fallback connection policies
>
>
>
> 1) not sure on this as still investigating but I'm guessing your using
> either policies or endpoint analysis wrong when setting up.
>
>
>
> 2) It's a vpn connection meaning your now local to the protected
> network. if it was going to the CAG you'd be going outside of that. I
> would think it's working the way it should.
>
>
>
> 3) Dunno, have to ask Citrix which I will do tonight since I'm chatting
> with them on AAC.
>
>
>
> 4) download the SDK and good luck. I've heard it's not easy. This
> link:
> http://support.citrix.com/forums/thread.jspa?forumID=101&threadID=73893&tstart=0
> has other links in it you may be interested in.
>
>
>
> Jeff
>
>
>
> On 3/21/06, *Pavlo Ignatusha* < Pavlo.Ignatusha@xxxxxxxxxxxxx> wrote:
>
> Hi group,
>
> Lately we were working on CAG with AAC policies. Along the way we
> encountered a few difficulties and we thought we'd ask for your input.
>
> Environment: CAG with AAC option v4.2 (no hotfix AAC420W001). PS4
> 3-server farm. Windows Server 2003 SP1 AD.
>
> We would like to use some endpoint analysis and continuous scans in our
> AAC policies. We also would like to configure a fallback type of access
> so if the client device does not pass the requirements they still get
> AAC portal with minimum of "Preview" access. Here is what we found:
>
> Continuous scans seem to only work with Citrix Secure Access client
> (VPN). In other words if you want to use continuous scan, the user must
> fall under the requirements for a connection policy that launches the
> client. You can have multiple connection policies, but it will only
> look at the policy with the highest priority. Once that either fails or
> passes, it will react accordingly. So, if you have one connection
> policy that would say to launch the VPN client under restrictive
> conditions (they have a certain antivirus running and a watermark in the
> registry), and a connection policy with a lower priority that says not
> to launch it under a less restrictive condition (such as that antivirus
> is not installed, or that the watermark is not present), once the first
> one passes or fails, it simply reacts to that policy rather then going
> to next policy if the previous policy failed.
>
> Now, when that initial policy that tries to connect to the VPN fails due
> to the non-restrictive conditions, no VPN connection is made. This
> would be satisfactory if the portal didn't react a certain way with a
> VPN connection. Basically what happens is that when the Secure Access
> client is launched, the portal automatically tries to redirect its
> connection to:
>
> https://aac_server_fqdn/citrixlogonpoint/logonpoint_name
>
> And not the usual
>
> https://appliance_fqdn/citrixlogonpoint/logonpoint_name
>
> And that's not a problem if the VPN connection is established, but when
> it fails, you suddenly don't have this network resource, and hence,
> can't hit the portal anymore. This is also true if a continuous scan
> detects an error after a VPN connection is established.
>
> (Just an aside: When the VPN does make a connection and the user doesn't
> have any network resources assigned through access policies, they have a
> default resource of the AAC server. That way, when a VPN client is
> connected, the users can then hit the AAC server fine, we're just not
> sure WHY this happens this way.)
>
> Using access policies and Endpoint Analysis scans it seems possible to
> give different levels of access depending on the conditions that are
> present on the client device (antivirus running, certain browser,
> etc...). It is not too straightforward either as we had to create 1
> filter for the condition of antivirus, and 1 filter with NOT antivirus
> (using the 'not' operator in the filter). Then we created 2 access
> policies, one with each of the filters, so that when a user has an
> antivirus present (that is based on our endpoint analysis), they receive
> certain capabilities, and if they don't have it present, they receive
> restricted capabilities.
>
> So we have some questions...
>
> 1- How to configure fallback between connection policies?
>
> So far we think that the server looks at the highest priority connection
> policy, and then reacts accordingly without looking at any other
> connection policy that is associated with that specified user. This way
> it is completely useless to have a connection policy priority list and
> also to have different connection policies applying to the same user
> when they come from different devices (such as a less secure
> environment).
>
>
> 2- Why does the portal try to connect to the FQDN of the AAC rather then
> the FQDN of the appliance if the Citrix Secure Access client is engaged
> (whether it be a successful connection or not, see previous question)?
>
> Frankly, if this did not happen, then we really wouldn't be too worried
> about a fallback connection policy when the initial connection policy
> fails, as the user would still be able to access the portal as normal,
> just not any network resources. This is exactly what we would setup as a
> fallback connection policy anyways.
>
>
> 3- Why can't we also use continuous scans on access policies?
>
> Is this simply because it needs a VPN connection to the user to
> continuously check for these things?
>
>
> 4- How do we create custom endpoint analysis scans?
>
> Ideally, if we can't get the continuous scan and fallback connection
> policy stuff figured out, then we'd still like to check for registry
> watermarks. This ability (registry checking) only seems to be in the
> continuous scan, although, in the endpoint analysis, there is a section
> for custom endpoint analyses. The problem with that is, is it's looking
> for a *.cab file, which I have absolutely no idea how to create.
>
> Thanks,
>
> Pavlo Ignatusha & Curtis Brunet,
> Pembroke Regional Hospital
> tel. +1 (613) 732-3675 ext.6150
> fax. +1 (613) 732-9986
>
>
> --
> The information in this email belongs to the Pembroke Regional Hospital
> and may contain confidential and privileged information for the sole use
> of the individual or organization to which it is addressed. If you are
> not the intended recipient, you are hereby notified that any disclosure,
> copying or distribution of the contents of this email is prohibited.
> If you have received this email in error, please contact the sender and
> destroy all copies of the original message.
>
> ************************************************
> For Archives, RSS, to Unsubscribe, Subscribe or
> set Digest or Vacation mode use the below link:
> //www.freelists.org/list/thin
> ************************************************
>
>
>
> --
> The information in this email belongs to the Pembroke Regional Hospital
> and may contain confidential and privileged information for the sole use
> of the individual or organization to which it is addressed. If you are
> not the intended recipient, you are hereby notified that any disclosure,
> copying or distribution of the contents of this email is prohibited.
> If you have received this email in error, please contact the sender and
> destroy all copies of the original message.
>
>
>
> --
>
>
> The information in this email belongs to the Pembroke Regional Hospital
> and may contain confidential and privileged information for the sole use
> of the individual or organization to which it is addressed. If you are
> not the intended recipient, you are hereby notified that any disclosure,
> copying or distribution of the contents of this email is prohibited.
> If you have received this email in error, please contact the sender and
> destroy all copies of the original message.
>
>
>
> --
>
>
> The information in this email belongs to the Pembroke Regional Hospital
> and may contain confidential and privileged information for the sole use
> of the individual or organization to which it is addressed. If you are
> not the intended recipient, you are hereby notified that any disclosure,
> copying or distribution of the contents of this email is prohibited.
> If you have received this email in error, please contact the sender and
> destroy all copies of the original message.
>
>
>
>
>
> --
>
>
> The information in this email belongs to the Pembroke Regional Hospital
> and may contain confidential and privileged information for the sole use
> of the individual or organization to which it is addressed. If you are
> not the intended recipient, you are hereby notified that any disclosure,
> copying or distribution of the contents of this email is prohibited.
> If you have received this email in error, please contact the sender and
> destroy all copies of the original message.
>
>
>
> --
>
> The information in this email belongs to the Pembroke Regional Hospital
> and may contain confidential and privileged information for the sole use
> of the individual or organization to which it is addressed. If you are
> not the intended recipient, you are hereby notified that any disclosure,
> copying or distribution of the contents of this email is prohibited.
> If you have received this email in error, please contact the sender and
> destroy all copies of the original message.
>
>
Other related posts:
