Integrating Citrix XenApp with Novell Access Manager 3.x



By: khurni

January 21, 2010 10:16 am

Reads: 475

Comments:7

Rating:0

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:

  • Citrix Server farm that hosts your Applications via ICA—located on your private LAN. App servers have Novell Client installed on them, and are in AD domain that’s synced via IDM 3.5.x from eDirectory so that userid/passwords match.
  • Citrix Web Interface server on IIS/Windows 2003—located on your private LAN. Web Interface is set to use eDir authentication, not Windows auth.
  • Citrix Secure Gateway (CSG) that’s located in your DMZ on Windows 2003
  • NAM IDP/LAG—located in your DMZ and maybe also another cluster on your private LAN

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.

FormFill Policy:

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:

You have to leave the javascript enabled or the citrix timeout and redirection won’t work properly.

Proxy Service:

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:

webinterface.abc.com

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:

From external:

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?

  1. It’s almost 100% pure Citrix, so if you have problems you can call Citrix for tech support and not have to worry about vendor fingerpointing.
  2. You can use NAM for SSL and SSO to the web interface.
  3. No need to mess with SSL VPN.
  4. It just works.

Note that we use eDirectory authentication, so the formfill is setup for that method.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Categories: Uncategorized

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.

7 Comments

  1. By:dbligh

    I’m trying to figure out the benefit of having Access Manager in the solution if the Citrix Gateway Server is being used..

    Granted my knowledge isn’t expansive on the CSG, but from what I’ve been reading, can’t you protect the Web Interface using the CSG instead of a NAM implementation?

    Just trying to understand what the benefit is here.

  2. By:khurni

    Generally speaking, if one is going to use the CSG and the Web Interface, they should be on two separate servers, with the Web Interface on the private LAN and the CSG in the DMZ.

    While you CAN login directly to the CSG (and it therefore communicates to the web interface server as well) you don’t get the benefit of Single Sign On, not to mention you cannot really control who can or cannot get to the web interface server.

    Whereas with NAM, if the user tries to get to the web interface server, they are sent to NAM and therefore you get some semblance of access control/authorization along with single sign on. Plus you’re not exposing the IIS server directly to the internet traffic as NAM is a proxy.

    But there are many ways to get to citrix with or without NAM (you could use the Citrix CAG appliance which basically does an SSL VPN type of solution albeit a little expensive).

  3. By:dbligh

    thanks for that khurni, we’re currently working with Citrix on a similar solution and they seem to be fairly open to the way it’s being presented. It’s been approved at least for POC.

    Will keep this updated on how this rolls out.

    Cheers

  4. By:woodsy_ca

    I have been working through this same process with XenApp 6.5 and the latest versions of CSG and Web Interface.

    I haven’t been very successful. Ultimately, the problem comes down to the SSL configuration between Access Manager and the CSG. When I attempt to access the CSG server via Access Manager, I get a 504 error page. In the CSG log, I see the following:

    [warn] SSL handshake from client failed
    [error] SSL Library Error 47 on xxx.abc.com:443 with peer 192.168.x.x: An unclassified SSL network error occured. (error code: error:14094418: lib(20):func(148):reason(1048))

    xxx.abc.com is a replacement, of course, but the error does show the proper URL for the CSG server. And the peer address is the default address of the LAG. I’m at a bit of a loss on how to configure Access Manager to resolve the SSL problem. For testing purposes, I am using an internally signed certificate on the CSG, but I have imported both the server and root certificates to the Access Manager certificate stores.

    My grasp on how Access Manager handles this type of communication is rather tentative. Any suggestions?

  5. By:kjhurni

    The “easy” way is to go into the reverse proxy config you made for the LAG that points to the CSG. On the Web server section there’s a spot that you have the IP address of the CSG and the port it’s using. It’ll probably be port 80

    You’ll check the box “Connect using SSL” and then change the drop-down to be: don’t verify
    Change the TCP port from 80 to 443 on the “connect port” section.

    This assumes of course, that you’re not trying to actually pump the .ICA client traffic through NAM.

    This is all in the NAM documentation as well (how to configure LAG reverse proxies).

  6. By:keongregory

    We configured the CSG and WI on the same server. Initially, when we configured this to work with NAM, we used the same IP and port as the CSG to access the web interface. This resulted in getting an error when trying to launch a published application.

    The problem is encountered because the ICA traffic is trying to be tunneled through NAM as khurni has noted above.

    To use NAM when the CSG and WI are on the same server, you must expose the CSG to the DMZ and protect the WI directly with NAM:
    1. Setup two separate DNS records for the Citrix WI and the CSG. (The WI must be accessible to NAM; the CSG must be accessible to the end-users).
    2. Configure NAM as khurni has outlined, with the web server and port for the proxy being that of the Citrix WI server (not the CSG).
    3. Configure the WI to use the hostname of the CSG in the secure client access settings.
    4. Configure the CSG for “Direct” access method for the web interface. (This will stop users from being able to log into the WI by accessing the CSG URL).

  7. By:TellierS

    Hi

    I want to use NAM without CSG server.

    Can you explain the impact on the ica file?

    The rewriter is already modified to accept the ICA file (mime type : application/x-ica)

    Which parameter need to be modified? or added?

    parameter with reverse proxy address, parameter with internal address of citrix server

    iChain add this info:

    ProxyHost=webapp2.xxx.xx:443
    ProxyType=Secure
    ProxyUsername=71a0a8d076b73ff27245075b
    ProxyPassword=ddaf9c31f3d13c87b064c5062fa837661eb7f58f

    [Encoding]
    InputEncoding=ISO8859_1

    [WFClient]
    CPMAllowed=On
    ClientName=-.username.R-o31nn
    ProxyFavorIEConnectionSetting=Yes
    ProxyTimeout=30000
    ProxyUseFQDN=Off
    RemoveICAFile=yes
    TransparentKeyPassthrough=Local
    TransportReconnectEnabled=On
    VSLAllowed=On
    Version=2
    VirtualCOMPortEmulation=Off

    [ApplicationServers]
    ConsoleOne=

    [ConsoleOne]
    Address=172.x.x.x:1494 -> citrix server IP
    AutologonAllowed=ON
    BrowserProtocol=HTTPonTCP
    ClearPassword=58AD9CE35865EB
    ClientAudio=Off
    DesiredColor=8
    DesiredHRES=1024
    DesiredVRES=768
    DoNotUseDefaultCSL=On
    Domain=\72C9AE7AF5B23F18
    EncryptionLevelSession=EncRC5-128
    FontSmoothingType=0
    InitialProgram=#ConsoleOne
    LPWD=0
    Launcher=WI
    LocHttpBrowserAddress=!
    LogonTicket=58AD9CE35865EB72C9AE7AF5B23F18
    LogonTicketType=CTXS1
    LongCommandLine=
    NRWD=0
    ProxyTimeout=30000
    SFRAllowed=Off
    SSLEnable=Off
    SessionsharingKey=-iA62uhUfLz9kHpqe1nlpPC
    StartIFDCD=1392132332089
    StartSCD=1392132332089
    TRWD=0
    TWIMode=On
    TransportDriver=TCP/IP
    UILocale=en
    WinStationDriver=ICA 3.0

    [Compress]
    DriverNameWin16=pdcompw.dll
    DriverNameWin32=pdcompn.dll

    [EncRC5-0]
    DriverNameWin16=pdc0w.dll
    DriverNameWin32=pdc0n.dll

    [EncRC5-128]
    DriverNameWin16=pdc128w.dll
    DriverNameWin32=pdc128n.dll

    [EncRC5-40]
    DriverNameWin16=pdc40w.dll
    DriverNameWin32=pdc40n.dll

    [EncRC5-56]
    DriverNameWin16=pdc56w.dll
    DriverNameWin32=pdc56n.dll

    ICA file mofdified by iChain

    [Encoding]
    InputEncoding=ISO8859_1

    [WFClient]
    ProxyHost=citrixurl2.xxx.xx:443
    ProxyType=Secure
    ProxyUsername=71a0a8d076b73ff27245075b
    ProxyPassword=ddaf9c31f3d13c87b064c5062fa837661eb7f58f
    CPMAllowed=On
    ClientName=-.username-P.I-byt2f
    ProxyFavorIEConnectionSetting=Yes
    ProxyTimeout=30000
    ProxyUseFQDN=Off
    RemoveICAFile=yes
    TransparentKeyPassthrough=Local
    TransportReconnectEnabled=On
    VSLAllowed=On
    Version=2
    VirtualCOMPortEmulation=Off

    [ApplicationServers]
    Intranet site=

    [Intranet site]
    Address=citrixurl2.xxx.xx:1494
    AutologonAllowed=ON
    BrowserProtocol=HTTPonTCP
    ClearPassword=DF338E23E79883
    ClientAudio=Off
    DesiredColor=8
    DesiredHRES=1024
    DesiredVRES=768
    DoNotUseDefaultCSL=On
    Domain=\A8AEA2E2BE775A4D
    EncryptionLevelSession=EncRC5-128
    FontSmoothingType=0
    InitialProgram=#Intranet site
    LPWD=0
    Launcher=WI
    LocHttpBrowserAddress=!
    LogonTicket=DF338E23E79883A8AEA2E2BE775A4D
    LogonTicketType=CTXS1
    LongCommandLine=
    NRWD=0
    ProxyTimeout=30000
    SFRAllowed=Off
    SSLEnable=Off
    SessionsharingKey=-E24okMsI/5ZwbikBroMFBB
    StartIFDCD=1392132575338
    StartSCD=1392132575338
    TRWD=0
    TWIMode=On
    TransportDriver=TCP/IP
    UILocale=en
    WinStationDriver=ICA 3.0

    [Compress]
    DriverNameWin16=pdcompw.dll
    DriverNameWin32=pdcompn.dll

    [EncRC5-0]
    DriverNameWin16=pdc0w.dll
    DriverNameWin32=pdc0n.dll

    [EncRC5-128]
    DriverNameWin16=pdc128w.dll
    DriverNameWin32=pdc128n.dll

    [EncRC5-40]
    DriverNameWin16=pdc40w.dll
    DriverNameWin32=pdc40n.dll

    [EncRC5-56]
    DriverNameWin16=pdc56w.dll
    DriverNameWin32=pdc56n.dll

Comment