The root cause of WannaCry is budgetary, and therefor political

I don’t typically politicise my technical Twitter account, nor this blog, but some technical problems are political. It is impossible to engage with security in any depth without confronting political issues. Earlier today, I dumped some thoughts on a private Twitter account, and a friend asked me to make them public. Here’s are those Tweets:

  1. SMBv1 is a widely-used file service that has been actively deprecated by Microsoft for an eternity, but which is present in lots of devices like NAS, networking kit and other networked devices like Sonos. Microsoft runs a program to help vendors deprecate SMBv1, but these are the kinds of things that hardware vendors routinely fail to do well.
  1. With effective network segmentation, malware like WannaCry can’t propagate widely, even if machines allow arcane protocols.
  1. Some instruments simply will not work if they get patched, to address issues like SMBv1 weaknesses. However, these devices need to be isolated through controls like effectively segmenting the network, or not networking them at all.
  1. No security professionals should be surprised that WannaCry is happening.
  1. The NHS (and most of the public sector) needs money to dig itself out of a mountain of technical debt. This is not an IT/security problem. It is an inevitable consequence of the Tory assault on NHS. If people die, we know who holds blame.

One further thought post-tweets. Some people may rightly point out that some of the funding issues and IT problems at the NHS began under Labour, but the world has changed significantly since the Conservatives came to power, and there has been an unequivocal failure to engage with those issues meaningfully where budgets have been slashed. It is not possible to adapt to contemporary threats with the obsolete technologies in use today. This will not be the last significant failure of critical infrastructure unless the coffers are topped up, and even then we can’t expect upgrade projects to happen more quickly at the NHS than they do elsewhere. This basically means that even if budgetary problems are instantaneously solved, it will still take more than a year with the best will in the world to get these risks down to manageable levels.

Further reading:

I’m sure I’ll be a bit more active than I have been recently on my technical Twitter account over the coming days (@tr5tn).

Moving an Office 365 DirSync/ADFS domain from one Azure AD tenant to another

When helping our clients with Office 365 deployments, we sometimes find that DirSync has been associated with a trial tenant that is about to expire and/or was originally created with a provisional name, or similar. In any case, a public DNS name can only be verified once in Office 365, which associates that namespace with the Office 365 and Azure AD tenancies. So if we want to move DirSync (which is also a prerequisite for ADFS) to a new tenancy, then we need to back it out from the first tenant and re-associate it with the second. Unfortunately, that process isn’t exceptionally quick, but there are some manual steps that you can carry out in order to accelerate the change. As we do this more often, our list of things to check is growing, so this list may change, but this is where we’re at today. Please feel free to comment if you feel we’re overlooking anything.

Continue reading “Moving an Office 365 DirSync/ADFS domain from one Azure AD tenant to another”

Beware of Multiple Boots with OEM Protection Tools

I aim to keep this post reasonably quick, because I’ve lost enough time to this issue already and I want to get some other posts written up soon, but this is one of those things that I should probably help raise awareness of. I foresee that this could become more of an issue in future if take-up for Native Boot from VHD solutions rises, or as people run demos from bootable removable media, etc.

Continue reading “Beware of Multiple Boots with OEM Protection Tools”

Adding Drivers to Windows Deployment Services Boot Images

A while back, I posted an article on building a SharePoint development environment in Hyper-V, which included a part on automating deployment of the host machine. Although we’ve now moved to VMware Workstation, we still use this approach for automating deployment of our standard Windows 7 builds, and this commentary is generally relevant to any Windows Deployment Services (WDS) deployment.

When I learned WDS and the Windows Automated Installation Kit (which were both quite new in Windows Server 2008 R2 at the time), I contented myself with getting ~90% of the way to a fully-automated build, as the additional effort to get from 90 to 100% (mostly re: drivers) wouldn’t have paid enough immediate dividends and we needed to start capitalising on some of the other wins of our new environment. As is often the case, we never got back to that remaining 10%, but it’s become more of an issue in recent months, as we’ve added a few Dell Latitude E6410 and Lenovo W520 laptops – both of which had network drivers that the Windows 7/Windows Server 2008 R2 boot images didn’t recognise. Unfortunately the TechNet guidance on adding drivers to boot images is unclear (to me anyway), so I’m contributing this quick post to attempt to clarify the problem that we had and the simple step-by-step solution.

Continue reading “Adding Drivers to Windows Deployment Services Boot Images”

Conficker Protection Breaks Search

A couple of months ago I was happily building a client’s SharePoint Server 2010 farm when I stumbled at Search. The Service Application provisioned fine, but when I pushed out topology changes I started to have problems. Later, these problems returned in different forms, but the root cause appears to have been consistent. In this post I will review the symptoms, the single fix and the reason why this issue emerged in this environment. I’ll also look at some unexpected permission changes that occur when new servers receive Search Service Instances.

Continue reading “Conficker Protection Breaks Search”

Testing Manage Patch Status

In my last post I discussed how the Product Version Job timer job uses the Windows Installer Service to query the installed state of SharePoint 2010 servers and how the Manage Patch Status page in Central Administration displays this information. I also touched on my reservations about what we can infer from this data. In this post, I’m diving a bit deeper in to that question.
Continue reading “Testing Manage Patch Status”

Inside Manage Patch Status

Back in August, I stumbled across a new type of DCOM 10016 error in SharePoint 2010, caused by the Product Version Job timer job. When I found the error, I was primarily concerned with keeping my event logs clean. Since then, the inelegance of my original work-around and the incomplete picture I contented myself with at the time began to nag at me, but I only recently started digging deeper, prompted largely by the fact that this topic has generated more traffic to my blog in the last quarter than any other.

Continue reading “Inside Manage Patch Status”

Scheduled Sitemap Generation for SharePoint 2010 Websites

As promised in my SharePoint 2010 SEO Analysis with the IIS SEO Toolkit post, while the IIS.NET SEO Toolkit does an excellent job of generating an initial sitemap and providing a nice GUI for ad hoc updates, it does not offer any obvious scheduling mechanism to ensure that your sitemap stays current with the changing content in your CMS. Thankfully, my colleague Glyn Clough whipped up some PowerShell to produce a full sitemap for your web application based on Jie Li’s initial script, which was scoped at the root web. Running this as a Windows scheduled task will get you a very up-to-date sitemap for all sites in your web application with very little on-going maintenance. Nice one Glyn!

Fixing the Usage and Health Data Collection Service Application Proxy

You may notice that the Usage and Health Data Collection Proxy is Stopped after deploying it in your environment. This is not just a matter of starting the service like it is with some Service Applications. In this case the SA proxy itself appears to be stopped.

Unfortunately I’ve found a problem with our development build, or rather, with SharePoint 2010. You may notice that the Usage and Health Data Collection Proxy is Stopped after deploying it in your environment. This is not just a matter of starting the service like it is with some Service Applications. In this case the SA proxy itself appears to be stopped. It appears that this is a known problem when provisioning this Service Application via the GUI. In fact, ours was created automatically as part of the Search Service Application creation process. At any rate, it doesn’t work in its current state in our environments, so it won’t actually collect any data.

To fix this just requires a couple of lines of PowerShell, courtesy of this article (to which I’ve added some clarification here).

Continue reading “Fixing the Usage and Health Data Collection Service Application Proxy”