Here you go: http://support.citrix.com/article/CTX107497 On http://support.citrix.com <http://support.citrix.com/> , click the Tools like on the left. It's on the bottom of the page. _____ From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Pavlo Ignatusha Sent: Wednesday, March 22, 2006 8:29 AM To: thin@xxxxxxxxxxxxx Subject: [THIN] Re: CAG AAC 4.2 fallback connection policies Carl, Just the info we wanted to hear. Yes, being new to the whole AG and AAC we did not know the history of these product lines. We haven't seen the EPA scan for the watermark. Any chances you posting the link? 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 Carl Stalhood Sent: March 21, 2006 5:54 PM To: thin@xxxxxxxxxxxxx Subject: [THIN] Re: CAG AAC 4.2 fallback connection policies 1. I don't think the connection policies are cumulative like the access policies so only one would apply. 2. The default is to go to the FQDN of the AG which proxies to AAC which proxies to other websites. If you connect using the VPN, this proxy hop is no longer necessary since you should have direct access to the AAC server and other websites through the VPN. If you create a web resource and check the box to "bypass proxy" then direct connectivity to the website is required through the VPN client. 3. Keep in mind that AAC and AG used to be two completely separate products. The Access Policies were originally included with AAC. The Continuous Scan Policies were on the AG only (not AAC). And since the only thing the AG did was initiate a VPN connection, the Continuous Scan Policies only apply when connected using the VPN. Essentially what they did is take the old AG administration and plug it into the AAC console and called it "integrated". If you consider AG and AAC as two separate products with one integrated console then it makes more sense. I can't think of how the continuous scan policies could be applied without the VPN connection since there is nothing running on the client to continually check for these conditions. It would be nice if they created some generic EPA scans that allow you to specify reg keys, files, and processes to check for at logon but these would not be checked continuously. There is a custom EPA from Citrix that does watermark checking by looking for a registry key so one of these is available now. _____ From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Pavlo Ignatusha Sent: Tuesday, March 21, 2006 4:02 PM To: thin@xxxxxxxxxxxxx Subject: [THIN] Re: CAG AAC 4.2 fallback connection policies 1) I don't see how else we can set it up. Would be nice to see somebody else testing this and posting a reply. 2) I can agree to that but we are still facing a problem that if connection policy fails user can not access AAC portal. Since I do not technically need any connection policy to access AAC portal (just access policy) then why am I prevented from accessing it if connection policy fails? Jeff, would you mind discussing these issues with citrix folks at your meeting? I really appreciate your help 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 <http://support.citrix.com/forums/thread.jspa?forumID=101&threadID=73893&tst art=0> &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.