This is a first draft to give a basic information of how you can integrate Novell Access Manager (NAM) 3.x with Citrix XenApp (aka: Citrix). This setup assumes you wish to perform SSO from NAM into the Citrix Web Interface, and that you do not wish to use the NAM SSL VPN to get access to the Citrix App servers.
This document also assumes you are using the Citrix Web Interface v 4.6 with the latest patches from Citrix. (there were some issues with Citrix web code that caused problems if you launched the web interface from a web browser via an HREF as it had java cross-site scripting issues).
The server setups are as follows:
First things first: Get it working all by itself (that way if you have problems you can blame Citrix).
One thing to note: We have our Web Interface server set to ONLY route through the CSG if it’s been accessed externally (there’s really no need to use the CSG if you’re on your private LAN, IMO). I believe the setting is in the Web Interface Admin GUI and it’s in the section: Manage Secure Client Access.
Assuming your NAM and CSG are in your DMZ you can put a line that basically says to use the gateway only if the IP network is say: 192.168.x.x (whatever your IP network for your DMZ is)
Citrix Web Interface DNS name: wi-2003.abc.com (this is the actual hostname of the Windows server. We will make an alias for a public DNS name later that will resolve to the IP of the NAM LAG proxy).
Launch a web browser from the private LAN and point it to the web interface. You should see something similar:
Tree name is blanked out to protect the innocent.
At this point you could type your userid and password (eDirectory) and click LogOn and you would be good to go. (the [Find Context] will find your edirectory context).
Make sure you can launch a Citrix App. If all works well, let’s get the Single Sign On part working next via NAM.
First we need to create the form fill policy.
Here’s what ours looks like:
I’ve blanked out the tree name, but will expand the “Insert Text in Header” here:
Create a DNS entry such as: webinterface.abc.com
This will resolve to the IP of the LAG Proxy Service that we’re going to create.
Enter the appropriate IP address and click OK.
Now edit the proxy service and we’re going to adjust the Resources tab:
We need to make two resources. One is for the “main” URL. We protect this so that you cannot even get to the Web Interface without authenticating first. The Authorization policy is up to you (you can put something simple like if user is in O=ABC or something).
Now for the Login resource:
I also put an auth procedure, along with an auth policy so that you’re required to login as well before you can hit the login page. Otherwise if you set the Auth procedure and Auth policy to: None, and None, it sets it up as a public resource and anyone can go accessing your server login page without authentication.
We do this so that the formfill can match on the URL code. Now I’ll go to the formfill tab:
Don’t forget to Enable policies. I forget all the time and then it doesn’t work so hot.
At this point, save your changes and update your IDP and LAGS accordingly.
Now, you need to make sure that your PC can resolve the:
Webinterface.abc.com to the IP of the LAG
If that works, you should be able to just launch IE/Firefox and go to:
You should be presented with the IDP login page and after you enter your credentials, you should be SSO into the Web Interface and see your published apps (or whatever it is that you want to see).
You will see a few Web Interface redirects if you have the default settings turned on (ie, auto-client detection, etc.)
At this point, assuming you have setup your CSG in your DMZ (there’s an SSL certificate exchange that you have to do between it and the STA which, in our case, is ALSO on the Web Interface server in the private LAN), you’re basically all set at this point.
Firewall holes from public to DMZ:
80/443 to your IDP/LAG (depending on how you have things setup)
80/443 to the CSG in your DMZ
DMZ to Private LAN:
80/443 from LAG to Web Interface
1494 from the CSG to the actual Citrix XenApp servers on your private LAN
443 from the CSG to your Web Interface/STA (again, in our case, the STA is on the Web Interface Server).
I’m leaving out the other firewall holes for Admin console and eDir/AD from the IDP
Here’s basically (very basic) how traffic should go:
Web Browser does HTTPS to webinterface.abc.com which really points to your LAG (or L4 switch if you have one, which then goes to the LAG). Once you login to the IDP, you should be SSO’d to the Web Interface. You will click on some published APP/resource for Citrix.
At that point, the .ICA file should be delivered to your PC via HTTPS. This .ICA file will contain the information that tells the Citrix Web Client on your PC where to go. If you did not use the CSG, your ICA file would contain the private addreses of your Citrix Servers. Because the Web Interface sees your IP request as coming from the LAG (remember that setting we configured?) it knows that it should route your traffic through the CSG.
So the .ICA file will have the published IP/DNS of your CSG (ie: csg.abc.com that resolves to the actual CSG servers IP that’s sitting in your DMZ). The CSG will get this .ICA information and check with the STA (Secure Ticketing Authority) to make sure you are really authorized. If the key/session is valid, then the CSG will act as an .ICA proxy to the actual Citrix server on your private LAN and it will talk to that specific server via the 1494 Citrix ICA protocol.
Why go with this approach?
Note that we use eDirectory authentication, so the formfill is setup for that method.
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.