JasonSamuel.com

I’ve covered Access Gateway quite a bit in the past and these two articles on my blog are a good primer for what I’m about to cover:

1. How to setup your Citrix Netscaler (Access Gateway) and Web Interface for iPads and mobile devices that use Citrix Receiver

2. Quick way to brand Access Gateway and Web Interface 5.4 with company logo and colors

Now let’s throw a new scenario into the mix. You want to allow users from another domain access to resources through your Access Gateway and Web Interface. Here is what you need to do to accomplish this.

SETTING UP A DROPDOWN BOX TO PASS THE DOMAIN
On your Access Gateway, if you followed my “branding guide” article above you will have noticed on the themes available from the Citrix blogs there are 2 versions, one normal and one with a dropdown. If you chose Horizon to customize like I did, make sure to download Horizon2.gz which has the code for the dropdown already in it. You just need to add your domains in the code. This is found in these two files:

\Horizon2\ns_gui\vpn\index.html

\Horizon2\ns_gui\vpn\tmindex.html

If you have your own theme and just want to add the code, Citrix has an excellent CTX article here covering it:

How to Add a Drop-down Menu with Domain Names on the Logon Page for Access Gateway Enterprise Edition:
http://support.citrix.com/article/CTX118657

What’s happening here is that a dropdown box is created with pre-populated domain names that you specify in your code. The user selects the proper domain when logging in and then this domain name is inserted into the header and passed to the Netscaler Access Gateway vserver where the authentication policy examines it. Based on the name the Netscaler sees in the header, it forwards the request on to the correct authentication server. This works great with LDAP authentication servers. I have not tested it with TACACS or RADIUS yet.

SETTING UP ACTIVE DIRECTORY LDAP AUTHENTICATION
Now it’s time to setup your Active Directory authentication for each of your domains.

1. Download LDAP Browser 4.5 for free here: http://www.ldapbrowser.com/download.htm

2. Go to your Netscaler under System > Authentication > Servers tab and create a new LDAP server. Use port 636 for secure LDAP instead of 389. Use LDAP Browser to get the Base DN and Administrator Bind DN. I prefer to use the app so I don’t fat finger the distinguished name and spend an hour trying to figure out that I missed a comma. Using LDAP Browser is much quicker and less error prone. The Base DN can be your entire AD domain or you can lock it down to an OU. The Administrator Bind DN is the actual account name that is used to enumerate AD. So CN = the user name, OU= the OU it’s in, etc. Add the password for this service account.

Make sure to select “SSL” for security type near the bottom. Click the blue “Retrieve attributes” link and it should talk to AD. Then the drop down boxes in Other Settings will not be greyed out anymore. Set the following:

Server Logon Name Attribute = samAccountName
Group Attribute = memberOf
Sub Attribute Name = CN
SSO Name Attribute = UserPrincipalName

So everything should look like this so far:

3. Now expand the Netsted Group Extraction arrow near the bottom. You need to enable it and set the same Group Name Identifier as you did for Server Logon Name Atrribute. In this case samAccountName. Then press OK to create the server:

4. Now it’s time to create the policy and bind it to the server. Hit the tab for Policies and create a new policy. Choose the server you just created. For the Expression, you will want:

REQ.HTTP.HEADER Cookie CONTAINS domain1

where domain1 is the name of your first domain.

5. Now do steps 2 through 4 again but for your second domain, domain2.

6. Almost done. What we’ve done so far is create two authentication servers and two authentication policies. These two policies are good for web browser users (IE, Firefox, Chrome, Safari, etc.) but mobile devices using the Citrix Receiver native app like iPhones, iPads, Android phones, Android tablets, etc. will not work just yet. This is because they cannot pass cookie values. Nor do they pass the domain during authentication against the Access Gateway (a traffic capture can confirm it only passes user ID and password). You need to create a different set of authentication policies for these. So you will create one for each domain. You will bind to the same authentication server as the other policies but you’ll want to add the word “mobile” or something descriptive to the end of the policy name so you know what it is for. The expression should be:

REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver

7. Now do the same for your other domain, domain2.

8. Now go to your Access Gateway vserver and add all 4 policies you created. Take a look at my example screenshot closely and the priority order.

Here is the logic behind this policy order:

100 – Domain1 user logs in via web browser and uses drop down/passes cookie for domain1 so authenticates against domain 1 DC.

110 – Domain2 logins via web browser and uses drop down/passes cookie for domain2 so authenticates against domain 2 DC

120 – Domain1 user logins via iPad so first two policies are automatically false since the native Citrix Receiver app can’t pass a cookie. Authentication policy is looking for CitrixReceiver in the header so it will try to authenticate against domain 1 DC. It will be successful and the user will see his apps.

130 – Domain2 user logins via iPad. The first two are false for the same reason as 120. The expression from policy 120 is true so the user will actually authenticate and fail against domain 1 DC. Then it moves on to the 130 policy and authenticates against the domain 2 DC. It will be successful and the user will see his apps. Note, if a user has the same account name on both domains, it will cause a rejected login attempt on domain 1 which depending on your Active Directory account lockout policy can eventually lead to an account lockout. Just be mindful of this and adjust your policy accordingly if you need to.

MODIFYING YOUR SESSION POLICIES
9. Now on to the session policies. If you followed my guide on How to setup your Citrix Netscaler (Access Gateway) and Web Interface for iPads and mobile devices that use Citrix Receiver you should have 2 policies. One for regular traffic and one for mobile/Citrix Receiver traffic. Should look something like this:

Go ahead and click on the blue profile link for the CitrixReceiver policy first.

10. Under the Published Applications tab, clear the Single Sign-on Domain, you don’t need it anymore. SSO is being handled by the authentication server now. Specifically the SSO Name Attribute setting for each server which you set as UserPrincipalName. So it is automatically passing the UPN formatted user credentials to the Web Interface as the same time the user is successfully authenticating against the Access Gateway using the SAM account name. Pretty cool right? Now do the same for your other policy that controls regular web traffic.

11. An extra step for your mobile traffic policy. Under the Client Experience tab, you can set the Clientless Access to Allow and the Plug-in Type to Java but it’s not necessary. It will still work but since it’s mobile traffic only, this won’t hurt.

SETTING UP ACTIVE DIRECTORY AUTHENTICATION GROUPS
12. Now let’s move on to setting up your authentication groups. Let’s say each domain has a security group that gives users access via the Access Gateway. Again, there are 2 well documented methods for group extraction:

How to Configure a NetScaler Appliance for Active Directory Group Extraction for LDAP:
http://support.citrix.com/article/CTX111079

How to Configure a NetScaler Appliance for Active Directory Group Extraction for LDAP Using the Groups Allowed To Login Feature:
http://support.citrix.com/article/CTX125797

I prefer the first method. It’s basically just one step in one place (the authentication server object) and goes into effect at the authentication level. No fooling around trying to control it via a session policy. So go back to your 2 authentication servers you created before and take a look at the Search Filter field. It should be blank at the moment.

13. Go to LDAP Browser and get the DN for for the security group you want to give access to for your first domain.

14. Go back to the Search Filter field and type memberOf= followed by the DN (distinguished name) for the security group. So it should look something like this:

That easy. Make sure to do it for the authentication server for domain 2 as well. Go ahead and test your login scenarios and everything should work perfectly.

ADDING REDUNDANCY FOR YOUR AUTHENTICATION SERVERS
I only covered how to add a single authentication profile (domain controller) for each of the 4 policies on the vserver. Most companies are going to have multiple DCs. There is no way to add multiple DCs per authentication policy. The solution is to create a Load Balanced vserver with all your DCs behind it per domain and then add the IP of the vserver to an authentication server that is bound to the authentication policy. So in the example I’ve been showing you, I would have to create 2 load balanced vservers since I am working with 2 domains.

15. Go to Load Balancing > Servers > and add all your servers here:

16. You guys know I prefer to create service groups vs. services and the reasons why if you’ve read my previous Netscaler articles so go to the Service Groups section and add a new services group. Select SSL_TCP for the protocol.

Specify the server based members and make sure to set the port to 636. You can weight the servers here if you want to. Under the Monitors tab, go ahead and add a ping monitor or whichever monitor you prefer. Do this for each group of your authentication servers. You might want to group them by city, datacenters, production vs. DR, or whatever makes sense in your environment.

17. Now create a load balanced virtual server for your first domain. Select SSL_TCP for the protocol, port 636, and give it an IP address. Under the Service Groups tabs, add the groups you need. Keep in mind you won’t be able to see the SSL_TCP service group you created until you set the vserver protocol to SSL_TCP. Under the Methods and Persistence tab, you can get creative if you like or just leave it the default Least Connection. It really depends on your environment and where you prefer traffic to go. Under the SSL Settings tab, bind the cert you use for your Access Gateway vserver. Do all of this for your other domain as well. Both load balanced vservers should be in the UP state at this point.

18. Now go to System > Authentication > Server tab and left click on one of the DCs. Then at the bottom click Add, this will copy all of the settings on the DC you had highlighted and allow you to create a new one based off of it. So you don’t have to put all your DNs and stuff in again. Just give it a unique name and for the IP, type in the IP of LB vserver you just created for that domain:

Now do the same for the other domain.

19. Now go to the Policies tab and edit each of your 4 policies. You can simply change the server in the drop down to the new one you created for each of your 4 policies and you’re done. All authentication traffic is now going through your load balanced vservers. Keep in mind that before, LDAP traffic was going from your NSIP to each DC. When you use LB vservers, traffic is going from the SNIP to each DC. So make sure you have your firewall ports open from the correct source IPs or you won’t be able to authenticate. Retest all your scenarios and everything should continue to work just as before.

TROUBLESHOOTING LOGINS
Once you’ve set everything up you might encounter issues and need to troubleshoot. There are a few ways to troubleshoot logins. I’ve covered this before here:

How to troubleshoot RADIUS or TACACS authentication issues on a Netscaler/Access Gateway

20. First you can troubleshoot the authentication layer but capturing of all authentication happening on the device. Open Putty and connect via SSH to your Netscaler. Enter the shell by typing

shell

and pressing enter. Then type:

cat /tmp/aaad.debug

and the cursor will go to the next screen and wait. Open up your web browser and attempt to login to the Access Gateway. Immediately you will see the request happen in your SSH window. You’ll see exactly what is happening line by line like this. You’ll even see the nested group extraction taking place:

The last line will show the accept or reject:

When you’re done, press Ctrl+Z to exit.

21. The next layer to troubleshoot is all the polices. All of them, authentication, session, etc. You want to see everything a user hits when he logs in. So type the following:

nsconmsg -s disptime=1 -d current -g pol_hits

and login to the Access Gateway again using a web browser. Immediately in your Putty window you’ll see what all policies were hit:

This will help troubleshoot your policy flow. We’ve built a lot of intelligence into the cascading authentication and session policies and based on the user’s device and domain, it will vary what all they hit. This is an excellent way to test each of those scenarios.

22. The last step is getting down to the packet layer and analyzing the traffic using Wireshark. I’ve covered this in my previous post but go to System > Diagnostics > Start New Trace and set the packet size to 0. Then press Start.

Login to your Access Gateway via web browser, stop the capture, and download it to your desktop. You will also want to WinSCP into the Netscaler and grab the SSL RSA key for the SSL cert you are using on your Access Gateway site so you can decode the SSL traffic. Then double click on the .cap packet capture file and it will open in Wireshark. Go to Edit > Preferences > Protocols > SSL > and click Edit in the RSA Keys field:

In the SSL Decrypt Window, hit New in the bottom right side and this window will popup. Type in the IP address of the Access Gateway vserver, port 443, protocol http, the exact path on your hard drive to the SSL RSA key file, and leave the password blank. Then press OK to add it:

Press okay and get back to your capture. Now in the Filter field, just type the following:

frame contains youruserID

because we want to find all the instances of your user ID being passed. You should be able to find your user ID and password in plain text. Follow the TCP stream if you need to to find out exactly what is happening.

Hope this helps. Please leave a comment if this post helped you or if you have any questions and I’ll try my best to help.

Wow, long title there! Just like it says, I’m going to cover opening Sharepoint documents in a Windows 7 XenDesktop VDI session using XenApp published Office products with content redirection enabled. Here’s an example scenario:

• Your company uses Sharepoint and the URL is http:\\sharepoint.domain.com. It is part of the Local Intranet zone in IE.
• Your users are using Windows 7 VDI/XenDesktop VMs with Citrix Receiver Enterprise pulling published apps into the Start menu.
• You have Office 2010 products (Word 2010, Excel 2010, Visio 2010, etc) published via XenApp with content redirection enabled so .docx, .xlsx, .vsd files launched in the VDI session will open using the published Office app.
• Your users want to click on a Word, Excel, Visio, etc. document in a Sharepoint document library and click the Edit button to edit the document instead of just Read Only. They expect the published Office app to launch and allow them to edit the document.

THE PROBLEMS
In this scenario, when the user clicks on let’s say a Visio document in Sharepoint, the published app will launch but the document will not be sucked in. You’ll get a “File not found” error and if you look closely, the URL begins with “\\” as if it’s a UNC path instead of an HTTP path:

If you click OK, Visio will open but no diagram will open.

If you right click, Save As the Visio diagram to your C: drive and attempt to open it locally, it will launch the published Visio instance but will give you the following “File not found” error:

Again, look closely. It says “\\Client\” instead of your VM’s name.

THE FIXES
Well, really it’s 1 fix and 1 workaround for now. Let’s start with the fix first. We’re going to get local files and files residing on network shares launching right using the published app. I’m going to use Visio and a .vsd file again as the example:

1. On the Windows 7 VM, you must enabled Native Drive Mapping to be able to launch the .vsd file via published Visio. You can follow the CTX article here to make the registry change:

http://support.citrix.com/article/CTX130378

or you can enforce it via group policy. One thing though, on Windows 7 x64 the path is:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\
Advanced\Modules\ClientDrive

NativeDriveMapping
Reg Type: REG_SZ
Add the Value: True

Once the value is set to TRUE, try launching the .vsd file you saved to your hard drive or on a network share. It will launch immediately. Then go to File – Save As in Visio and checkout the path bar. It will say “\\Client\C$\Users\xxxx\”. So now your system recognizes the word “Client”.

This is because you’re going through 2 virtualization layers. Citrix has an excellent article detailing how Client drives are passed through multiple sessions here:
http://support.citrix.com/article/CTX127872

You can also read more about the NativeDriveMapping key here:
http://support.citrix.com/article/CTX124389

Additionally here is a really good CTX article from Citrix that covers Client Drive Mapping troubleshooting that might be helpful to you:
http://support.citrix.com/article/CTX238200

And some info describing differences in Client drive mapping between the different versions of XenApp and Presentation Server here:
http://support.citrix.com/article/CTX127614

2. Now back to Visio diagrams in Sharepoint. First you need to verify content redirection is behaving correctly. In my case, I needed to make sure to change the published app location to include the “%**” switch. By default when you enable content direction, it will be:

"D:\Program Files (x86)\Microsoft Office\Office14\VISIO.EXE" "%*"

with just one asterisk. You need to add two so it looks like this:

"D:\Program Files (x86)\Microsoft Office\Office14\VISIO.EXE" "%**"

The reason for this is documented in this CTX article:

http://support.citrix.com/article/CTX116887

This was written for Presentation Server 4.5 but it still applies to XenApp 6.5 just fine.

Once you get content redirection squared away on your XenApp server, things will still not work correctly unfortunately when opening docs in Sharepoint in your XenDesktop session. You can try right clicking and editing but you will still get the File not found error. This error has nothing to do with Client Drive Mapping. Being a Sharepoint Architect in a previous role long ago, my gut feeling was this is a WebDAV issue. Remember, Sharepoint uses WebDAV with document libraries though to the casual observer it might appear to be a UNC file share path. My gut was telling me Receiver was not handling WebDav paths correctly and was treating them like regular SMB file share paths. No proof this is the culprit just yet, only a hunch.

Let’s run an experiment. In your Sharepoint document library, click Actions > Open with Windows Explorer:

You’ll notice the path bar says “http://sharepoint.domain.com” when you open it here:

Go ahead and launch the Visio diagram in this document library. When you try and launch it, it will launch published Visio and give you the same File not Found error as before. In some scenarios even an Access Denied error though it never actually was able to find the file. Again, it is looking for “\\sharepoint.domain.com” instead of using WebDAV (or the DavWWWRoot keyword) which should be parsed like the HTTP protocol “http:\\sharepoint.domain.com”. Sharepoint Content Redirection is never going to work because Citrix Receiver doesn’t know how to get there. One work around is to tell your users to save locally, edit, then upload. But this is annoying and most users will complain.

I started thinking Mini Redirector (which is Microsoft’s WebDav client and part of the Windows 7 OS) was trying to hand-off the DavWWWRoot keyword in the URL to Receiver and Receiver didn’t know what to do with it. Looking at the URL though it didn’t even seem to be passing it through. It was as if it was passing a straight UNC path. Or maybe is was not talking to owssupp.dll which is required to interact with and edit docs in Sharepoint. Maybe somehow it wasn’t handing off through Receiver properly. Now I was really starting to go down the rabbit hole and before I dug further, I figured I’d give Citrix Support a call and see if they had any input.

I was able to talk to a XenApp support technician and a XenApp Developer who were both very knowledgeable. I explained my WebDav theory and we ran a little experiment. We ran Process Monitor from my Windows 7 workstation and attempted to edit a simple Word document in Sharepoint. The published version of Word launched as expected and failed to find the file. Here is the URL that was passed to the PNAgent when we used the Process Tree display:

You can see that it passed:

\\Client\\\sharepoint.domain.com\link\to\doc\repository\test jason.docx"

Looks a bit odd, doesn’t it? No wonder it can’t find the file.

Then we went to the XenApp server with Word 2010 installed locally, opened Internet Explorer, and navigated to the Sharepoint document library. When I clicked Edit on the Word document this time, this is what was passed to the locally installed Word:

And of course the Word document successfully launched. You can see it passed a nicely formatted HTTP URL:

http://sharepoint.domain.com/link/to/doc/repository/test%20jason.docx"

The XenApp Developer verified this was actually a bug and needed to be fixed. It may or may not be WebDav related, but he confirmed there is definitely a disconnect at the Content Redirection level via Sharepoint as I had suspected. It has been added to their bug queue to get taken care of.

In the mean time, his suggestion is to publish Sharepoint itself on the same server Office 2010 products are installed on (publish IE passing the Sharepoint URL during launch). This is a good workaround but may annoy a few users. I always hate publishing IE because of the stuff you have to do to lock down/harden the browser. People can get confused and start browsing to Youtube or other process intensive websites using this published instance of IE if you don’t completely lock down the allowed URLs. This can cause a severe impact on XenApp performance for all users on the box. If I limit tabs, then people start complaining they can’t open additional tabs and the helpdesk gets flooded with phone calls. So just keep that in mind if you use this workaround.

Another work around I found online is by Anthony Obi:

http://community.obilogic.co.uk/blogs/teamblog/archive/2011/10/25/sharepoint-2010-edit-document-via-citrix-xenapp.aspx

He has an issue where owssupp.dll was not being detected on the client system (because it wasn’t there) and added an extra menu item in his Sharepoint deployment to edit documents as a work around. He modified the new Edit action to launch some Javascript that talks to PNAgent.exe that then talks to the published Office instance and passes the correct URL. This might work as well for you but of course it requires a modification of your Sharepoint environment and end user training.

I will post here as I get updates from Citrix Support on this issue. It’s a fairly unique scenario but definitely not uncommon in the real world as application delivery and desktop virtualization continue to be separated through multiple layers.

With newer versions of XenApp (6.x on up) and Citrix Receiver, multi-monitor support is great and works as expected. But if your environment still has some PCs with legacy Citrix Online plugins (less than 12.x), you might get unexpected behavior like an application launching and stretching across both monitors. You can try going to AppCenter and setting the session size of your application under Appearance but it probably won’t work depending on your plugin version. With older versions of XenApp and Presentation Server, there were a ton of multi-monitor configuration registry flags Citrix made available that you could use to manipulate the size and location of the application. These flags no longer work in XenApp 6.x and up. To verify your problem, go to your web interface and launch your application while doing a packet capture. You’ll notice something like:

DesiredHRES=0
DesiredVRES=0

in the portion of the TCP stream with the ICA file being generated and pulled down from the web interface. You need to override this. So the work around is to go to your Web Interface to the following path:

C:\inetpub\wwwroot\Citrix\XenApp\conf

and open the default.ica file. You’ll see a section like this:

[ApplicationServers]
Application=

[Application]
Launcher=WI
TransportDriver=TCP/IP
DoNotUseDefaultCSL=On
BrowserProtocol=HTTPonTCP
LocHttpBrowserAddress=!
WinStationDriver=ICA 3.0
ProxyTimeout=30000
AutologonAllowed=ON

right after this section, add this:

[Word 2010]
TWIMode=Off
DesiredHRES=1024
DesiredVRES=768

where the name of your application is in the bracket exactly as you publish it in AppCenter (it is case sensitive). In my example, I am publishing “Word 2010″. The switches above mean the following:

TWIMode - disable seamless mode (so there is a box around the application)
DesiredHRES - horizontal size
DesiredVRES - vertical size

You don’t have to disable seamless mode but I did in this example since my user wanted it for a specific reason. You can pretty much set any ICA setting you need for an application this way without impacting all the applications in your farm. Here is a full list of ICA Settings from Citrix:

http://support.citrix.com/proddocs/topic/ica-settings/ica-settings-wrapper.html

Hope this helps!

Windows 7, Citrix Receiver 3.0, 3.1, 3.2 etc., and Web Interface 5.4 all work hand in hand with newer XenApp farms. But you might notice if you have older farms in your Web Interface, apps from those farms will not launch when using Windows 7 and Citrix Receiver. You’ll get a message like this when you click on an app icon:

The network connection to your application was interrupted.  Try to access your application later, or contact your help desk.

Really helpful right? Well if you look at your event log on your Windows 7 box, you get something even more cryptic:

The description for Event ID 1 from source ICA Client (Vanadium) 
cannot be found. Either the component that raises this event is not 
installed on your local computer or the installation is corrupted. 
You can install or repair the component on the local computer.

If the event originated on another computer, the display 
information had to be saved with the event.

The following information was included with the event: 

Vanadium: TW Protocol error: Data rejected
Cmd = CMD_TW2_TEXTOUT
The data containing the error is below (1953 bytes)

I get this error with apps hosted on legacy MetaFrame XP and Presentation Server 4.0 farms. The work around is to go to your farm’s console, right click on your farm name, Properties > ICA Settings and uncheck the “Discard redundant graphics operations” setting.

After making this change, the apps will launch just fine. Additionally on some MetaFrame XP apps, I’ve had to go under the actual published application properties and lower the resolution of the app. I doubt Citrix will ever release a fix for this since legacy farms are not supported and reached End of Life years ago. You should get your apps moved over to newer XenApp farms as soon as possible.

If you are using ICA files to connect to a XenApp farm for whatever reason, and you are running Citrix Receiver Enterprise, it will attempt to passthrough credentials by default if you have setup Receiver to allow passthrough authentication using the ADM template. This is bad when you are trying to connect to a different domain because you will get the “The user name or password is incorrect” logon error message every time you launch the ICA file. It is trying to pass the wrong credentials:

You really don’t want to change your ADM file settings because that will break functionality for other things. The best way around this is to add these two lines to your ICA file:

UseLocalUserAndPassword=Off
AutoLogonAllowed=Off

Once you do that, launching the ICA file will work correctly and will show the domain the server is a member of:

So you want to give iPads, iPhones, Android phones and other mobile devices and tablets that have Citrix Receiver access to your enterprise infrastructure securely. This can be done pretty easily using a Netscaler and the Access Gateway (aka CAG/Citrix Access Gateway, AGEE/Access Gateway Enterprise Edition) which is an SSL VPN among other things. First you need to prep your Citrix Web Interfaces.

In this example, I want users sitting inside the building with their iPads connected to the corporate WiFi direct access to XenApp and XenDesktop. I want anyone external to have to come in through the Access Gateway to get access. So I need to make sure I have 2 Services sites on my web interface:

The default site is PNAgent (which is a reference to the old legacy Program Neighborhood). This services site is setup for Direct access and will service all my internal iPads and other devices that need it. The second site is the one I created manually called “AccessGateway”. This one is setup as Gateway Direct mode. This is the site that will be handling traffic from the CAG (Citrix Access Gateway):

When you are setting up the site, just add the farms as you would any other site. Nothing is different. In my case, I am using port 8080 as the XML Service port:

Under Secure Access, hit Next:

Here you need to type in the FQDN that your iPads and other devices are all pointed to. You need to type in the actual name, not the IP. So in my example, I want my users to hit this URL in Citrix Receiver:

http:\\receiver.company.com

so in this box, I would type:

receiver.company.com

This is presented to your iPad and other devices through the Web Interface in the form of an ICA file later so it needs to be the same. Also make sure to disable Session Reliability. Session Reliability is not supported on iPad and other devices using Citrix Receiver. So this means all ICA traffic will be on port 1494, not 2598. So keep that in mind when opening up firewall ports:

The last page is to add the STAs (Secure Ticket Authorities). You DO NOT need to add an STA from every farm you are connecting to. Just 2-3 STAs for redundancies sake is enough. It won’t be a whole lot of traffic. All it will be used for is to pull the ticket hash value when a client hits the web interface and then later to validate that ticket. In my case, I am using port 8080 for the XML Service port so that needs to reflect here in my STA URLs. You may be using port 80 so you would not to enter the port. In my example, it is:

http://servername:8080/scripts/ctxsta.dll

The ctxsta.dll is an ISAPI extension for IIS that will take the ticket request, process it, and send back the generated ticket. When a user hits the Access Gateway and comes in through the web interface, the web interface will send this request to the STA. Once the web interface gets the ticket (a random 32 character hash value) from the STA, it builds the ICA file to present back to the client and this value will be included. Then validation occurs just before the actual ICA session is launched and the STA needs to validate the ticket.

So now that the web interface config is complete, it’s time to configure the Netscaler. Go to the Access Gateway section and expand the Policies section. Then click Session and click the Profiles tab at the top. We are going to create a session profile first. I will call the profile “CitrixReceiver_Profile”:

I don’t really needs to change anything in this profile except on the last tab, Published Applications. Under Web Interface Address, I type in the URL to the web interface “Access Gateway” site I had create in the steps above earlier on the web interface. But I need to make sure I point directly at the config.xml file which has all the configuration information in it for the Access Gateway to read. So in my case, the URL is:

http://receiver.company.com/Citrix/AccessGateway/config.xml

Hit OK, and click the Policies tab. Create a new session policy to filter out traffic and only allow Citrix Receiver traffic. I will call my policy “CitrixReceiver_Policy”:

The actual policy will look like this, notice how it looks at the TCP User-Agent header for “CitrixReceiver”. For any other traffic, like a web browser for example, it will drop the packet. Don’t forget to choose the “CitrixReceiver_Profile” you created so that it knows to pass Citrix Receiver traffic to your new “AccessGateway” services site:

Hit OK and you are done setting up policies. Now go to Authentication under Policies and setup your Active Directory authentication. For better security, I recommend RADIUS. You will need to setup the policy and the back end server here:

Then go to your SSL certs and make you have a valid 3rd party SSL cert for your “http://receiver.company.com” website. Traffic will be SSL encrypted and Citrix Receiver does not support self signed certs. Make sure your intermediate and root certs are there and everything is linked properly. Otherwsie your SSL chain will be broken which will lead to issues:

Now that we have all the pieces in place, it’s finally time to configure our Access Gateway virtual server. So go to Access Gateway > Virtual Servers > and hit Add. Give it a name, IP address, leave it on port 443, leave the protocol as SSL, and add your SSL cert over to the column in the right. It should look something like this. And yes, Down State Flush is unchecked meaning if the vserver goes down, TCP sockets will remain active and won’t immediately be disconnected. You don’t have to uncheck it though:

Now click the Authentication tab, and add your Authentication Policy:

Now click on Policies and add your Citrix Receiver policy. By default, the priority will be 0 which is actually last. Doesn’t matter if you only have 1 policy but if you add more, you might forget to change it then. So just set it as 10 for now:

Now lastly, you need to add your STAs under the Published Applications tab. The same exact STAs you specified in your web interface several steps above. Again, I am using port 8080 for my XML Service so I have specified it here after each server name. Once you are done, press OK and then immediately open the virtual server again, go to the Published Applications tab, and you will see the green arrow and the word “UP” next to each STA. You will also see it has pulled the identifier down:

And now you’re done with the config! Don’t forget to open up firewall ports. In the DMZ, you will need 443 to come through and hit the Access Gateway URL (receiver.company.com in my case). From the Netscaler SNIP (subnet IP), not the Access Gateway virtual server IP, you need the XML Service port (8080 in my case but 80 if you left it default) open to all the STA servers you specified. You also need ICA (port 1494) open to all your XenApp application servers or XenDesktop VMs open from the SNIP as well. Lastly, you need to open up port 80 from the Netscaler SNIP to your web interface for HTTP traffic. Just remember, the SNIP is the one communicating to your internal servers, not the Access Gateway VIP so don’t get confused when adding your firewall rules. The only exception would be authentication (LDAP, RADIUS, etc.). This traffic comes from the NSIP (Netscaler management IP), not the SNIP or MIP. So take this into consideration when opening your ports.

Now to test! Open up Receiver in your iPad and type the URL, in my case “receiver.company.com”. Set your credentials and connect. If you did everything right, it should enumerate all the apps on all the farms you had specified on your “AccessGateway” services site. Click an app and it should launch just fine.

You can do an nstrace (packet capture) on the Netscaler itself to verify and also as a troubleshooting step if something isn’t working as expected. Pull the capture file over and use Wireshark to read and filter it. Remember above when you were setting up your services site and had the type the FQDN name and I mentioned this is important because it is passed back to the iPad in the ICA file? Well here it is, the red arrow is where it appears under “SSLProxyHost”:

And don’t forget to apply your CAG licenses. You might have only licensed the appliance itself and said to yourself you would apply the CAG licenses later…yes I’m guilty of this. By default you can only have 5 simultaneous CAG users so don’t forget to apply the license before releasing to production. You need to also make a decision of SmartAccess/CCU/Universal licenses vs basic licenses. If using basic licenses, you can set it up for up to 10,000 concurrent users, here is a great KB from Citrix on how to do this:

http://support.citrix.com/article/CTX125567

Also don’t forget to set the global user limit on number of sessions through the Access Gateway. It should match up to the number of licenses + 5 you get for free with the appliance. By default the Maximum Number of Users setting is 5. This is found under Access Gateway > Global Settings > Change authentication settings. You can also limit this per Access Gateway vserver if you wish:

And what if nothing works after going through all these steps? Well it can be any number of reasons. Citrix has an excellent troubleshooting PDF available here called “Citrix Receiver for Mobile Devices Troubleshooting Guide” with plenty of screenshots. It is extremely helpful:

http://support.citrix.com/article/CTX125533

Try flipping through it and if you can’t figure it out, post here and I can see if I can help.

***UPDATE***
You might also want to allow regular clients (IE, Chrome, Firefox, etc.) running Windows 7, OS X, etc. access through the Access Gateway to your Web Interface via SSL. Something a lot of companies do. For that just create another Access Gateway site but under “XenApp Web Sites”:

Make sure you set the authentication service URL to whatever your AG URL is, so following the same example:

https://receiver.company.com/CitrixAuthService/AuthService.asmx

The Secure Access method must be Gateway direct mode just like you did for the Services Access Gateway site above.

The FQDN should be the AG URL your users are hitting externally so:

receiver.company.com

Go ahead and enable session reliability since it is supported on workstations. So keep in mind ICA traffic will be on port 2598 when opening firewall ports.

Now add your STAs in the same order as before:

On your Netscaler under Access Gateway > Policies > Session, you will need to create a policy for non-mobile devices. The Web Interface address is the internal URL of your web interface you want client’s to passthrough to. You can also put your domain in the Single Sign-on Domain box so it passes through the credentials:

Default Authorization Action I set to DENY usually:

Under the Client Experience tab, I allow Single Sign-on to Web Applications:

Now under the Policies tab, you need to create your session policy and bind it to the profile you just created:

My expression will be:

REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver

And now finally under the Access Gateway, make sure both policies are in it. I set the mobile device policy first, then everything else. Doesn’t really matter though what order you have it:

One last bit of info. If you want to only allow mobile devices with Citrix Receiver installed and have regular browser traffic (IE, Chrome, Firefox, etc.) redirected somewhere else, it’s pretty easy to do. For your port 80 traffic, you need to create a load balanced virtual server on the same IP as your Access Gateway virtual server. The effective state will be down since you will not add any services or service groups to it. Under the Advanced tab, set a Redirect URL to the site you want to redirect your PC browser users to.

Now for port 443 traffic, the Access Gateway virtual server will be servicing that traffic. Unfortunately Access Gateway vservers do not support Responder policies. The quick way of getting around this is creating a Responder policy and binding it globally instead. In my case, I created the following Responder policy to redirect any traffic that is not detected to be from Citrix Receiver:

HTTP.REQ.HEADER("User-Agent").SET_TEXT_MODE(IGNORECASE).REGEX_MATCH(re/CitrixReceiver/).NOT

and if it can’t figure out the User Agent, it will drop the packet per the Undefined Result action:

For the action, I set it to redirect to the URL I want browser users to end up on:

And then you can bind it globally:

Now all my Citrix Receiver SSL traffic will hit the Access Gateway vserver and regular browser based SSL traffic will be redirected to the URL I specified. What’s cool about this is that as you test it, the hit count should increase on the policy. Just be careful binding a policy like this globally since it will impact every vserver on your Netscaler. It works fine in my scenario because this particular appliance is dedicated for Access Gateway connections only.

When you launch Internet Explorer and open your Citrix web interface page, you want it to pass through the user’s credentials and see all the available apps. When the user clicks on an app, it should launch immediately with no further prompts. Plain and simple.

But this is not always the case unfortunately. Sometimes pass-through authentication breaks. Symptoms I have seen are:

1. You get prompted for credentials at the Web Interface logon (an authentication error occurred error message) like this:

2. Passthrough at the web interface works fine but when launching an app, you get a Windows 2008 R2 logon screen from the XenApp server like this:

3. You get a combination of both issues above.

Don’t worry, there are a number of things you need to check that can resolve these issues for you. One or more of these factors may be the cause of errors in your environment. Just run through the bullet points below and verify everything:

1. You need to be using Citrix Receiver Enterprise if possible and not just the plain Citrix Receiver. The latest Citrix Receiver is 3.1 but 3.0 behaves the same way. It comes with Online Plugin 13.1.0.89 enabled out of the box. You can go to the “Receiver for Windows 3.1 – Admins” download page here:

https://www.citrix.com/English/ss/downloads/details.asp?downloadId=2319945&productId=1689163

You will need to download the 55.1 MB zip file. Inside you will see both “CitrixReceiver.exe” and “CitrixReceiverEnterprise.exe”. The one you want to install is the Enterprise version. This version will install with pass-through authentication support automatically for you as well as Single Sign On (SSO). You can always install and enable SSO with the standard Receiver using the “/includeSSON” and “ENABLE_SSON=Yes” command line switches and this actually will give you pass-through authentication features (more on this in bullet point 7 below). Receiver Enteprise will require administrator access to install on PCs unlike the standard/regular Citrix Receiver. The difference between the two versions is described here:

http://support.citrix.com/proddocs/topic/receiver-31-windows/ica-clients-deciding-v2.html

Note how Enterprise has “Single sign-on/pass-through authentication” but standard only has “Single sign-on”?

Now here’s a big problem. When an end user tries to download the Receiver off the Citrix website, it will not show Enterprise:

http://www.citrix.com/receiver

Go ahead and choose Windows in the drop down. The next page will show the download for Receiver. It does not specify if it is Standard or Enterprise. If you download the executable, it is just CitrixReceiver.exe which is the Standard version you had downloaded above.

So if you are troubleshooting pass-through authentication, the first thing you want to make sure of is go to Add/Remove programs on the user’s PC and verify it says “Citrix Receiver (Enterprise)” like below and not just “Citrix Receiver”:

I’m guessing Citrix only offers the standard version to end users so they are not confused on which one to download. The problem is if you are in an environment where Receiver Enterprise is not deployed centrally or if users take it upon themselves to install the latest Receiver from Citrix’s website (which does not require admin rights btw), they can cause a big mess and you are stuck troubleshooting it.

Another tip, you need to restart your PC for the pass-through authentication to work after you finish installing Receiver Enterprise 3.1. It will sometimes not start the Single Sign On process until you restart your PC. Or it will start it but it still not correctly passthrough credentials for whatever reason. So your best bet is to restart your PC to make sure everything is working correctly. Once you restart your PC, open Task Manager and verify “ssonsvr.exe” is running like below:

Here is another screenshot from Process Explorer which shows the dependency a bit better:

You can also go to the registry and under “HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\SSON” it should have a string value called “Enable” with a value data of “True” like this. This means SSO was installed. This key will be there if you installed Enterprise or forced the SSO install using Standard. Here is a Windows XP example:

Another thing you can do, and I’m on an XP 32 bit box right now, is navigate to “C:\Program Files\Citrix\ICA Client” and open up appsrv.ini in Notepad. You should see “SSOnUserSetting=On” at the very bottom which means that single signon is enabled.

Another check to verify for Enterprise installation, go to “HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PNAgent” in the registry and look for the DWORD value “EnablePassThrough”. It should have a value of “1″ meaning it is enabled. Standard Receiver doesn’t include the PNA plugin so you won’t even have this key if you were using it.

2. You need to verify the Citrix Receiver group policy allowing pass-through authentication has been applied to the PC you are working on. If you are just working on a test machine, you can apply this policy to just that PC for testing purposes instead of through AD. Just open up gpedit.msc on the PC, right click on “Administrative Templates” and then click “Add/Remove Templates…”. Click Add and choose the following file:

C:\Program Files\Citrix\ICA Client\Configuration\icaclient.adm

Once you have added it, navigate down to Computer Configuration > Administrative Templates > Citrix Components > Citrix Receiver > Authentication and you will see an option called “Local user name and password”. Double click on it and set it to Enabled. You need to have “Enable pass-through authentication” and “Allow pass-through authentication for all ICA connections” enabled. So it will look like this:

If you expand the User Configuration section, you will see the same settings under there as well. I usually have it set there as well but it is not necessary. In my testing, you can leave it enabled at the computer level and it will work. The changes should be instant from my testing but if they don’t take, try doing a “gpupdate /force”, restarting your browser, and/or rebooting your machine.

3. There is a known issue with XenApp 6.5 where pass-through authentication will not work. You need to apply Hotfix XA650W2K8R2X64001 to all your XenApp servers. You can get it here:

http://support.citrix.com/article/CTX130794

This will update your ccticket.dlls among other files that will fix the issue.

4. Verify on your XenApp servers that the RDP connection is set to not prompt for passwords. Under the Remote Desktop Session Host Configuration console, doubleclick on RDP-Tcp, then click the Log on Settings tab. Verify “Use client-provided log on information” is selected and “Always prompt for password” is NOT checked:

5. Verify in the Web Interface console that you have specified pass-through authentication for the XenApp site. Just open the Web Interface Management console, right click on your site, and click Authentication Methods. Pass-through should be checked here:

It should also be done on the XenApp Services site if you need it.

6. Pass-through authentication will not work in Firefox. I’ve added my web interface to the Trusted URIs config in FireFox but it won’t work. NTLM Passthrough authentication works fine on the web interface, but it won’t carry to the XenApp server when launching an app. You can add your WI to the list by typing this in the address bar in FireFox:

about:config

Then just type “NTLM” in the filter box. Add the URL (without the http:\\) in the “network.automatic-ntlm-auth.trusted-uris” box. If you do manage to somehow getting pass-through authentication to work in Firefox, please leave a comment below. I’m not a huge IE fan.

Quick note in IE, you do not need to add your WI URL to the Trusted Sites security zone for passthrough to work. Local Intranet is all you need from my experience. Sometimes you may get prompted at the web interface for credentials. Just make sure the site appears in Local Intranet and not Internet. I’ve seen issues where NTLM passthrough may not work in this scenario.

7. One final note, I did some additional testing using the Standard Receiver and command line installation. If you install Standard Receiver using command line with the following:

CitrixReceiver.exe /includeSSON ENABLE_SSON=Yes

You will see in Process Explorer or Task Manager that “ssonsvr.exe” is indeed running after the install. In my testing I was able to get it to actually pass-through but on certain XenApp 6.5 servers only. They had the pass-through hotfix I talk about below in bullet point 3 above applied. This was the only exception. And it only worked immediately after the Citrix Receiver install without rebooting the system. After rebooting the PC, it behaved like all other regular unpatched XenApp 6.5 and below farms. I would get the Server 2008 logon.

I then added the .adm template and configured it as described in bullet point 2 above and pass-through authentication worked fine with both patched and unpatched XenApp 6.5 servers. It even worked on XenApp 5 Feature Pack 3 farms with Web Interface 5.3 just fine.

If you check Process Explorer as you launch an app, the whole chain is there from the single sign on service to the connection manager down to the ICA client/Online Plugin:

So bottom line, you can get standard Receiver to work with passthrough but only if using these command line switches during install. I would just deploy Receiver Enterprise to begin with to avoid having issues down the road. It just seems to make more sense to me.

After your install XenApp 6.5 and setup your web interface site under Web Interface 5.4, you may notice that going to the web interface will show you a plugin install page like this if you don’t have the right web plugin installed on your system:

The problem is when you click on this install button, it takes the user to:

http://www.citrix.com/site/SS/downloads/index.asp

where they have to dig around and find the proper plugin. This is a horrible end user experience because they don’t know what to download and can get confused and frustrated.

So instead, you can host the web plugins for the different OSes on your web interface server itself just like previous editions of Web Interface. Here are the steps to do this. I installed on XenApp 6.5 and Web Interface 5.4 on a Server 2008 R2 for this example so these are 64 bit paths. Just edit the path below to regular “Program Files” if you are using a 32 bit OS.

1. Go to:

c:\Program Files (x86)\Citrix\Web Interface\5.4.0\Clients

you will notice it is empty like below:

2. Now go to your XenApp 6.5 media/install files and drill down to the Windows clients folder:

Citrix Receiver and Plug-ins\Windows

3. Copy the “Windows” folder into the “c:\Program Files (x86)\Citrix\Web Interface\5.4.0\Clients” folder. You can also copy over the Java, Linux, and Mac folders if you support those clients but in this example, I am only copying over the Windows clients.

4. Once everything is copied, go into the Windows folder and you will see all the clients listed:

5. Now go to the Web Interface console and click Client Deployment on your XenApp website. Make sure “Offer upgrades for clients” is checked if you want users to be prompted to upgrade their clients when they hit the WI and are detected to be running an old version. By default this is unchecked and that is fine if you don’t want to give them an option to update just yet.

7. Now the fun part, go to:

c:\inetpub\wwwroot\Citrix\XenApp\conf

and open the WebInterface.conf file in Notepad. Scroll down till you get to the ICA clients section which is commented out by default.

8. Since Citrix Receiver 3.0 that is currently shipping with XenApp 6.5 has the Online Plugin version 13.0.0.6684 embeded, you can uncomment this line and instead of “CitrixOnlinePluginWeb.exe” type “CitrixReceiver.exe”. This will give users the option to install the Citrix Receiver instead of a legacy Online Plugin:

9. You don’t have to do an iisreset as the change should be instant but for good measure, you can:

10. Now when you go to the web interface in your browser, you will notice the green Install button is there but there is also a little check box underneath that says “I agree with the Citrix license agreement”. This means the install file is being hosted on the web interface server now. Check the box and hit Install:

11. Save or Open the file depending on what your browser prompts you with (I am using Firefox):

12. Run the file to install the Citrix Receiver:

13. It will prompt when complete unlike some older Online Plugin versions:

14. Click Continue on the Web Interface once the installation is complete:

15. Now you can logon. If you have passthrough authentication enabled, it should log you in automatically if using Internet Explorer. In Firefox, make sure to enable NTLM passthrough for the URL and it will do the same. Here is my article I wrote a while back on how to do this targeted at Sharepoint admins but the same steps will work for your web interface URLs:

http://www.jasonsamuel.com/2010/02/08/getting-firefox-to-pass-active-directory-credentials-to-sharepoint-2007/

Otherwise it will give you the Explicit logon prompt:

15. Now you may not want to deploy Citrix Receiver to your end users and just want to remain on a legacy version of Online Plugin. This is fine too. All you have to do is manually create a “Online Plug-in” folder under:

c:\Program Files (x86)\Citrix\Web Interface\5.4.0\Clients

and drop your legacy plugin executable in there:

and then make sure your WebInterface.conf is uncommented and says “CitrixOnlinePluginWeb.exe”:

16. If you want to force your users to run a minimum version of the Online Plugin or otherwise get the “Install the latest plugin” screen, you can append the version number to the end of the string. In this example, I only want to let users connect and bypass the Install screen who are using 11.2 or greater so I typed:

ClientIcaWin32=Filename:CitrixOnlinePluginWeb.exe,Directory:Windows,Mui:Yes,ClassID:238f6f83-b8b4-11cf-8771-00a024541ee3,Version:11.2.0

A few things to note on client detection and Firefox vs. Internet Explorer. IE can detect the difference between lets say version 11.2.0.31560 vs. 12.0.3.6. But Firefox cannot. Firefox can only detect if a client is installed or not, it cannot detect version numbers. So if you specify in your WebInterface.conf that only 12.0 clients can connect without the update screen and the user connects using 11.2 with Firefox, they will not get the update screen. If you run a manual client detection under Settings > Run Client Detection, it will say “The preferred client is already available on your computer.”

In IE, it detects the client version just fine. To test, make sure a legacy online web plugin is installed on your system such as 11.2.0.31560 for example. Edit your WebInterface.conf like above and set the version to “11.2.0.31560″. Hit the web interface and you will passthrough with no issue. Now edit the string again and change it to “11.2.0.31561″. Try going to the web interface and you will now get a prompt asking you to update.

So please keep the browser client detection issues in mind if you do allow your users to run browsers other than Internet Explorer. There are better ways to rollout a client update to your user base that are more controlled and less “error prone” if browser flavor is a concern in your environment.