ADFS Additional Authentication Rules – MFA Issue Type

Leave a comment

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

Leave a comment

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

Leave a comment

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

1 Comment

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!

 

Script – control Client Access features using set-mailbox

Leave a comment

I put together a short script recently which will enumerate all users in an Office 365 Group (Security/Distribution/O365Group) and disable certain Client Access features. In my case, I wanted to disabled IMAP, POP and MAPI connectivity. This leaves a user only able to perform Kiosk style connectivity through either OWA, EWS or ActiveSync. The users in question had E1 licenses, but the customer wanted to limit connectivity so that rich mail clients such as Outlook could not be used.

The script looks like this:

$group=Get-MsolGroup | Where {$_.DisplayName -eq "uk-dg-kiosk"}
$groupid=$group.ObjectId
$groupmembers=Get-MSOLGroupMember -GroupObjectId $groupid
ForEach ($member in $groupmembers.emailaddress)
{Set-CASMailbox $member -ImapEnabled $false -MAPIEnabled $false -PopEnabled $false}
ForEach ($member in $groupmembers.emailaddress)
{Get-CASMailbox $member}

I have also created a similar script which will apply to any user which has a particular license SKU:

$licensepack=Get-MsolUser -All | Where {$_.Licenses.AccountSKUId -ccontains "MISSTECH:ENTERPRISEPACK"}
ForEach ($user in $licensepack.userprincipalname)
{Set-CASMailbox $user -ImapEnabled $false -MAPIEnabled $false -PopEnabled $false}
ForEach ($user in $licensepack.userprincipalname)
{Get-CASMailbox $user}

This could be run on demand, or using a scheduled task. Using a scheduled task involves supplying credentials so be careful when you do this!

Have a look at my guide for setting up scheduled tasks with Office 365 to learn how to avoid using plain text passwords in your tasks: https://misstech.co.uk/2016/06/08/office-365-powershell-and-scheduled-tasks/

Till next time x

 

DNS Traffic Management Policies

Leave a comment

This awesome new Server 2016 feature can be used to create a DNS policy which responds to a query for the IP address of a web server with a different IP address based on the source subnet of the client.

Let’s take an example; we have ADFS configured in Azure using the following settings:

Hostname: sts.misstech.co.uk
Internal IP: 192.168.9.11
External IP: 57.119.128.179 (this is made up so don’t try and go there!)

There are 2 sites, London and Manchester. London has a VPN link to Azure, however Manchester has no route to Azure. Both sites are connected to each other and the Domain Controller is located in London.

This means that London users (on 192.168.10.0/24) can access ADFS, however Manchester users (on 192.168.11.0/24) cannot access ADFS using the internal IP. We need to route Manchester users to ADFS via the external ADFS IP, but how to do this when they are resolving DNS records via the same Domain Controller? Host files can do this but that is complex and doesn’t allow for mobility. Enter Traffic Management using Server 2016.

To do this, the following steps need to do performed.

·       First, add the subnets which you want to use for traffic management.

Add–DnsServerClientSubnet –Name “Manchester” –IPv4Subnet “192.168.11.0/24” –PassThru

·       Next, add the subnet associated zone. The zone must already exist for this command to work.

Add-DnsServerZoneScope -ZoneName “eacsdemo.online” -Name “Manchester” -PassThru

·       Add the DNS Resource Record

Add-DnsServerResourceRecord -ZoneName “eacsdemo.online” -A -Name “sts” -IPv4Address “52.169.178.129” -ZoneScope “Manchester” -PassThru

·       Add the Traffic Management Policy to route Manchester requests through to

Add-DnsServerQueryResolutionPolicy -Name “ManchesterPolicy” -Action ALLOW -ClientSubnet “eq,Manchester” -ZoneScope “Manchester,1” -ZoneName “eacsdemo.online” -PassThru

These policies are very versatile, allowing you to combine multiple parameters (using AND/OR) such as client subnet, protocol, or time of day to create complex policies which can help you direct clients to the correct location.

I’ll finish this post with a small tip; if you want to remove or get the policy, make sure you specify the zone name or a null value will be returned. For example:

Get-DnsServerQueryResolutionPolicy -ZoneName “misstech.co.uk” -PassThru

remove-DnsServerQueryResolutionPolicy -ZoneName “misstech.co.uk” -PassThru

 

Azure Classic to Resource Manager Migration – Validation failed

1 Comment

I am starting to investigate the migration of resources from Azures Classic deployment mode into the shiny Azure Resource Manager mode.

The first step for me was to attempt to validate the VNET which I wanted to migrate to see if it was compatible. I ran the command listed on the following website (https://azure.microsoft.com/en-gb/documentation/articles/virtual-machines-windows-ps-migration-classic-resource-manager/)

    Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName

As I expected (nothing is ever simple is it?!) I received an error as shown below. The problem was that the validationmessages shown was limited and didn’t really show me any detail. In my case all it showed me was the name of my VNET.

Validation failed.  Please see ValidationMessages for details

In order to get some more detailed information out of the cmdlet, I ended up saving the validation command to a variable and then calling the variable, as shown below:

$validate = Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName -Verbose

$validate.validationmessages

This gave me lots of detail and I discovered that I had typed the VNET name incorrectly. D’oh! I forgot that when you create a Classic VNET in the new portal, the actual name of the VNET is not what you see in the new portal. You need to have a look in the old manage.windowsazure.com portal to see the actual name.

Hopefully this helps some folk out there!