Post offering a free Recreational Vehicle!

Social Engineering and your users

All my customers want to talk about security these days. So much of our day to day work is done on the internet now, and the security landscape has changed significantly over the last 5-10 years. Our perimeter is no longer restricted to our LAN and firewalls, but instead lives with the users identity. Users are highly likely to use their corporate network password on other sites; who knows whether this other site has been breached or not?

Things like this scare us IT admins, and even scarier now is the gargantuan amount of misinformation and misdirection on the internet. From that advert that looks like a “next page “button to the link to an article which promises to show you the most amazing thing you’ve ever seen a koala do, users will literally click on anything. Today I want to share one of these examples. I noticed this morning that a friend of mine had shared this post on Facebook:

Post offering a free Recreational Vehicle!

Wow! A free RV. Amazing right? But this post looked a little strange. Who can afford to give away an RV, let alone 15 of them? And what did “can’t be sold because they have been stock this year” mean? My curiosity got the better of me and I decided to click through. This is what I found:

RV Main Page

Now let me give you a few facts:

  • This page only had a single post. This one.
  • It has 83,045 shares and 35,015 comments. In 3 days. Both of these numbers have gone up by around 1,000 while I have been writing this.
  • The page had nothing in the about section. No website, no contact details, nothing. Nada. Zip. It was basically an empty page with one post on it.

This was clearly a ruse and nobody was going to get themselves a free RV. I mean hey, maybe I’m wrong and an awful cynic who has been scarred by the internet. But in reality, this was a more than likely a social engineering experiment or phishing scam. Maybe the “lucky winners” would be contacted and asked for some personal details so that they could claim their free prize? Maybe they were directed to a fake Facebook login page? And maybe their Facebook login password was the same as their corporate network password?

This post shows us all just how easy it is to get people to click on something, or believe something, on the internet. And this stuff is everywhere we look. As an internet user, we are faced with a constant stream of misinformation and misdirection, never quite knowing when something is real and when it isn’t.

Security has never been more important. Using web filtering, multi factor authentication and implementing features for mail scanning like Safe Links and Safe Attachments (found in Exchange Online Protection) can help to a certain degree,  but a very large part of this fight is user education. People should be taught that their first response should be one of doubt, not of excitement about the amazing thing they are about to see, or the prize they will never win.

It’s a dangerous world we live in. But at least I’ll have a new RV to protect myself.

Exchange 2016 on Server 2016 – A reboot from a previous installation is pending

Recently I was attempting to install Exchange 2016 on Server 2016. On attempting to run the setup.exe /preparealldomains /iacceptexchangeserverlicenseterms command, I was receiving a failure when checking prerequisites which stated that:

PS E:\> .\Setup.EXE /preparealldomains /iacceptexchangeserverlicenseterms

Performing Microsoft Exchange Server Prerequisite Check

Prerequisite Analysis FAILED

A reboot from a previous installation is pending. Please restart the system and then rerun Setup.
For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.RebootPending.asp

I had rebooted the server a few times and ensured that no restarts were pending.

In versions of Server prior to Server 2016, I would be looking for the UpdateExeVolatile registry key and the PendingFileRenameOperations registry key under HKEY Local Machine. However these didn’t appear to be in their normal place. Eventually I did a search of the Registry and discovered that PendingFileRenameOperations has moved to:

HKLM\System\ControlSet001\Control\Session Manager\PendingFileRenameOperations

The previous location of this key was:

HKLM\System\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

Removing the entries in PendingFileRenameOperations resolved the problem in this case.

 

VNET Peering – When to use and when not to use

VNET Peering has been an available feature for almost a year now and has proved to be a very useful, popular, and for a long time the most requested feature. That said, as much as we would like to mesh together all our Azure VNETs into one lovely firewalled network topology, this isn’t always possible or suitable.

The situations whereby VNET peering (or it’s associated features) cannot be used are as follows:

  • VNETs in different regions cannot have a peering relationship
  • VNETs with overlapping address spaces cannot be peered
  • VNETs which are both created using the Classic Deployment model cannot be peered
  • VNETs which are created using mixed deployment models cannot be peered across different subscriptions (although this will be available in the future)
  • Both VNETs must be created using the Resource Manager Deployment Model for Gateway Chaining (using a gateway in a peered VNET) to function
  • There is a default limit of 10 VNET peers per VNET. This can be raised to a maximum of 50 using Azure Support requests

This still leaves many applicable situations whereby VNET peering can be very useful and can provide the hub and spoke, high speed, low latency network which your Azure subscription/s need.

 

ADFS Additional Authentication Rules – MFA Issue Type

ADFS Claim / Additional Authentication rules can appear very complex and confusing, and that’s because they are! One thing that tripped me up recently is related to the issue section of a claim rule whereby MFA is specified. During a project, I created a rule from a template I had used for another customer. Upon saving the rule I found that it didn’t apply MFA as I was expecting, and instead caused an error message in ADFS during logon attempts.

The rule I had used was issuing a claim for the Azure MFA Server rather than the Azure MFA Cloud Service. To clarify, the difference in the claim type is as follows:

Azure Cloud MFA

=> issue(Type = "http://schemas.microsoft.com/claims/authnmethodsreferences", Value = "http://schemas.microsoft.com/claims/multipleauthn");

Azure MFA Server

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");

 

This is an important distinction and needs to be considered when applying different types of authentication flows in ADFS.

 

 

Virtual Machine Core Count – Azure

Today is not the first time I have come across this issue, but I’m going to make sure it’s the last time I google how to find out the limits applied to an Azure subscription!

By default, different VM soft limits apply to different types of subscriptions. If you come across this issue, your error will look something like this:

New-AzureRmVM : Operation results in exceeding quota limits of Core. Maximum allowed: 10, Current in use: 10

From memory (this may not be correct), the limits are as follows for different subscription types:

  • Pay as you go – 10 cores per VM type / region
  • CSP – 30 cores per VM type / region
  • VL – 20 cores per VM type / region
  • EA – I’m not sure!

If you want to see how many cores you are allowed by default, you need to login to Azure Powershell and run the following command, substituting your region.

Get-AzureRMVMUsage -Location "West Europe"

This will give you an output similar to below:

PS C:\WINDOWS\system32> Get-AzureRmVMUsage -Location "West Europe"

Name                         Current Value Limit  Unit
----                         ------------- -----  ----
Availability Sets                        3  2000 Count
Total Regional Cores                    10    10 Count
Virtual Machines                         8 10000 Count
Virtual Machine Scale Sets               0  2000 Count
Standard Av2 Family Cores               10    10 Count
Basic A Family Cores                     0    10 Count
Standard A0-A7 Family Cores              0    10 Count
Standard A8-A11 Family Cores             0    10 Count
Standard D Family Cores                  0    10 Count
Standard Dv2 Family Cores                0    10 Count
Standard G Family Cores                  0    10 Count
Standard DS Family Cores                 0    10 Count
Standard DSv2 Family Cores               0    10 Count
Standard GS Family Cores                 0    10 Count
Standard F Family Cores                  0    10 Count
Standard FS Family Cores                 0    10 Count
Standard NV Family Cores                 0    12 Count
Standard NC Family Cores                 0    12 Count
Standard H Family Cores                  0     8 Count
Standard LS Family Cores                 0    10 Count
As you can see, for each region there is a subset of machine types. If you need to raise a core limit, you need to raise an Azure support ticket and request an increase for the required region and VM type. This does not cost anything and from my experience is usually done within 24 hours.
Hopefully this helps some folk out there who come across this issue. If you haven’t seen this yet and are planning an Azure rollout, it would be worth requesting this increase prior to starting your project!

Azure AD Powershell – Token Lifetime Configuration for MFA

The default token expiry in Azure AD for ADAL clients (using Modern Authentication) is 14 days for single factor and multi factor authentication users. This can stretch up to 90 days as long as the user does not change their password, and they do not go offline for longer than 14 days.

This means that clients using Outlook or Skype for Business can perform MFA once and then remain signed in using their access token for up to 90 days before being required to authenticate using MFA. As you can imagine, this is not an ideal situation for multi-factor authentication as a compromised account could be accessed through a rich client application with no MFA for up to 90 days.

Until recently, this could not be modified. However Microsoft released Configurable Token Lifetime as a Preview feature quite recently. This allows for various properties to be controlled, giving administrators more granular control over token refresh and enforcing a more secure MFA policy.

The Azure team have provided a solid guide here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-configurable-token-lifetimes

To do this, you need the Azure AD Preview PowerShell module. Install this by running the following from a PowerShell prompt:

Install-Module -Name AzureADPreview 

Here is a sample policy I’ve configured which will change the MFA token lifetime to 12 hours. I’ve combined this with ADFS Claim Rules which only enforce MFA if the user is on the extranet and using particular applications:

New-AzureADPolicy -Definition @("{`"TokenLifetimePolicy`":{`"Version`":1, `"MaxAgeMultiFactor`":`"12:00:00`",`"AccessTokenLifetime`":`"04:00:00`"}}") -DisplayName OrganizationDefaultPolicyScenario -IsOrganizationDefault $true -Type TokenLifetimePolicy

This is  a much needed feature from the point of view of security controls, although keep in mind it is still in Preview!

 

 

Keep up to date with Office 365 IP Changes

It’s quite common for administrators to get caught out by IP changes in the Office 365 pool, and to find a service becoming intermittently inaccessible due to the addition of an IP address range to the pool of IPs used by an Office 365 service.

Microsoft publish an RSS feed to make this a bit easier for admins to follow, however I wanted to take this one step further.

Using Microsoft Flow (or IFTTT if that’s your bag), you can configure an event so that an update to an RSS feed prompts an action. That action could be to send an email, to update SharePoint or Yammer, or to update a Spreadsheet (amongst others). People consume information in many different ways, and this is one way to customise the delivery of this information to suit the way you work.

As an example, I want to send an email to myself every time a change is made to the Office 365 IP address RSS feed. To do this, I have logged into Microsoft Flow and have created a new Flow for myself.

The trigger event will be an RSS feed to look for changes to https://support.office.com/en-us/o365ip/rss

Microsoft Flow RSS Trigger

Microsoft Flow RSS Trigger

 

The action event will be to send an email through to me to warn me to update my firewall:

Microsoft Flow Send an Email

Microsoft Flow Send an Email

 

That’s all there is to it! You can choose any action you desire when an update is made to the RSS feed.

Hope this helps!