# Citrix

## SSO to Office365 with NetScaler Unified Gateway

### How-to configure SSO to Microsoft Office365 with Citrix NetScaler Unified Gateway

In this Blogpost I want to show you how-to configure Office365 as a SaaS Application in a Citrix NetScaler Unified Gateway. We will also make use of a SAML Based Authentication to realize a Single Sign-On experience. To get this working it is necessary that your Office365 Account is configured as a SAML Service Provider. I blogged about how to do this here, so I will move directly to the interesting part.

We start by creating the needed SAML SSO Profile. Go to NetScaler Gateway -> Policies -> Traffic and switch to the last Tab which is called SAML SSO Profiles. You will see that this SAML SSO Profile looks like your SAML IdP Profile except one small difference. The Relay State Expression. As Ingmar Verheij already explained in his Blog about SSO to Sharefile with Unified Gateway it doesn´t matter which  expression you are working with as long as it has a correct syntax. The rest of those Values should match your SAML IdP Policy or at least work with your Office365 configuration. My SAML SSO Profile does contain this values:

• Signing Certificate Name: Select your Certificate which you are using to sign the SAML Responses/Requests.
• Audience: urn:federation:MicrosoftOnline
• And make sure you set the Attribute1 Value to mail.

In the second Step we will create the Microsoft Office365 SaaS Application. Go to NetScaler Gateway ->Resources -> Bookmarks. After you hit Add you have to enter a Name and Display Name. Under Bookmark you have to enter the Microsoft Office365 Login Page. I do work here with https://portal.office.com. Select SaaS as the Application Type and select SAML Based Authentication as the SSO Type. Under SAML SSO Profile you have to select your SAML SSO Profile which you created a few moments ago.

To finish the configuration you only have to bind the newly created Bookmark to your Citrix NetScaler Unified Gateway. You will do this in your Unified Gateway vServer under Published Applications->URL

If you open your Unified Gateway and login you should the Office365 SaaS Application. As soon as you start the Application, you will see your Office356 Landingpage without entering any Credentials.

My name is Jens Trendelkamp. I currently work as an IT Consultant at sepago GmbH. My fields of specialty are Application Delivery, SBC\VDI Solutions and Enterprise Mobility based on Products from Microsoft and Citrix.

## NetScaler as a SAML IdP for Office 365

#### How-to configure Citrix NetScaler as a SAML Identity Provider for Microsoft Office 365

Since I got some spare time I thought it would be cool to upgrade my Lab Environment and add the SAML Identity Provider Role to my Citrix NetScaler so that my Microsoft Office365 Account would be able to authenticate against the Citrix NetScaler IdP.

Before we start this little how-to, I assume that you already got a Citrix NetScaler up and running. The same goes for your Microsoft Office365 Account and the sync of your Users between your On-Premise Active Directory and the Azure Active Directory. DirSync and Azure AD Connect are both fine. You will need a Citrix NetScaler AAA vServer or a Citrix NetScaler Gateway vServer which is public available through SSL and a SSL Certificate which is trusted by a public CA. Additional you need another SSL Certificate which will be used to sign the SAML Tokens. This Certificate can be self signed or you can use the same public Certificate which is used for the AAA / Gateway vServer. It´s up to you.

Let´s start with the Citrix NetScaler Part. First we create a AAA or Gateway vServer. Make it public available and bind the public SSL Certificate to the vServer. Because I’m quite limited on public IPs and it´s not possible to bind more than one VPN Server to a Content Switch, I am “forced” to use my NetScaler Unified Gateway.

We have to create an LDAP Server and an LDAP Policy. The important part here is that you have to set a Value for Attribute 1. With this setting the Mail Address will be extracted from LDAP Request, which is needed by Microsoft Office 365. My LDAP Server looks like this:

You also have to create a LDAP Policy and bind the created LDAP Server to it. Nothing fancy here

In the next step we will create the SAML IdP Profile. Go to Security -> AAA – Application Traffic -> Policies -> Authentication -> Basic Polices -> SAML IdP and switch to the Profiles Tab. You need to create a Profile like this:

The complete URL within Assertion Consumer Service URL is https://login.microsoftonline.com/login.srf. In the IDP Certificate Name you will have to choose your SSL Certificate with which you will sign your SAML Tokens. Make sure the Private Key for this Certificate is present on the NetScaler! The Issuer Name should represent the Public URL of your AAA / Gateway Server. https://aaa.fqdn.com/saml/ replace aaa.fqdn.com with your public AAA / Gateway vServer. The other Values should match the Screenshots.

Of course we have to create the corresponding Policy.

Because it´s possible to bind multiple SAML IdP Policies to one AAA / Gateway Server which most certainly have different settings, I do check the Referer if it matches the Microsoft Login Page. This way you are able to create different SAML Identity Provider for different Service Providers with only one AAA / Gateway. To end the NetScaler Configuration Part it is necessary to bind the LDAP Policy and the SAML IdP Policy to our vServer. Make sure the SAML IdP Policy has the lower Priority. Your AAA / Gateway vServer should look something like this:

We will now switch to the Microsoft Office365 Part. You need to open the Windows Azure Active Directory Modul for Windows Powershell. Connect to your Azure AD using the command Connect-MsolService. In Case your Domain is already Federated to have to undo this. You do this by set the Authentication back to Managed Set-MsolDomainAuthentication -DomainName domain.com -Authentication Managed. After that it is possible to Convert the Domain back to Standard with the following command Convert-MSOLDomainToStandard –DomainName domain.com -SkipUserConversion $false -PasswordFile c:\userpasswords.txt. For more Information please read this Microsoft Documentation We will set a few variables in the Powershell Session: •$url = “https://aaa.fqdn.com/saml/login”
• $uri = “https://aaa.fqdn.com /saml/login” •$ecpUrl = “https:// aaa.fqdn.com /saml/login”
• $dom = “fqdn.com” •$fedBrandName = “Company Name”
• $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“C:\pathtocertificate\certificate.cer”)$certData = [system.convert]::tobase64string($cert.rawdata) You will have to replace aaa.fqdn.com with the URL of you AAA / Gateway vServer. Now you have to run the following command to switch your Domain to use your SAML IdP Set-MsolDomainAuthentication -DomainName$dom -federationBrandName $fedBrandName -Authentication Federated -PassiveLogOnUri$url -SigningCertificate $certData -IssuerUri$uri -ActiveLogOnUri $ecpUrl -LogOffUri$url –PreferredAuthenticationProtocol SAMLP

After a few Moments the changes should have been applied and Microsoft Online will redirect you to your AAA / Gateway vServer for Authentication

Some Tips and Resources:

My name is Jens Trendelkamp. I currently work as an IT Consultant at sepago GmbH. My fields of specialty are Application Delivery, SBC\VDI Solutions and Enterprise Mobility based on Products from Microsoft and Citrix.

## Step By Step Guide to Single Sign-On to Storefront in Clientless Access Mode

While playing in my Lab with the Citrix NetScaler Unified Gateway I encountered the following problem. Within Clientless Access mode I could not access the Storefront Server. To be honest it wasn’t working at all.
Google Chrome showed me the following screen

While the Internet Explorer gave me at least an error.

Since the ICA Proxy Mode worked very well I started digging  Thanks to Maik Steppeler from Citrix who helped with the last missing piece of this jigsaw! I assume you have the NetScaler Gateway & the Storefront up and running. I assume also that you have everything configured till a point where “it should be working” 😉 If not please ping me.

At first we start on the Storefront Server(s). We navigate to the web.config file within your Webstore Folder. Something like this C:\inetpub\wwwroot\Citrix\YourStoreWeb.

You will find the followings entry three times:

If you are only using the Internet Explorer you have to change the Value within “<add name=”X-Frame-Options” value=”deny” />” from deny to allow. If you and your user are also using Chrome or FireFox you will also have to change <add name=”Content-Security-Policy” value=”frame-ancestors ‘none'” /> from none to self.

After editing it should look like this:

Now restart you IIS. Also make sure you enabled Remote Access in your Storefront Store.

We are now switching to the NetScaler. Within the NetScaler change to your Session Profile and enable “Single Sign-on to Web Applications” if this is not already enabled.

Go back to the Global Settings of the NetScaler Gateway and go to “Configure Domains for Clientless Access”

That’s it! If you now login and change to your Application section you will see your Applications published through Storefont without providing additional credentials!

My name is Jens Trendelkamp. I currently work as an IT Consultant at sepago GmbH. My fields of specialty are Application Delivery, SBC\VDI Solutions and Enterprise Mobility based on Products from Microsoft and Citrix.

## Multiple WorxMail Instances

There are several circumstances where you want to offer Multiple WorxMail Instances with preconfigured Application Settings. For example a WorxMail Version for your Microsoft Exchange Users and another Version for your Lotus Notes Users. If you just import a second Version of WorxMail in your AppController and only changing the Application Name you will experience some problems. With this hack you will be able to offer your Users preconfigured Multiple WorxMail Instances. But it is still not possible to use both Versions of this App on the same Device at the same Time. In this Case you will still get the usual behavior. This will work ofcourse with other WorksApps too, i.e. WorxWeb.

We will start with downloading the latest Version of WorxMail from Citrix. You have to wrap this .ipa as you are used to by using the Citrix MDX Toolkit. After you have your .mdx file you need to extract the policy_metadata.xml file from the .mdx. You need to do this because after we modified the .ipa the Citrix MDX Toolkit will not recognize the .ipa as WorxMail anymore.

Now to the fun part

Open the WorxMail.ipa file with WinZip or similar Tools and extract the PayLoad Folder somewhere where you will find it. Open the Folder and Right Click WorxMail.app. Open the app by selecting Show Package Content.

Here you need to find the Info.plist File and copy it to Location where you can edit it i.e. the Desktop. Open the File with your Favorite Editor and search for CFBundleIdentifier. Below this entry you will see <string>com.citrix.mail</string>. If you are editing WorxWeb this string will be named “com.citrix.browser

This Value needs to changed! If you want to deploy a second WorxMail Version for Example for Lotus Notes change the Value to com.citrix.maillotus. Save the Info.plist and copy the file back to the WorxMail.app File by using Drag&Drop. After that you can zip the Payload Folder again into WorxMail.ipa or just replace the Folder within the existing .ipa. Please be aware of the following fact; If you want to use the Update Function within the AppController when new Versions of WorxMail are available you need to edit the Info.plist again and replace the String with the same Value! If not it is not possible to update the App.

Now it is time to wrap your modified .ipa file as usual. Before you can Upload the .mdx file to your AppController you need to replace the policy_metadata.xml within the .mdx from the beginning. After that you can upload the .mdx to your AppController give the Application a Name and start testing.

My name is Jens Trendelkamp. I currently work as an IT Consultant at sepago GmbH. My fields of specialty are Application Delivery, SBC\VDI Solutions and Enterprise Mobility based on Products from Microsoft and Citrix.

## Automated Application Wrapping

If you are deploying and/or managing Citrix XenMobile Environments one small part of work you have to deal with is the Application Wrapping. If you do have to do this often because of new Application Versions or you have to wrap the Applications for multiple Customers you will be quite quickly annoyed by the Citrix MDX Toolkit GUI. Because of that (and because the GUI does not work on virtualized Macs running on Windows. Why does the GUI need OpenGL?! WindowServer: _CGXGLDisplayContextForDisplayDevice: No matching context for device – disabling OpenGL) i started to use to MDX Toolkit CLI. Since May the MDX Toolkit is very well documented!  XenMobile MDX Toolkit Documentation

But let´s get to the point. I created two little bash scripts for Automated Application Wrapping. One for iOS and one for Android.

#### Android Version:

######################################################################################################
# Purpose:
# Automatically wrap Android Applications for XenMobile
#
# Scriptname:
# Android-wrapping.sh
#
# $ScriptVersion = “0.000.0002 # # Comments: # # Prerequisites: # – Citrix MDXToolkit # – Java JDK 1.6 or 1.7 # – Android SDK 19.0.0 or later # – Valid User Generated Keystore # # Author(s): # Jens Trendelkamp, Jens.Trendelkamp@sepago.de, sepago GmbH # # Change history: # 21.05.2014, Jens Trendelkamp, Jens.Trendelkamp@sepago.de # – Initial version # 24.08.2014, Jens Trendelkamp, Jens.Trendelkamp@sepago.de # – Updated CLI Commands to work with the latest MDX Toolkit # ####################################################################################################### # # KEYSTORE = Keystore Path # ALIAS = Key Alias # STOREPASS = Keystore Password # KEYPASS = Private Key Password # APKDIR = Path to the unwrapped Android Applications ####################################################################################################### #!/bin/sh KEYSTORE=~/Keystore_path/appwrapping.keystore ALIAS=appwrapping STOREPASS=password KEYPASS=password APKDIR=/User/Jens/APKs APKS=ls -r$APKDIR/*.apk
rm -rf $APKDIR/wrapped && mkdir -p$APKDIR/wrapped

for i in $APKS ; do bname=basename -s .apk$i
java -jar -Xmx1024M /Applications/Citrix/MDXToolkit/ManagedAppUtility.jar wrap \
-in $i \ -keystore$KEYSTORE \
-keyalias $ALIAS \ -keypass$KEYPASS \
-storepass $STOREPASS \ -out$APKDIR/wrapped/$bname.mdx done #### iOS Version: ###################################################################################################### # Purpose: # Automatically wrap iOS Applications for XenMobile # # Scriptname: # iOS-wrapping.sh # #$ScriptVersion = “0.000.0002”
#
#
# Prerequisites:
# – Citrix MDXToolkit
# – Xcode 5.0+
# – Xcode Command Line Tools
# – Valid Certificate and Provisioning Profile
#
# Author(s):
# Jens Trendelkamp, Jens.Trendelkamp@sepago.de, sepago GmbH
#
# Change history:
# 21.05.2014, Jens Trendelkamp, Jens.Trendelkamp@sepago.de
# – Initial version
# 24.08.2014, Jens Trendelkamp, Jens.Trendelkamp@sepago.de
# – Updated CLI Commands to work with the latest MDX Toolkit
#
#######################################################################################################
#
# CERT = Name of the signing certificate
# PROFILE = Path to the Provisioning Profile
# IPADIR = Path to the unwrapped iOS Applications
#
#######################################################################################################
#!/bin/sh
CERT=”iPhone Distribution: some company”
PROFILE=/Users/Jens/provisioning_profile.mobileprovision

IPAS=ls -r $IPADIR/*.ipa rm -rf$IPADIR/wrapped && mkdir -p $IPADIR/wrapped for i in$IPAS ; do
bname=basename -s .ipa $i /Applications/Citrix/MDXToolkit/CGAppCLPrepTool Wrap \ -in$i \
-Cert “$CERT” \ -Profile$PROFILE \
-out $IPADIR/wrapped/$bname.mdx
done

If you modified the setting and start the script you will see something like this:

Of Course these bash scripts are pretty simple but it´s a good way to start using the MDX Toolkit CLI

My name is Jens Trendelkamp. I currently work as an IT Consultant at sepago GmbH. My fields of specialty are Application Delivery, SBC\VDI Solutions and Enterprise Mobility based on Products from Microsoft and Citrix.

## SSL Offloading / Content Switching with Citrix NetScaler and PRTG Network Monitor

A quick one. I tried to publish the PRTG Webinterface through a NetScaler using SSL Offload and Content Switching. While testing my setup with a Webbrowser it all seemed to worked fine. But as I tried the iOS Application from Paessler I run into the following problem.

PRTG iOS APP

Since there are two Knowledge Base articles from Paessler available how to use an IIS or Apache as a Reverse Proxy (Link 1 Link 2) and I could access the Webinterface with my Browser I was pretty sure I made a mistake somewhere.

So I connected my iPad to XCode and checked the Console Logfile while setting up My Account.

XCode Error Log

Content Switching Policy

The App is trying to access prtg.trendelkamp.net:443. This got me thinking. I checked my NetScaler Content Switching policy.
The policy says that the hostname needs to be the same as I configured, prtg.trendelkamp.net. And since the PRTG App adds the port at the end of the hostname there is no matching policy anymore. As soon as I changed the expression to HTTP.REQ.HOSTNAME.CONTAINS(“prtg.trendelkamp.net”) the App worked fine

My name is Jens Trendelkamp. I currently work as an IT Consultant at sepago GmbH. My fields of specialty are Application Delivery, SBC\VDI Solutions and Enterprise Mobility based on Products from Microsoft and Citrix.

## How to change/modify Android WorxApp Icons

Last week I explained how to modify WorxApp Icons on iOS Devices. This time I want to show you how to do this for the Android Apps since the necessary steps are slightly different.

For Android we need to decompile the .apk files before we can edit them. To accomplish this we need the apktool. You can download the tool here. After you finished installing the apktool we can directly start with decompiling the .apk file. In this example I moved the .apk to the same folder as the apktool and run the following command: ./apktool d applicationname.apk After the decompiling is finished you´ll find a new directory within your apktool folder.

Android WorxApp

In this folder you can edit the Icons as you wish. Since the .png for different resolutions are spread across several folders I searched for launcher which will show all relevant files. As you can see I spent a lot of time to customize the files 😉

Android WorxApp

After you are done you have to rebuild the .apk file. This will also be done by the apktool. You can start this process with the following command: ./apktool b applicationfolder applicationname.apk

Android WorxApp

Now you can wrap the newly created .apk as you are used to with the MDX Toolkit.

My name is Jens Trendelkamp. I currently work as an IT Consultant at sepago GmbH. My fields of specialty are Application Delivery, SBC\VDI Solutions and Enterprise Mobility based on Products from Microsoft and Citrix.

## How to change/modify iOS WorxApp Icons

I was asked how to modify the WorxApp Icons to match the Cooperate Identity Policy. To accomplish this you will need a Mac with XCode installed, an Image Editor like Gimp and of course the .ipa file you want to modify.

Let´s start with extracting the icons from the .ipa file. If you do this by simply extracting the images from the .ipa file you will get the following error in Gimp and similar Programs.

iOS WorxApp

This is absolutely normal since these Images have been optimized. To undo this we need to “uncrush” them. I found a nice script by Peter Boctor which “uncrushes” whole .ipa files. The script can be found here.

Start the script with the .ipa file you want to edit.

iOS WorxApp

After the script successful ended you will find a new folder named like the .ipa file and an Images at the end.

For a better overview I move the files i need to edit to a separate folder. Now you can now start to edit/replace the images as you wish.

iOS WorxApp

After we have finished editing or replacing the images we want to “crush” them again. Since I ‘am a lazy guy I created a little script which “crushes” a whole directory.

#!/bin/sh

for png in find $1 -name “*.png”; do echo “crushing$png”

pngcrush -rem allb -brute “$png” temp.png mv -f temp.png$png

done;

I also added the path to pngcrush binary to my Environment Variable

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/

iOS WorxApp

You´ll start the script with the following command: ./crush.sh foldername

iOS WorxApp

iOS WorxApp

Your folder (in my example it´s called “png”) now contains “crushed” .png files which need to be moved to your original .ipa file. To do this I extracted the WorxMail Application folder from the .ipa/Payload folder. After that I opened the WorxMail Package by clicking “Show Package Contents”. Copy the modified Icons from your folder to the WorxMail Package and make sure you replace the files.

iOS WorxApp

iOS WorxApp

Of course you need to put the WorxMail Application back to the .ipa file. In my case I used WinZip and simply dragged the file to the correct place.

iOS WorxApp

Now it´s time to wrap the app as usual with the MDX Toolkit and upload it to your AppController. If all worked well you can now install/update the customized app which hopefully looks better than mine J

iOS WorxApp

My name is Jens Trendelkamp. I currently work as an IT Consultant at sepago GmbH. My fields of specialty are Application Delivery, SBC\VDI Solutions and Enterprise Mobility based on Products from Microsoft and Citrix.

## How to deploy WorxMail and WorxWeb for Windows Phone 8.1

While upgrading our sepago XenMobile Environment to support WorxMail and WorxWeb for Windows Phone 8.1 i thought to write a blog post about this since its not easy to find all needed informations.

– You will need a Microsoft Developer Account. Register here http://dev.windows.com/

– A Symantec Enterprise Mobile Code Signing Certificate is required. This can be orderd athttps://products.websecurity.symantec.com/orders/enrollment/microsoftCert.do You can find your Symantec-Publisher-ID within your Microsoft  Developer Account. Navigate to the Windows Phone Store Dashboard –> Account. Here should your Symantecd-ID be listed. After the ordering process is finished and you followed the instructions provided within the mails you will receive a *.pfx certificate.

– A Windows 8.1 64-bit computer is needed. Also .NET 4.5, Silverlight 5 Runtime, SDK and at least Visual Studio Express 2013 have to be installed.

– The following files from your MyCitrix Account have to be downloaded – MDX Toolkit for Windows Phone 8.1, WorxMail for Windows Phone 8.1 v9, WorxWeb for Windows Phone 8.1 v9 and Worx Home for Windows Phone 8.1 v9

– And of course a fully working XenMobile v9 Enterprise Environment.

If the prerequisites are complete we can finally start doing things

– At first we create a *.aetx file. This one is needed to configure the Windows Phone Enterprise Hub Policy within the Device Management. We need to open the Visual Studio Command Line as an Administrator. We navigate to C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.1\Tools\AETGenerator and excute the following command “AetGenerator.exe “c:\Path\to\your\Symantec\Certificate.pfx” passwordforyourcertificate”. You should now find tree new files in the AETGenerator Directory. We only need the AET.aetx file.

– To create the Windows Phone Enterprise Hub Policy we also need to wrap the WorxHome App. We will stay in our Visual Studio Command Line an navigate to the Directory where the MDX Toolkit for Windows Phone 8.1 is located. Here we create two new Directorys. One for our unsigned apps and one for signed apps. You should put the three downloaded Apps from Citrix to the unsigned folder. To wrap the WorxHome App we will execute the following command:

The phonePulisherId can be found within the Microsoft Developer Account: Login and navigate to Windows Phone Store Dashboard –> Account.

– Now we can create our Windows Phone Enterprise Hub Policy. Login with your Adminstrator Account to your MDM Server and create a new Windows Phone 8.x Enterprise Hub Policy. Enter a Name and if you want a Comment and upload the created AET.aetx und your wrapped WorxHome.xap file. Don´t forget to add the created Policy to a Deployment Package

– To use WorxMail and WorxWeb we also have to wrap them. But the command is this time a bit different since we have to add the MDX Policies. Within the Visual Studio CL we execute the following command for WorxMail

and for WorxWeb

Make sure you copy the *.mdx file to a save place after you created them. With each new wrapping process the Preptool will emtpy the signed folder. You can upload both Apps now to your AppController and configure the MDX Policies as u used to.

– Finally you can enroll your Windows Phone. Citrix published a very nice Blog Article how to do thishttp://blogs.citrix.com/2014/07/03/windows-phone-8-1-device-enrollment-process-xenmobile-9-0/. But other mentioned in the Citrix Blog Auto Discover is not needed for this. We are the living proof