New functionality now in preview for Conditional Access

New functionality now in preview for Conditional Access

So I was happily minding my own business looking at the configuration of my Conditional Access and notice 3 new options have appeared;

  • Baseline policy: End user protection (Preview)
  • Baseline policy: Block legacy authentication (Preview)
  • Baseline policy: Require MFA for Service Management (Preview)

Baseline policy: End user protection (Preview)

This policy protects users by requiring multi-factor authentication (MFA) during risky sign-in attempts to all applications. Users with leaked credentials are blocked from signing in until a password reset.

Once the policy is enabled, users are required to register for MFA within 14 days of their first login attempt. The default method of MFA registration is the Microsoft Authenticator App.

This policy is either On or Off and you can also exclude users from receiving this policy

Baseline policy: Block legacy authentication (Preview)

This policy blocks all sign-ins using legacy authentication protocols that don’t support multi-factor authentication (such as IMAP, POP, SMTP). The policy does not block Exchange ActiveSync.

  • Office 2013 (without registry keys)
  • Office 2010
  • Thunderbird client
  • Legacy Skype for Business
  • Native Android mail client

This policy is either On or Off and you can also exclude users from receiving this policy. This policy is great as I have configured a custom built policy for just this but my policy also includes Exchange Active Sync.

Baseline policy: Require MFA for Service Management (Preview)

This policy requires users logging into services that rely on the Azure Resource Manager API to perform multi-factor authentication (MFA).

Services requiring MFA include:

  • Azure Portal
  • Azure Command Line Interface (CLI)
  • Azure PowerShell Module

This policy is either On or Off and you can also exclude users from receiving this policy

Its great to see some more brilliant developments in Conditional Access and really excited to see these go live with customers.

Regards
The Author – Blogabout.Cloud

Directory Based Edge Blocking in Exchange Online or (DBEB for short)

Directory Based Edge Blocking in Exchange Online or (DBEB for short)

What is DBEB? It is a solution that allows an organization to reject message for invalid recipient at the service network perimeter. DBEB enables your Office 365 Global Administrator to add mailed-enabled recipients to Office 365 and block all messages sent to email address that aren’t present in Office 365.

Valid messages are then subject to the rest of the service filtering layers which are;

Antimalware
Antispam
Mail Flow Rules (otherwise knows as Transport Rules)

Invalid messages are blocked before filtering even occurs, and a non-delivery report (also known as an NDR or bounce message) is returned to the sender. The NDR looks like this:

1
550 5.4.1 [<InvalidAlias>@\<Domain>]: Recipient address rejected: Access denied

Important Note

In hybrid environments, in order for DBEB to work, email for the domain must be routed to Office 365 first (the MX record for the domain must point to Office 365).

Configuring DBEB

First of all, you need to verify that your accepted domain EXO is an Internal Relay, this is done by going to Exchange Admin Console –> Mail Flow –> Accepted domains.

If, your domain type is Authoritative you will need to click the edit button and set to internal relay

Adding your users to Office 365

In the EAC, go back to Mail flow > Accepted domains.

Select the domain and click Edit.
Set the domain type to Authoritative.
Choose Save to save your changes, and confirm that you want to enable DBEB.

  • Until all of your valid recipients have been added to Exchange Online and replicated through the system, you should leave the accepted domain configured as Internal relay. Once the domain type has been changed to Authoritative, DBEB is designed to allow any SMTP address that has been added to the service (except for mail-enabled public folders). There might be infrequent instances where recipient addresses that do not exist in your Office 365 organization are allowed to relay through the service.
  • For more information about DBEB and mail-enabled public folders, see Office 365 Directory Based Edge Blocking support for on-premises Mail Enabled Public Folders.

Regards.
The Author – Blogabout.Cloud

Microsoft Teams Direct Routing with Azure Audiocodes SBC

Microsoft Teams Direct Routing with Azure Audiocodes SBC

Microsoft Teams Direct Routing is the latest in connecting your SIP trunk provider but how about leveraging the Microsoft cloud and deploy your Session Boarder Controller (SBC) into Azure.

Audiocodes are one of many SBC providers using Azure to provide an additional options with your approach to moving to Microsoft Teams.  If your a consultant deploying AudioCodes Mediant VE SBC for Microsoft Azure, this process couldnt be any easier with using Azure Resource Manager (ARM) templates which can be developed to adapt to any customer requirements.

If you have a bit of Azure knowledge in deploying new resources the below image will not be to difficult understand.

But if this is the first time you’ve looked deploying a resource in Azure, I highly recommend looking at creating a template and use Visual Studio. This will allow you to make modification in the code and learn how ARM templates work.

How much does the Audiocodes Virtual Machine cost?

The below tables is based on today costing as of 12 November 2018 and these prices may change.

VM Size Offering Family VCPU RAM Data Disk Max IOSP Temporay Storage SIP Sessions Price
D2_v2 Standard General Purpose 2 7 8 8×500 100GB 200 £75.41
D2_v3 Standard General Purpose 2 8 4 4×500 50GB 500 £66.54
D3_v2 Standard General Purpose 4 14 16 16×500 200GB 900 £150.83

Microsoft Teams Direct Routing will only get bigger as time goes on and you can expect the number of supported SIP sessions to increase (expected 6000 sessions in Q1 2019). It is also worth noting that Audiocodes also offer a multi tenant SBC so if you are a service provider, you can house multi customers on a single SBC appliance.

Regards

Author – Blogabout.Cloud

Dynamic groups in Microsoft Teams

Dynamic groups in Microsoft Teams

Microsoft Teams now supports dynamic groups but what does this mean? Dynamic groups are an Azure AD Premium (P1) feature that allows group membership to be automatically tied to AD attributes (i.e. users with a location of ‘London, New York or Seattle’) that will continuously sync as the membership changes over time. Dynamic group membership reduces the administrative overhead of adding and removing users.

Which is great for IT Administrator across the group.

How to create a dynamic group

Please follow the steps from here

https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-create-rule

Once you have created the group, every assigned member will receive an email stating they have joined the defined group

We already have a group (Office or Security) and would like to change its membership type to “Dynamic”

Of course you can do this from the Azure AD admin center. Please follow the steps from here https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-change-type

How do create a Microsoft Team with a Dynamic Group

Launch Microsoft Teams and click “Join or create a team

Click “Create a team from an existing Office 365 Group

Select the dynamic group you are an owner of and the group name will become the Team name.

Command Questions

Does this support syncing Security Groups (SGs)?

No, dynamic membership groups are different from SG/DL

How long does the dynamic group changes take to reflect in Teams?

This can take up to 2 hours after membership changes are reflected in Azure portal.

Regards,

Author – Blogabout.Cloud

Configuring Microsoft Intune – Apps within your company portal

Configuring Microsoft Intune – Apps within your company portal

Do you have one of the following licencing sets and you are not utilising Microsoft Intune? It would be criminal.

  • Intune
  • Enterprise Mobility + Security E3
  • Enterprise Mobility + Security E5
  • Microsoft 365 E3
  • Microsoft 365 E5
  • Microsoft 365 F1
  • Microsoft 365 Business
  • Microsoft 365 Education A1
  • Microsoft 365 Education A3
  • Microsoft 365 Education A5

Its time roll out the company portal and manage your corporate data across all mobile device.

Microsoft Intune is not available for the following licence sets and you need need to purchase one of the valid sets above.

  • Office 365 F1
  • Office 365 Business Premium
  • Azure Active Directory Free, Basic, Premium P1, Premium P2 None

Launch Microsoft Azure Portal

(https://portal.azure.com)

Open Intune either by using the Search resources, services, and docs or from your favourites. Select Client apps, Apps.

As you can see, there are no applications found currently within Client apps. In this section are able to define a number of different applications types with can be used whole Microsoft Intune platform.

For the purposes of this blog post we are only focusing on Other –> Built-In applications which have been optimised by Microsoft to ensure that all corporate data and general applications are secure.

Built-In applications target most of the Microsoft applications that are used day to day by all corporate enterprises. We will be selecting Adobe Acrobat Reader for Intune as an example of how to configure and publish applications into the company portal.

Click on your chosen app, press “Select” and press “Add”

Select Properties, App information – configure

Within this section you will need we will need configure the app information with the following

  • Category – This is not key but allows you group business, productivity, etc.. applications together
  • Display this as a feature app in the Compant Portal – Yes 
  • Logo – Give the application a logo which will appear in the company portal

Save the changes

Select Assignments, Add group

Under Assignment type, I have selected Available for enrolled devices.

Select Include Groups, Select Yes, Press OK x2 and Save

This will now make this application available within the company portal and you can repeat this process for other built-in applications.

 

This concludes this post

Regards

The Author – Blogabout.Cloud

Install PowerShell for Azure Stack

Install PowerShell for Azure Stack

Installing PowerShell for Azure Stack has a number of prerequistes which need to be met. The following script has been designed and tested to preform all the necessary tasks within a single script execution.

The following steps have been taken from https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-powershell-install

1. Verify your prerequisites

Before your get started with Azure Stack and PowerShell, you will need to have a few requirements in place.

PowerShell Version 5.0
To check your version, run $PSVersionTable.PSVersion and compare the Major version. If you do not have PowerShell 5.0, follow the link to upgrade to PowerShell 5.0.

Note

PowerShell 5.0 requires a Windows machine.

Run Powershell an elevated prompt
You will need to be able to run PowerShell with administrative privileges.

PowerShell Gallery access
You will need access to the PowerShell Gallery. The gallery is the central repository for PowerShell content. The PowerShellGet module contains cmdlets for discovering, installing, updating, and publishing PowerShell artifacts such as modules, DSC resources, role capabilities, and scripts from the PowerShell Gallery and other private repositories. If you are using PowerShell in a disconnected scenario, you will need to retrieve resources from a machine with a connection to the Internet and store them in a location accessible to your disconnected machine.

2. Validate if the PowerShell Gallery is accessible

Validate if PSGallery is registered as a repository.

Note

This step requires Internet access.

Open an elevated PowerShell prompt, and run the following cmdlets:
PowerShell

Import-Module -Name PowerShellGet -ErrorAction Stop
Import-Module -Name PackageManagement -ErrorAction Stop
Get-PSRepository -Name “PSGallery”

If the repository is not registered, open an elevated PowerShell session and run the following command:
PowerShell

Register-PsRepository -Default
Set-PSRepository -Name “PSGallery” -InstallationPolicy Trusted

3. Uninstall existing versions of the Azure Stack PowerShell modules

Before installing the required version, make sure that you uninstall any previously installed Azure Stack AzureRM PowerShell modules. You can uninstall them by using one of the following two methods:

To uninstall the existing AzureRM PowerShell modules, close all the active PowerShell sessions, and run the following cmdlets:
PowerShell

Uninstall-Module AzureRM.AzureStackAdmin -Force
Uninstall-Module AzureRM.AzureStackStorage -Force
Uninstall-Module -Name AzureStack -Force

Delete all the folders that start with Azure from the C:\Program Files\WindowsPowerShell\Modules and C:\Users\AzureStackAdmin\Documents\WindowsPowerShell\Modules folders. Deleting these folders removes any existing PowerShell modules.

4. Connected: Install PowerShell for Azure Stack with Internet connectivity

Azure Stack requires the 2017-03-09-profile API version profile, which is available by installing the AzureRM.Bootstrapper module. In addition to the AzureRM modules, you should also install the Azure Stack-specific PowerShell modules.

Run the following PowerShell script to install these modules on your development workstation:

Version 1.4.0 (Azure Stack 1804 or greater)
PowerShell

# Install the AzureRM.Bootstrapper module. Select Yes when prompted to install NuGet
Install-Module -Name AzureRm.BootStrapper

# Install and import the API Version Profile required by Azure Stack into the current PowerShell session.
Use-AzureRmProfile -Profile 2017-03-09-profile -Force

# Install Module Version 1.4.0 if Azure Stack is running 1804 at a minimum
Install-Module -Name AzureStack -RequiredVersion 1.4.0

Version 1.2.11 (before 1804)
PowerShell

# Install the AzureRM.Bootstrapper module. Select Yes when prompted to install NuGet
Install-Module -Name AzureRm.BootStrapper

# Install and import the API Version Profile required by Azure Stack into the current PowerShell session.
Use-AzureRmProfile -Profile 2017-03-09-profile -Force

# Install Module Version 1.2.11 if Azure Stack is running a lower version than 1804
Install-Module -Name AzureStack -RequiredVersion 1.2.11

Confirm the installation by running the following command:
PowerShell

Get-Module -ListAvailable | where-Object {$_.Name -like “Azs*”}

If the installation is successful, the AzureRM and AzureStack modules are displayed in the output.

All seems simple, right?

PowerShell script demonstration

The following video demonstrates the Set-AzureStackPS script, which is available to download via the following URL.

Download

PowerShell for Azure Stack (178 downloads)

Change Log

Version 1.1 – Features

  • Improved error detection for failed PowerShell module installation
  • Improved support for PSGallery detection
  • Improve code structure

Reporting Issues

If you identity any issues within running the script please email theauthor@blogabout.cloud

Regards

The Author – Blogabout.Cloud