Integrate Azure MFA with NetScaler Gateway for Two-Factor Authentication


The Network Policy Server (NPS) extension for Azure MFA adds cloud-based MFA capabilities to your authentication infrastructure using your existing servers. With the NPS extension, you can add phone call, text message, or phone app verification to your existing authentication flow without having to install, configure, and maintain new servers. 

This extension was created for organizations that want to protect VPN connections without deploying the Azure MFA Server. The NPS extension acts as an adapter between RADIUS and cloud-based Azure MFA to provide a second factor of authentication for federated or synced users.

When using the NPS extension for Azure MFA, the authentication flow includes the following components: 

  1. NetScaler receives requests from VPN clients or Citrix ICA Proxy users and converts them into RADIUS requests to NPS servers. 
  2. NPS Server connects to Active Directory to perform the primary authentication for the RADIUS requests and, upon success, passes the request to any installed extensions.  
  3. NPS Extension triggers a request to Azure MFA for the secondary authentication. Once the extension receives the response, and if the MFA challenge succeeds, it completes the authentication request by providing the NPS server with security tokens that include an MFA claim, issued by Azure STS.  
  4. Azure MFA communicates with Azure Active Directory to retrieve the user’s details and performs the secondary authentication using a verification method configured to the user.

Pre-Requisites

There are some requirements that are needed to be met for deploying this solution.

Licenses

The NPS Extension for Azure MFA is available to customers with licenses for Azure Multi-Factor Authentication (included with Azure AD Premium, EMS, or an MFA stand-alone license). Consumption-based licenses for Azure MFA such as per user or per authentication licenses are not compatible with the NPS extension.

Libraries

These libraries are installed automatically with the extension.

The Microsoft Azure Active Directory Module for Windows PowerShell is installed, if it is not already present, through a configuration script you run as part of the setup process. There is no need to install this module ahead of time if it is not already installed.

Azure Active Directory

Everyone using the NPS extension must be synced to Azure Active Directory using Azure AD Connect, and must be registered for MFA.

When you install the extension, you need the directory ID and admin credentials for your Azure AD tenant. You can find your directory ID in the Azure portal. Sign in as an administrator. Search for and select the Azure Active Directory, then select Properties. Copy the GUID in the Directory ID box and save it. You use this GUID as the tenant ID when you install the NPS extension.

Network requirements

The NPS server needs to be able to communicate with the following URLs over ports 80 and 443.

Additionally, connectivity to the following URLs is required to complete the setup of the adapter using the provided PowerShell script

Sync domain users to the cloud

This step may already be complete on your tenant, but it’s good to double-check that Azure AD Connect has synchronized your databases recently.

  1. Sign in to the Azure portal as an administrator.
  2. Select Azure Active Directory > Azure AD Connect
  3. Verify that your sync status is Enabled and that your last sync was less than an hour ago.

Determine which authentication methods your users can use

There are two factors that affect which authentication methods are available with an NPS extension deployment:

  1. The password encryption algorithm used between the RADIUS client (VPN, Netscaler server, or other) and the NPS servers.
    • PAP supports all the authentication methods of Azure MFA in the cloud: phone call, one-way text message, mobile app notification, OATH hardware tokens, and mobile app verification code.
    • CHAPV2 and EAP support phone call and mobile app notification.
  1. The input methods that the client application such as VPN, Netscaler, or others can handle. For example, does the VPN client have some means to allow the user to type in a verification code from a text or mobile app?

Register users for MFA

Before you deploy and use the NPS extension, users that are required to perform two-step verification need to be registered for MFA. More immediately, to test the extension as you deploy it, you need at least one test account that is fully registered for Multi-Factor Authentication.

Use these steps to get a test account started:

  1. Sign in to https://aka.ms/mfasetup with a test account.
  2. Follow the prompts to set up a verification method.
  3. Create a Conditional Access policy to require multi-factor authentication for the test account.

Important!

Make sure that users have successfully registered for Azure Multi-Factor Authentication. If users have previously only registered for self-service password reset (SSPR), StrongAuthenticationMethods is enabled for their account. Azure Multi-Factor Authentication is enforced when StrongAuthenticationMethods is configured, even if the user only registered for SSPR.

Combined security registration can be enabled that configures SSPR and Azure Multi-Factor Authentication at the same time. For more information, see Enable combined security information registration in Azure Active Directory.

You can also force users to re-register authentication methods if they previously only enabled SSPR.

Installing Network Policy Server Role

Install the Network Policy Server role in your environment. You can choose to install this on any domain joined Server OS machine in the network.

Ideally, you would want to sit close to your Active Directory server just to make it quicker to send traffic for Authentication and Authorization. Or Just install this straight on your AD server, it’s totally up to you.

Installing the NPS role is dead easy. Just fire up your Server Manager and go to Manage – Add Roles and Features. Select Network Policy and Access Services

It will ask you to install Remote Server Administration Tools. Say Add Features.

Click Next (3 times) until you reach the Confirmation page. Click Install

  • Once installed, you will need to register the server in Active Directory.
  • Open the NPS console as below and right click the NPS node and click Register Server in Active Directory

Now it’s time to install the NPS extension for Azure.

Installing and Configuring NPS Extension for Azure MFA

Stop!

1) Before you proceed with this step, you will need to have the Azure Administrator account handy.
2) Ensure that NPS server could access the internet to the URLs specified in section Network Requirements
  • Once downloaded, run the NpsExtnForAzureMfaInstaller.exe as an Administrator. If you want to change the install location, Click Options and choose a different location.
  • if not, just Click Install
  • The setup is quick. Click Close, once finishes.
  • Open PowerShell as Administrator. You have to have your Azure Portal admin credentials handy before this step.
  • Navigate to the install location for NPS Extension C:\Program Files\Microsoft\AzureMfa\Config using PowerShell.
  • Run the Powershell script in that directory AzureMfaNpsExtnConfigSetup.ps1 as below
  • PowerShell will begin the installation of NuGet provider assemblies including MSOnline cmdlets
  • It’s gonna tell you that you are installing this from an untrusted repository. Just say A for Yes to All and continue.
  • Now, PowerShell will take you to portal.azure.com where you will need your Azure AD admin credentials to login.
  • Login with your Azure credentials
  • At this stage, it will ask for the Tenant ID. Copy the Directory ID and paste it in the PS window

It does a few things as below

## It creates a Self-Signed certificate

## It grants private key access to NETWORK SERVICE

## Restarts the NPS Policy Service

You may now exit out of PowerShell as it is time to configure NPS.

Configure NPS

Configure RADIUS Clients

  • Open the NPS console and navigate to RADIUS Clients and Server Folder
  • Expand the folder and Right Click on RADIUS Clients
  • Select New
  • Configure the settings as below
    • Give it a Friendly Name
    • Enter the IP address of the NetScaler (NSIP)
    • Enter a Shared Secret Key (Save this key as we will need this later)
    • Click Ok

Add all the RADIUS clients following the steps above. If you set this up on a NetScaler HA configuration, you will have 2 NetScaler NSIPs to add. You should something similar as follows.

Configure Remote RADIUS Servers

  • Select the node – Remote RADIUS Server Groups
  • Right- click and select New
    • Give a Group Name
    • Click Add
  • Type the IP address or name of the Active Directory Domain Controller Server in there and Click OK.

Tip!

The AD server is required to be added for the Remote RADIUS node. This is where the RADIUS/NPS server triggers the first step of authentication and will be passed on to the AD server for validating the LDAP credentials. If you add the NPS server details in here, it will NOT work!

You can choose to add the FQDN of the domain controller or just use the IP address. You can multiple DCs in here for redundancy.

  • Click on the Authentication/Accounting tab. Configure it as below
  • Click on the Load Balancing tab now and supply the weightage to the servers if you are adding multiple AD servers.
  • You can also configure the Timeout settings in here.

Notice that I have increased the timeout values to 60. This is important when using phone calls and SMS based authentication because they take more time. Even when using the Microsoft Authenticator app, default values are a little too less, so adjust it according to your environment.

Add all the servers that you intend to use as Domain Controllers in here.

Configure Connection Request Policies

It is time now to create a Connection Request Policy. We need a couple of them for this deployment. There are a few things to keep in mind as follows before we proceed to create the policies.

  • The default built-in connection request policy uses NPS as a RADIUS server and processes all authentication requests locally.
  • To configure a server running NPS to act as a RADIUS proxy and forward connection requests to other NPS or RADIUS servers, you must configure a remote RADIUS server group in addition to adding a new connection request policy that specifies conditions and settings that the connection requests must match.
  • If you do not want the NPS to act as a RADIUS server and process connection requests locally, you can delete the default connection request policy.
  • If you want the NPS to act as both a RADIUS server, processing connection requests locally, and as a RADIUS proxy, forwarding some connection requests to a remote RADIUS server group, add a new policy using the following procedure and then verify that the default connection request policy is the last policy processed by placing it last in the list of policies. This is the approach we are using for NetScaler deployment.

Create a Connection Request Policy for No Forward

  • Open the NPS server console and expand Policies node
  • Right Click Connection Request Policies and choose New
  • Give the policy a Name
  • Click Next
  • Click Add
  • Select Client IPv4 Address
  • Click Add again
  • Specify the Client IP v4 Addresses – This will be the NetScaler NSIP if RADIUS isnt load balanced. If load balanced, you must use the Subnet IP of the NetScaler (SNIP)
  • Click Next
  • Configure Authentication as below
  • Click Next

  • Configure the Authentication exactly as below
  • Click Next a couple of times until the Summary page is reached.

Create the second Connection Request Policy for Forwarding

  • Right Click Connection Request Policies and choose New
  • Give the policy a Name
  • Click Next
  • Click Add
  • Select NAS Identifier
  • Click Add again
  • Enter the name of the NAS Identifier – MFA
  • Click OK
  • click Next
  • Configure the Authentication as below – MS-CHAP-v2
Inserting image...
  • Click Next
  • If you are on the Summary page, click Finish

The two connection request policies should be moved up in the policy priority order and should look like the below.

Create the Network Policy

  • Go to the Network Policies node
  • Right Click and select New
  • Give the policy a Name
  • Click Next
  • Click Add
  • Select NAS Identifier
  • Enter MFA in there
  • Click Add again

  • Click Next
  • Select Access Granted

  • Click Next
  • Configure the Authentication methods as below
  • a few more extra clicks will get you to the Summary page.
  • Click Finish on the Summary page.
  • Make the policy that we just created higher up in the order.
  • Disable the existing or built-in Network policies.
  • Disable the existing Network Policies (Default) 
  • Move the new Network Policy to the top and assign it priority 1

Repeat the above steps on all the other NPS servers that you have in the deployment. 

NetScaler Configuration

You can now proceed to create your vServer in NetScaler. It could be a NetScaler Gateway or a VPN vServer. In this post, i will not be showing how to create a NetScaler vServer. It is fairly straightforward and there are tons of blog posts on it on the internet. You will just need to set eveything up just like how you would setup a single factor Gateway portal in NetScaler.

  • You will need to make sure that ports 1812 and 1813 are open from the NetScaler to the backend NPS server (bi-directional)
  • If you have multiple subnet IPs on the NetScaler, use a Net profile to isolate traffic to a particular source IP address.
  • If you aren’t load balancing NetScaler, NSIPs are the source IP address. Otherwise SNIPs will need to be used. (The client IPv4 address entries that you made in the previous step will change accordingly)

Create RADIUS Policies and Profiles

  • Go to NetScaler Gateway node – Policies – Authentication – RADIUS
  • Go to Servers tab and click Add
  • Give a name to the Server profile
  • Enter the IP address of the NPS server
  • Port is 1812
  • Enter the Shared Secret Key
  • Change the time out to 60 seconds if you intend to use phone calls, SMS or phone app auth.
  • Test the connection and ensure that you get all green
  • Click More
  • Enter the NAS ID here – MFA
  • Password encoding as mschapv2
  • Click Create
  • Similarly, create additional RADIUS servers using the same steps above.

Create RADIUS policies now to attach the RADIUS server profiles so that it could be bound to vServers.

  • Create a RADIUS policy and attach the profile as below

Once, your vServer is ready, the RADIUS policy could be attached to the vServer as a primary authentication. Doing this will still perform Active Directory LDAP authentication after which the NPS extension will check the second factor authentication.

You can now test with an account that is MFA enabled. If everything is setup correctly, MFA will work fine and prompt with a second factor.

Troubleshooting

  • Always check the Authentication server status of RADIUS server in NetScaler. It should be green when the traffic is allowed. if it is not, check why? Work with your NW team to figure out why the traffic doesnt reach the NPS backend or being returned back.
  • Add a DNS A record entry for the Remote URL for Citrix access
  • If the NetScaler IPs (NSIP) don’t work, try the Subnet IP as RADIUS clients. If you make a change, ensure that the change is reflected in the Network Policies too.
  • On NetScalers where multiple subnet IPs are used, isolate the traffic using NET Profiles.
  • Check aaad.debug logs on NetScaler.
    • if you get the below, it is mosty likely an issue with the RADIUS client IPs. It is just that the wrong IP is being used.

No valid RADIUS responses received.

Rejecting with error code 4004

  • Look out for Routing issues. If your NPS servers are sitting in a different subnet as compared to NetScaler IPs, looking at the Route table could shed some light. If routes are missing, add them. But please remember not to break existing traffic. If unsure, ask the network guy for assistance.
  • Check the Dial-In tab in AD properties for the user. Ensure that the user is allowed access. Or You can configure NPS to override the AD settings by setting the below (look for the red dot below)
  • Use the Health Check tool for Azure MFA
  • Event Logging – Ensure that NPS logs are turned ON. Log files will be found at C:\Windows\System32\LogFiles. Make sure that the logs are set to DTS compliant. Event Viewer is also a reliable source.
  • If you don’t want to limit non-MFA users from accessing the portal, you can add the below registry keys to the NPS servers. This will allow users who aren’t registered in Azure MFA to continue to authenticate using LDAP authentication. This is vital during migration phase. However, this setting must be removed before you move into production.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa
REG_SZ=REQUIRE_USER_MATCH
Value=FALSE

Hope this helps! Please feel free to comment or provide feedback.

Desktop Restart – Citrix Storefront Power Management


If you have noticed the Restart button for published desktops in Citrix Virtual Apps and Desktops 7 1912 LTSR recently and wondered why in the world Citrix would give users access to users to restart machines, you are not alone. Make no mistake, this is a perfectly fine setting to be enabled out-of-the-box for VDI deployments where just Desktop OSes are being published or on the delivery group that contains Desktop OSes. You would want your users to be able to restart the desktop every now and then anyway.

Now after going through the Citrix SDK documentation, I found the below notes for the -AllowRestart argument that governs the restart button.

AllowRestart (System.Boolean) Indicates if the user can restart sessions delivered from the rule’s desktop group. Session restart is handled as follows: For sessions on single-session power-managed machines, the machine is powered off, and a new session launch request made; for sessions on multi-session machines, a logoff request is issued to the session, and a new session launch request made; otherwise the property is ignored.

So, it isn’t too bad to have that button available for RDSH delivery groups but should probably be called something else. The name “restart” has a negative vibe to it in multi-session world. lol

The option\button will appear like the below.

How would you remove the Restart option?

You will need to do this via Powershell.

asnp citrix*
Get-BrokerAccessPolicyRule

Find the delivery group that has RDSH based published desktops and take a note of the Name parameter. You can do this on all the delivery groups if you want to disable this button for all published desktops, both RDSH and VDI.

Run the below command to find the value for the delivery group that you want to turn OFF the setting for. The parameter we are looking for is AllowRestart. When the value is True, Restart button is shown. Setting it to False will remove the button from Storefront.

Get-BrokerAccessPolicyRule -Name "XA-W2K16-DG-CORE_Direct_1"

Now, run the below command to turn off the Restart button

Set-BrokerAccessPolicyRule -Name "XA-W2K16-DG-CORE_Direct_1" -AllowRestart $False

You may need to do this for the AG version and Direct version of the delivery group.

Direct Version
Access Gateway version

Refresh the Storefront page via gateway and internally to see the results.

That’s all to it folks. Have a good one!

Configure RDP Proxy in NetScaler


The RDP Proxy functionality is provided as part of the Citrix Gateway and currently is available to all NetScaler Enterprise and Platinum customers.

The following RDP Proxy features provide access to a remote desktop farm or an RDSH session host server through Citrix Gateway:

  • Secure RDP traffic through CVPN or ICAProxy mode (without Full Tunnel).
  • Single sign-on (SSO) to RDP servers through Citrix Gateway. Also provides an option to disable SSO if needed).
  • Enforcement (SmartAccess) feature, where Citrix ADC administrators can disable certain RDP capabilities through Citrix Gateway configuration.
  • Single/Stateless(Dual)  Gateway solution for all needs (VPN/ICA/RDP/Citrix Endpoint Management).
  • Compatibility with native Windows MSTSC client for RDP without the need for any custom clients.
  • Use of existing Microsoft-provided RDP client on MACOSX, iOS, and Android.

Firewall Ports

RDP proxy requires port 3389 to be opened from the internet. You could also choose to use other port numbers if you don’t want to use the 3389 port. In a nutshell, just opening 443 port isn’t enough to get this to work.

Initial Configuration

Now to get started, we will need to enable RDP proxy feature if it isn’t turned ON. For that, navigate to SystemSettingsConfigure Advanced Features and ensure that RDP proxy is turned ON. if not, tick the box to Turn ON RDP proxy feature. You will need NetScaler Enterprise and above for this feature to work.

Create LDAP Profile and Policy

Create an LDAP profile for authentication. Navigate to NetScaler Gateway – Policies – Authentication – LDAP

Click on the Servers tab and click Add. Enter the required details such as AD server IP address, port details and a service account. For those who haven’t done this before, here is a helpful link from Citrix. It’s dead easy to set this up. https://docs.citrix.com/en-us/citrix-gateway/12-1/authentication-authorization/configure-ldap/ng-ldap-authen-configure-tsk.html If you have any questions, just pop it in the comments window and I will respond when I see them.

Now create the LDAP policy. Click on the Policies tab, click Add. Enter the entries as shown in the picture below. Ensure that the correct LDAP profile is selected.

Create the RDP Client Profile

Navigate to NetScaler Gateway – Policies – RDP Profiles and Connections – Client Profiles

Click Add

Give it a name such as RDProxy_Profile and leave the rest of the values default if you would like. I changed the RDP Cookie Validity from 60 sec to 120 seconds

Click OK

Create an RDP Server Profile

Create an RDP Server Profile. Click on the first tab that says Server Profile

Click Add and enter a name for the server profile. Enter the IP address (this is the IP address of the RDP Proxy Virtual Server that you will configure under the NetScaler Gateway). Enter the port number – You can choose to go with the default RDP port if you wish to or choose another one

Click OK

Create a Session Profile

Now, go to NetScaler Gateway – Policies – Session – Session Profiles. Click Add

Give the profile a Name

No changes under the Network Configuration tab. Leave everything as default there

Under Client Experience tab, change Clientless Access to ON and tick Single Sign-on to Web Applications and Credential Index to Primary. the last setting is turning ON Single Sign-on with Windows

Under the Security Tab, select Default Authorization to ALLOW and Secure Browse to ENABLED

Under Published Applications, set ICA PROXY to OFF

Under the Remote Desktop tab, pick the RDP Client profile that was created in the previous step

Click Create

Create a Session Policy

Now create a Session Policy that will be bound to the NetScaler Virtual Server. Remember that we haven’t created the virtual server yet.

Switch to Session Policies tab and click Add. Give the session policy a Name and pick the session profile that we just created in the previous step.

Create a Bookmark

Now create a Bookmark and this is what will appear to the users in the form of an application icon to click on.

Give a Name to the bookmark and enter the name of the string that you want to be displayed in the portal. Enter the Bookmark link in the format rdp://IPaddressOfTheBackendRDSServer

Click Create

Create the Gateway Virtual Server

Let’s create the Gateway Virtual server next. Navigate to NetScaler Gateway node, expand that and under Virtual Servers, click Add

Under Basic Settings, configure the below items

  • Name – RDPProxy_rdpproxy.fqdn.co.nz
  • IP Address type – IP Address
  • IP Address – X.X.X.X
  • Port – 443
  • Pick the RDP Server Profile – RDP Server Profile
  • Ensure that Enable Authentication, AppFlow Logging and State is turned ON
  • Disable ICA Only

Click OK

Attach a Server Certificate. The certificate can be a wild card cert or you could choose to get a named certificate that matches the external RDP proxy FQDN

Now bind the Primary authentication policy. We are going to use LDAP and hence I will use LDAP policy that we created in the steps above.

Under SSL Parameters, ensure that only TLS1.2 is turned ON for enhancing the security of client connections.

You can choose to go with the default SSL ciphers or modify the ciphers according to the company requirements.

Under Portal theme, I went with RfWebUI which I think is one of the cleanest UIs. You could choose to create a custom one and use that instead.

Under Published Applications, choose the URL Name and select RDP Link (this is the bookmark link that was created)

Under Policies, attach the Session Policy named RDP Session Policy

Click Create

Testing the Setup

Selecting the RfWebUI gives the below logon page and users could simply use their domain user name and password to log in. They don’t need to enter the domain name.

Upon login, you will be shown the Favorites page where you could add links for quick access. This is very similar to the subscriptions in Storefront.

Click on the Desktops tab and you will be able to see all the published Bookmarks there. I have one in there, you can choose to have any number of bookmarks.

Click on the RDP link to launch the application. It will first download the app.rdp file which could be used to launch the application. You will just need to give the users access to the servers locally by adding them to the Remote Desktop Users group or you could choose to do this via AD domain groups to manage it centrally.

How to verify that NetScaler COOKIEINSERT persistent sessions are working?


Ever had issues with your Storefront load balancing setup not working after painstakingly setting up NetScaler load balancing?

Now, let’s discuss a few reasons why cookie based persistence are better (in some scenarios) compared to Source-IP based persistence.

In some circumstances, using persistence based on source IP address can overload your servers. All requests to a single Web site or application are routed through the single gateway to the NetScaler appliance, even though they are then redirected to multiple locations. In multiple proxy environments, client requests frequently have different source IP addresses even when they are sent from the same client, resulting in rapid multiplication of persistence sessions where a single session should be created. This issue is called the “Mega Proxy problem.” You can use HTTP cookie-based persistence instead of Source IP-based persistence to prevent this from happening.

If all incoming traffic comes from behind a Network Address Translation (NAT) device or proxy, the traffic appears to the NetScaler appliance to come from a single source IP address. This prevents Source IP persistence from functioning properly. Where this is the case, you must select a different persistence type.

HTTP Cookie Persistence

When HTTP cookie persistence is configured, the NetScaler appliance sets a cookie in the HTTP headers of the initial client request. The cookie contains the IP address and port of the service selected by the load balancing algorithm. As with any HTTP connection, the client then includes that cookie with any subsequent requests.

When the NetScaler appliance detects the cookie, it forwards the request to the service IP and port in the cookie, maintaining persistence for the connection. You can use this type of persistence with virtual servers of type HTTP or HTTPS. This persistence type does not consume any appliance resources and therefore can accommodate an unlimited number of persistent clients.

Note: If the client’s Web browser is configured to refuse cookies, HTTP cookie-based persistence will not work. It might be advisable to configure a cookie check on the Web site, and warn clients that do not appear to be storing cookies properly that they will need to enable cookies for the Web site if they want to use it.

By default, the NetScaler appliance sets HTTP version 0 cookies for maximum compatibility with client browsers. (Only certain HTTP proxies understand version 1 cookies; most commonly used browsers do not.) You can configure the appliance to set HTTP version 1 cookies, for compliance with RFC2109. For HTTP version 0 cookies, the appliance inserts the cookie expiration date and time as an absolute Coordinated Universal Time (GMT). It calculates this value as the sum of the current GMT time on the appliance and the time-out value. For HTTP version 1 cookies, the appliance inserts a relative expiration time by setting the “Max-Age” attribute of the HTTP cookie. In this case, the client’s browser calculates the actual expiration time.

So some of the benefits of using cookie based persistence are

  • Easy to configure
  • Load balancer does all the work without involving the back end services (mostly a web server)
  • No connection table to maintain
  • Activity based – Time out is based on idle connection and not the total connection time
  • caters to most of the load balancing scenarios
  • if proxies are involved in the setup where source IPs are masked, this makes it an easy choice

Cons of Cookie based persistence

  • can throw off the load balancing where timeouts are set to 0 or when time outs are long lived
  • when Type 0 cookie is used, time of the cookie value is absolute(GMT time). When type 1 is used, relative time is used (local time)
  • hard to troubleshoot

Testing COOKIEINSERT persistence

Use Putty or some other SSH clients to login to the NetScaler.

sh lb vserver vservername

If you take a closer look at the snippet above, the letters in yellow shows that COOKIEINSERT persistence is turned ON with a time out value of 0 mins. This means that the cookies doesn’t have an expiry time set by the NetScaler appliance. The backup persistence is set to SourceIP with a time out value of 60mins. You can also see the cookie values at the bottom of the results staring with NSC_xxxxxxx

You will now need to get into Shell with an account that has permissions. To get to shell, type shell and hit enter

Now type the following

nsconmsg -i vservername -s ConLb=1 -d oldconmsg

In the snippet above, the highlighted text in yellow shows that persistence is set to Cookieinsert and the number of hits for each service. You will also get values such as response times, CPU and memory utilization.

VIP value shows the total number of hits to the vServer hits
Each service has a line starting with S (IP Address) and its status.
Hits (x, x/sec) shows the initial (method) hits to the service for a new connection.
P (x, x/sec) shows hits to the service that are served using a persistence cookie

Also, check the current persistent session via the commands below

sh persistentsessions
sh persistentsessions -summary

The curious case of NetScaler access with error message ” The Connection to “Desktop” failed with status (Unknown client error 1110)”


I was pulled into to look at a problem for one of our customers with their Netscalers which stopped the user connections intermittently throwing a very “helpful” error message ” the connection to the desktop failed with status (unknown client error 1110).

The customer description was “it only started to happen a few weeks ago and these days it’s quite impossible to land a successful connection from the outside of our corporate network.”

I managed to get a couple of screenshots of error messages from the users and they appeared like below. When queried, the internal access via Storefront is working fine.

image001

Looking at the error message, there are a multitude of reasons why you would get that, and I am outlining the common areas to check in such cases.

  • Check if the Root certificates and intermediate certificates are available on the client devices. If frequently patched, the client will most probably have the latest and update Root CA’s from various public CAs. Check the IE’s / Other browsers’ certificate store to verify the Root and Intermediate CA SSL certs
  • If using non-IE browsers for connectivity, switch over to IE to see if it connects. IE is the safest bet when it comes to connectivity to Citrix environments.
  • Check for SSL ciphers attached to the NetScaler Gateway vServer. If high security ciphers are used, this issue may occur. Relax the cipher suites to see if that makes a difference. Again, if cipher suites are an issue, the problem will occur every single time when you connect and not sporadically.
  • Check the STAs on the NetScaler and ensure that it matches with the STAs configured on the  WI/Storefront. This is one of the most critical setting to check and probably the first one to check if the issue occurs only sporadically. There is a high possibility of an STA mismatch as it turned out to be in my case.
  • Check the FW from the NetScaler to the VDA – As the title says ensure that the Citrix ports to the VDA are open from the Netscaler