[THIN] Re: CAG AAC 4.2 fallback connection policies
- From: "Jeff Pitsch" <jepitsch@xxxxxxxxx>
- To: thin@xxxxxxxxxxxxx
- Date: Mon, 3 Apr 2006 13:33:43 -0400
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.
>
>
Other related posts:
