Wednesday, June 15, 2016

Attempting to add NetScaler device to Citrix Command Center fails with: “Discovery failed for | Error: Unable to Ping using SNMP after enabling SNMP”

Problem

You’ve just completed deploying Citrix Command Center 5.2 45.4 and attempt to add your NetScaler pair to the device list but the process fails with the following error:

Discovery failed for <NSIP>

Error: Unable to Ping using SNMP after enabling SNMP

image

image

image

Solution

One of the reasons why this error would be thrown is if the Citrix Command Center server is unable to access the NetScaler via UDP Port 161 as shown in the following firewall log capture:

image

To correct the issue, simply allow UDP port 161 from the Citrix Command Center to the NetScaler and initiate the add device process again:

image

Tuesday, June 14, 2016

Workaround for addressing display size when connecting to VMware Horizon View desktops with 3K or 4K devices

One of the frequent issues I’ve noticed the clients I work are coming across is the use of devices that have 3K or 4K resolution. These devices look great when running the native operating system but render connections to VMware Horizon View desktops unusable due to the small display size of the virtual desktop. Most administrators who have come across this issue most likely would have made an attempt to change the DPI of the virtual desktop only to find that the configuration screen is locked:

image

The way I got around this with my 3K display Mac a few years ago was to simply change the Windows virtual desktop resolution back to a lower setting then connect to the VDI but this defeats the purpose of having a high resolution display. Fast forward to a few years later when a client asked me to look into this again, it looks like VMware has included an experimental (unsupported) registry key addition for VMware Horizon View Client 3.4 or newer that allows DPI scaling so that the display is sized appropriately to the 3K or 4K device connecting to the desktop.

I’ve noticed that there appears to be several places where this registry key should be added depending on the operating system so I’ve included the 3 paths to check:

32-Bit Operating System:

HKCU\Software\VMware, Inc.\VMware VDM\Client

REG ADD "HKCU\Software\VMware, Inc.\VMware VDM\Client" /v EnableSessionDPIScaling /t REG_DWORD /d 1

64-Bit Operating System:

HKCU\Software\Wow6432Node\VMware, Inc.\VMware VDM\Client\

REG ADD "HKCU\Software\Wow6432Node\VMware, Inc.\VMware VDM\Client\" /v EnableSessionDPIScaling /t REG_DWORD /d 1

Surface Pro 3 64-Bit Operating System:

HKCU\Software\Policies\VMware, Inc.\VMware VDM\Client

REG ADD "HKCU\Software\Policies\VMware, Inc.\VMware VDM\Client" /v EnableSessionDPIScaling /t REG_DWORD /d 1

-------------------------------------------------------------------------------------------------------------------------------------------------------------

Hope this helps anyone who may be experiencing this issue.

Thursday, June 9, 2016

Securing Citrix NetScaler VPX to score A+ rating on SSL Labs

I’ve received quite a few requests from clients over the past few months requesting to secure their NetScaler published services to score an A+ on Qualys SSL Labs:

https://www.ssllabs.com/ssltest/

I’m a bit late to writing this blog post as there are plenty of other excellent posts that demonstrate the process so in an effort to add a bit more value to the community, this post will demonstrate the process on a NetScaler VPX NS11.0 63.16.nc via the command line.

Without any additional configuration, NetScaler published services such as Citrix XenApp/XenDesktop typically scores a C:

image

Note that the following vulnerabilities exist as shown in the screenshot above:

  • SSL 3 enabled
  • No support for TLS 1.2
  • Server accepts RC4 cipher, but only with older protocol versions
  • Server does not support Forward Secrecy with the reference browsers

Step #1 – Turn off SSLv3 and enable TLSv11 + TLSv12

The first step is to turn off SSLv3 and enable TLSv11 and TLSv12 on your Load Balancing Virtual Server(s) and NetScaler Gateway Virtual Servers.

The following screenshots shows where the settings are in the GUI for the Load Balancing Virtual Server named StoreFront-lbvip:

image

image

The command to execute are as follows:

set ssl vserver StoreFront-lbvip -ssl3 disabled

set ssl vserver StoreFront-lbvip -tls11 enabled

set ssl vserver StoreFront-lbvip -tls12 enabled

image

With the commands above executed, the protocols should now be displayed as such:

image

Repeat the same process for the NetScaler Gateway Virtual Servers.

The following screenshots shows where the settings are in the GUI for the NetScaler Gateway Virtual Servers named www.contoso.com_external and www.contoso.com_internal :

image

image

The command to execute are as follows:

set ssl vserver www.contoso.com_external -ssl3 disabled

set ssl vserver www.contoso.com_external -tls11 enabled

set ssl vserver www.contoso.com_external -tls12 enabled

image

With the commands above executed, the protocols should now be displayed as such:

image

Step #2 – Create new custom Ciphers

The set of SSL Ciphers will allow us to score an A+ SSL scan on a NetScaler VPX appliance:

  • TLS1-ECDHE-RSA-AES256-SHA
  • TLS1-ECDHE-RSA-AES128-SHA
  • TLS1-DHE-RSA-AES-256-CBC-SHA
  • TLS1-DHE-RSA-AES-128-CBC-SHA
  • TLS1-AES-256-CBC-SHA
  • TLS1-AES-128-CBC-SHA
  • SSL3-DES-CBC3-SHA

Execute the following to create a group named Custom-VPX-Cipher with the ciphers listed above:

add ssl cipher Custom-VPX-Cipher

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES256-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES128-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-256-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName SSL3-DES-CBC3-SHA

image

With the above commands successfully executed, we should now see the following Cipher Group created:

image

Step #3 – Bind new custom Ciphers to Load Balancing Servers

With the new cipher group created, proceed with binding them to the Load Balancing Virtual Server(s) and NetScaler Gateway Virtual Server(s):

bind ssl vserver StoreFront-lbvip -cipherName Custom-VPX-Cipher
bind ssl vs StoreFront-lbvip -eccCurveName ALL

bind ssl vserver www.contoso.com_external -cipherName Custom-VPX-Cipher
bind ssl vs www.contoso.com_external -eccCurveName ALL

bind ssl vserver www.contoso.com_internal -cipherName Custom-VPX-Cipher
bind ssl vs www.contoso.com_internal -eccCurveName ALL

image

----------------------------------------------------------------------------------------------------------------------------------------------

Note that I’ve found the binding process a bit finicky at times and had to unbind the cipher groups so if this is necessary, use the following commands:

unbind ssl vserver StoreFront-lbvip -cipherName DEFAULT

unbind ssl vserver www.contoso.com_external -cipherName DEFAULT

unbind ssl vserver www.contoso.com_internal -cipherName DEFAULT

----------------------------------------------------------------------------------------------------------------------------------------------

With the new cipher group binded to the virtual servers, we can use the following commands to review the bindings:

show ssl vserver StoreFront-lbvip

show ssl vserver www.contoso.com_external

show ssl vserver www.contoso.com_internal

image

image

image

Note that navigating to the ciphers binding in the GUI may throw the following warning:

No usable ciphers configured on the SSL vserver/service

image

I’ve done a bit of research on this and it appears we can safely ignore it.

Step #4 – Create a Deffie-Hellman (DH) key for Forward Secrecy

The following screenshots shows where to create the Deffie-Hellman (DH) key in the GUI of the NetScaler:

NetScaler > Traffic Management > SSL

image

image

The command to execute to create the Deffie-Hellman (DH) key is as follows:

create ssl dhparam /nsconfig/ssl/dhkey2048.key 2048 -gen 2

image

Note that the process could take a few minutes before completing so wait until the green cursor display changes to a >:

image

Reviewing the /nsconfig/ssl directory on the NetScaler should now show the dhkey2048.key key that was created:

image

Step #5 – Assign Deffie-Hellman (DH) key for Forward Secrecy to Virtual Server

With the Deffie-Hellman (DH) key successfully created, proceed with assigning it to the virtual servers.

The following screenshots shows where the settings are in the GUI:

image

Execute the following command to assign the key:

set ssl vserver StoreFront-lbvip -dh ENABLED -dhFile "/nsconfig/ssl/dhkey2048.key" -dhcount 1000

image

Repeat the process for the NetScaler Gateway Virtual Servers:

set ssl vserver www.contoso.com_external -dh ENABLED -dhFile "/nsconfig/ssl/dhkey2048.key" -dhcount 1000

set ssl vserver www.contoso.com_internal -dh ENABLED -dhFile "/nsconfig/ssl/dhkey2048.key" -dhcount 1000

image

Step #6 – Create a Rewrite Action and Policy for Strict Transport Security

Execute the following to create a Rewrite Action for Strict-Transport-Security:

add rewrite action act_sts_header insert_http_header Strict-Transport-Security q/"max-age=157680000"/

image

With the command above successfully executed, you should now see the following action created:

image

image

Execute the following to assign the Rewrite Action for to a policy:

add rewrite policy pol_sts_header TRUE act_sts_header

image

With the command above successfully executed, you should now see the following policy created with the action assigned:

image

image

Step #7 –  Bind the Strict Transport Security policy to the Virtual Servers

With the Strict Transport Security policy created, proceed with binding them to the virtual servers with the following commands:

bind vpn vserver www.contoso.com_external -policy pol_sts_header -priority 100 -gotoPriorityExpression END -type RESPONSE

bind vpn vserver www.contoso.com_internal -policy pol_sts_header -priority 100 -gotoPriorityExpression END -type RESPONSE

bind lb vserver StoreFront-lbvip -policy pol_sts_header -priority 100 -gotoPriorityExpression END -type RESPONSE

image

With the command above successfully executed, we should now see the policy binded to the virtual servers:

image

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

Having completed all the steps outlined above should now allow the NetScaler site to score an A+:

image

Monday, June 6, 2016

Changing the Phone Extension in Avaya Communicator for Microsoft Lync 2013 after the initial configuration

Problem

You’ve completed deploying the Avaya Communicator for Microsoft Lync (version 6.4.0.2.50) client side integration with Skype for Business Server 2015 to replace the previous Lync Server 2013 and Avaya AES server’s RCC functionality but noticed that you are unable to change the Extension in the Avaya Communication for Microsoft Lync because it is greyed out once it has been configured:

image

Solution

I’m not exactly sure if this is by-design but one of the ways I found to workaround this was change the Choose the Device for Calls: setting to another option (in this case it is the Computer setting):

image

Then change it back to the previous Desk Phone option and you will then notice that the Extension field is no longer greyed out:

image

Wednesday, May 18, 2016

Launching XenApp 7.6 desktop published through NetScaler appliance throws the error: "The connection to "" failed with status (Unknown client error 1110)."

Problem

You attempt to launch a XenApp 7.6 desktop published through NetScaler appliance:

clip_image002

clip_image002[5]

… but notices that you are presented with the following error message:

The connection to "<YourXenAppGroup>" failed with status (Unknown client error 1110).

clip_image002[7]

Solution

One of the common reasons why this error would be thrown is if there is a misconfiguration or lack of Secure Ticket Authority (STA) configured in the load balancing virtual server on the NetScaler appliance.  To correct this issue, launch the properties of the load balancing virtual server representing the StoreFront servers, review the Published Applications settings and ensure that STA Servers are configured:

image

Saturday, May 14, 2016

The message: "One of your on-premises Federation Service certificates is expiring..." is presented when you log into the Office 365 portal at https://portal.office.com

Problem

You’ve recently noticed that you receive the following message when logging into the Office 365 portal at https://portal.office.com:

One of your on-premises Federation Service certificates is expiring. Failure to renew the certificate and update trust properties within 27 days will result in a loss of access to all Office 365 services for all users.

image

You’ve checked your on-prem hosted ADFS server’s certificate and verified that it has not expired:

image

Solution

The following are 2 options I found after browsing the internet looking for an answer:

Option #1 – Manually renew the certificate

"One of your on-premises Federation Service certificates is expiring" message in the Office 365 portal

https://support.microsoft.com/en-ca/kb/2992335

Option #2 – Wait and allow certificate to auto renew

The following forum topic was responded by a Microsoft support representative indicating that the certificate should auto renew:

https://community.office365.com/en-us/f/613/t/173158

The day that I checked on the certificate was April 20 and launching the AD FS Management console on the ADFS server…

image

… then navigating to AD FS > Service > Certificates showed that the certificate was expiring on June 1 which was more than 20 days before the expiration date:

image

What I ended up doing was set up a calendar reminder on the 19 day before June 1 to check back and when I did on May 13, I noticed that the ADFS server had indeed renewed the Token-decrypting and Token-signing certificate the day before on May 12:

image

Logging onto Office 365 via https://portal.office.com also confirmed that the warning message was no longer displayed:

image