Wednesday, May 17, 2017

Determining whether servers and desktops are protected from WannaCrypt / WannaCry Ransomware

It has been a busy week for most of my clients after the media published articles indicating that major organizations such as the NHS were infected by the WannaCry ransomware cryptoworm. Although a patch for this vulnerability was released as early as March 2017, some of my clients either had a portion of their servers unpatched or all of them since I’ve found it is not uncommon for companies to miss months of patching due to various business related reasons.  There has been a lot of information made available since last week but I’ve found that there are bits and pieces of important ones scattered on different sites so I wanted to write this post to include the information provided by Microsoft that I found useful when assisting clients to determine whether they are protected.

The Microsoft First Patch Released

The first available patch Microsoft made available for this vulnerability was released in March 2017 known as Security Update MS17-010, SMBv1 and information about this could be found at the following Security TechCenter bulletin:

Microsoft Security Bulletin MS17-010 - Critical
https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

Installing the patch above would protect the cryptoworm from spreading to other servers via the legacy SMBv1 protocol and an alternative workaround would be to disable SMBv1 all together which Microsoft recommends to do if the customer was running Windows Vista or later.

Versions of Windows Affected

All version of Windows are affected by the vulnerability and the following table provides the KBs required to protect the operating system:

  • If one of updates is installed on the system, the system is protected.
  • The vulnerability has been fixed in the March 2017 Security update but the March, April and May rollup also includes all previous updates including March security update)
Operating System 2017 March (Security Only) 2016 March (Monthly Quality) 2016 April (Monthly Quality) 2017 May (Monthly Quality) Independent Update
Windows XP / Windows Server 2003 / Windows 8 NA NA NA NA

KB4012598

Windows Vista / Windows Server 2008 NA NA NA NA

KB4012598

Windows 7 / Windows Server 2008 R2

KB4012212

KB4012215

KB4015549

KB4019264

NA
Windows Server 2012

KB4012214

KB4012217

KB4015551

KB4019216

NA

Windows 8.1 / Windows Server 2012 R2

KB4012213

KB4012216

KB4015550

KB4019215

NA
Windows 10 1507 / Windows 10 LTSB 2015 NA

KB4012606

KB4015221

KB4019474

NA

Windows 10 1511

NA

KB4013198

KB4015219

KB4019473

NA
Windows 10 1607 / Windows 10 LTSB 2016 / Windows Server 2016 NA

KB4015438

KB4015217

KB4019472

NA

Determining whether patch is installed

On a Windows Server 2012 or 2008 server, you can use the wmic qfe list command to determine whether the patch is installed.  The following are the commands to execute on a Windows Server 2012 R2 or Windows 8.1 operating system when determining whether the required patch is installed:

wmic qfe list | find "KB4012213"

wmic qfe list | find "KB4012216"

wmic qfe list | find "KB4015550"

wmic qfe list | find "KB4019215"

**Note that if the KB after the find is case sensitive so use capital letters.

If the patches are not installed then no output would be written as shown in the following screenshot:

image

If the patch is found then the following output will be displayed:

image

Patching the Operating System Vulnerability

As mentioned in the Versions of Windows Affected section, the operating system is protected as long as one of the patches is installed so it is always advisable to install the latest rollup package rather than any of the previous rollups or security patch only.  However, if downloading a 200MB+ rollup package for a Windows Server 2012 operating system:

https://www.catalog.update.microsoft.com/Search.aspx?q=KB4019215

image

… is a problem for whatever reason then the alternative option is to download the security patch only which is around 37MB in size:

https://www.catalog.update.microsoft.com/Search.aspx?q=KB4012213

image

Alternative to Patching

If downloading and installing the appropriate patch is not an option then disabling SMBv1 could be an interim solution.  The following are instructions for how to disable SMBv1:

Windows Vista and later

Windows 8.1 or Windows Server 2012 R2 and later

  • For client operating systems:
  1. Open Control Panel, click Programs, and then click Turn Windows features on or off.
  2. In the Windows Features window, clear the SMB1.0/CIFS File Sharing Support checkbox, and then click OK to close the window.
  3. Restart the system.
  • For server operating systems:
  1. Open Server Manager and then click the Manage menu and select Remove Roles and Features.
  2. In the Features window, clear the SMB1.0/CIFS File Sharing Support check box, and then click OK to close the window.
  3. Restart the system.

The following are links to articles that outline the impact of disabling SMBv1:

Tuesday, May 9, 2017

Unable to change Domain field when logging into VMware Horizon View with factor authentication enabled

Problem

You’re attempting to log into VMware Horizon View where 2 factor authentication is enabled and you use your email address or UPN as the User name:

image

However, you notice that you are unable to change the Domain field as the drop down box is greyed out and locked:

image

Solution

I am unsure as to whether this problem is specific to the SecurEnvoy 2 factor authentication software this environment had but a way to get around this is to use the format domain\username for the User name field instead:

image

Using this login format will unlock the domain drop down box so you can now select the domain:

image

Friday, May 5, 2017

Blocking a URL subdirectory and redirecting to request to the root with Citrix NetScaler

I’ve been asked several times in the past about how to block subdirectories when a website is published with a NetScaler and the most recent request was for blocking Exchange Server 2016 /ecp access.  As most Exchange administrators are aware, Exchange 2013 and 2016 allows an administrator to manage Exchange via the OWA URL but with the /ecp subdirectory.  This isn’t usually a concern when accessed via the internal corporate network but administrators get nervous when it is available via the internet.  With this recent request, I thought it would be a good idea use it as an example to demonstrate what the configuration would look like. 

**Note that this post is not endorsing the idea to block the ECP URL because I am unsure as to whether Exchange 2016 fully supports this without breaking any features for regular users as it did in Exchange 2013.  There has been several forum posts that appear to suggest it is ok but I’ll leave it up to others to decide to do it or not.

Step #1 – Create Pattern Set

Begin by creating a pattern set to match the ecp string with the following command:

add policy patset deny_ecp_url

Alternatively, you can create this via the GUI as well:

AppExpert > Pattern Sets > Add

image

image

image

Open the properties of the newly created Pattern Set, click on the Insert button and create the ecp pattern:

image

image

Step #2 – Create Rewrite Action

With the Pattern Set created, proceed with creating a Rewrite Action to replace /ecp with the root with the following command:

add rewrite action rw_deny_ecp_url_act replace HTTP.REQ.URL.PATH_AND_QUERY "\"/\""

Alternatively, you can create this via the GUI as well:

AppExpert > Rewrite > Actions

image

Type: Replace

Expression to choose target location*: HTTP.REQ.URL.PATH_AND_QUERY

Expression: "/"

image

Step #3 – Create Rewrite Policy

With the Rewrite Action created, proceed with creating a Rewrite Policy with the previous Rewrite Action assigned via the following command:

add rewrite policy rw_deny_ecp_url_pol "HTTP.REQ.URL.PATH.GET(1).TO_LOWER.EQUALS_ANY(\"deny_ecp_url\")" rw_deny_ecp_url_act

Alternatively, you can create this via the GUI as well:

AppExpert > Rewrite > Policies

image

Action: rw_deny_ecp_url_act

Undefined-Result Action*: –Global-undefined-result-action

Expression*: HTTP.REQ.URL.PATH.GET(1).TO_LOWER.EQUALS_ANY("deny_ecp_url")

image

Step #4 – Bind Rewrite Policy to Virtual Server

With the Rewrite Policy created, we can now bind it to the virtual server that publishes the Exchange OWA website via the following command:

bind lb vserver <virtualServerName> -policy rw_deny_ecp_url_pol -priority 100 -gotoPriorityExpression END -type REQUEST

Alternatively, you assign the policy via the GUI as well:

Traffic Management > Load Balancing > Virtual Servers

image

Bind a new Request Policy to the virtual server:

image

image

With the new policy binded to the virtual server, any requests to the /ecp directory should redirect the user to the regular OWA login page:

image

Which means they would never be able to reach this page:

image

Monday, May 1, 2017

Attempting to run Test-ExchangeServerHealth.ps1 throws the error: "Mail flow test: WARNING: Connecting to remote server webmail.domain.com failed with the following error message..."

Problem

You attempt to run the Test-ExchangeServerHealth.ps1 health check script found at the following Microsoft TechCenter:

Generate Health Report for an Exchange Server 2016/2013/2010 Environment
https://gallery.technet.microsoft.com/office/Generate-Health-Report-for-19f5fe5f

… but notice that the report generated is indicating that the mail flow test is failing for your Exchange servers:

image

Executing the cmdlet interactively in the console displays the following error:

------ Checking CONTOSOBMEXMB01
DNS Check: Pass
Ping Check: Pass
Uptime (hrs): 571
Server version: Exchange 2016
Roles: Mailbox
Mailbox Server Role Services: Pass
Client Access Server Role Services: Pass
Unified Messaging Server Role Services: Pass
Hub Transport Server Role Services: Pass
Total Queue: 0
Mailbox databases mounted: Pass
MAPI connectivity: Success
Mail flow test: WARNING: Connecting to remote server webmail.contoso.com failed with the following error message
: WinRM cannot
process the request. The following error occurred while using Kerberos authentication: Cannot find the computer
webmail.contoso.com. Verify that the computer exists on the network and that the name provided is spelled
correctly. For more information, see the about_Remote_Troubleshooting Help topic.
WARNING: Cannot validate argument on parameter 'Session'. The argument is null or empty. Provide an argument that is
not null or empty, and then try the command again.
Remove-PSSession : Cannot validate argument on parameter 'Id'. The argument is null. Provide a valid value for the
argument, and then try running the command again.
At C:\PS-Scripts\Test-ExchangeServerHealth.ps1:450 char:22
+     Remove-PSSession $session.Id
+                      ~~~~~~~~~~~
   + CategoryInfo          : InvalidData: (:) [Remove-PSSession], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.RemovePSSessionCommand

Fail

image

Manually executing the Test-Mailflow cmdlet on the servers complete without any issues.

Solution

One of the reasons why this error would be thrown is if you have entered the FQDN that represents your load balanced CAS servers for the PowerShell (Default Web Site) Internal URL field:

image

Changing the field as shown in the screenshot above causes the script to connect to the virtual name to execute PowerShell cmdlets, which is what causes the following error which complains that the the virtual name does not map to a computer account in Active Directory to be thrown:

Mail flow test: WARNING: Connecting to remote server webmail.contoso.com failed with the following error message
: WinRM cannot
process the request. The following error occurred while using Kerberos authentication: Cannot find the computer
webmail.contoso.com. Verify that the computer exists on the network and that the name provided is spelled
correctly.

To correct the issue, change the Internal URL field back to the internal FQDN name of the server:

image

Friday, April 28, 2017

Unable to search for users outside of the domain the Citrix XenDesktop 7.11 Citrix Director server is joined to

Problem

You’ve noticed that your Citrix XenDesktop 7.11 environment with Citrix Director installed:

image

image

… is unable to look up users from another domain that there is a forest trust configured to:

image

imageimage

Navigating into the Sessions tab displays these foreign domain accounts:

image

… and navigating into the Filters menu displays these accounts:

image

Clicking on the listed accounts from the foreign domain opens the properties of the account:

image

However, you receive the following messages:

Cannot retrieve machines.

No details are available.

image

Clicking on the user icon on the top left corner displays the following message:

User details cannot be retrieved from Active Directory.

Cannot find the user. View Director server event logs for further information (Refer Citrix KB article CTX130320).

image

Solution

A default install of Citrix Directory requires additional configuration to allow it to look up accounts in other domains that have forest trusts configured and the following demonstrates the process.

Begin by launching the Internet Information Services (IIS) Manager on the Citrix Director server then navigate to: Sites > Default Web Site > Director and open up the Application Settings configuration:

image

Select the Connector.ActiveDirectory.Domains line item and then click Edit:

image

In the Value field:

image

Append the additional domain that there is a forest trust configured and contains accounts you would like Citrix Director to lookup:

image

Note the additional domain at the end of the string (user);(server),:

image

A restart of IIS is not required so proceed to log back into the Citrix Director console:

image

You should now notice that the problematic accounts from the foreign domain will now display information:

image

image

image

Searching for these accounts will now work as expected:

image

Monday, April 24, 2017

Attempting to install the Citrix XenDesktop 7.11 VDA agent fails with: Installation of MSI File ‘IcaWS_x64.msi’ failed with code ‘InstallPackageOpenFailed’ (1619).”

Problem

You’re attempting to the Citrix XenDesktop 7.11 VDA agent on a Windows 7 desktop but the installation immediately fails with the following error message:

Installation of MSI File ‘IcaWS_x64.msi’ failed with code ‘InstallPackageOpenFailed’ (1619).

image

Clicking on the View Details link displays the following:

Error Id: XDMI:B70F91CB

Exception:

Citrix.MetaInstaller.MetaInstallerException Installation of MSI File 'IcaWS_x64.msi' failed with code 'InstallPackageOpenFailed' (1619).

at Citrix.MetaInstaller.Msi.InstallProduct(InstallationContext context, String msiPath, String parameters)

at Citrix.MetaInstaller.MsiComponent.Install(InstallationContext context)

at Citrix.MetaInstaller.InstallationManager.InstallComponent(IInstallableComponent component, InstallationContext installContext)

image

Reviewing the installation logs has the following information at the end of the log:

16:32:18.9638 $ERR$ : XenDesktopSetup:MSI file C:\Windows\TEMP\Ctx-AD3A7E10-3F36-4A0C-BE5F-B348771B0200\Extract\Image-Full\x64\Virtual Desktop Components\WS\IcaWS_x64.msi not found on media.

16:32:18.9658 : XenDesktopSetup:About to install MSI File 'C:\Windows\TEMP\Ctx-AD3A7E10-3F36-4A0C-BE5F-B348771B0200\Extract\Image-Full\x64\Virtual Desktop Components\WS\IcaWS_x64.msi' using params 'INSTALLDIR="C:\Program Files\Citrix" ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="1" MSIRMSHUTDOWN="2"' log file is 'C:\Users\tluk\AppData\Local\Temp\Citrix\XenDesktop Installer\MSI Log Files\IcaWS_x641895175363.txt'

16:32:18.9658 : XenDesktopSetup:Starting synchronous process 'msiexec' with args '/i "C:\Windows\TEMP\Ctx-AD3A7E10-3F36-4A0C-BE5F-B348771B0200\Extract\Image-Full\x64\Virtual Desktop Components\WS\IcaWS_x64.msi" /lv "C:\Users\tluk\AppData\Local\Temp\Citrix\XenDesktop Installer\MSI Log Files\IcaWS_x641895175363.txt" /quiet INSTALLDIR="C:\Program Files\Citrix" ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="1" MSIRMSHUTDOWN="2" CLOUD=False REBOOT=ReallySuppress'

16:32:19.0158 : XenDesktopSetup:Process output: T h i s i n s t a l l a t i o n p a c k a g e c o u l d n o t b e o p e n e d . V e r i f y t h a t t h e p a c k a g e e x i s t s a n d t h a t y o u c a n a c c e s s i t , o r c o n t a c t t h e a p p l i c a t i o n v e n d o r t o v e r i f y t h a t t h i s i s a v a l i d W i n d o w s I n s t a l l e r p a c k a g e .

16:32:19.0168 : XenDesktopSetup:Process output:

16:32:19.0178 : XenDesktopSetup:Process output:

16:32:19.0188 : XenDesktopSetup:Process completed with error code 1619

16:32:19.0188 $ERR$ : XenDesktopSetup:Installation of MSI File 'IcaWS_x64.msi' failed with code 'InstallPackageOpenFailed' (1619).

16:32:19.0198 $ERR$ : XenDesktopSetup:InstallComponent: Failed to install component 'ICA for Workstation Services'. Installation of MSI File 'IcaWS_x64.msi' failed with code 'InstallPackageOpenFailed' (1619).

16:32:19.0198 $ERR$ : XenDesktopSetup:Recording installation failure. Installation of MSI File 'IcaWS_x64.msi' failed with code 'InstallPackageOpenFailed' (1619).

16:32:19.0208 PROC : XenDesktopSetup:InstallComponent: Exit

16:32:19.0208 : XenDesktopSetup:Install tasks for this session have finished.

16:32:19.0208 : XenDesktopSetup:Installation failed

16:32:19.0638 : XenDesktopSetup:InstallationManager returned Failed

image

Solution

This error actually threw me off for quite a few hours because the client called me to troubleshoot the issue over the phone which meant I wasn’t able to run the install myself.  After downloading different versions of the VDA agent, disjoining the template from the domain to eliminate GPO related issues, reviewing Windows hotfixes and patching the Windows 7 desktop to the latest version, what ended up being the issue was that the client used the server version of the the VDA agent:

VDAServerSetup_7.11

image

The installation completed as soon as the client downloaded the correct VDA agent:

VDAWorkstationSetup_7.11

image

image