Citrix XenMobile MDM 8.6 SSL Offload via NetScaler (How To)

Citrix XenMobile MDM 8.6 SSL Offload via NetScaler (How To)

Citrix XenMobile MDM 8.6 SSL Offload via NetScaler (How To)

This post has already been read 55128 times!

Update: A few new steps to get this working have been added to this post, plus (and this is important) when you are installing MDM by following this post DO NOT UPDATE THE CERTIFICATES.  Run with the self signed certificates that XenMobile will install by default.

I was working on a XenMobile MDM Pilot and whilst working on it Citrix released a patch to enable SSL Offload at the NetScaler for MDM traffic.  I thought I would write a post on setting this up and converting from a wizard driven Load Balancer for MDM to a manually created SSL Offload solution.

Firstly you will need to download the Citrix Patch to the XenMobile MDM Server and save it to a convenient location.  The patch can be found here:

http://www.citrix.com/downloads/xenmobile/product-software/xenmobile-86-mdm-edition.html

You may need a My Citrix account to access this download.

Once you have the patch on the MDM Server log into it and copy the patch to the following location:

\XenMobile Device Manager\tomcat\webapps\[instance_name]\WEB-INF\lib (on all cluster nodes, in a clustered XDM config)

copy_the_patch

Copy the patch file to MDM

Restart the ZDM Service (or better still restart the entire MDM server).

Thats it! your MDM server is patched.  Of course you will need to re-configure the NetScaler or you will still be using SSL BRIDGE for the load balancer.

You should check that the patch is installed by going to the following URL on your MDM Server https://localhost/zdm/helper.jsp and you should see the following patches listed.

xenmobile_patches_installed

Active Patches

As you can see below, my MDM server is currently running on the dns name xenmobile.domain.com.  This is configured as a SSL_BRIDGE load balancer on the NetScaler, also shown below.

old_dns_name

SSL_BRIDGE dns name

ssl_bridge_lb

SSL BRIDGE Load Balancer

You can also see by the image below that I have NO SSL Offloading in place currently.

no_ssl_offloading

No SSL Offloading defined

So, to migrate from the old bridged connection to an offloaded one you first need to disable and remove the existing Virtual Server (Load Balancer) and the existing Services.

remove_old

Remove Services and Virtual Servers

You then need to create a new service for each MDM server you have in your cluster (This needs to be done on port 80 in order to offload to that).  The Service parameters are:

  • Monitor – tcp
  • Server – XenMobile MDM Server
  • Port 80
xenmobile_offload_service

XenMobile Offload Service

Ensure that the service is reporting as up before proceeding

xenmobile_service_up

Service Up

You will then need to create the SSL Offload Load Balancers to handle both services.  You will again need one for 443 and one for 8443.

Before you do this you will have to upload 2 new certificates to the NetScaler from the MDM Server.  Follow the below steps to do this.  (Note: Thanks to Justin Maeder from Citrix for these steps)

On XenMobile Device Manager Server browse to C:\Program Files (x86)\Citrix\XenMobile Device Manager\tomcat\conf and open cacerts.PEM in notepad

You should have 2 separate certs inside this file – The top is the Devices Cert and the bottom is the Root Cert.

The file should look something like this:

—–BEGIN CERTIFICATE—–

Random text

—–END CERTIFICATE—–

Copy the top certificate to a new file called Device-CA.cer

Copy the bottom certificate to a new file called Root-CA.cer

Inside the NetScaler GUI navigate to Traffic Management > SSL > Certificates and install both certificate files

After both certificates are uploaded, you will now need to link them together. In the Certificates pane select the Devices-CA certificate and choose Action > Link. When this opens, you should choose your Root-CA certificate that you uploaded earlier.

xenmobile_self_signed_certs

Self Signed Certs

Inside the NetScaler GUI navigate to SSL > Policies and then click Add.

Beside the Action field (To the right) click on the Plus sign

Enter a Name for the SSL Action and make the following changes

  • Client Certificate – ENABLED
  • Certificate Tag – NSClientCert

Click on Expression Builder to reveal the Expression Builder dialogue box. Using the drop-down options, create the following expression:

CLIENT.SSL.CLIENT_CERT.EXISTS

Create the SSL Policy

xenmobile_ssl_policy

XenMobile SSL Policy

You will now have to create 2 SSL Offload Servers.  1 for port 443 and 1 for port 8443 (Apple device enrolment)

Inside the NetScaler GUI navigate to Traffic Management > Load Balancing > Virtual Servers

Create a new virtual server bound to the service on port 80 you created earlier.  Use the parameters shown below.

ssl_offload_port_443

SSL Offload Port 443

Click the SSL Settings tab and add the certificates in this order: External SSL (dns name your users will use to access XenMobile), Devices-CA, Root-CA.  When adding the devices and root CA click the down arrow on the add button and add them as a CA.

ssl_offload_443_parameters

SSL Parameters

Click the SSL Policies button and bind the policy you created earlier.

ssl_policies

SSL Policies

Click the SSL Parameters button and enable Client Authentication and set the cert to optional.  This is shown below.

ssl_parameters

SSL Parameters

Create another Virtual Server for port 8443, bind the service on port 80 to it and add the EXTERNAL certificate to it.

You should now have 2 SSL Offload Servers showing as live.

servers

SSL Offload Servers

Thats it! Assuming the external port forwarding and dns is in place you should be able to connect to your MDM server and SSL will be offloaded at the NetScaler.  Test connecting and setting up your Apple and Android devices.

Hope this helps someone out.

Laters,
b@m

 

24 thoughts on “Citrix XenMobile MDM 8.6 SSL Offload via NetScaler (How To)

  1. JT

    Just to confirm – the server certificate is the external CA signed (ie Verisign) certificate. I’ve followed this exactly, and reverted the MDM server back to the self-signed certs but ios still fails with invalid URL. Android works fine since it’s all 443.

    1. Bretty Post author

      Hi there. Yes, the primary cert on the ssl offload VIP is the external one. (This must match the external address you have when setting up mdm) and the additional 2 are the 2 Certs extracted from the file. Make sense?
      Apologies for the slow reply. Have to sleep sometime! :-)

  2. Matt Gladding

    I’ve been having some trouble with this and I think it’s more on the MDM site than netscaler.

    For example when on the server itself I browse to http://localhost/zdm and all I get is a blank screen, but if I go to https://localhost/zdm I get the console (after a cert warning).

    So when I set my Loadbalance to use port 80 as the backend service, from the outside world all I get is a blank page when browsing to https://mobile.domain.com/zdm

    Enrollment obviously doesn’t work either. Ideas?

    1. Bretty

      Hi,

      It sounds like a MDM problem bearing in mind that the admin console is not working from the local MDM Server. Can you post up the Tomcat log file? Should be able to see from that if the service is failing on port 80?

      Cheers,
      Dave.

      PS: The other option is to create 2 services to port 443 rather than port 80 and terminate the public SSL at the NetScaler and tunnel the traffic tot he MDM server using the self signed certs. If you in a hurry to get it in that is??

      1. Matt Gladding

        I was able to find the port conflict and clear that up.
        But now I get connection failed due to security policy when a device is enrolled?

          1. Matt Gladding

            android currently (haven’t gotten around to testing iphones) and pure mdm for the time being… figured I’d get it working a piece at a time.

          2. Bretty Post author

            What’s the exact error message your getting and at what point in the enrollment? Make sure 443 and 8443 are open to the mdm server from the firewall. Even 8443 for Bon android devices. I had to open up that port for kindle fire devices!

          3. Matt Gladding

            Literally “connection failed due to security policy” on the device.

            The setup I have is MDM fronted by a netscaler to do SSL offload.

            I installed the patch, setup everything as described here and other places (sadly edocs doesn’t have anything yet).

            It will enroll. Like the device shows up in MDM with the user I use. But it doesn’t apply any policies, and I constantly get that error on the phone. It’s like it doesn’t like that the phone is proxied through the netscaler

          4. Bretty Post author

            Can you post the firewall rules you have in place for MDM up here (obviously blank out relevant details etc) and also the ns.conf file from the NS. Will have a look at it.
            Might be tomorrow morning now though, getting late here in the UK…

            Dave.

          5. Bretty Post author

            Also, the user assignment for the enrolling account. Can you make sure the role assigned is user and not support / admin etc?

  3. Matt Gladding

    The user is assigned to user (it’s a member of domain users and that group is assigned user role). As for firewall rules. It’s a sonicwall so I can’t just copy and paste command line but the following rules.

    mobile.domain.com is natted to the VIP
    And 443 and 8443 are allowed through.

    1. Bretty Post author

      Can you give me some details about what policies you are pushing via MDM.
      From what your saying the enrollment is working ok, if you look in devices then you get an all green result (so to speak) by your device?
      It may be down to a policy being pushed out. Can you try to disable any auto created policy groups, creat a new one and only assign a simple pass code configuration to it.
      Without looking it seems that the FW and VIP is correct.
      To rule out the netscaler you could port forward 443 and 8443 for mobile.domain.com direct to mdm as a test. That said it sounds like the issue is with the mdm server and not the netscaler.
      Dave.

      1. Matt Gladding

        No,

        It enrolls as in the authentication happens, the device gets added to MDM, but then on the device it gives that error, and in MDM the device shows orange (pending). I have sliced back the deployment so the only policy it wants to push is a passcode policy (generic, require 4 characters, 5 minute lock).

        It works fine passing 443 and 8443 to the MDM server, I tested that already. It ONLY happens when traffic is proxied through the netscaler.

  4. Sam pat

    When you have a Ha pair of MDM servers, Ssl offloading does not work that well. Believe it is missing a step of setting Ssl persistence. That fixed it for me with v8.7.

    1. Bretty Post author

      Yep, this is only for a single node session. If you have multiple nodes you would need to enable sticky sessions on the netscaler. Will update this for future reference. Thanks for pointing it out.
      Bretty.

  5. Xen Lee

    Hi,

    Thanks for your article.

    Following your steps, I got a certificate error. When I add the mdm server address to WorxHome, I ‘v got a certificate error, it says ‘No certificates found’ and when I access the mdm server with browser https://fqdn/zdm, I got a certificate error and cannot find the mdm page 404.

  6. Jay

    Hi Bretty,

    Excellent article, is it possible to update the article in relation to XenMobile 8.7 and setting up the sticky sessions via NetScaler?

    Thanks

    Jay

      1. Jay

        Hi Bretty,

        Thanks for the quick reply, we have encoporated the guidance outlined above on our NetScaler and all the monitors show as up, however it just doesn’t seem to relay the requests back to our clustered 8.7 MDM instances. Looking at previous comments it suggests the SSL Persistence needs to be setup in a clustered MDM solution which I have changed on the VIP, however I am unsure if this is the correct place to change it. Additionally I have upped the amount of HTTP requests each MDM server can handle but alas no joy. Any thoughts on why it may not be working as intended?

        Thanks

        Jay

  7. เบอร์มงคล

    Right here is the right site for anybody who wants to find out
    about this topic. You know a whole lot its almost hard to argue with you (not that
    I personally will need to…HaHa). You definitely put a new spin on a subject that’s been written about for a long time.
    Great stuff, just excellent!

Leave a Reply

Your email address will not be published. Required fields are marked *