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