[THIN] Re: CAG AAC 4.2 fallback connection policies

  • From: "Jeff Pitsch" <jepitsch@xxxxxxxxx>
  • To: thin@xxxxxxxxxxxxx
  • Date: Tue, 21 Mar 2006 13:14:49 -0500

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
> ************************************************
>

Other related posts: