It’s always my problem

Sat, 10 Jan 2026 21:58:21 +0000

I don’t understand why the UK government have not blocked Grok and X over their CSAM problems ( www.theregister.com/2026/01/0… ).

I don’t understand why Google and Apple haven’t removed their apps from their respective app stores either.

That’s all I’ve got to say.

Fri, 09 Jan 2026 09:54:41 +0000

Maybe ‘dumb homes’ are the new smart?

Went shopping for a new bathroom the other day - our en-suite is old and worn out. One thing I specified is “No smart shower” because as an IT Pro who likes to relax in a hot bath away from all the tech, the last thing I want to do is troubleshoot a network problem to run the bath.

With that in mind, Jason Fried’s The Big Regression struck a chord. I do like the idea of Smart Home stuff but it has to approve the quality of life for you in the home, it’s got to cope if the normal “tech wrangler” is dead or long-term ill. It’s got to recover nicely after a power cut, instead of needing things to be rebooted in a particular order just to get the lights on and the boiler running after a storm.

Gift cards considered harmful?

Fri, 19 Dec 2025 19:29:38 +0000

Through John Gruber’s article at Daring Fireball, Gift Card database, an Australian website that tracks, well, gift cards has a fantastic guide to spotting when a physical gift card may have been tampered with.

This is a rising problem where scammers tamper with a physical gift card in a store so that it is activated when you purchase the card but you are unable to redeem the money loaded onto the card, leaving them able to do so at their leisure.

There have been cases where people have lost access to their Apple/Xbox/Google account after becoming the innocent victim of scammers. At this point, I have to wonder if I’d dare redeem a gift card as I don’t know for sure if it is ‘safe’. This could be the start of the death of buying physical gift cards in stores.

💻 Zettle code 2

Sat, 02 Nov 2024 20:20:00 +0000

this is the enshittification that Cory @doctorow@marmot.fr writes about. My partner has a Zettle terminal that was used maybe twice then put away for some time. Upon going back to it, it gives a code 02 error which indicates tampering…which I’m certain hasn’t happened unless the Cat knows more than she’s admitting.

I have managed to get around this tamper lock by plugging an ‘unofficial’ usb C lead in, doing a factory reset, and avoiding the physical power-off button. It now works fine… provided nobody touches the power button.

So by my reckoning, either their tampering alert is triggering for no good reason, because the unit still works - and that’s bad for Zettle’s users, or Zettle’s tamper protection is absolutely trivial to defeat… which is also a massive problem.

Tue, 29 Oct 2024 19:59:47 +0000

There’s a long thread on Edugeek about pay and conditions for IT staff in UK education.

I quit edu work about 6 years ago and my current employer in the private sector pays much better but is also much more respectful of its staff than anything I’ve ever seen in UK edu.

We’re seeing more and more private data being stored by schools who need to know about students and parents. We’re seeing more attacks on IT infrastructure, and we’re seeing the people protecting the security and integrity of children’s education and privacy being undermined. This can’t go on.

Apple's designs

Tue, 29 Oct 2024 18:46:27 +0000

Anyone ordered a Mac Mini yet? I’ve not got a use for one, but I’m intrigued. I can live with the power button being on the bottom.

@gruber@mastodon.social makes an interesting point about the Apple Mouse charge socket being on its bottom; you might not agree with Apple but these are design choices, not design mistakes.

Becoming a Chartered IT Professional

Mon, 28 Oct 2024 20:20:02 +0000

I have recently been working on my professional development and was delighted to be awarded the status of Chartered Information Technology Professional (CITP) from the British Computer Society last year.

Why does this matter?

Chartered status can only be granted by organisations which have received a Royal Charter to make these awards and Chartered status should be equivilent across different professional fields, so CITP status is considered equal to other professional awards such as Chartered Engineer or Chartered Surveyor.

CITP is a measure of current (at the time of award) competency.

For those of you who haven’t come across the term before Chartered Professional is the pinnacle of professional awards in the UK - it’s a measurement of professional competence. For anyone visiting from the states, you could think of this as being broadly like being a licenced Professional Engineer, in the field of IT.

CITP isn’t about how long you’ve been in IT

CITP isn’t an award you get for hanging around the place. It’s a measure of current competence and professionalism. Candidates are independently assessed against the SFIAplus skills framework to ensure they meet the right criteria for experience over several years, and CITP holders must maintain and renew their ‘certificate of current competence’ to retain the status.

CITP isn’t about being better at IT than others.

CITP is a measure of the professional, ethical, and technical level I’m working at right now. It’s an affirmation that I’m working at that level and that I’m able to present evidence of that for an independent assessment by an industry body. It’s not a claim by either the BCS or me that I’m automatically better than anyone who is not a CITP.

CITP isn’t about knowing everything

I work in Infrastructure, cloud and architecture these days, and my CITP application and assessment was based around those areas. My competency as measured by the award is around these areas. It doesn’t mean I’m an expert at every aspect of IT (I’m not great at either programming or soldering and being a CITP didn’t magically help me be any better).

The code of conduct I’ve agreed to as part of my BCS membership and CITP award compels me to be aware of and honest about my weaknesses. And over the 30+ years I’ve been working in IT most of the biggest failures I’ve seen have been to overconfidence or an inability to step back and reflect on a decision.

So, I’m still not the person you want to write you a complex computer program… but I can admit my limits and set about helping you find someone who can do an excellent job of writing your code for you.

Sun, 27 Oct 2024 20:21:43 +0000

👋 Not written anything about my techie noodling 👩‍💻👨‍💻💻in ages, but busy migrating to micro.blog from Wordpress.

it’s been interesting to say the least. The Wordpress implosion, which I’m not qualified to write about, got me thinking about the why, if and how of blogs in 2024. Micro.blog turned out to be very easy to migrate to, and has some neat features. So yeah. I should redirect my domain name soon so let’s see how that goes. I might then write about the migration process and why micro.blog.

Securing Admin roles in Azure Active Directory

Tue, 14 Jul 2020 20:48:12 +0000

I’m going to continue my recent look at securing your Office 365/Azure AD directory with a quick dive into using Conditional Access rules to protect your directory’s most prized asset - accounts with admin roles.

These are roles that can be used to accomplish admin tasks within your organisation’s Office 365/Azure AD and Azure estate and they are important because they are essentially the keys to the kingdom. While you should be looking to secure all your accounts because all your users probably have access to sensitive information, systems or services; admin accounts are the accounts that give their user access to your entire estate in one or two leaps. An attacker doesn’t need to worry about compromising your board’s accounts one at a time to look at emails if they can compromise an admin account to download everyone’s emails to PST and add a few interesting rules to your Exchange Online transport rules while they’re there too.

I’m going to talk later in this post about the right way to protect admin accounts using MFA, but first of all I want to talk about the two most common issues with admin permissions.

Two of the most common weaknesses I still see in both AD and Azure AD management are assigning admin rights to a user’s daily driver account, and assigning overly permissive privileges.

Don't assign admin rights to daily driver accounts

If your organisation is guilty of this then putting a stop to it right now is easily one of the simplest ways to improve security. When I talk about a "daily driver account", I'm talking about a person's everyday user account that they log on to when they start work, that they use for their normal Internet use, talking to others on Teams or Slack, send and receive email from. The issue comes when a user needs an admin privilege to get a job done. Perhaps he's part of the helpdesk team and you assign him the rights to reset passwords and clear MFA registrations in Azure AD. Perhaps she's your Office 365 app specialist and she needs SharePoint or Exchange administrator rights to get the job done.

That’s fine… but don’t assign admin rights to their standard account. If their account is compromised via a webpage or email, this makes it utterly trivial for an attacker to exploit any admin permissions assigned to that account. Instead, create a separate admin account for each IT staff member and assign the rights to that account only.

Over-permissioning accounts

Also a common error, and one that's somewhat down to Microsoft in the O365/Azure AD world. Consider my helpdesk admin and my Exchange Online admin from the last section. Clearly they need some kind of admin access to do their role, but they don't need to be Global Administrators to accomplish their task. This allows them more permissions than they need to carry out their job and this presents several threats

It raises the impact risk of any mistake they make - I can't accidentally delete the Azure AD directory if I don't have permission to do so.
It again means that any hacker that compromises their admin account has wider scope to cause harm than they might otherwise have had.
From a data protection / governance angle, personal data should be stored in such a way that allows you account for how it is used, and stored with integrity and confidentiality in mind. It's hard to do that if everyone on your network can use admin rights they don't need to view or alter customer data.

Protecting Admin accounts with MFA

In my recent article on Passwordless authentication I mentioned protecting user accounts with some form of MFA. This should obviously apply to administrative accounts and roles just as much as it does to normal users.

You can, of course create a group for your admin users, then assign a Conditional Access rule to that group that requires MFA when you sign in. I’ve seen that applied in several places, similar to the example below.

This will work of course, and as I’ve said before, if you’ve done this then you’re ahead of the far too many people who haven’t done even this much. But this approach has two disadvantages.

You must remember to put admin users into the correct group, and you must trust your admin users not to remove themselves from that group. Still nobody makes mistakes and nobody gets fed up of using MFA right?
MFA against cloud apps will secure portals but it requires you to stay on top of the changes Microsoft make to these portals, and most importantly of all, does not do enough to protect against access via PowerShell or the Graph API.

There is a better way: Secure admin roles rather than admin people

Microsoft allow you to create Conditional Access rules that secure roles rather than people or portals.

Administrative roles in Office 365/Azure AD are what drive your admins use of the Azure and Office 365 portals. They are also what drive use of the technologies such as Graph API and PowerShell that are used to build the portals. This means that any attempt to use a protected role with any method will go through your Conditional Access rules. Keep in mind that while I’ve spoken about Conditional Access rules purely as a way to enforce MFA, you can actually make several requirements mandatory for accessing sensitive roles or data if you use MFA.

This means that you do not need to remember to add each new admin user to a group; or worry that Fred has granted himself global admin rights on his personal account again; or that you don’t even know what I’m talking about when I mentioned Graph API earlier, let alone how to secure it.

You do need to check that a new role hasn’t been added to the list in Azure/Office 365, but then this only becomes a real risk if you assign this role to your admin users.

Consider the example rule Conditional Access rule below, which demonstrates securing Directory Roles rather than groups or individuals.

Here we have chosen to secure Directory Roles rather than users. This means that any use who has that role assigned to them will be managed by this Conditional Access rule each time they sign in. It doesn’t matter how they connect, and it doesn’t matter if they’re using the role or not. If they have the role assigned to their account at all, they will need to meet the login standards required by the Conditional Access rules you set.

We are using the role to allow login on any device platform, but only from a trusted location. We are also requiring the user complete a MFA challenge, and to use a device that is Hybrid Azure AD joined and compliant with our Intune MDM policies.

At this point we’re saying you must be using MFA, be on-site (this could include connecting via a VPN remember), and have a device that can be checked and managed by Azure AD. This is about as safe as it gets. Combine this with passwordless login to ensure the MFA process is as secure as possible and your admins will be working securely and with as little friction as possible when using MFA.

You could expand this further with the correct Azure AD P2 licences, and block logins to these roles from high risk user or sign-in scenarios. In fact, if you have P2 licences, I strongly suggest you do exactly that.

And yes, it is possible to lock yourself out with these rules if you’re not careful. Which is while we’ll cover Break-glass accounts in another post, and why you should use the report function and test very carefully before enabling this feature.

Using Passwordless for Office 365

Sun, 05 Jul 2020 16:18:42 +0000

As the pace of attacks continues against companies who use online services, major IAM providers such as Microsoft and Okta are looking for ways to improve theirs and your security game.

I was fortunate enough to attend the 2019 Okta forum in London and one of the drums Okta beat throughout the entire presentation was Passwordless Authentication. Microsoft are also recommending this as a major improvement to Office 365/Azure security even on top of MFA.

What is Passwordless?

Passwordless Authentication essentially means turning over the full login process to your MFA device. All my examples here are going to talk about Azure AD/Office 365 and the Microsoft Authenticator app, but other IAM / MFA providers will be similar.

When you log on to a service that uses passwordless auth, rather than simply being asked for your username and password then needing to supply a simple 6 digit pin or approve a ‘push’ notification, you simple log in with your username and you will be shown a question on screen that will need to be answered on your MFA device. The MFA device should verify that it really is you answering the query by carrying out a biometric check also alongside the query (e.g. using Face ID to verify who is using the MFA app).

This stops your password being stolen by a compromised webpage or computer, and also validates your login against several of the the standard 5 authentication factors:

Something you are: Using biometrics to make sure it's really you.
Something you have: Your login token (e.g. phone with Microsoft Authenticator.

You could argue that this is also an example of Somewhere you are, because you, the login token and the device you're logging in to all have to be in the same location at the same time.

All this means that simply phishing your password or event stealing your unlocked mobile phone with your authenticator app on it will not help an intruder.

I’m going to run you through a quick guide to setting this up on Microsoft’s Azure AD along with Conditional Access in the rest of this article.

Branding your login page.

This isn't necessary to complete a test but I do think branding your Microsoft login page for Office 365 is important. Part of encouraging users to avoid fake login pages (on the grounds that even with Passwordless, some users will still fall for a fake site asking for a password) is to make your login page customised to your corporate standard. As logos are trivial to steal, this will not do much to stop a determined attacker who is specifically targeting you, but it will slow down the rate of casual drive-by credential theft. You have other tools for spotting targetted attacks.

To do this, log in to Azure Portal as a Global Administrator and proceed to Azure Active Directory > Company Branding. Then click Configure.

A form will appear asking you to select files for background, logos, etc. These will hopefully be self-explanatory and as these are standard corporate resources, you will probably have them to hand without too much trouble, e.g. your corporate desktop wallpaper for the sign-in page background image, etc.

When you are ready, click Save at the top of the form. Your changes will be live immediately (though they may not show up everywhere consistently just yet).

You can use this custom branding on links to the Microsoft login pages by adding ?whr=yourdomain.com to the end of a url, for example: account.activedirectory.windowsazure.com/proofup.a…

Now that things look professional we can move on to the feature presentation

Enabling Passwordless Authentication.

Prerequisites

I'm going to assume you're comfortable with the basics around MFA using Conditional Access (CA), creating a CA rule, and enrolling users into MFA. I'm assuming you already have your users configured and licenced. I'm also glossing over a lot of what I consider to be good practice for Azure MFA configuration. I will return to that later but the point of this article to to talk about passwordless. The CA rules you will see in use in this article are the ones used in the recent article about Azure MFA and Chromebooks.

Getting Started.

One thing to remember here is that Passwordless isn't an alternative to Azure's MFA mechanism. Instead it is an additional layer. This means that you can choose to apply Passwordless to some or all of your MFA users, which is great for testing. Let's get started/

Create a test group. For the purposes of this article, I’m creating an Azure AD group named IAMP_Passwordless_MFA but you can use groups synced from AD if you please.

From the Azure portal, open Azure Active Directory > Security > Authentication Methods.

Select Microsoft Authenticator Passwordless sign-in. On the control panel that appears below, select Enable = Yes, and for Target select the test group you created earlier. Click Save once you are happy with your settings, which should look similar to the ones above.

We now need to check our Conditional Access rules. In the Azure Portal, click home and then find your Azure AD Conditional Access service.

Locate your appropriate CA rule (MFA all Devices and Users in my case, below) and click to edit.

In the CA rule, select Users and Groups > Include, and ensure your test group is listed here.

Testing Passwordless

Now we're ready to test. Firstly, make sure your test group has a test user placed into it. You will also need a test device to run Microsoft Authenticator from. This can be almost any modern Android or iOS device that can do Touch or Face Biometric ID and the device must not be registered to another Azure AD tenant. This might make testing on a separate test tenant a little difficult.

To start, open up a new browser session to your Office 365 or Azure portal and sign in as your test user. You should see your newly branded login screen at this point too.

You will probably be asked to proceed through the MFA enrolment process at this point with the “More Information Required” screen.

Once your test account is enrolled and working properly with the Microsoft Authenticator and Push notifications, you are ready to enable Passwordless on this device.

In the Microsoft Authenticator app, tap on the entry for your test account to view its properties. Now tap the entry for Enable Phone Sign-In. You will be warned that your device will need to be registered against your Azure AD directory and that device security (e.g. Touch ID/Face ID) is required.

Click Continue. When prompted, sign in as your test user on that device and complete the wizard.

On your PC, sign out as that user, close your browser session and open a fresh one. Then sign in as the test user and you should now be prompted for a passwordless sign-in and prompted to complete the appropriate Touch or Face biometric challenge in order to log in successfully.

You can also view this in the Azure AD sign in reports for the test user, where it will show as MFA requirement satisfied by strong authentication. Microsoft document the log values for troubleshooting here if you have any trouble.

Azure Conditional Access for Chromebooks

Fri, 03 Jul 2020 17:11:25 +0000

I suspect most of you reading this article will already know this, but part of Microsoft’s Azure AD (AAD) / Office 365 Cloud directory service that you get when you pay for premium AAD is Conditional Access (CA), which can be used to allow quite sophisticated access controls for accessing Office 365 resources.

Of course, you get basic Office 365 MFA with the basic Office 365 enterprise product, and you should absolutely look into enrolling your users and turning this on straight away if that is what you have. Don’t let my talk of better MFA systems stop you implementing one of the single most effective protections for your Office 365 accounts and data possible.

Conditional Access, a very quick primer.

[caption id="attachment_919" align="alignleft" width="300"] Fig 1: Azure Conditional Access Config[/caption]

Conditional Access rules let you set various conditions (clue in the name!) on login to achieve some quite subtle changes in security profile.

For example, you can decide whether or not a device needs to be enrolled in Intune based on location, take different actions depending on the risk profile of the logon, have different logon conditions to satisfy based on whether a user is using a desktop computer or mobile device, or App vs. Browser, and so-on.

One slightly weird issue I’ve run into lately with using Azure Conditional Access to drive MFA is dealing with operating systems that Microsoft do not support directly.

For many people this is a non-issue. If you want all users to go through identical validation regardless of device type, login type, etc, you can do this with just one rule, for example, consider the basic CA rule below.

[caption id=“attachment_923” align=“aligncenter” width=“1024”] Fig 2: MFA All Devices and Users[/caption]

This is a very basic CA rule that requires all users (I excluded my test user to avoid locking myself out while writing this) accessing Office 365 from any location except trusted locations (e.g. outside the office) via the browser or modern authentication-based apps to be required to successfully complete a MFA challenge.

This is very simplistic and will catch all users on all devices. This is a reasonable pattern for a simple CA rule where you don’t need to differentiate between types of users, or types of device, or apply different rules depending on location.

But quite often, we want a bit more control than that. We want to apply different rules to different users.

Complex CA rules and Chromebooks

[caption id="attachment_926" align="alignright" width="189"] Fig 3: Sign-in risk.[/caption]

Perhaps we have a group of users who don’t need to logon from outside the office at all, or a group of especially valuable accounts whose logins we want to track more closely than others. My view on this btw, is that all logins are equally value because compromising a so-called “low value” account can often be a stepping stone to compromising other “high value” accounts by sending phishing emails to the high value users that must be safe, they’re internal, for example.

Perhaps we want to apply different login actions based on risk level, so we need different policies for different risk levels? This can be useful if we want to say that a “high risk” user login is denied, or has to pass extra checks in order to be allowed. To do this, we’d create several CA rules for different risk profiles.

Or perhaps we want to apply different rules for different devices. This is where the Chromebook issue I talk about in the title comes in to play.

Consider the pair of rules visible in the first screenshot in this article:

MFA Conditional Access test for Desktop - applying settings to Windows and MacOS device types.
MFA Conditional Access test for Mobile - applying settings to mobile device types.

To do this, I created two rules similar to the one above, but with 1 small difference.

[caption id=“attachment_928” align=“aligncenter” width=“1024”] Fig 4: MFA for mobile vs. MFA for desktop[/caption]

The mobile rule looks for Android, iOS or (for the sake of completeness) Windows Phone. The desktop rule looks for Windows or MacOS. This is great… until someone logs on with a Chromebook (or a Linux system for that matter). What policy does that fall under?

Sadly, where Microsoft don’t have explicit support for a platform, it doesn’t get tested for CA compliance under either of these rules because it isn’t a listed system, so all your nice CA rules are being subverted for the cost of a cheap Chromebook, or a cheaper or even completely free Linux ISO.

This means that devices that fall into this pattern are not being targetted by your Conditional Access rules. This means that any rules around DLP, MFA, etc. built on this pattern will not work properly with unknown devices.

Luckily this is easily fixable. You have two choices, both of which revolve around the Device Platforms Controls above. You might notice that some controls in the CA creation process have an include and exclude tab, and this includes the Device Platforms control. We can use a combination of Include and Exclude to direct unsupported or"unknown" devices down a particular route as follows.

To Deny Logins for unsupported devices, do the following.

Create a CA rule similar to my "MFA All Users and Devices" rule earlier in the article (Fig 2).

[caption id=“attachment_932” align=“aligncenter” width=“1024”] Fig 5: CA blocking unsupported devices[/caption]

Create a CA rule and under Device Platforms, click the Exclude tab and select all your supported Platforms. This means the rule to block access will not apply to your supported Device Platforms that you've just selected.
Still in Device Platforms, return to the Include tab and select Any Device. Click Done.
Select Grant under Access Controls.
Click Block Access, then Select.
Click Save to save your new rule. Review it carefully and when you are sure it is right, return to editing the rule and Enable the policy, then click Save again. The rule will become active straight away.

This rule will apply to all devices excluding Android, iOS, Windows and MacOS, and is set to block access to platform types not listed on the Exclude tab, which is useful if you require all supported devices to be successfully enrolled in Intune, and to block all other access.

To support MFA on Chromebooks/Linux, do the following.

Firstly, keep in mind your limitations. For example. if a device isn't able to be enrolled in Intune, you cannot expect it to work with CA rules that require Intune compliance. My assumption in this example is that we have two types of device login:

Desktop based, for MacOS and Windows, which does not require the device to be enrolled in Intune. (I'm including laptops and Surface tablets as "desktop" here).
Mobile based, for Android and iOS, which does require the device to be enrolled in Intune.

So in this example, we're classifying Chromebooks and Linux as a "desktop OS", and our CA rule for desktop devices already requires MFA for logins from desktop devices but does not require AAD join or Intune Compliance. This is a common scenario when a business wants to allow users to access their email from a personal device at home.

[caption id=“attachment_936” align=“aligncenter” width=“1024”] Fig 6: Require MFA for Mac OS, Windows and “unknown”, excluding mobile devices.[/caption]

Edit your Desktop MFA rule, and under Device Platform, click on the Exclude tab and select Android, iOS and if you must, Windows Phone. This means that the your Desktop MFA CA rule will not target mobile devices, leaving them to be targetted by your specific Mobile Device rule.
Still in Device Platform, return to the Include tab and select Any Device. Click Done on the Device Platforms tab.
Click Save to update your CA rule. The change will be applied straight away.

This rule requires MFA for all devices, except the devices specified in Device Platforms / Exclude . Those excluded devices can then be used with another CA rule, as per my example of different login routes for mobile OS vs "desktop" OS.

Teams CAA70007 errors

Tue, 09 Jun 2020 20:04:17 +0000

Has this ever happened to you? You're using Teams like normal and one day it doesn't start. No reason, just the usual Teams error that tells you nothing. You try the usual workarounds (Mark Vale's write-up on cleaning the Teams Cache is invaluable) but nothing helps. So back to that error that doesn't tell you anything.

Teams being helpful

Or maybe it does tell you something. The error code in the bottom left corner: CAA70007. That looks promising... except it isn't. No sign of the error in the Microsoft documentation and no help in the Microsoft Answers.

But I've found a possible answer. To see if you have the same issue I was having, open up your Event Viewer, and expand Applications and Services Log > Microsoft > Windows > AAD, then click on the Operational Log. If you see a lot of 1098 AADTokenBrokerPlugin errors, then I may have a solution.

For me, there was a series of 0xCAA5001C Token Broker Operation Failed errors. This can indicate things like out of date components, faulty internet connection, etc but if you're reading this you've probably already checked all that.

Searching for more info about 0xCAA5001 errors then led to this Microsoft article which is a useful fix.

You should read and understand the article before making changes but If you're in a rush and just want a short answer that doesn't involve more reading then, what I did was as follows: (the usual warnings about registry editing apply)

Open regedit and browse to the following key:

HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\ Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy

Right click, select permissions and disabled inheritance on this key(making sure to create a copy of the current permissions when asked).
Still in the permissions window, I then re-enabled inheritance, ticked Replace all child objects permission entries with inheritable permission entries from this object and hit OK. This fixed my issue.

Teams now starts. Hooray! I do love Teams as a concept but issues like this make me think there's a lot of work to be done on the basic tools.

Tuning up Intune - Building your toolset

Sat, 11 May 2019 20:49:37 +0000

Introduction

When talking about how Intune works with a colleague, I likened assembling a working Intune configuration to protect corporate devices and data to working with small pieces of Lego to build a house.

The reason for this comparison is that a managed Intune environment is built up of lots of different components that can all be slotted together - or left out - to build the environment you want.

Intune's Building Blocks

When a user installs Company Portal for the first time and authenticates through it they will be asked to enrol their device. This steps through the Device Management policies, which allow us (as the Intune Administrator) to control the features on their device (e.g. block or allow use of the Camera, require a device password, allow us to lock or wipe the device (or at least corporate information) later on if the device is stolen, etc.

When a user attempts to access Corporate data via applications, we can require the applications are configured in a certain way, that the apps themselves are protected by a password, and so on.

We can also use conditional access policies to require certain other things of the user, such as only allowing access under certain risk profiles (e.g. blocking access from jailbroken devices, or from ‘suspicious’ Internet addresses).

We can combine some or all of these to provide a carefully managed environment for accessing corporate data on the move, for ensuring corporate devices are protected in the event of theft, and that users cannot easily move data from a secure environment to an insecure one.

If users are working with their own devices rather than corporate ones, it’s possible to just use Mobile Application Management (MAM) to control how your corporate data is accessed without changing the way your users have to interact with their own personal devices on a day-to-day basis. This presents some risks but the choices is yours to make.

If you wish, you can just use Mobile Device Management (MDM) to configure a corporate device to meet some basic standards and leave the users to manage applications themselves. Again, this presents some risks (and these days, certainly, I’d advise against just doing that) but the choice is yours to make.

If you don’t have the budget for Azure AD Premium then you can configure the more basic elements of MDM and MAM and not worry about Conditional Access rules, DLP or other features. Again this is a risk but the choice is yours to make.

Obviously the ideal situation is to use Azure AD Premium features along with the full Intune suite of MDM and MAM features, but even here there are choices to make about how you build up your policies and what experience your users are going to have.

Putting the blocks together

Now that we’ve seen the building blocks, we can try putting them together.

First you have your users in Azure Active Directory (AAD). You may not realise it if you’re just using Office 365 for your business, but all the User Identity and Access Management for Office 365 is managed in AAD.

This means that for better or worse, features from O365 and features from Azure AD will both apply to your users, who will be listed in both places as per my example here.

You need to make a decision based on licences and your intentions as to where you will manage devices, in Office 365 or in Azure. This is known as setting your MDM Authority.

The Office 365 Device Management tools (As an Office 365 admin, look under Admin Centers, Device Management) give you access to the basic Mobile Device Management capabilities found in the base-level O365 MDM product.

The full Intune suite, available under the Azure portal gives you additional features such as Application Management, along with access to more granular reporting and configuration options for Mobile Device Management. If you have the full Enterprise Mobility Management package, you will also be working with the Azure portal for features like Conditional Access.

App Stores

Intune allows you to link to the Apple iOS, Google Android and (obviously perhaps) Microsoft Windows App stores. This allows you to control what apps can and cannot be installed and even make some apps mandatory. More on this later.

PowerShell management

Lastly in terms of management tools, I should mention PowerShell. As I'm sure most people reading this will already know, PowerShell is Microsoft's command line interface to both its on-premises and cloud components. It's probably fair to say that Microsoft's PowerShell support is still undergoing rapid development as it aims to become a full toolkit for managing what previously was a GUI experience, but it's still incredibly powerful and useful.

PowerShell starts to make sense for Intune if you need to do some repetitive tasks or ones that would be difficult to do through the GUI, such as back up your configuration, which is a great way of documenting a “baseline” for your install and tracking changes; as well as a useful way for moving settings from a test to a production environment; or for consultants to rapidly deploy certain common scenarios to multiple customers. I plan to talk more about Microsoft Graph myself but I very much recommend John Seerden’s introduction to the Intune PowerShell SDK, along with his backup tool I link to above.

Intune’s PowerShell modules are built around the Microsoft Graph API. This is a set of programming interfaces that was originally developed for Office 365 and which has been expanded to cover larger parts of the Microsoft cloud services. It seems intimidating to delve beneath the hood at first but Graph is quite useful for managing large parts of your online services. If you’re unsure where to start with Graph then I’ll point you to Microsoft’s 30 days of Microsoft Graph blogs and the Microsoft Graph Explorer.

Tuning up Intune, an introduction.

Sat, 30 Mar 2019 15:52:44 +0000

Introduction to Microsoft Mobile Device Management

I'm currently settling in to a new job where I'm spending a fair amount of time working with Microsoft's Mobile security management tools, mostly Microsoft Intune. This is largely what I was doing towards the end of my old job too, and while there's some great people writing great material out there, I think there's a lack of articles that try to start at the beginning with current (as of April 2019) tools and pull all the strands together, so that's what we're going to talk about here.

First of all, let’s talk about some industry standard terms that you might see in this article and everywhere else.

Mobile Device Management (MDM) - this refers to management tools for smartphones, tablets, and also more recently laptops and desktops. MDM tools typically apply policies to devices (or users) that control how the device the user is working with operates.

If you’re used to using Active Directory management of devices then you might consider MDM to be loosely similar to GPOs applied to a desktop machine to control the basic environment.

Mobile Application Management (MAM) - This refers to the management of the applications themselves on a mobile device. MAM differs from MDM in that MAM allows us to have more granular control over the behaviour of different applications without necessarily taking control of the whole device (though it’s possible and often desirable to use device and application policies together).

Data Loss Prevention (DLP) - Systems that monitor data and attempt to spot unauthorised access, modification or sharing.

Enterprise Mobility Management (EMM) - This term encompasses MDM, MAM, mobile user security and data loss prevention tools (DLP) working together with user account security (e.g. multi-factor authentication, detection and blocking of “risky” logins) to try and provide a secure environment for mobile workers.

Microsoft's EMM product family.

Microsoft refer to their product family as "Enterprise Mobility + Security" and not surprisingly, it's designed to integrate with Office 365 and Azure Active Directory.

There are several different levels of Microsoft Intune, each with different levels of functionality and different benefits.

Mobile Device Management for Office 365

This is the basic package for Office 365 Business subscribers and is bundled with the Office 365 enterprise packages. It gives you a simplified dashboard for enrolling and managing mobile devices and Windows clients, and is designed to offer a simple "baseline" level of control over mobile access to data and services for businesses using Office 365.

Microsoft Intune

Microsoft Intune is the full Microsoft "MDM experience", allowing you to fully manage devices and applications in Office 365/Azure Active Directory. It allows you to enrol devices, assign policies to groups of users in a similar way to MDM for O365, but also adds full MAM capability, allowing you to apply granular controls to applications that are using your data without necessarily having to enrol the device into MDM.

Intune adds support for Mac OS to the list of devices that can be managed.

Enterprise Mobility + Security

EMS is the full package. It requires (or provides, depending on how you look at it) a subscription that includes Azure Active Directory (AAD) premium, and provides you with everything that Microsoft Intune itself allows, along with vastly improved safeguards for user accounts and data.

In Summary

If this seems confusing then don't worry - it is a little confusing. You can think of the three packages above as "Good, Better, Best" and try to think about what your requirements are. For example, if you're running a relatively small business and you primarily use Office 365 to deliver email via Exchange Online and you simply want to provide some controls around how all your users access email away from the office then you may find that MDM for O365 does enough for you.

If you’re running a rather more sophisticated cloud presence where you’re making use of more Office 365 capabilities, where your users might be a bit more mobile, or logging in from a wider range of devices and you wish to be able to control application use from BYOD devices, or you have users running MacOS, then Microsoft Intune is probably the right level for you.

If you’re after still more granular control, if you wish to have different sets of requirements for access to systems, if you’re running a large business who places a lot of data and services in the cloud, if you wish to track data and user access patterns in detail and lock down access to applications or data depending on different levels of “risk” attached to a log-in attempt (e.g. risky sign-ins) then you will need the full Microsoft EM+S licence.

As ever with Microsoft, there are many different combinations of licences you can buy and assign to your users to give you these capabilities. I’m not going to break them down in detail here but in broad strokes, you can think of the basic Office 365 E3 enterprise licence (or A3 for education) as giving you MDM for O365.

You can add Intune by itself as a specific item if you just need slightly more control on top of the basic package, and if you need Office 365 and EM+S then you probably should look at the Microsoft 365 Enterprise packages that provide Windows licences, Office 365 licences and EM+S all in one package. There are all kinds of options and deals available depending on what you need so other than pointing out that the different tiers are there, I’m not even going to attempt to explain them here.

I’ve already talked about some more advanced concepts such as using Intune to deliver Password resets to Windows domain devices, and in the next post I will look at assigning licences and enrolling devices.

Chocolatey in the workplace

Mon, 03 Sep 2018 11:33:55 +0000

I talked previously about using Chocolatey for home use. It makes building a PC at home nice, simple and fast. It makes supporting non-technical friends and family nice and easy, ensuring you can build their computers how they want and keep them up-to-date with just a few simple commands (that can even be put in the scheduler, so neither you or they have to worry about them).

We’ve recently just completed a Windows 10 rollout at my college. I’m very pleased with it and, I think, the college’s staff and student customers also seem quite pleased. One of my team has worked incredibly hard on producing a perfect build of Windows 10 that revolves around a large image with most of the applications pre-installed. As we use SCCM and this is quite happy to deploy packages on a piecemeal basis itself, we had a lot of discussion about this and while we still think that SCCM is incredibly useful, it does have a few limits:

It's based around old technology. SCCM is a development of Microsoft's Systems Management Server and frankly, it shows. There are all kinds of weird and wonderful legacy dead ends to get lost in. This leads to...
It's incredibly complex to use. If you're someone like Boeing or Microsoft themselves then it's about as complex as you need it to be, but for your average SME, a lot of the features are overkill.
It's not terribly reliable. Let me explain: When you build a machine with SCCM you can assign several packages of configuration items (e.g. packages, settings) as part of the initial task sequence and these should all install fairly reliably. Packages that are installed after this initial task sequence seem to install in their own time. Debugging why these packages fail or take excessively long to install requires expert debugging of potentially dozens of logs spread between the client and the server.
SCCM requires a large and complex infrastructure deployment, potentially with many multiple servers needed for even a relatively simple SCCM deployment.

Chocolatey isn't a magic fix for these issues but it does have a number of advantages:

Package installation is managed by the client (though you can push instructions to the client) and is much easier to predict and control.
It's easier to upgrade packages with newer versions with Chocolatey vs. the process on SCCM to supersede old packages.
Chocolatey's server infrastructure is relatively lightweight.
Chocolatey packages allow you to ensure that a package is installed consistently whether manually or by automation - the install method is the same choco install $package -y command line statement either way and should produce the same result either way... which also makes it easy to examine and debug any issues.
Chocolatey allows you to install packages in a particular order. Of course you can do that with SCCM now, but if you're looking at Intune and thinking of deploying Win 32 packages via powershell profiles then you might have noticed that powershell scripts don't run in a particular order which means that any dependencies have to be resolved by you. Chocolatey also supports dependencies internally, by the way.

We're currently using a hybrid deployment where we've built a "classic" image for our deployment but installed some of the packages into that baseline using chocolatey. This has improved our ability to generate new, consistent images much faster as well as being able to update packages in the future via chocolatey's own update model, which will work well for devices that aren't always on site.

With a combination of Chocolatey and a few other PowerShell tricks, it’s possible to run a couple of scripts to join a device to your domain and then install a baseline set of packages, as per my example scripts below.

Join domain and restart device

set-executionpolicy unrestricted # Self-elevate the script if required if (-Not ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] 'Administrator')) { if ([int](Get-CimInstance -Class Win32_OperatingSystem | Select-Object -ExpandProperty BuildNumber) -ge 6000) { $CommandLine = "-File `"" + $MyInvocation.MyCommand.Path + "`" " + $MyInvocation.UnboundArguments Start-Process -FilePath PowerShell.exe -Verb Runas -ArgumentList $CommandLine Exit } }
Portable build script 1. Should be run on a Windows 10 Professional system that we wish to “build” as a domain device

Does the following:

1. Ensure we’re elevated and if not elevate the session

2. Remove ‘bad’ apps that simply shouldn’t be on the workstation

3. Join the domain, placing the device in the Admin\Laptops OU in Workstations

3. Change product key to a Windows 10 Enterprise KMS key. This ‘upgrades’ the system to Windows 10 enterprise but…

…. the system MUST be on the network to find a KMS server on restart.

############ LAST UPDATE: 08/02/2018 Rob

If you’re in this list you’re being uninstalled

Get-AppxPackage officehub | Remove-AppxPackage Get-AppxPackage skypeapp | Remove-AppxPackage Get-AppxPackage getstarted | Remove-AppxPackage Get-AppxPackage zunemusic | Remove-AppxPackage Get-AppxPackage bingsports | Remove-AppxPackage Get-AppxPackage xboxapp | Remove-AppxPackage get-appxpackage oneconnect | remove-appxpackage get-appxpackage phone | remove-appxpackage get-appxpackage candy | remove-appxpackage

Prevent random “cloud content” nonsense from downloading

reg add hkey_local_machine\software\policies\microsoft\windows\cloudcontent /v DisableWindowsConsumerFeatures /t REG_DWORD /d 1

Join the domain. Note credentials below for a non admin account with unlimited domain join rights.

$domain = “your.domain.example.com” $username = “$domain\account” $password = “Hunter2” | ConvertTo-SecureString -asPlainText -Force

$credential = New-Object System.Management.Automation.PSCredential($username,$password) Add-Computer -DomainName “your.domain.example.com” -OUPath “OU=scripted,OU=build,OU=Workstations,OU=MySite,DC=your,DC=domain,DC=example,DC=com” -Credential $Credential

change product key to your enterprise KMS workstation key and force a reboot.

Changepk.exe /ProductKey #####-#####-#####-#####-#####

shutdown /t 0 /r

Chocolatey Software Build

set-executionpolicy unrestricted # Self-elevate the script if required if (-Not ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] 'Administrator')) { if ([int](Get-CimInstance -Class Win32_OperatingSystem | Select-Object -ExpandProperty BuildNumber) -ge 6000) { $CommandLine = "-File `"" + $MyInvocation.MyCommand.Path + "`" " + $MyInvocation.UnboundArguments Start-Process -FilePath PowerShell.exe -Verb Runas -ArgumentList $CommandLine Exit } }
Portable build script 2. Should be run on a Windows 10 Enterprise system that we wish to “build” as a college device

Ensure that machine is Win 10 enterprise and domain joined first (run the domain join script first!)

Does the following:

1. Ensure we’re running as admin and elevate if we’re not

2. install chocolatey

3. install apps using chocolatey repository

############ LAST UPDATE: 08/02/2018 Rob

Now running elevated so launch the script:

install chocolatey, chocolatey apps

Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString(‘https://chocolatey.org/install.ps1')) choco install -y office365-2016-deployment-tool /Shared

choco install -y adobe-creative-cloud

choco install -y sql-server-management-studio choco install -y 7zip.install choco install -y vlc choco install -y googlechrome

Done, now reboot

shutdown /t 0 /r

You can obviously pick and choose from these examples as you wish.

Backup to the cloud.

Sun, 26 Aug 2018 15:47:17 +0000

Introduction

So I think a lot of us take backups for granted. It's one of those things you look at once and then tend to not worry about too much. As long as its working, why worry?

Except… if you don’t look at it, how do you know how well its working? I’m talking from the viewpoint of a senior engineer or manager here of course, hopefully if you’re a junior engineer who has been put in charge of backups you’re making sure that the current system works well and telling people about any concerns you might have. If not, go do that now. I’ll still be here, I promise.

So a couple of things have been stirring in my mind lately. Firstly is the incredible story of NotPetya and the impact it had on businesses all over the world. One especially poignant story is that of Maersk and it’s told very well in an incredible article on the Wired website.

Now, I’m possibly tempting fate here but I can say that my employer has not had serious threats from this kind of malware attack. I’m going to put some of that down to good work by my team, some of that down to not being a very interesting direct target and some of that down to good old-fashioned grace-of-God (or luck if you prefer to call it that).

But we shouldn’t be taking any of those things for granted. Not me, not you. So with thoughts of what malware might do to an on-site backup repository in mind, I was already thinking of alternatives.

One of the issues my employer has, as an educational establishment, is funding to undertake major projects. We’ve had a quantum tape library on-site for some time and used it with Arcserve backup and this actually worked very well. I’ve got no complaints about either product. One issue we did have due to funding was getting the money available to tackle both hardware and software components of our backup system at the same time, as the two items tended to have different life-cycles.

One of the worst reasons I can think of to do something is “because that’s always what we’ve done” so after a bit of creative work on budgets and schedules, I was able to line up all the components of our backup system to be evaluated and replaced or renewed together.

And I found something interesting.

The cost of backups

One of my frequent "go to" phrases goes along the lines of "if you think doing it right is expensive, you should see the real cost of being too cheap" and this obviously applies to backups. You need a robust and reliable system that you can count on to work without too much day-to-day intervention. You need to carry out test restores from your system so that you can trust it. Most important of all, you need a backup environment your team understands and believes in, so that they can transfer that belief to others in the business.

Now that we’ve established that whatever backup you choose needs to be one that works and that there’s more to cost than the price, we can talk about the price.

The figures below reflect the college’s investigation into our needs some time ago. They should be taken as simple examples and comparisons and are not indicative of the prices that a supplier or vendor might be using now.

On-Premises backup to tape

Tape backups have served the college well over time but I think they are becoming less useful and relevant to where we want to be as a college in 2018.

Tapes deteriorate over time and both software and standards change. Simply having data on a tape from 6 years ago is no guarantee we can retrieve the data.
Tapes are currently stored on-site at some expense and require manual intervention to be changed. New tapes need to be purchased and old ones need to be retired. To achieve true business resilience, we need to store data off-site and this will cost at least £1,440 a year, plus our time managing that service.
We don’t refer to the tape backups very often. We’ve been retaining data for several years but have only used tape to restore data a couple of times in the past few years, when it’s proven to be a lengthy experience.

If we keep going with tape we will need to replace the current tape library with a new one, as it has reached the end of its useful life; it was purchased in 2012 and is based around LTO5 and is out of manufacturer’s support.

The figures below are for a similar replacement: 2 drives in a library that has a capacity of 50 drives (which we currently have) but only licenced for 25 slots. We will need to upgrade the slot licence at some point in the life-cycle but we could start with the 25 slot licence.

Quantum i3 tape library. This would cost £13,068. We would stick with Quantum because we’re familiar with it, we know it is compatible with our hardware (e.g. it should just plug into the server the current library is using) and we know it is compatible with the Arcserve software.

We will also need new tapes, fitting the new LTO 8 standard. To fill this library and have a complete set of replacements we will need three of the 20 tape library packs. The cost of these is £3,211 each.

We will also need to continue the Arcserve licence, which will cost £11,996 a year Ongoing costs would be the Arcserve licence and a box of tapes a year, so:

If we consider the tape library to have a 6-year life span, we can divide the cost of the initial purchase of tapes and tape library over the lifespan of the device to get £3,785.50 and add that to the yearly costs to say that it would cost us £20,230.50 a year to continue tape backups for the next 6 years.

Backup to the Cloud

After some thought we decided to look at Azure for our backup storage provider, so the rest of this article talks about the cost of using Azure for backups. You might have better reasons to use AWS or someone else than we did, and the prices again should be taken as an indicator based on when the research was first done, not a guarantee of what you might pay yourself at the time of reading.

One thing that occurred to us with backup to the cloud is that we could use Microsoft System Center Data Protection Manager to manage our backups. This was a no-cost option for us due to the licence terms we already had with Microsoft. and this obviously makes a huge difference to the bottom line numbers.

“Cloud backup” is something of a marketing term. We’re going to continue to use it here, but it’s worth remembering that what we’re talking about is more formally referred to as “using Microsoft Azure Backup to store backups and replicas of our systems and data off-site in EU and UK data centres”.

With this proposal, we proposed deploying Microsoft’s backup software on-premise and have that create a backup of all our systems and data to an on-premises storage server. We will then choose to have some of these backups extended into the cloud so that they’re safely stored off-site.

Systems that will only be backed up on-site will be “non-essential”, which typically means services that can be relatively easily rebuild in the event of a major incident. Systems and data that will be backed up to the cloud will include systems that would be extremely difficult to reconstruct and/or data that would be impossible to re-create.

To give an example, the student CRM “Front End” server, which only contains information about how to render CRM data would be backed up locally, as it would be trivial to reconstruct this after a major disaster. The data held and used by the CRM system, which is stored in one of our main database servers would be backed up to the cloud as part of the backup of the database server.

How does Azure work?

Backup pricing in Azure is costed fairly simply. You pay to use backup services to the tune of £7.50 a month for a 500Gb “instance”. This means that a basic application server that uses 200Gb of space will use 1 instance of £7.50 a month. A major file share server that uses 1200Gb of space will use 3 instances, £22.50 a month.

On top of this, we also pay for storage we use, depending on redundancy and tiers.

Redundancy levels refer to how Microsoft protect data stored in Azure. LRS, ZRS or GRS refers to how the data is replicated around the Azure infrastructure, and is explained in detail here.

The choices for backup vaults seem to centre around LRS (Locally Replicated) and GRS (Globally Replicated). LRS means that the data is replicated only within the same datacentre, and GRS means that the data is replicated globally between several Microsoft data centres around the world, and costs more to use. We chose “LRS” for our backup vault as it seemed to us that the backup copy in Azure would be the third copy of the data we would have in normal operating conditions (e.g. live working server, local backup, cloud backup) and that was good enough for us.

You should make your own assessment of your requirements and base your decision on that. For example, if we had an extensive cloud deployment of VMs with irreplaceable data on them it would make sense to consider globally replicating the backup vault for that data with GRS, just in case…

Tiers relate to speed and ease of access, and are referred to as “Hot”, “Cool” and “Archive” tiers. Archive tier is designed to be written to often and read from rarely and is costed favourably to that model. As we’re anticipating keeping backups on-site and only using Azure storage for recovery from a major disaster, we’re proposing that all our backups are made to Archive storage. If we find we’re reading backups from cloud for one or two systems on a regular basis then those systems should be migrated to backup to the ‘cool’ tier.

We can combine the pricing per tier with the pricing per instance to get example pricing for the 200Gb application server we mentioned before. (Note that you pay for instances in 500Gb steps but pay for the precise storage you use per Gb.

So to backup the application server would cost £7.50 plus archive storage (0.0017 * 200) £0.34 = £7.84 per month.

To back up our example major file share server will use 3 instances (£22.50) plus archive storage (0.0017 * 1200) £2.04 = £24.52 per month.

With all this in mind, we looked at the data we would be moving off-site and felt that it should cost about £2900 to implement the project as a one-off cost in the first year, with storage costing £7000 p.a. assuming our storage space needs stay roughly neutral (1). This represents a notable saving in the first year and we’ve gone down that road quite happily.

DPM could be a little less moody to work with, admittedly, but we can re-assess whether we wish to use other backup software to write to our Azure data vault in the future.

In terms of business continuity, by moving backups off-site we have some isolation not just from the obvious (and probably least likely) disasters that people think about when talking about this kind of thing but also from malware that hijacks local servers and encrypts or deletes data. You’d have similar isolation from malware with tape of course, but you’d still need to get the data off-site.

(1) Future storage requirements are an interesting one. Normally you anticipate growth when modelling storage and backup plans for the future but as we’ve migrated all our mailboxes to Office 365 in the past and we’ve just finished migrating our SharePoint sites in to Office 365 also, coupled with a strategy to push OneDrive for Business hard at our staff and students vs. our need for ever greater report generation and processing of CRM data, I can see our storage requirements staying neutral or even decreasing in terms of capacity, while the requirement for faster storage to improve database performance increases.

Tuning up Intune - Self Service Password Reset from the login screen.

Thu, 23 Aug 2018 13:28:19 +0000

Introduction

One of the new features in Windows 10 1803 is the ability for "local Active Directory" Domain joined workstations to allow users to reset their password from the login screen. This was introduced for Azure Active Directory joined systems in Windows 10 1709.

In this post I’m quickly going to run through what you need to do in order to configure this for your domain. I’m making the following assumptions:

You have Azure AD configured, and have sync working for local AD users to AAD.
You have the correct Office 365/Azure Azure Active Directory Premium, Intune / Enterprise Management Suite licences already enabled and assigned to users.
You have configured Self Service Password Reset for your Azure AD Domain, including password writeback (e.g. your test users can use https://aka.ms/sspr to reset their password from a web page). If not, see here. SSPR from the login screen will not work if SSPR isn't already properly configured.
You have some Windows 10 1803 devices joined to your domain for testing.

Getting Started

In order to configure SSPR on the Windows 10 login screen you will need to do the following:

Configure Hybrid Azure AD join for your target computers.
Configure your devices to be managed by Intune, Microsoft's MDM component in Office 365/Azure Active Directory.
Configure a couple of Intune Profiles with settings for your target computers, and apply these to the test computers.
Assign your Intune SSPR profiles to your target computers.
Test... and you're (hopefully) done.
Troubleshooting

Configuring Hybrid Azure AD Join

As you probably know if you're the kind of person who reads IT techie posts past the first few paragraphs, in order to manage computers in a traditional enterprise network, you would join them to a directory service such as Active Directory (AD), which would give you a central place to create and configure users to log on to those computers, along with settings for your users and devices. As you probably know if you're looking at an article on configuring Microsoft Intune, you can also have users and devices connected to Azure Active Directory (AAD), which allows you to create and manage computers and users in AAD.

It’s been possible with a variety of tools over the years to synchronise user accounts between your on-premise AD and AAD. This has typically been used to move user mailboxes to the Exchange Online component of Office 365 without having to maintain two different accounts for the same user, as this would be a huge pain for both the users and the IT department. The current tool that Microsoft provide for synchronising account details between AD and AAD is known as AD Connect. At the time of writing, the current version is 1.1.888.0, which was released to fix a really annoying bug with high CPU use in AD Connect 1.1.819.0.

From the release of AD Connect 1.1.819.0, Microsoft have greatly simplified the configuration of Hybrid AAD join, enabling you to complete all of the configuration steps from the AD Connect wizard in most cases. I’ve used this to configure our Hybrid AAD join and it did everything for me, including re-configuring our AD FS farm correctly which I know scares more than a few people away from configuring Hybrid AAD join.

There are lots of good reasons to keep your AD Connect setup up-to-date and this is one more very important reason among other good reasons such as enabling automatic updates, general bug and performance fixes, etc. You can review the AD Connect release notes and version history and grab the latest copy from here, and if you use AD Connect at all I strongly suggest that you do so every few months.

Once you’ve configured Hybrid AAD join and allowed time/triggered an update in whatever method you’re using, you can verify that computers from Active Directory are being imported into AAD by opening your Azure Active Directory Portal, going to all devices and searching for a computer you know should be synchronised.

Hopefully you will find your device is now visible in AAD. Check the join type and it should say “Hybrid Azure AD joined”. This means that this has been syncronised from your local AD. If you’re doing this via AD Connect you should also be able to open the AD Connect Synchronization Service Manager and see the devices you’ve chosen to sync included as “Adds” in what will probably a fairly hefty Delta import job.

Configure your devices to be managed by Intune.

The next step after getting the devices in to AAD is to have them managed by Intune. If you're following this along with me, you'll need to configure Intune to act as your MDM Authority for the target devices and then use Intune to manage settings related to SSPR on those devices.

Enabling Intune

To enable Intune, if you've not done so already, go to your Azure Portal, open Azure Active Directory and select "Mobility (MDM and MAM)". From here, select "Microsoft Intune". The Configuration options for Intune will appear.

Note the two options for MDM (Mobile Device Management) and MAM (Mobile Application Management). If that confuses you then you’re not alone but broadly speaking, the difference is that MDM is targeted to managing devices that your org controls and MAM is targeted to managing Applications and data, whether or not you control the device.

The main thing to consider for what we’re talking about here is that your MAM and MDM scopes cannot overlap. Users and devices need to be managed by one or the other and there cannot be a clash. You can choose to work with just MDM as in the example above where the scope for MDM is set to “All” and the MAM scope is set to “None”, or you can choose to just target some users and devices for MDM and target some others for MAM by selecting “Some” and targeting groups for MDM and MAM respectively.

To add the Intune to your Azure portal shortcuts the way I’ve done here, go to “All Services”, search for “Intune” and “star” it as a favourite. Then drag to where you want it in your list.

Enrolling a device in Intune

In Azure Active Directory, create some test groups for users and devices you wish to target for Intune, and populate them with your test subjects. Being able to see computer accounts in AAD and assign them to groups is another test of the Hybrid Azure AD Join, by the way.

In this example we have two groups for test devices, one that we’re using to apply general Windows 10 device profiles, and one that we’re using specifically to test SSPR.

Next, go to Intune to enroll your devices. From the main Intune home screen, select “Device Enrollment” and verify that your Tenant name looks right, that your MDM authority is set to Intune and your account status is Active.

With that all in order, return to Intune Home, then go to Device Compliance, then Policies, then click “Create Policy”. Create a policy by giving it a name, setting the platform to target Windows 10 and later, and working through Device Health, Device Properties, System Security and Windows Defender ATP settings.Still in your policy, choose Assignments and under “Include”, assign your target users (either “All Users” or a previously created and populated group of test users).

Doing this will ensure you will get a view of the “device health” of devices that enroll into Intune.

Now we’ve done the following:

Enabled Azure AD Hybrid Join for our on-prem Windows 10 devices, and verified that's worked.
Enabled Intune and configured it to enroll our Windows 10 devices.

We are now ready for the next step, configuring Auto-MDM enrollment group policy settings in our local AD.

Move your test devices to their own OU in Active Directory.
Create and link a new GPO to this OU.
In the GPO, open Computer Configuration, Policies, Administrative Templates, Windows Components, MDM.
Set "Auto MDM Enrollment with AAD Token" to Enabled.
(If you've got it set to Enabled elsewhere) also set "Disable MDM Enrollment" to "Disabled".

For more information about this process, see this Microsoft article.

This will now create a set of scheduled tasks on each computer in that OU that will attempt to enroll that device into Intune.

You can view these tasks in Task Scheduler, Microsoft, Windows, EnterpriseMgmt,{guid}. You can view how these tasks are behaving in the event viewer, under Applications and Services Logs, Microsoft, Windows, DeviceManagement-Enterprise-Diagnostics-Provider.

It’s normal to see a few errors here during the first attempts to connect to Intune, which are typically Event ID 76 messages in the Admin log here. All being well they should settle down and you should see successful enrollment messages (Event ID 72 and 75).

If not, check your network firewall isn’t preventing your devices from reaching the URLs/IPs mentioned in this article. If you’re still having trouble, I’ve found the foxdeploy article on Intune enrollment troubleshooting to be very useful.

Once you have this working you can verify that the Intune console can see the device by going to Intune home, Devices, All Devices and searching for the device name.

In the example above, devices 10370, 10745 and 10868 are all working correctly. They’re imported into Azure AD correctly and they’ve successfully run the MDM auto-enrollment task, changed their management authority to Intune and applied the compliance policy.

10758 is an example of a problem you might have in a mixed SCCM/Intune environment where a machine has failed to change its MDM authority to Intune because it has the SCCM agent on it. I’ll be discussing how to fix that in another article.

Testing Intune Profile Management.

Before we proceed with deploying SSPR settings, it's wise to apply a test Intune profile and make sure that behaves as expected. Device or User profiles are how you apply settings to target

You don’t have to do this but if you’re new to Intune then it’s a good idea to make sure you’re comfortable with applying a harmless setting before pushing out something that might cause issues.

We’re going to push out a profile to change the desktop wallpaper on managed computers. To do this, go to Intune Home, Device Configuration and Profiles. Select Create Profile. Give your profile a name and select “Windows 10 and later” under Platform. Under Profile type, select “Device Restrictions”.

Under Device Restrictions, Select Locked Screen Experience and put in a URL that links directly to a suitable graphics file.

Click OK to close the Personalization window, Click OK to close Device Restrictions then on your profile’s property page, click “Save” to save the profile.

Now we need to assign the policy. Click Assignments, choose an appropriate target device group under “Include” and click Save again. You may want to choose a more modest scope for your test deployment than I’m using below, though “All Users & All Devices” here does only refer to objects that are already enrolled in Intune.

Note that the setting we’ve changed, the login screen wallpaper basically, applies to devices. We need to test our ability to target devices rather than users, as SSPR is also a change to the device.

Now we play the waiting game while we wait for the test devices to receive and apply the updated profile.

Assign your Intune SSPR profiles to your target computers.

Now we've proven that we can control Windows 10 devices via Intune and push profiles down and see them apply, we can create a couple of profiles to enable SSPR.

There are two items to push down to your test devices, and each will require its own profile. Note that we are pushing these profiles down to groups of devices, not people. We are changing the way the devices work, not configuring user options.

Creating your Windows 10 SSPR Device Configuration profile.

Go in to Device Configuration and create a new Intune profile as before, selecting Windows 10 and later for the Platform, and Custom for the Profile Type.

We will now create a custom OMA-URI setting under the Settings tab.

Give the setting a meaningful name. Or not, it's not me who has to document it later.
For OMA-URI, put ./Vendor/MSFT/Policy/Config/Authentication/AllowAadPasswordReset
For Data type select Integer
For Value, type 1.
OK out of this setting and save the profile.
Under Assignments, assign this profile to your target devices.
Save this profile and now you're ready for the next part.

The next setting we need to deliver is a registry change. There's a number of ways to do this but I'm going to walk through making the change via Intune, because I feel it makes sense to keep as much of the deployment settings in one place as possible, but if you have a preferred method for delivering registry changes to devices then go for it.

Create a powershell .ps1 file with the code below in it and give it a sensible name:

# # Rob 22/8/2018 Adds SSPR registry entry to Windows 10 computers (see [docs.microsoft.com/en-us/azu...](https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-sspr-windows)) # This script will create the registry path, key and value if they're not present. If it's present, it will update the value to ensure it's correct. # $registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\AzureADAccount" $Name = "AllowPasswordReset" $value = "1" IF(!(Test-Path $registryPath)) { New-Item -Path $registryPath -Force | Out-Null New-ItemProperty -Path $registryPath -Name $name -Value $value ` -PropertyType DWORD -Force | Out-Null}
ELSE { New-ItemProperty -Path $registryPath -Name $name -Value $value ` -PropertyType DWORD -Force | Out-Null}

From Device Configuration, open PowerShell Scripts and choose "Add". Give the PowerShell script profile a sensible name like "SSPR Registry Setting" and upload the .ps1 file we created previously.

Under Settings, ensure that both “Run this script using logged on credentials” and “Enforce script signature check” are set to No. Once you’ve created the profile, assign it to your test machine group the same as we did for the OMA-URI profile.

If you want to create the registry key by other means, the path you want is: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AzureADAccount (you may need to create the “AzureADAccount” key. You need to create a dword entry named “AllowPasswordReset” here and assign the value “1” to it.

That’s it. Once the profiles we’ve just created have applied to your test machines, that in theory is all you need to do.

Test... and you're (hopefully) done.

If all is well, you should see "Reset Password" under the normal Windows Login dialogue.

Select this and you should hopefully be taken through a SSPR interface that is similar to the web page SSPR process. Assuming this happens and it completes without errors, congratulations, you’ve read a fairly long blog post and configured SSPR for your AD devices. I’d call that a decent job!

Troubleshooting

We're making the assumption at this point that you've got devices enrolled successfully in to Intune.

No Reset Password link appears.

If the Reset Password link does not appear, this suggests the settings we created in the profiles above are either incorrect or are not being applied correctly. This is why assigning a test profile for something harmless like wallpaper is a good idea before trying to roll out more complex settings, so if you haven't done that already, try creating that test profile now, assign it to the same machine groups as your SSPR profiles and check that it applies as expected.

To further troubleshoot, we can look at the profile we’ve created for SSPR, by going to Intune Home, Device Configuration, then Profiles. Now select the SSPR profile and you should be taken to the overview screen for this profile. In an ideal world this would be a nice big green circle like our example, showing that the target devices have all applied the profile correctly.

If there’s an issue here, you should see a colour coded entry to tell you what went wrong.

You can troubleshoot the powershell script profile in a similar way. You can also run regedit on a target machine and look for the registry entry (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AzureADAccount). If it’s not there and you don’t want to delay testing of SSPR you can then also cheat a little by manually creating the entry using the notes in the previous section.

Reset Password link is there but does not work.

I've had some fun with this. It appears that SSPR on the desktop is rather sensitive to GPOs that change the login experience in any way. A symptom of this is that the Reset Password button appears, but clicking it doesn't result in the expected login to the SSPR recover page and instead you just get dropped back to the login screen.

After a very long twitter conversation with Nick Wiley (@npwiley), in which we’ve discovered that we’ve both got things working by setting directly opposite settings at one point, I’m just thinking that the best approach is to not attempt to manage the login experience with GPOs at all and just use modern management. (See below for twitter thread.)

So, this is something of an uncertain ground. From Nick’s tests (he’s done more of the heavy lifting here than I have, and deserves the credit), the main policy/setting to worry about at the login screen is the policy that blocks app notifications.

twitter.com/npwiley/s…

twitter.com/RobertoMo…

twitter.com/npwiley/s…

My Server’s been hacked – What do I do now? Pt 3.

Wed, 14 Mar 2018 20:12:33 +0000

Finally. Finishing up after Part 1 and Part 2, this is the end of my updated thoughts on an old Server Fault post with some final thoughts on reducing risks in the future.

Reducing the risk in the future.
The first thing you need to understand is that security is a process that you have to apply throughout the entire life-cycle of designing, deploying and maintaining an Internet-facing system, not something you can slap a few layers over your code afterwards like cheap paint. To be properly secure, a service and an application need to be designed from the start with this in mind as one of the major goals of the project. I realise that's boring and you've heard it all before and that I "just don't realise the pressure man" of getting your beta web2.0 (beta) service into beta status on the web, but the fact is that this keeps getting repeated because it was true the first time it was said and it hasn't yet become a lie.
You can’t eliminate risk. You shouldn’t even try to do that. What you should do however is to understand which security risks are important to you, and understand how to manage and reduce both the impact of the risk and the probability that the risk will occur.

Risk management for those who have never heard of risk before. I think this latter part of the original post reads as rather naive now… and yet people still seem to struggle to break out of the traps that this advice is designed to prevent.

What steps can you take to reduce the probability of an attack being successful?
For example:

Was the flaw that allowed people to break into your site a known bug in vendor code, for which a patch was available? If so, do you need to re-think your approach to how you patch applications on your Internet-facing servers?

Was the flaw that allowed people to break into your site an unknown bug in vendor code, for which a patch was not available? I most certainly do not advocate changing suppliers whenever something like this bites you because they all have their problems and you'll run out of platforms in a year at the most if you take this approach. However, if a system constantly lets you down then you should either migrate to something more robust or at the very least, re-architect your system so that vulnerable components stay wrapped up in cotton wool and as far away as possible from hostile eyes.

Was the flaw a bug in code developed by you (or a contractor working for you)? If so, do you need to re-think your approach to how you approve code for deployment to your live site? Could the bug have been caught with an improved test system, or with changes to your coding "standard" (for example, while technology is not a panacea, you can reduce the probability of a successful SQL injection attack by using well-documented coding techniques).

Was the flaw due to a problem with how the server or application software was deployed? If so, are you using automated procedures to build and deploy servers where possible? These are a great help in maintaining a consistent "baseline" state on all your servers, minimising the amount of custom work that has to be done on each one and hence hopefully minimising the opportunity for a mistake to be made. Same goes with code deployment - if you require something "special" to be done to deploy the latest version of your web app then try hard to automate it and ensure it always is done in a consistent manner.

Could the intrusion have been caught earlier with better monitoring of your systems? Of course, 24-hour monitoring or an "on call" system for your staff might not be cost effective, but there are companies out there who can monitor your web facing services for you and alert you in the event of a problem. You might decide you can't afford this or don't need it and that's just fine... just take it into consideration.

Use tools such as tripwire and nessus where appropriate - but don't just use them blindly because I said so. Take the time to learn how to use a few good security tools that are appropriate to your environment, keep these tools updated and use them on a regular basis.

Consider hiring security experts to 'audit' your website security on a regular basis. Again, you might decide you can't afford this or don't need it and that's just fine... just take it into consideration.

Again, I don't have much to add to this, except to say that it feels that this hasn't aged that well. In the era of 'Move fast and break things' the idea that we have time to do most of this seems ludicrous. Of course we're going to have a smooth deployment route for software from dev to test to prod (Of course, everyone has a test and dev environment, but not everyone has a separate production environment) . Of course we're going to re-architect all our functions at the drop of a Hacker News post about a new framework... but we don't have time to be formal about it.

Again, we’re back to easy deployment of both systems and code, making both platforms disposable and easy to replace. This isn’t the holy grail of never being a victim of intrusions either, but it can help to mitigate some of the risks if it’s done well and you are certain your developers and the dev/test environments are secure.

What steps can you take to reduce the consequences of a successful attack?
If you decide that the "risk" of the lower floor of your home flooding is high, but not high enough to warrant moving, you should at least move the irreplaceable family heirlooms upstairs. Right?

Can you reduce the amount of services directly exposed to the Internet? Can you maintain some kind of gap between your internal services and your Internet-facing services? This ensures that even if your external systems are compromised the chances of using this as a springboard to attack your internal systems are limited.

Are you storing information you don't need to store? Are you storing such information "online" when it could be archived somewhere else. There are two points to this part; the obvious one is that people cannot steal information from you that you don't have, and the second point is that the less you store, the less you need to maintain and code for, and so there are fewer chances for bugs to slip into your code or systems design.

Are you using "least access" principles for your web app? If users only need to read from a database, then make sure the account the web app uses to service this only has read access, don't allow it write access and certainly not system-level access.

If you're not very experienced at something and it is not central to your business, consider outsourcing it. In other words, if you run a small website talking about writing desktop application code and decide to start selling small desktop applications from the site then consider "outsourcing" your credit card order system to someone like Paypal.

If at all possible, make practising recovery from compromised systems part of your Disaster Recovery plan. This is arguably just another "disaster scenario" that you could encounter, simply one with its own set of problems and issues that are distinct from the usual 'server room caught fire/was invaded by giant server eating furbies' kind of thing.

Good business principles that I hope that most people who have a formal web presence are following for their Internet-facing systems. I still get lots of requests for help from people working in smaller businesses where this just isn't done... until it's too late.

Finally:

I think the main shift in managing intrusions has been to data being the most important thing. Remember your legal obligations to the people whose data you hold, and remember to work on your deployments.

If you are scared to rebuild any system or service in your business then this is a critical weakness, both in terms of intrusion and in terms of risk to the business if it fails through “natural” causes.

Outsource where applicable. Microsoft Azure, Google Cloud and Amazon AWS are highly likely to be better than you at standing up virtual platforms for public web servers (don’t take this personally, they’re better than me too). Microsoft and Google are highly likely to be better than you at managing email services (again, don’t take it personally, me too).

Each time you outsource intelligently you’re buying into improved security and freeing up your time from mundane tasks to think about how to manage and protect the things that really matter; your business, its customers, and all your data.

My Server's been hacked - What do I do now? Pt 2.

Wed, 14 Mar 2018 19:38:21 +0000

Following on from Part 1 of my revision of an old Server Fault post, we will continue on to look at remediation after an intrusion.

(Part 3 available here)

Understand the problem fully:

Do NOT put the affected systems back online until this stage is fully complete, unless you want to be the person whose post was the tipping point for me actually deciding to write this article. I'm not going to link to that post so that people can get a cheap laugh, but the real tragedy is when people fail to learn from their mistakes.

Examine the 'attacked' systems to understand how the attacks succeeded in compromising your security. Make every effort to find out where the attacks "came from", so that you understand what problems you have and need to address to make your system safe in the future.

Examine the 'attacked' systems again, this time to understand where the attacks went, so that you understand what systems were compromised in the attack. Ensure you follow up any pointers that suggest compromised systems could become a springboard to attack your systems further.

Ensure the "gateways" used in any and all attacks are fully understood, so that you may begin to close them properly. (e.g. if your systems were compromised by a SQL injection attack, then not only do you need to close the particular flawed line of code that they broke in by, you would want to audit all of your code to see if the same type of mistake was made elsewhere).

Understand that attacks might succeed because of more than one flaw. Often, attacks succeed not through finding one major bug in a system but by stringing together several issues (sometimes minor and trivial by themselves) to compromise a system. For example, using SQL injection attacks to send commands to a database server, discovering the website/application you're attacking is running in the context of an administrative user and using the rights of that account as a stepping-stone to compromise other parts of a system. Or as hackers like to call it: "another day in the office taking advantage of common mistakes people make".

This is where having a good incident manager is invaluable. It's her job to deal with pressure to get services back online quickly and balance that against the complexity of determining the extent of an intrusion.

The technical team investigating the intrusion, determining damage, etc. should be carefully shielded from immediate interference by well-meaning executives who may be making decisions based on emotions or bad publicity. That isn’t to say that the technical team can take all the time in the world either; nothing undermines customer confidence like a slow response or services that are offline for a very long time. There’s a balance between the various priorities and it’s up to the incident manager to make sure everyone is aware of that balance.

It’s important to be thorough when investigating the root cause and the extent of an intrusion so that you can give a correct and concise response when customers (or the press if you’re a larger organisation) press you for information. No one likes uncertainty and people will want an accurate response to questions about what happened to their data and what they need to do next.

It’s also important to understand the nature and extent of any intrusion in order to be sure you have correctly dealt with it. This again is a matter allowing competent people the time to be thorough in their examination of all potentially affected systems. This brings me back to my point in part 1 about worrying about services and “scale out” rather than small numbers of custom servers. This can both minimise exposure and improve your return to production; e.g. if intruders break into your front end web servers and the only thing they can directly access is web site code, you’ve hopefully minimised the impact of the intrusion (don’t misunderstand me, this is still very bad!) and hopefully you’ve also made it relatively easy to update the vulnerable front end code and redeploy new web servers.

Why not just "repair" the exploit or rootkit you've detected and put the system back online?
In situations like this the problem is that you don't have control of that system any more. It's not your computer any more.
The only way to be certain that you’ve got control of the system is to rebuild the system. While there’s a lot of value in finding and fixing the exploit used to break into the system, you can’t be sure about what else has been done to the system once the intruders gained control (indeed, its not unheard of for hackers that recruit systems into a botnet to patch the exploits they used themselves, to safeguard “their” new computer from other hackers, as well as installing their rootkit).

Can’t think of much to change here except to say that this is more true now than it ever was, if anything. Once you’ve lost control of a server it can no longer be trusted. These days there are just too many ways to hide exploit code.

And again, we now have greatly reduced cost and complexity for rebuilding servers. It’s now not only possible but easy to completely script the build of an entire web application stack and have a new web service spun up before the hipsters in marketing have finished arguing about wht vrbs 2 drp (srry) from the new domain name.

Make a plan for recovery and to bring your website back online and stick to it:
Nobody wants to be offline for longer than they have to be. That's a given. If this website is a revenue generating mechanism then the pressure to bring it back online quickly will be intense. Even if the only thing at stake is your / your company's reputation, this is still going generate a lot of pressure to put things back up quickly.
However, don’t give in to the temptation to go back online too quickly. Instead move with as fast as possible to understand what caused the problem and to solve it before you go back online or else you will almost certainly fall victim to an intrusion once again, and remember, “to get hacked once can be classed as misfortune; to get hacked again straight afterwards looks like carelessness” (with apologies to Oscar Wilde).

I'm assuming you've understood all the issues that led to the successful intrusion in the first place before you even start this section. I don't want to overstate the case but if you haven't done that first then you really do need to. Sorry.

Never pay blackmail / protection money. This is the sign of an easy mark and you don't want that phrase ever used to describe you.

Don't be tempted to put the same server(s) back online without a full rebuild. It should be far quicker to build a new box or "nuke the server from orbit and do a clean install" on the old hardware than it would be to audit every single corner of the old system to make sure it is clean before putting it back online again. If you disagree with that then you probably don't know what it really means to ensure a system is fully cleaned, or your website deployment procedures are an unholy mess. You presumably have backups and test deployments of your site that you can just use to build the live site, and if you don't then being hacked is not your biggest problem.

Be very careful about re-using data that was "live" on the system at the time of the hack. I won't say "never ever do it" because you'll just ignore me, but frankly I think you do need to consider the consequences of keeping data around when you know you cannot guarantee its integrity. Ideally, you should restore this from a backup made prior to the intrusion. If you cannot or will not do that, you should be very careful with that data because it's tainted. You should especially be aware of the consequences to others if this data belongs to customers or site visitors rather than directly to you.

Monitor the system(s) carefully. You should resolve to do this as an ongoing process in the future (more below) but you take extra pains to be vigilant during the period immediately following your site coming back online. The intruders will almost certainly be back, and if you can spot them trying to break in again you will certainly be able to see quickly if you really have closed all the holes they used before plus any they made for themselves, and you might gather useful information you can pass on to your local law enforcement.

I'm mostly summarising earlier points here so I won't rehash them again. I will say that the plan I talk about for getting back into production should ideally be produced and wargamed before the incident occurs. We should be rehearsing all our business continuity plans really, and successful hack incidents are really just another class of risk to the business.

My Server's been hacked - What do I do now? Pt 1.'

Wed, 14 Mar 2018 19:01:37 +0000

Introduction

In this series of posts I’m revisiting an answer to a question that appeared on Server Fault way back in 2011. I’m pleased to say that it’s been viewed over 100,000 times, and I like to think its helped a few of them.

But it’s time to look again. Since I wrote that post, there have been some huge intrusions, such as the well known Ashely Madison, Anthem Medical Data and JP Morgan breaches that affected millions of people.

[source: wikipedia list of data breaches]

I'm not writing for the people who operate at the kind of scale of those sites here. I'm writing for the scores of people who manage small and medium enterprise systems which handle data and are if anything, despite being a smaller target than the kinds of organisations I mention above, are likely to be under just as much pressure as they don't have the kinds of infosec budgets of a Sony or an Experian and could well be seen as a softer target. My original post text from Serverfault is quoted below, with my thoughts, revisions and edits added as new text.

(Part 2 and Part 3 are available)

Don't Panic
First things first, there are no "quick fixes" other than restoring your system from a backup taken prior to the intrusion, and this has at least two problems.

It's difficult to pinpoint when the intrusion happened.

It doesn't help you close the "hole" that allowed them to break in last time, nor deal with the consequences of any "data theft" that may also have taken place.

This question keeps being asked repeatedly by the victims of hackers breaking into their web server. The answers very rarely change, but people keep asking the question. I'm not sure why. Perhaps people just don't like the answers they've seen when searching for help, or they can't find someone they trust to give them advice. Or perhaps people read an answer to this question and focus too much on the 5% of why their case is special and different from the answers they can find online and miss the 95% of the question and answer where their case is near enough the same as the one they read online.
That brings me to the first important nugget of information. I really do appreciate that you are a special unique snowflake. I appreciate that your website is too, as it’s a reflection of you and your business or at the very least, your hard work on behalf of an employer. But to someone on the outside looking in, whether a computer security person looking at the problem to try and help you or even the attacker himself, it is very likely that your problem will be at least 95% identical to every other case they’ve ever looked at.

Don’t take the attack personally, and don’t take the recommendations that follow here or that you get from other people personally. If you are reading this after just becoming the victim of a website hack then I really am sorry, and I really hope you can find something helpful here, but this is not the time to let your ego get in the way of what you need to do.

I still stand by this first part, more or less, though I will admit to borrowing the first two words from Douglas Adams.

It's important to reflect before you act. Before doing anything, you need to make sure that everyone concerned knows what their responsibilities are to the business, its customers, and the legal frameworks in the countries you operate in.You may have obligations to notify customers that they're victims of information theft, to notify legal/government departments, etc. and it's important that you don't act in haste and potentially lost information about the extent of an attack or destroy evidence of who was responsible, how they did it, etc.
It's important to appoint someone to manage the incident. It is their job to co-ordinate the technical, legal and operational responses of the business to the incident, which means that they cannot get bogged down in details from any one of those areas.
Therefore: The incident manager should not be the technical lead in the investigation. It's tempting in a smaller business to put the "IT manager" in charge of the incident (that's fine) and then also expect the IT Manager to be her own technical lead, which is a gross error.The technical role should be delegated, possibly even outsourced to a specialist, and the manager needs to be taking a step back from worrying about technical trivia and instead concentrating on what the business needs to do to protect itself and its customers.
Don't take the attack personally. It's just business, even when it isn't. This is all about making good decisions. It's ok to be upset but it's not ok to make bad decisions because you're upset.Ability to step back from the emotional impact of things like this and work dispassionately should absolutely play a part in your choice of incident manager, technical lead, and so-on, in case you were wondering.

You have just found out that your server(s) got hacked. Now what?
Do not panic. Absolutely do not act in haste, and absolutely do not try and pretend things never happened and not act at all.

First: understand that the disaster has already happened. This is not the time for denial; it is the time to accept what has happened, to be realistic about it, and to take steps to manage the consequences of the impact.Some of these steps are going to hurt, and (unless your website holds a copy of my details) I really don’t care if you ignore all or some of these steps, that’s up to you. But following them properly will make things better in the end. The medicine might taste awful but sometimes you have to overlook that if you really want the cure to work.Stop the problem from becoming worse than it already is:

The first thing you should do is disconnect the affected systems from the Internet. Whatever other problems you have, leaving the system connected to the web will only allow the attack to continue. I mean this quite literally; get someone to physically visit the server and unplug network cables if that is what it takes, but disconnect the victim from its muggers before you try to do anything else.

Change all your passwords for all accounts on all computers that are on the same network as the compromised systems. No really. All accounts. All computers. Yes, you're right, this might be overkill; on the other hand, it might not. You don't know either way, do you?

Check your other systems. Pay special attention to other Internet facing services, and to those that hold financial or other commercially sensitive data.

If the system holds anyone's personal data, immediately inform the person responsible for data protection (if that's not you) and URGE a full disclosure. I know this one is tough. I know this one is going to hurt. I know that many businesses want to sweep this kind of problem under the carpet but the business is going to have to deal with it - and needs to do so with an eye on any and all relevant privacy laws.

However annoyed your customers might be to have you tell them about a problem, they'll be far more annoyed if you don't tell them, and they only find out for themselves after someone charges $8,000 worth of goods using the credit card details they stole from your site.Remember what I said previously? The bad thing has already happened. The only question now is how well you deal with it.

Disclosure is where it's at now.

If I'm going to criticise my 2011 self for anything, it's for failing to take disclosure seriously enough. Well that and waffling. But in 2018, disclosure has become a huge part of the response to a security breach and it's completely right that it should be.

Intrusions into servers themselves while still a problem that needs to be addressed operationally, are almost unimportant these days, because data and services are now seen as the valuable commodities, more so than servers themselves(1), and these days it should be fairly trivial to rebuild a server with tools like puppet, Microsoft System Center, Chocolatey and Kubernates. We should be treat servers as cattle, not as pets, we should be worrying about the services running on these servers and “scaling out” so that the loss of one server isn’t an issue as such, and this completely changes how we can approach an intrusion into any one server - of course it also increases the complexity of determining whether or not your entire farm is rooted, but there ain’t no such thing as a free lunch.

There are a number of positions that need to be considered in disclosure and you need to be aware of how these are perceived throughout the world. If you’re a US company operating in the EU and holding data on EU B2C customers on systems that are local to you then you may have a very complex set of laws to consider, for example, and it may be difficult to know how to balance these requirements.

One thing that might help, ironically, is the rise of cloud. If you can store and process personal data in the same legal zone as the customers who own that personal data then you will probably greatly reduce your legal complexity. I’m predominantly referring to the UK interpretation of the disclosure requirements for GDPR in my examples here because I’m a UK citizen living and working in the UK/EU for an UK/EU employer who tasks me with securely storing and processing the data of UK/EU residents.

This is not any kind of legal advice or opinion and you absolutely should check the legal requirements for the country you’re based in and the countries your company operates in.

Legally, you may have an obligation to disclose any data breach that occurs on your site. In the EU we are obligated under Article 33 of the GDPR regulations to notify our local “supervisory authority”, which is the information commissioner (ICO) in the UK and under Article 34 we’re also obligated to notify “data subjects” about any breach that’s likely to have resulted in any of their “personal data” being shared with others.

If you read any of these articles you’re probably still not any wiser about when and whom to notify - what are the thresholds for notification? To that end, I’ll point you at this discussion on the Varonis blog which tries to break down what the thresholds mean and what actions you need to take.

But there’s another angle. What is the ethical impact of your disclosure policy? If you feel that an incident doesn’t quite meet the legal requirements where you are to require you to disclose an intrusion/data theft, then what about ethical obligations? What about customer confidence, which can be critically impacted when you’re caught acting unethically around an intrusion? At this point I would suggest that disclosure of data loss or theft is the most important and complex part of your playbook should you suffer a security incident. Get it wrong and you may find yourself in legal difficulties and you will certainly lose credibility with your customers. Get it right… and while it’s still never going to be fun to admit you suffered an intrusion, you can at least win respect from current and potential future customers by showing professional resolve and an ability to learn from your mistakes.

(1) Though given the rise of "cryptojacking", where hackers break into webservers to insert javascript into websites that allows them to use visitors to that website to mine cryptocurrency might start to swing things back the other way again. The only thing that stays the same in IT is change.

Easy PC rebuilds with Chocolatey

Sat, 09 Sep 2017 09:51:57 +0000

One of the things that I’ve always been interested in is automation, and being able to reproduce a ‘known state’ reliably and consistently. This applies at work when building servers or workstations thanks to tools like SCCM and Fog, and should be in your grasp at home or in even the smallest office, thanks to Chocolatey.

Not to make a fine point of it, between my last post and this one I’ve rebuilt my PC, installing windows from scratch and all my applications, prepared breakfast for my partner and myself, started some laundry, and dealt with the cat pulling the net curtains down in my study.

The easiest part of that was the computer rebuild, with help from Chocolatey. Remember having to spend ages downloading and installing applications when you had to reinstall your Windows PC at home? Remember looking at Linux and (whatever other opinions on Linux you might or might not have) being envious of package managers like apt-get?

Well this is now perfectly possible in Windows. To reinstall my PC today I:

Made sure my backups of my documents folders were up-to-date (which these days is just a matter of making sure your cloud sync tool of choice is working).
Formatted my system disk and re-installed windows with a bootable windows 10 memory stick.
Installed my password manager of choice in Edge so I could get into my accounts.
Ran "rob_choco_install.ps1" from an administrative Powershell command line.
That's it.
Well not entirely. I'm still not happy that apps from the windows store install without my consent on a new PC and take effort to tidy up. If you want us to use the store, here's a suggestion Microsoft: Genuinely compelling applications and content. Just a thought.

So what's "rob_choco_install.ps1" then? Simple, a bit of powershell that contains the instructions below:

Set-ExecutionPolicy AllSigned; iex ((New-Object System.Net.WebClient).DownloadString('[chocolatey.org/install.p...](https://chocolatey.org/install.ps1')))
choco install -y malwarebytes choco install -y opendns-updater choco install -y spotify choco install -y itunes choco install -y office365proplus choco install -y adobe-creative-cloud choco install -y steam choco install -y uplay choco install -y chrome choco install -y chromium choco install -y palemoon choco install -y firefox choco install -y vlc choco install -y notepadplusplus choco install -y windirstat choco install -y adblockplus-firefox choco install -y adblockpluschrome choco install -y plexmediaserver choco install -y plex-home-theater choco install -y handbrake.install

So the first line installs Chocolatey from Chocolatey.org’s server. The subsequent lines install about 90% of all the applications I use on this computer as Application Packages. An application package is an application, plus installation steps for Chocolatey to use to install the application. I could have all those application packages on one line but I personally prefer to split them up, but if you wanted, one line like the example below would be just as valid as my example above.

choco install -y windirstat vlc firefox notepadplusplus steam uplay

Sure, some of these packages are just tiny little applications, but there are some heavy hitters in there too, for example:

choco install -y office365proplus choco install -y adobe-creative-cloud

Yes, those are full installers for the Office 365 full 'Click to Run' package, and Adobe's Creative Cloud manager. So that's the full version of Microsoft Office and Adobe's Creative Cloud suite, along with other applications like iTunes, Steam, my many web browsers, all installed automatically while I was off poaching eggs and asparagus for breakfast.

This means that if you have good backups of your data (and if not, why not), a good password manager (and again, if not why not) and the will to try something new, your computer at home can be rebuilt from scratch in slightly less than an hour without you having to do much of anything except log in.

What about security? Good question. The free to use open source package repository does make checks of the packages but you should still carry out your own due diligence. Luckily, there is a virus scanning service in the opt-in paid for subscription versions of Chocolatey, along with the ability for all of us to look at the packages we’re installing and what they do before installing them.

[caption id=“attachment_739” align=“alignleft” width=“300”] Office 365 Package on Chocolatey[/caption]

For example, where I mention Office 365 ProPlus above, it would surely be a problem to install that from a compromised source. Luckily, I can go to the package repository, search for ‘office365proplus’ and see what the package contains and does. I can expand the ‘files’ option and inspect the files and notice the download source is a Microsoft.com site, and I can check the configuration file to ensure nothing suspicious is happening… and I can do this for all the packages in the repository.

In my opinion and with some caveats, this is a good option for security. While it’s fairly easy to get reasonable providence for packages like Microsoft Office and Adobe Creative Cloud, it might be more difficult for less computer savvy people to wade through deceptive ads when they go online and just search for “Malwarebytes” in their new computer’s default web browser…

[caption id=“attachment_740” align=“aligncenter” width=“300”] “I just went on the Internet, and I found this”[/caption]

What about keeping it all updated? Good question. Many of these applications will update themselves once they’re installed anyway. Steam and Spotify are good examples that lots of people will be familiar with on a home PC of how this can work.

For everything else installed through Chocolatey, it’s still not too bad.

Choco upgrade all

Yes, running that from a powershell command line (or if you're feeling fancy, a powershell job in your task scheduler) will update all applications installed via Chocolatey to the latest version published in the Chocolatey repository.

What about removing old software? Again, not too bad…

Choco uninstall package-name

What about a GUI to manage this with? Ah yes. I have to admit I felt the same way when I started playing with Chocolatey, though I find myself using it less and less now, but still, you've got options.

Choco install -y chocolateygui

... will install a graphical interface for Chocolatey. This really only allows you to do the basic stuff such as install, upgrade, remove and search for packages. Luckily, that's about 90% of what most people want to do.

[caption id=“attachment_765” align=“aligncenter” width=“300”] Chocolatey Gui allows you to do basic installation and management of packages.[/caption]

What about business use? I could tell you my thoughts now, but this article is getting long and it’s time to go to the gym, so wait for part 2.

Malware emails - doing it wrong.

Sat, 09 Sep 2017 06:12:09 +0000

I’m currently reading /r/sysadmin on reddit at the moment, specifically this post from someone ranting that a user complain that “malware spam e-mail” went to their mail client’s spam folder. While this is classed as a rant on the site and not intended as deep analysis of a problem, their entire comment on this was:

What the hell? This is exactly what it should have done!

I'm really not sure what to say to this, or to the responses that suggest telling the "user" that they're too dumb to have a job involving computers, except to say that this is wrong-headed thinking of the highest order.

If an email is known to be ‘bad’, that is, if we can say with certainty that it contains malware, or links to malware, then it simply shouldn’t be delivered to the mailbox at all. If something is in the mailbox then it’s a fair possibility it will be opened. Not because ‘users are dumb’ but because we’re all human and can click on anything by accident or at the end of a long day. And a simple scan of /r/sysadmin will show that IT professionals are not immune to doing this themselves.

Leaving aside the issue of things going undetected by your security systems, if your email security scans can identify something with 90% confidence or more as malware-related, or phishing, or even ‘good old-fashioned spam’ then it should be possible to tell it to simply not deliver the email. It should also be possible to quarantine these messages in an area that is separate from the mailbox and prevent non-technical users from being able to release malware by allowing the network manager to control who has access to which types of blocked content.

If your email scanner cannot do that then you have a bad email scanner. If your email scanner can do that but known bad emails end up being delivered to mailboxes anyway then whoever is in charge of that scanner is doing a bad job.

Another post on this thread sums up the reason why a lot of ‘users’ (I do prefer the term ‘customer’) dislike IT professionals quite well:

At some point, these mouth breathers have to take some personal goddamn responsibility. If you walked out into the road without looking because the light said you could, then you get run over, guess what? You're still dead.

Charmed, I'm sure. Actually, I agree that people do need to take responsibility for their own actions. I won't, in fairness, defend people who store important email messages in their mail client's 'trash' folder and expect it to still be there the next day.

But responsibility is a two-way thing. I’m responsible for providing the best service to my customers that I can with the budget I have. To me, that includes not delivering known malicious emails to their mailbox, and not calling the customers stupid when my systems get it wrong.

It’s so rare that malware breaks through into our email accounts where I work that our customers pretty much all tell me straight away…

And you know what? I’m glad they tell me and I always thank them politely and assure them they’ve done the right thing by putting a ticket in about it, because that’s much better than guessing for themselves and running malware code.

Office 365 email migration gotchas

Tue, 08 Aug 2017 10:13:19 +0000

One of the things I’m working on at the moment is moving the remainder of our Exchange organisation over to Office 365 / Exchange Online.

We moved the bulk of our accounts some time ago; students here have been on Office 365 Exchange email for a few years, but staff and ‘role’ email accounts have been held on local Exchange servers until this month.

The things I’ve seen people worry about on these migrations have actually been the least of my worries. All my mailbox accounts migrated using the Exchange Online migration tools without any real difficulty. The few gotchas I found here are that users with an online archive mailbox cannot be migrated ‘as is’, and users who do not have a ‘@domain.mail.onmicrosoft.com’ address defined in their email addresses.

The most common cause for the email address is the default email address policy not being applied to that user, which is a tickbox in the EMC on your Exchange server recipients / mailbox user / email addresses dialogue, or can be enabled via powershell with: Get-RemoteMailbox <name of mailbox> | Set-RemoteMailbox -EmailAddressPolicyEnabled $True

Or if you wish to apply this to all mailboxes (ensure it hasn’t been disabled for a reason if you have a large number of mailboxes in this state): Get-mailbox –resultsize unlimited | Set-Mailbox -EmailAddressPolicyEnabled $true

Another issue is with password complexity rules and role / service mailbox accounts. Based on our experience here, where an account has been set up some time ago, and subsequently the password complexity rules for your domain have changed so that the account’s password would no longer be valid, then even though it still is valid as far as your local domain is concerned and you can log into a domain workstation with the ‘old’ credentials, login to Office 365 may well fail. The answer is to update the password to one that meets your new complexity requirements.

Lastly, and again this might be an issue with older service accounts, ensure that the UPN is sensible (I suggest it should match the email address, and I think most people would agree with me).

We’ve been able to update things like database email settings, role mailboxes and third-party apps to send SMTP mail directly via Office 365, rather than a local relay, using those caveats around passwords and the mail server settings below:

SMTP Server : smtp.office365.com Port : 587 SSL / TLS : Yes (note that if your app uses really old SSL 2.0 and nothing newer you may have trouble. It’s time to upgrade)

Authenticate with:

Username : user@domain.com (should be the full UPN as defined in Active Directory User & Computers) Password : {Active Directory Password}

Keeping Children Safe in Education

Sun, 11 Jun 2017 11:09:25 +0000

So I recently did a podcast with SonicWall on Safeguarding and the statutory guidance on Keeping Children Safe in Education (KCSiE). You can listen to it here.

Invaluable resources:

Safer Internet Centre's Advice section.
Internet Watch Foundation (IWF)
Thinkuknow website.

Upgrading Windows PKI from SHA1 to SHA2

Wed, 07 Jun 2017 09:35:48 +0000

As I’m sure most of us know by now, SHA1 cryptography hashes have been increasingly under attack, and are now regarded as fully broken. In fact, my use of “now” kinda understates the point; you should be urgently looking to upgrade to SHA2 if you have any devices or servers using certificates.

If you’re not aware of these risks then please look around. There are some good introductory articles on the entrust website that talk about this issue, but please note that these articles are from 2014 and somewhat understand the urgency of the issue.

Upgrading your public facing websites and services that use public certificates (e.g. certificates you purchase from a public Certificate Authority, aka “CA”, online) is actually fairly easy; buy a new certificate from a competent supplier, install it, remove old certificate. Job done… (though as ever the devil is in the details).

For those who are running a Windows Certificate Authority (CA) to issue private certificates to servers and devices on your network, there is potentially a different problem: How do you ensure that your private CA is able to issue SHA2 certificates, and if not, how do you upgrade it so that it can?

I’m going to discuss the methods I use, which are designed for a Windows PKI infrastructure with several levels (a root CA and subordinate “issuing” CAs).

In a lot of ways, this really isn’t difficult at all. The steps you need to perform to actually complete the upgrade are extremely simple but the preparation you should carry out beforehand needs to be painstakingly done.

Prerequisites

I'm assuming that you're fairly knowledgeable and comfortable with manipulating certificates, and understand basic processes around managing private Windows CAs on your network. If this doesn't describe you then I strongly advise you to get help, hire a consultant if need be, before proceeding. While I'm actually quite confident that the processes I outline below are robust and that the articles I link to are good, well written articles from knowledgeable people, you will still to be able to understand the concepts we're talking about and be able to adopt instructions to your environment before starting the upgrade process.

First of all, you need to examine your environment. If you’re using Windows XP machines and Windows 2003 servers then you will have problems with SHA2 certificates. There is a hotfix available but if this describes your environment then certificate hashes are probably the least of your security worries. You should also review appliances and applications on your network that use certificates issued by your CAs and ensure that they can handle the update to SHA2. This should apply to most modern systems that are kept reasonably up-to-date, but “most modern systems” isn’t the same as “all”, so make sure you’ve checked this before starting work.

Ideally your Certificate Authorities should be running the newest version of Windows Server possible, and I’d strongly suggest a bare minimum of Windows 2012 to cover all bases. It’s perfectly possible to upgrade a 64-bit version of Windows 2008 server all the way through to Windows 2016 server if you need to. Whether or not you feel that’s a good idea is possibly another question, but you’ve hopefully kept your CAs isolated and free from other roles and that should help make upgrading the CA servers in place more viable.

If you’re using an older 32 bit version of Windows Server then you cannot upgrade directly to Windows 2012 or newer. If this is you, there is an article on migrating your CA to a new server on Technet which you can follow to upgrade to a modern CA.

I’d also suggest that CAs are a good candidate for virtualisation, which will make some of the operations I’m about to discuss easier, and in any case you don’t want your PKI infrastructure to die because of a dodgy hard drive in a server from 2006. My guides below assume you’re working with at least Windows Server 2012 (my examples were tested on Windows Server 2016) and that you’ve ensured that your Cryptographic provider is already upgraded to Microsoft Key Storage Provider.

To ensure that you’re ready to upgrade, go to each CA on your network, open the Certificate Authority Admin GUI, right-click on the CA name and select Properties.

Here we’re interested in two things. The Hash Algorithm is set to SHA-1 which means it needs upgrading, and the Provider is set to “Microsoft Strong Cryptographic Provider” (CSP), which means that you need to upgrade the provider to “Microsoft Key Storage Provider” (KSP).

Think of this as a two-step process if it helps explain the process: before you can upgrade the root certificate you need to upgrade the container that holds it.

I’m not covering how to upgrade from a CSP to a KSP in this article because there are plenty of wonderfully written articles out there which cover how to do both the CSP -> KSP and SHA1 -> SHA2 upgrades together and I wanted to offer something that had clear steps for people who were already at the KSP stage. I suggest following this Technet article on migrating from a CSP to a KSP if you need to update your cryptographic provider.

A typical installation

A typical Windows server based PKI setup should contain at least two CAs; a root CA which should ideally be offline (e.g. not a domain member and not part of the general network) and certainly should be as isolated and secure as possible) which is used to validate the other CAs on your network, and one (or more) issuing CAs which handle the task of receiving certificate requests and issuing certificates to users and workstations on your network.

To upgrade this kind of setup is a 6 stage process:

Upgrade the root CA cryptographic algorithm to SHA-2.
Use the upgraded root CA to issue a SHA-2 root certificate, and verify this certificate is correct.
Import the new SHA-2 root certificate into AD, ensure the subordinate CAs update their certificate stores, and can see the updated root certificate.
Upgrade the subordinate CA cryptographic algorithm to SHA-2.
Request new certificates for each subordinate CA from the root CA, and verify this certificate is correct.
Verify that new certificates issued by the subordinate CAs are fully trusted SHA-2 certificates.

The upgrade process itself.

Remember, we're only handling the SHA1 to SHA2 conversion here. If you also need to migrate your CA from a CSP to a KSP then please use this technet article.

Ensure that you have good backups of all your CAs taken using your backup software of choice. Do a test restore and make sure you’re happy with the quality of these backups (You can always use a test restore to an isolated VM to practice the CA upgrade process).

Note that following this process will leave you with SHA1 CA certificates sitting alongside your new SHA2 CA certificates on your CAs. This is fine, both certificates will be valid for the natural lifetime of the SHA1 CA certificate, at which point the SHA2 certificate will be the only valid one and can be renewed as normal in your own timeframes.

On the Root CA:

Ensure you can 'roll back' by backing up the CA.

To back up the CA database and root certificate itself, open an admin powershell prompt and run the following commands.

mkdir c:\CAUpgradebackup
$filepath = "c:\CAUpgradebackup\Backups"
$password = "MyPassword"

This creates the environment you will need to back up your CA configuration in a folder on your c drive named "CAUpgradebackup". You can (and probably should) customise both this file path and the password for your needs rather than just going with my defaults.

You are now ready to backup certificate database and certificates. All the commands here are carried out at your powershell prompt you created above.

certutil -p $password -backup $filepath

Then export your current CA service config from registry:

Reg export hklm\system\currentcontrolset\services\certsvc\configuration $FilePath\CAConfiguration.reg /y

And back up your CRLs (I’m assuming they’re published to the default file path here):

Copy-Item -Path "C:\Windows\System32\certsrv\certenroll\*.crl" -Destination $FilePath

You’ve now backed up your root CA. You can now navigate to the folder specified in $filepath above and verify that you have good data.

Upgrading the Cryptographic Algorithm

When you are sure that your backup was successful and you can recover data, you are ready to upgrade your cryptographic algorithm to SHA-2. If you are using virtual servers for your CAs, now would be a good time to take a snapshot, just in case.

Ensure the Certificate Server service is running
Carry out the upgrade by typing the command below into your powershell prompt:
```
certutil -setreg ca\csp\CNGHashAlgorithm SHA256
```
Stop, and then restart the Certificate Server service.

You can now verify the upgrade worked by opening the Certificate Authority Admin GUI, right-clicking on the CA name, and select Properties.

You should see something similar to my example here, the provider should still read “Microsoft Software Key Storage Provider”, but the Hash Algorithm should now read SHA256.

With that done, you have just two things left to do on the root CA, update the root CA’s own CA certificate, and publish the certificate to AD.

To do the first part, simply cancel out of the properties dialogue we were looking at above, right-click the CA name again, and select “Renew CA certificate”. Follow this process, allowing the CA to stop, issue itself a new CA certificate, and restart.

You should now see a new certificate listed in the CA Certificates list. Select it and choose “View Certificate”. You should be able to see the new certificate issued as a SHA-2/SHA256 certificate, as per the example below.

Lastly, at least as far as the root CA goes, you need to upload this certificate to Active Directory in order for the subordinate CAs (and downstream clients for that matter) to be able to find this certificate in the chain when validating newly issued SHA2 certificates. If your root is ‘online’, e.g. connected to AD, this will happen automatically. If your root CA is offline then you will need to publish the root certificate to AD yourself. Rather than make this article longer than needed, I will simply point you at this serverfault article if you don’t already know how to do that.

On each Subordinate/Issuing CA in turn

Ensure that the new SHA2 certificate from your root CA is visible in the Local Computer's "Trusted Root Certification Authorities" store. You can use the Certificates MMC snap-in for this. If it is not visible, ensure you've published the root certificate correctly and from a command line use gpupdate /force to update the available certificates. Do not proceed until you have the updated root certificate available and you've verified that it shows as OK.

Ensure you can 'roll back' by backing up the CA.

To back up the CA database certificate, open an admin powershell prompt and run the backup commands we used earlier (see earlier instructions for detailed explanations for each step).

mkdir c:\CAUpgradebackup
$filepath = "c:\CAUpgradebackup\Backups"
$password = "MyPassword"

This creates the environment you will need to back up your CA configuration in a folder on your c drive. You are now ready to backup certificate database and certificates.

# backup the CA database and cert
certutil -p $password -backup $filepath
# export the CA registry configuration
Reg export hklm\system\currentcontrolset\services\certsvc\configuration $FilePath\CAConfiguration.reg /y
# backup CRLs
Copy-Item -Path "C:\Windows\System32\certsrv\certenroll\*.crl" -Destination $FilePath

Backup CA Templates (This is a new step for subordinate/issuing CAs)

certutil -catemplates | Out-File -FilePath "$FilePath\Templates.txt"

You’ve now backed up your subordinate CA. Verify that you have good data in the backup folder before proceeding.

Upgrading the Cryptographic Algorithm

Ensure the Certificate Server service is running
Carry out the upgrade by typing the command below into your powershell prompt:
```
certutil -setreg ca\csp\CNGHashAlgorithm SHA256
```
Stop, and then restart the Certificate Server service.

You can now verify the upgrade worked by opening the Certificate Authority Admin GUI, right-clicking on the CA name, and select Properties.

You should see something similar to my example here, the provider should still read “Microsoft Software Key Storage Provider”, but the Hash Algorithm should now read SHA256.

With that done, you have just one thing left to do on the subordinate CA, update the CA certificate, and publish the certificate to AD.

To do this, simply cancel out of the properties dialogue we were looking at above, right-click the CA name again, and select “Renew CA certificate”. Follow this process, allowing the CA to stop, issue a certificate request which you can then fulfill on the root CA and then install the newly issued certificate on your subordinate CA.

Repeat this process for all subordinate/issuing CAs

Test your new certificate servers

You can now test your new SHA 2 pki infrastructure by logging on to a test workstation, opening the certificates MMC, ensuring the root and subordinate CA certificates appear in the Trusted Root Certification Authorities and Intermediate Certification Authorities sections for the local computer, and then going to personal certificates and renewing one of the certificates you see there. It should renew without errors, obviously, and show both signature algorithm and signature hash algorithm as SHA256.

I know this is along and drawn-out process, but it’s like a lot of things, the precautions usually aren’t needed but lets face it, if you ring up Microsoft and say “I just hosed all my CAs following a process that’s only semi-official at best, and don’t have a backup” they’re going to record the call, dub it over comedy “ommpah-ooompah” trombone noises and play it at the support Christmas party forever.

It’s always my problem

Maybe ‘dumb homes’ are the new smart?

Gift cards considered harmful?

💻 Zettle code 2

Apple's designs

Becoming a Chartered IT Professional

Securing Admin roles in Azure Active Directory

Don't assign admin rights to daily driver accounts

Over-permissioning accounts

Protecting Admin accounts with MFA

Using Passwordless for Office 365

What is Passwordless?

Branding your login page.

Enabling Passwordless Authentication.

Prerequisites

Getting Started.

Testing Passwordless

Azure Conditional Access for Chromebooks

Conditional Access, a very quick primer.

Complex CA rules and Chromebooks

To Deny Logins for unsupported devices, do the following.

To support MFA on Chromebooks/Linux, do the following.

Teams CAA70007 errors

Tuning up Intune - Building your toolset

Introduction

Intune's Building Blocks

App Stores

PowerShell management

Tuning up Intune, an introduction.

Introduction to Microsoft Mobile Device Management

Microsoft's EMM product family.

Mobile Device Management for Office 365

Microsoft Intune

Enterprise Mobility + Security

In Summary

Chocolatey in the workplace

Join domain and restart device

Portable build script 1. Should be run on a Windows 10 Professional system that we wish to “build” as a domain device

Does the following:

1. Ensure we’re elevated and if not elevate the session

2. Remove ‘bad’ apps that simply shouldn’t be on the workstation

3. Join the domain, placing the device in the Admin\Laptops OU in Workstations

3. Change product key to a Windows 10 Enterprise KMS key. This ‘upgrades’ the system to Windows 10 enterprise but…

…. the system MUST be on the network to find a KMS server on restart.

If you’re in this list you’re being uninstalled

Prevent random “cloud content” nonsense from downloading

Join the domain. Note credentials below for a non admin account with unlimited domain join rights.

change product key to your enterprise KMS workstation key and force a reboot.

Chocolatey Software Build

Portable build script 2. Should be run on a Windows 10 Enterprise system that we wish to “build” as a college device

Ensure that machine is Win 10 enterprise and domain joined first (run the domain join script first!)

Does the following:

1. Ensure we’re running as admin and elevate if we’re not

2. install chocolatey

3. install apps using chocolatey repository

Now running elevated so launch the script:

install chocolatey, chocolatey apps

choco install -y adobe-creative-cloud

Done, now reboot

Backup to the cloud.

Introduction

The cost of backups

On-Premises backup to tape

Backup to the Cloud

How does Azure work?

Tuning up Intune - Self Service Password Reset from the login screen.

Introduction

Getting Started

Configuring Hybrid Azure AD Join

Configure your devices to be managed by Intune.

Enabling Intune

Enrolling a device in Intune

Testing Intune Profile Management.

Assign your Intune SSPR profiles to your target computers.

Creating your Windows 10 SSPR Device Configuration profile.

Test... and you're (hopefully) done.

Troubleshooting

No Reset Password link appears.

Reset Password link is there but does not work.

My Server’s been hacked – What do I do now? Pt 3.