Five things I wish I knew before ‘Next-Next-Finish’ing my Veeam Backup for Office 365 v4 installation

Veeam Backup for Office 365

Veeam Backup for Office 365 is an awesome product with a lot of possibilities and features. Just like Active Directory, it is a product that you can typically ‘next, next, finish’-install in about 10 minutes.

However, is that the best approach to implementing Veeam Backup for Office 365? Here’s my list of five things I wish I knew before ‘Next-Next-Finish’-ing my first Veeam Backup for Office 365 v4 installation roughly six months ago:

                        

Office 365 Sizer Tool

There is an awesome web-based tool by Veeam’s Senior Solution Architect Hal Yaman. The Microsoft Office 365 Backup Sizing tool, version 2 is a very efficient tool on how to estimate the storage requirements for Veeam Backup for Office 365. It takes all the guess work out of storage. I highly recommend it.

Read how to analyze your Office 365 Backup requirements with ease.

                      

Domain-Join

In recent months, Veeam is recommending to run Veeam Backup and Replication (VBR) on non-domain-joined boxes to make backups more resilient to ransomware attacks. However, you need to install Veeam Backup for Office 365 on a domain-joined box.

                                  

Modern Authentication is the way to go

The Security Defaults are in full swing for Azure AD tenants created after March 16th, 2020. Many other organizations using Azure AD without Azure AD Premium functionality are adopting the Security Defaults. Security Defaults are good from an information security point of view, as they require multi-factor authentication for privileged roles.

The Veeam Backup for Office 365 service account holds two highly-coveted privileged roles -Exchange Administrator and SharePoint Administrator- that both require multi-factor authentication.

Veeam Backup for Microsoft Office 365 offers a complete multi-factor authentication-proof installation. Here’s how to configure Veeam Backup for Microsoft Office 365 with Modern Authentication.

                                          

Default repository

Admins with some experience with setting up Veeam products know the first-run experiences. They offer great value if you need default settings.

When you first start Veeam Backup for Office 365, it offers a default schedule and a default repository with a default retention period. If one year of retention on a local disk is your preferred way to go, then you’d be done.

But are these the right settings for your repository? If not, than the consequence is that you’ll need to create a new repository, increasing the amount of storage needed for Office 365 backups on-premises to meet your goals in terms of retention and restore.

                                  

Offload to Object Storage is only available for new repositories

Many of the organizations I help have onboarded to Veeam Backup for Office 365 when it was version 1.5. We’ve been in-place upgrading these installations for years and have been able to take advantage of new and expanded features without a hitch.

However, the new option to offload Veeam Backup for Office 365’s backup repository to object storage, like Amazon S3 and Azure Storage, is not so easy to onboard; existing backup repositories can’t be transformed into offloaded repositories. The only right thing to do is to make a second (offloaded) repository and backup into that repository until the retention policy is reached for the objects in the original repository.

                                  

Concluding

I believe in a growth mindset. I believe that I should be ashamed of how I was doing things two years ago. This is how I learn. How I grow. How I heal. The other side of my approach is that I revisit old designs and approaches and thinking to myself: “I wish I knew then, what I know now…”. That’s perfect for sharing in blogposts like this one. Winking smile

0  

HOWTO: Use Azure AD Connect’s v2 Endpoint

Azure AD Connect

Azure AD Connect is Microsoft’s free tool to synchronize objects and their attributes from Active Directory Domain Services (AD DS) implementations to Azure Active Directory tenants. Many millions of organizations depend on Azure Active Directory and the APIs that the tool connects to. Now, there is a new endpoint Public Preview, so it’s time to take a closer look!

Why use the Azure AD Connect v2 Endpoint?

For years, Azure AD Connect has used an endpoint. The endpoint has served Azure AD Connect well. However, there are a couple of known limits to the endpoint:

Group membership limitations

With Azure AD Connect’s v1 endpoint, group memberships are limited to 50,000 members. Without a verified DNS domain name, a limit of 15,000 members is applied, though. With the v2 Endpoint, group memberships can now be set at 250,000 objects.

When the group memberships limit is increased, the new limit also applies to writing back Office 365 groups from Azure AD to Active Directory (if the Group WriteBack feature is enabled).

Performance limitations

Due to the way the v1 endpoint handles attribute changes, the v2 brings significant performance gains on exports and (delta) imports to Azure AD. Again, these changes benefit groups most as their members attribute may change often.

   

Known issues with the v2 Endpoint

There are three known issue for Azure AD Connect’s v2 Endpoint:

Additional errors shown

After enabling the new endpoint, you may see additional export errors on the AAD connector with name dn-attributes-failure. There will be a corresponding event log entry for each error with id 6949. The errors are informational and do not indicate a problem with your installation, but rather that the sync process could not add certain members to a group in Azure AD because the member object itself was not synced to Azure AD.

The new V2 endpoint code handles some types of export errors slightly different from how the V1 code did. You may see more of the informational error messages when you use the V2 endpoint.

In-place Upgrades

When upgrading Azure AD Connect, ensure that the steps below are rerun, as the changes are not preserved through the upgrade process.

Public Preview

Microsoft supports organization using the v2 Endpoint in production. If you need support when using this feature you should open a support case.

However, please know that Public Preview capabilities may be withdrawn and possibly redesigned before reaching further milestones. 

     

Getting ready

To take advantage of the v2 endpoints, you’ll need to meet the following requirements:

  1. One or more Azure AD Connect installations running version 1.5.30.0, or above.
  2. An Azure AD tenant in the global cloud. The Public Preview does not extend to sovereign clouds, like the US Government and VIANet’s China Azure, yet.

   

Enabling the use of the v2 Endpoint

Sign in on the Windows Server running Azure AD Connect.

Run the following lines of Windows PowerShell in an elevated Windows PowerShell window on the Windows Server with Azure AD Connect, that you’d want to use with the v2 Endpoint:

Set-ADSyncScheduler -SyncCycleEnabled $false

Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Extensions\AADConnector.psm1'

Set-ADSyncAADConnectorExportApiVersion 2

Set-ADSyncAADConnectorImportApiVersion 2

Set-ADSyncScheduler -SyncCycleEnabled $true

After these changes, the synchronization performance increases apply, but the group memberships limit of 50,000 members still applies.

    

Increasing the group memberships limit

To increase the group memberships limit, we’ll need to change the synchronization rule. Follow these steps to do so:

  1. Run the following line of Windows PowerShell in an elevated Windows PowerShell window on the Windows Server with Azure AD Connect, that you’d want to use with the v2 Endpoint:
                                                                                                 
  2. Set-ADSyncScheduler -SyncCycleEnabled $false
                                                 

  3. Open Synchronization Rules Editor from the Azure AD Connect folder in the Start Menu.
    The Synchronization Rules Editor screen appears.
  4. From the list of synchronization rules, select the Out to AAD – Group Join sync rule.
  5. Click the Edit button at the bottom of the Synchronization Rules Editor screen.
    The Edit Reserved Rule Confirmation pop-up appears.
  6. Click on the Yes button to acknowledge that to edit an out-of-the-box synchronization rule, you’d need to disable the rule and edit a copy of the original rule. As you click Yes, the original rule is disabled, an editable copy is created and you’ll start editing the copy.
    The Edit outbound synchronization rule screen appears.
  7. On the Description page of the Edit outbound synchronization rule wizard, change the value for Precedence to an available value between 1 and 99.
  8. Click the Next > button three times.
  9. On the Transformation page of the Edit outbound synchronization rule wizard, change the Source for the Expression for member. The source contains the default 50000 limit. You can change this value to anywhere between 50000 and 250000.
  10. Click the Save button.
  11. Close the Synchronization Rules Editor window.
  12. Switch to the PowerShell window.
  13. Run the following line of Windows PowerShell:
                                                                                                     
    Set-ADSyncScheduler -SyncCycleEnabled $true
0  

A Recap of Identity-related Announcements from Microsoft Build 2020

Microsoft Build 2020

Microsoft organized Microsoft Build 2020 as a free digital event between Tuesday May 19th 8AM Pacific Time and Thursday May 21st 8 AM Pacific Time.

Microsoft Build is Microsoft’s annual conference event, aimed at software engineers and web developers using Windows, Microsoft Azure and other Microsoft technologies. First held in 2011, it serves as a successor for Microsoft's previous developer events, the Professional Developers Conference (PDC) and MIX.

During Build 2020, Microsoft made the following Identity-related announcements:

   

Azure Active Directory External Identities

Azure Active Directory External Identities help organizations scale, manage directories and maintain continuity. They offer organizations the ability to scale IT resources and costs with just one solution that secures and manages all their identities.

Azure AD External Identities Public Preview empowers developers to build flexible, user-centric experiences for external users, including business partners and customers, and continuously customize without duplicating coding effort. External Identities also streamlines how IT admins manage their directories and identities — employee and external — through the Azure AD tool. 

IT leaders can optimize for business continuity by securely connecting with any user using the identity provider of their choice. This makes it easier for employees to remotely collaborate with their supply-chain partners in Microsoft Teams, SharePoint and custom line-of-business (LOB) apps, and for consumers to stay engaged through seamless digital experiences.

In Eha Goel’s demo, she showed the functionality with a user flow containing the B2X monitoring. Perhaps, this is the direction Microsoft is heading, leaving Azure AD B2B and Azure AD B2C behind.

                     

Application Consent Controls

IT administrators can create policies that decide the types of applications end users can consent to using Application Consent Controls Public Preview

Previously, IT administrators could either allow all end users or no end users to consent to applications. Using Application Consent Controls, admins can create policies in the Azure portal that determine which users can consent to which applications. For example, admins can allow end users to consent to applications that have been publisher verified, see below.

                  

Azure AD Consent Publisher Verification

Publisher Verification Public Preview allows developers with a verified Microsoft Partner Network (MPN) account to mark their applications as “Publisher Verified.”

Developers can distinguish their apps to end users by receiving a blue checkmark that indicates they are a verified publisher. Developers can differentiate their apps with a “verified” badge that will appear on:

  • The Azure Active Directory consent prompt
  • The Enterprise Apps page, and
  • Additional User Experience (UX) surfaces used by end users and admins.

IT administrators also will have increased transparency on whether verified or unverified apps are in use within their organization and can configure consent policies based on publisher verification.

                 

Microsoft Authentication Library Support

Microsoft Authentication Library (MSAL) now supports additional platforms, including Angular Generally Available and Microsoft.Identity.Web for ASP.NET Core Public Preview

Microsoft Authentication Library streamlines how developers implement the right authentication patterns, security features, and integration points that support any Microsoft identity:

  • MSA accounts
  • Azure Active Directory (AD) accounts and
  • Social accounts powered by Azure AD B2C.

Microsoft Authentication Library (MSAL) offers developers identity innovations such as passwordless authentication, multi-factor authentication and Conditional Access options that don’t require developers to implement that functionality themselves. Additionally, Microsoft Authentication Library (MSAL) for Android and iOS allow developers to build first-line worker apps that support shared device sign-in and sign-out.

               

Azure AD Authentication to Azure Database for PostgreSQL and Azure Database for MySQL

Microsoft’s Azure cloud service includes a portfolio of secure, enterprise-grade, fully managed database services that support open-source database engines.  Microsoft is announcing new product capabilities for these two database offerings:

  • Azure Database for PostgreSQL, and
  • Azure Database for MySQL

One of the new capabilities launched on both Azure Database for PostgreSQL and Azure Database for MySQL is Azure Active Directory Authentication Generally Available.

These new product capabilities will help developers across various types and sizes of workloads to productively leverage enterprise-grade security for their mission-critical work and effectively manage the costs of running their databases on PostgreSQL and MySQL.

1  

HOWTO: Secure VMware Horizon with Azure MFA through its NPS Extension

How To...

This week, one of my customers is switching to Azure multi-factor authentication as their only multi-factor authentication solution for their employees. As the organization leverages VMware Horizon, this implementation needs to be switched to Azure MFA as well.

Here’s how we secured their VMware Horizon implementation with Azure MFA through the Azure MFA NPS Extension:

 

Why use multi-factor authentication for Horizon?

Organizations face multiple challenges, including (but not limited to):

  • tackling current consumer cloud adoption problems
  • adhering to privacy regulations
  • achieving productivity

 

User cloud adoption problems

Today’s cloud applications and services allow sign-ins with email addresses, as it’s currently the only truly global identifier for people. However, as cloud applications and services are breached, credential sets fall in the hands of malicious people. Though credential stuffing attacks, they will use these leaked credentials and try them on your organization’s public facing applications and services.

Privacy regulations

To adhere to privacy regulations, organizations deploy virtual desktop solutions to provide secure means to achieve productivity with the organization’s sensitive data. There are many virtual desktop solutions in the market today, but VMware’s Horizon product is the popular choice for organizations.

1 + 1 = ?

However, when a malicious person gains access to the ‘secure’ productivity platform of an organization through stuffed credentials. the organization has a big problem.

Multiple MFA methods

With Microsoft cloud services on the rise, another problem might also arise: disparate multi-factor authentication methods for users. It’s counter-intuitive for people to have to use one multi-factor authentication method for one system or platform the organization uses, and another method for another. The hassle of keeping more than one method up to date for people who change phone numbers and/or phones yearly grows exponentially with each multi-factor authentication method added.

Note:
In my opinion, administrators should get used to multiple multi-factor authentication methods and solutions to avoid getting locked out by single multi-factor authentication solution acting up.

 

Getting ready

Before following the below steps, make sure you meet the following prerequisites:

  • Implement one or more additional Windows Server-based virtual machines to act as the Network Protection Services (NPS) Server(s) for Horizon. Make sure they run Windows Server 2016, or up. Implement the server on the same network as the Active Directory Domain Controllers.
  • Provide network connectivity between the new NPS Server(s) and the Horizon implementation. Take care of any routes and firewall configurations. Horizon View’s Connection Server(s) need access to the NPS Server(s) using UDP1812 and UPD1813.
  • Provide network connectivity between the new NPS Server(s) and Azure Active Directory. The NPS Server(s) need TCP80 and TCP443 access to these addresses:
      • https://adnotifications.windowsazure.com
      • https://login.microsoftonline.com
      • https://credentials.azure.com
      • https://provisioningapi.microsoftonline.com
      • https://aadcdn.msauth.net
      • https://*.nuget.org
      • https://nuget.cdn.azure.cn
  • You need the credentials for an account in Active Directory to join the NPS Server(s) to Active Directory.
  • You need the credentials to sign in to the NPS Server with an account that has local administrator privileges.
  • You need the credentials to sign in to the Horizon implementation with an account that has administrator privileges and access to Horizon Console.
  • You need the credentials for an account in Azure Active Directory that has the Global Administrator role.
  • Make sure all user accounts in Active Directory who will use Azure MFA with Horizon are synchronized to Azure Active Directory.
  • Make sure all persons who will use Horizon with Azure MFA have completed their one-time registration for Azure Multi-factor Authentication and are assigned the Azure AD Premium P1 stand-alone subscription license or a license bundle that includes Azure AD Premium P1.
  • Download the latest version of the NPS Extension for Azure MFA and place it on the disk of the NPS Server(s), so it’s available for installation.
  • Download the Visual C++ Redistributable Packages for Visual Studio 2013 (X64) and place it on the disk of the NPS Server(s), so it’s available for installation.

 

How to get the Azure AD Tenant ID

The installation of the Azure MFA Adapter needs the Azure AD tenant ID as input. To get this ID, follow these steps:

  • Open a web browser.
  • Navigate to the Azure AD Portal.
  • Sign in with an Azure AD account that has privileges to access the Azure AD data.
    As one of the prerequisites is the credentials of an Azure AD account with Global Administrator privileges, you can use that account, but you may opt to use a lesser privileged Azure AD account.
  • Perform multi-factor authentication, when prompted.
  • In the left navigation pane, click on Azure Active Directory.
  • In Azure Active Directory’s navigation pane, click on Properties.
  • Copy the value from the Directory ID field.
  • Close the web browser.

 

How to install the NPS Server

Follow these steps to install the NPS Server with the required components:

  • Sign in to the NPS Server wit local administrator privileges.
  • Start an elevated Windows PowerShell session and issue the following line of Windows PowerShell to join the Windows Server installation to Active Directory:
  • Add-Computer-DomainName"nlan.local"
  • Restart-Computer
  • After the Windows Server installation reboots, sign in with an Active Directory account that provides local administrator privileges to the NPS Server.
  • Start an elevated Windows PowerShell session.
  • Run the following line of Windows PowerShell to install the Network Protection and Authentication Server (NPAS) role:
  • Install-WindowsFeatureNPAS-IncludeManagementTools
  • Run the following line of
    Windows PowerShell to install the AzureAD PowerShell
    Module. Follow the on-screen instructions.
  • Install-module AzureAD
  • Run the Visual C++ Redistributable Package for Visual Studio 2013 to install it. Follow the on-screen instructions.
  • Run setup.exe from the NPS Extension for Azure MFA to install it. Follow the on-screen instructions.
  • Run the following lines of Windows PowerShell to configure the Azure MFA NPS Extension:
  • cd ”c:\ProgramFiles\Microsoft\AzureMfa\Config"
  • .\AzureMfaNpsExtnConfigSetup.ps1
  • When prompted, sign in with the Azure AD account with Global Administrator privileges.
  • Paste the Azure AD tenant ID.
  • Close the PowerShell window.

Repeat the above steps on the second NPS Server.

 

How to configure the NPS Server

Follow these steps to configure the NPS Server settings:

  • Now, Open the Network Policy Server management console from either Server Manager’s Tools menu, or the Administrative Tools folder in the Start Menu.
  • Right-click the NPS (Local) node in the top left corner of the navigation screen and click on the Register server in Active Directory menu item.
  • Next, right-click on the Radius Clients node in the navigation screen. Click New.
    The New RADIUS Client window appears.
  • Make these changes:
    • Select the Enable this RADIUS client option.
    • Specify a meaningful value in the Friendly name: field.
    • Define the IP address or fully qualified domain name for  the Horizon View Connection Server you’d want to configure with Azure MFA in the Adress (IP or DNS): field.
    • Specify a shared secret in the Shared secret: and the Confirm shared secret: fields, that will be used to obfuscate the traffic between the Horizon Connection Server and the NPS Server.
    • Click OK.
  • Create RADIUS clients for each Horizon Connection Server you’d want to configure.
  • Next, right-click on the Network Policies node in the navigation screen.
  • Duplicate the default Connections to other access servers network policy.
  • Assign priority 1.
  • Make two changes in the duplicated network policy:
    1. Check the Policy enabled option in the Policy State area.
    2. Check the Grant access. Grant access if the connection request matches this policy option in the Access Permission area.

AzureMFA NPS Settings (click for original screenshot)

  • Save the network policy by clicking OK.
  • Close the Network Policy Server management console.
  • Sign out.

 

How to configure VMware Horizon

On the Horizon View Management Server(s), configure the following settings:

  • Open Horizon Administrator.
  • Navigate to View Configuration, then to Servers.
  • On the Connection Servers tab, select a server instance to (re)configure.
  • Click Edit.
  • Click on the Authentication tab.
  • In the Advanced Authentication section, select RADIUS from the drop-down list for the 2-factor authentication value.
  • Enable the option Enforce 2-factor and Windows user name matching.
  • Enable the option Use the same user name and password for RADIUS and Windows authentication.
  • Click the Manage Authenticators… button
    The Manage Authenticators screen appears.
  • Click the Add or Edit button in the Manage Authenticators screen.
    The Edit RADIUS Authenticator modal screen appears.
  • On the Primary Authentication Server tab, specify the following settings:
    • Specify the hostname or IP-address for the NPS Server
    • For the Authentication type:, specify MSCHAP2.
    • Paste the RADIUS shared secret as the Shared Secret: value.
    • For the Server timeout: value, specify 10 seconds.
    • For the Max attempts: value, specify 1.

Azure MFA Horizon Settings (click for original screenshot)

  • To specify a second NPS Server with the Azure MFA NPS Extension installed, repeat the steps on the Secondary Authentication Server tab.
  • Click OK.
  • Close Horizon Console.

 

Concluding

The Azure MFA NPS Extension proves to be a splendid way to provide multi-factor authentication to VMware Horizon implementations. Now, credential stuffing attacks by malicious persons aren’t something to worry about anymore for the sensitive data handled in Horizon implementations.

Further reading

Download the NPS Extension for Azure MFA
Configure Firewalls for RADIUS Traffic
Integrate your existing NPS infrastructure with Azure Multi-Factor Authentication  Enable Two-Factor Authentication in Horizon Administrator

4  

Identity-related sessions at Microsoft Build 2020

Microsoft Build 2020

Microsoft organizes Microsoft Build 2020 as a free digital event between Tuesday May 19th 8AM Pacific Time and Thursday May 21st 8 AM Pacific Time.

Microsoft Build is Microsoft’s annual conference event, aimed at software engineers and web developers using Windows, Microsoft Azure and other Microsoft technologies. First held in 2011, it serves as a successor for Microsoft's previous developer events, the Professional Developers Conference (PDC) and MIX.

During Build 2020, you can enjoy the following general and Identity-related sessions:

 

Build Live Sessions

BDL211 – The importance of an Identity Platform

Speakers: Sonia Cuff, Jess Dodson, Jesse Suna
Date: Wednesday May 20
Duration: 60 minutes

Join Sonia, Jess and Jesse to discuss why Identity is a crucial technology component for both IT Pros and Developers.

 

Digital Break-out Sessions

INT105 – Building zero friction apps on Teams with SSO and Graph

Speaker: Nick Kramer
Level: 200
Date: Wednesday May 20, Thursday May 21
Duration: 30 minutes

Remove roadblocks on the way of your app adoption with SSO, Microsoft Graph, and resource-specific consent.

 

INT107 – Microsoft Graph Live

Speaker: Darrel Miller
Level: 100
Date: Tuesday May 19, Wednesday May 20, Thursday May 21
Duration: 30 minutes

Microsoft Graph is the API that describes the patterns of identity, productivity and security in organization around the world. Join us for a lively session and learn how to get started connecting you applications to the Microsoft Graph.

 

INT108 – Creating Trustworthy applications with Microsoft Identity

Speaker: Jeff Sakowicz / Philiipe Signoret
Level: 200
Date: Wednesday May 20, Thursday May 21
Duration: 30 minutes

Join this session and learn best practices to create secure and trustworthy applications with the Microsoft identity platform. Learn how to develop apps that can be securely adopted by organizations and how to use verification and certification programs to build trust.

 

INT109 – Reach millions of users building apps with the Microsoft Identity Platform

Speaker: Jean-Marc Prieur
Level: 200
Date: Wednesday May 20, Thursday May 21
Duration: 30 minutes

The Microsoft identity platform offers the building blocks for authentication, single sign-on and resource access. Join this session and learn how you can build apps that reach any user, from employees to customers to partners and more.

 

Community Connection Experiences

Com04 – Ask the Team: Azure Active Directory B2C

Speakers: Abhishek Agrawal, Steve Ball, Jenny Ferries, Neha Goel, and others
Level: 200
Date: Wednesday May 20
Duration: 60 minutes

Ask questions about customizing the way your customers sign up, sign in, and manage profiles when using iOS, Android, .NET, and single-page (SPA). Connect with Microsoft’s identity team!

 

COM09 – Ask the Team: Identity and Access for Azure

Speakers: Saeed Akhter, Sudheer Bysani, Ramiro Calderon, Jenny Ferries, and others
Level: 200
Date: Wednesday May 20
Duration: 60 minutes

Meet the Identity team and ask questions about best practices for securing Azure resources. Discuss RBAC and authenticating to Azure resources and your own microservices.

 

COM30 – Expert Q&A: Authentication Libraries

Speakers: Jenny Ferries, Bogdan Gavril, Jean-Marc Prieur
Level: 200
Date: Wednesday May 20
Duration: 30 minutes

Get questions about authentication libraries like MSAL.NET, middleware, and Microsoft.Identity.Web answered. Bring your questions about building secure by default ASP.NET Core web apps and web APIs.

 

COM45 – Expert Q&A: M365 Application Validation

Speaker: Michael Aldridge
Level: 200
Date: Wednesday May 20
Duration: 30 minutes

Creating and getting your application into the store is critical so customers can find it. Learn pro-tips on how to submit your application and avoid mistakes to get to market as soon as possible.

 

COM49 – Expert Q&A: Remote Work with Microsoft 365

Speaker: Stephen Rose
Level: 200
Date: Wednesday May 20
Duration: 30 minutes

Join Stephen Rose with your questions, comments, and feedback on our new portal to enable their employees to work remotely with Microsoft 365.

 

COM94/COM95 – Focus Group: Microsoft Graph Features and Feedback

Speakers: Yina Arenas, Vincent Biret, Arpitha Dhanapath, Ryan Gregg, and others
Level: 200
Date: Wednesday May 20, Thursday May 21
Duration: 60 minutes

Focus Groups are a chance for us to hear from you. To ensure all participants can share their thoughts, these sessions have limited capacity. Microsoft Graph is constantly evolving to keep pace with what our developers want. Come share your feedback with us around new features/services that are upcoming in Microsoft Graph Services.

 

COM96/COM97 – Focus Group: Microsoft Identity Platform Permissions & Consent

Speakers: Ipshita Nag, Jeff Sakowicz, Philippe Signoret, and others
Level: 200
Date: Thursday May 21
Duration: 60 minutes

Focus Groups are a chance for us to hear from you. To ensure all participants can share their thoughts, these sessions have limited capacity. Provide feedback on Microsoft Identity Platform's permissions & consent framework. Discuss challenges, consent policies set by customers, and the new publisher verification experience.

 

COM106 – Focus Group: Securing Applications and Services

Speakers: Susan Mings, Ipshita Nag, Kevin Yam
Level: 200
Date: Tuesday May 19
Duration: 60 minutes

Focus Groups are a chance for us to hear from you. To ensure all participants can share their thoughts, these sessions have limited capacity. Join the Microsoft Identity team to discuss your experience as a Developer or DevOps professional integrating apps with our authentication platforms so we can build better tools for you.

COM136 – Focus Group: Application Experience for Azure AD

Speakers: Allison Amaral, Luis Carlos Leon Plata, Sam Mak, Ipshita Nag, Ben Vincent
Level: 200
Date: Tuesday May 19
Duration: 60 minutes

Focus Groups are a chance for us to hear from you. To ensure all participants can share their thoughts, these sessions have limited capacity. See scenarios regarding the new unified app experience that combines the enterprise app and app registration experiences. Create, edit, and manage custom applications, app proxy, or gallery apps.

 

COM229 – Introduction to Digital Identity, the foundation of digital trust

Speaker: Kristina Yasuda
Level: 200
Date: Thursday May 21
Duration: 30 minutes

Single-sign on, multifactor authentication, usage of biometrics, etc. Have you ever noticed that how we authenticate and verify ourselves is at the foundation of digital trust? Welcome to the world of Digital identity! We will do a quick tour over the concepts, standards and use-cases.

0  

Twenty Years in IT

A Carreer in IT

Exactly twenty years ago, on May 15th 2000, I started working at Operator Groep Delft. While they weren’t my first employer, it was my first employer in IT.

In the past twenty years I’ve developed my skills and have grown a career. It wasn’t a straight line though, and it sure was a bumpy ride!

However, the people I met along the way and the experiences we share together have shaped me to the person I am today.     

Thank you! Thumbs up

 

More questions than answers?
Check my LinkedIn profile for details on my career and the IT challenges I might be able to help you with.

2  

TODO: Optimize the Azure Multi-factor Authentication methods used throughout your organization

Microsoft Azure Multi-Factor Authentication

Multi-factor Authentication will be organizations’ means of authentication verification for a while. After clearing the first hurdles in your organization when implementing multi-factor authentication, consisting of communication, registration and adoption, the next hurdle is optimization.

 

Why optimize Multi-factor Authentication?

Multi-factor Authentication offers verification of people authenticating to access organizational data, applications, services and/or systems; Beyond the username and password, multi-factor authentication allows for additional verification by prompting the person to prove he or she has access to something (a phone number, a pre-registered app on their phone) or to prove he or she is the person (through facial recognition or a finger print).

The recommendation is to have people register for at least two independent multi-factor authentication methods.

This way:

  • When a person forgets or loses their phone, they can still perform multi-factor authentication and achieve productivity
  • When a person gets a new phone, they don’t require the Authenticator app to be pre-registered to be able to perform multi-factor authentication and achieve productivity
  • When nothing else works, they can still sign in using their OATH-based token

Now, in some cultures and organizations, people don’t want to install any corporate application or pushed any organizational setting to their private phones. Multi-factor authentication was rolled-out, keys were handed out, etc. and now no-one in the organization has a firm grip on who uses what authentication method and why.

 

Azure MFA authentication method analysis

Microsoft offers a Windows PowerShell script to analyse Azure AD user objects to make recommendations on how to improve each user's Azure Multi-factor Authentication configuration.

Limitations

You can't use a guest (B2B) account to run this script against the target tenant. The script will execute in the guest's home tenant, not the target tenant.

Getting ready

To run the script, you’ll need to meet the following requirements:

  • You need an Azure AD tenant, obviously
  • You need a Windows system that has networking connectivity to Azure AD. If the system is located behind a proxy or firewall, allow the required traffic by specifying the proxy as the system-wide proxy and/or specify firewall rules to allow the traffic
  • You need a Windows system with at least PowerShell version 3 installed
  • You need local administrator privileges on the Windows system, unless you’ve previously installed the MSOnline PowerShell module (version 1.1.183.57 of the MSOnline PowerShell Module is required, or up).
  • You need networking connectivity to the Nuget infrastructure, unless you’ve previously installed the MSOnline PowerShell module (version 1.1.183.57 of the MSOnline PowerShell Module is required, or up).
  • You need permissions in the Azure AD tenant to enumerate user object properties. The user administrator role in Azure AD is the least privilege delegated role that provides these permissions.

Getting the script

Download the script from aka.ms/MFAAuthMethodsAnalysis.
A mirror of the script is available here.

Place it in an easily reachable folder on the Windows system.

Getting the Azure AD Tenant ID

The script requires input. It requires the Azure AD TenantID.
There are several ways to get this globally unique identifier (GUID) for your Azure AD Tenant, but below, I’ll show the graphical way to get it:

  • Open a browser
  • Navigate to the Azure AD Portal
  • Sign in with an account in the Azure AD tenant
  • Perform multi-factor authentication when prompted
  • In the left navigation pane, click on Azure Active Directory.
  • In Azure AD’s navigation pane, click on Properties.
  • In the main pane, the Tenant ID is shown in the Directory ID field.
  • Copy the value.
  • Sign out of the Azure AD Portal by clicking on the name of the signed-in account in the top-right corner of the portal experience. Click the Sign out link.
  • Close the browser

Sign in

Sign in with an account that has administrative privileges on the Windows system.

Install or Update the MSOnline Windows PowerShell Module

Open an elevated Windows PowerShell window.

Run the following line of Windows PowerShell to either install or update the MSOnline Windows PowerShell module:

Install-Module MSOnline -force

Run the script

In the existing (and yet elevated) Windows PowerShell window, navigate to the local folder where you’ve placed the MfaAuthMethodsAnalysis.ps1 script. For instance, you can run the following line:

cd C:\Mgmt

Then, run the script with the following options:

MfaAuthMethodsAnalysis.ps1 -TenantID <YourTenantID> | Out-GridView

Sign in with an Azure AD user account that has at least the User Administrator role assigned and perform multi-factor authentication, when prompted.

The script results in a GridView window with columns for the number of Authentication methods (MfaAuthMethodCount), the default method (DefaultMethod), a column per authentication method (AppNotification, OathTotp, Sms, Phone and AltPhone) and a column with Recommendations. The GridView allows you to sort by column.

Note:
The output does not include the actual phone numbers, etc. for privacy reasons.

Putting the information to good use

You can use the authentication method columns to create an inventory of the methods configured. This might result in statistics on the people that won’t use personal gear for business purposes.

You can use the recommendations to allow people in the organization to fulfill all of the multi-factor authentication methods. This way, any of the scenarios that might result in a lock-out (forgotten phone, etc.) do not hinder productivity.

 

Concluding

Use the Azure MFA authentication method analysis script to analyse and optimize Azure multi-factor authentication usage within your organization.

Also, consider other methods to satisfy multi-factor authentication like Windows Hello for Business and FIDO2-based security keys.

0  

Azure AD Connect 1.5.30.0 fixes two issues

Azure AD Connect

After every fresh major release of Azure AD Connect by Microsoft, several smaller hotfix releases update the functionality to prevent issues where administrators are not able to perform certain configurations or gain access to functionality.

Last week, Azure AD Connect version 1.5.30.0 was released, fixing two issues that were introduced in the first release of the 1.5.x.0 branch of Azure AD Connect releases.

 

What’s Fixed

Azure AD Connect version 1.5.30.0 fixing two issues:

Incorrect domain selection

This version of Azure AD Connect fixes an issue where unselected domains were getting incorrectly selected from the Azure Active Directory Configuration wizard.

Errors when setting AD Permissions

This version of Azure AD Connect fixes an issue in the ADSyncConfig Windows PowerShell module, where invoking dsacls.exe command used in all the Set-ADSync* Permissions cmdlets would cause one of the following errors:

  • GrantAclsNoInheritance : The parameter is incorrect. The command failed to complete successfully.
  • GrantAcls : No GUID Found for computer …

 

Additionally, for version 1.5.18.0 (the first release of the 1.5.x.0 branch of Azure AD Connect releases), the documentation now reads that an issue was fixed on the Domain and OU filtering page that would remove the Run Profiles of an Active Directory domain by just partially expanding the domain tree, without making any changes. This issue should have last been observed in 1.4.x.0 release versions.

 

Version information

This is version 1.5.30.0 of Azure AD Connect.
This release is the first release in the 1.5 branch for Azure AD Connect. It was made available for download on April 23, 2020.

 

Download information

You can download Azure AD Connect here.
The download weighs 96.5 MB.

0  

TODO: Move from per-user MFA to Conditional Access

Azure Multi-factor Authentication

One of the remnants of the PhoneFactor infrastructure is an old page that is linked in the Azure Portal. It allows for enforcing multi-factor authentication on a per-user basis. It should not be used for several reasons. Here’s why.

 

Ways to require multi-factor authentication in Azure AD

In Azure Active Directory, there are three ways to require multi-factor authentication:

  1. Through a Conditional Access Policy;
  2. Through Security Defaults, when the Azure AD account has a privileged role or is an Azure service owner. or;
  3. Through enabling an Azure AD user object with multi-factor authentication.

Conditional Access

Conditional Access policies are the preferred way to require multi-factor authentication and/or other apply other access restrictions, like requiring a compliant device or require a certain location (based on egress IP address).

It is a flexible and straightforward means to break free from the old actor-action-resource model in Active Directory, but requires Azure AD Premium licenses.

People who are in scope of a Conditional Access policy will be prompted for one-time multi-factor authentication registration when they first sign in. However, requiring people to perform registration is prohibited to people with Azure AD Premium P2 licenses assigned.

Security defaults

For organizations that run Azure AD tenants without Azure AD Premium licenses, multi-factor authentication can be enforced through the Security Defaults feature.

The Security Defaults are non-configurable, but require multi-factor authentication registration at first sign-in and require multi-factor authentication for Azure AD user objects with privileged roles like the Global Administrator, SharePoint Administrator and Exchange administrator roles.

Security Defaults may prompt people in the organization for multi-factor authentication, when the user is a high risk user. As this can be perceived as erratic behavior from the platform, these people might call the service desk, which is exactly what you want.

Per user multi-factor authentication

The third way is the original way of enforcing multi-factor authentication in Azure AD. On a per-user basis, multi-factor authentication can be enabled and then enforced for specific users. No matter how the account is used to sign in, or what application, system or service is signed into, multi-factor authentication is required.

 

What’s wrong with per-user multi-factor authentication?

There are three big problems with per-user multi-factor authentication:

No delegation

The page to configure these settings has never been migrated to the Azure Portal.
This leads to a disparate admin experience and confusion. Also, because the page is not a part of the Azure Portal, (custom) roles can’t be used to delegate access. Its access requires Global Administrator privileges.

Conditional Access Inaccuracy

Second, when you enable per-user multi-factor authentication, a Conditional Access administrator will be seeking everywhere as to why a user always needs to perform multi-factor authentication. Conditional Access does not know of the requirement. The sign-in logs do not mention the per-user requirement. People with the Conditional Access administrator role do not have access to the page, as its access is limited to people with the Global Administrator role.

App Passwords

And then there are the app passwords. App Passwords are only available to users with per-user multi-factor authentication configured. Microsoft offers app passwords to people who need to meet multi-factor authentication on legacy platforms and in legacy applications. However, visibility of the usage of app passwords is next to none, making them hard to eradicate once deployed.

Note:
After the per-user multi-factor authentication requirement is lifted, people will not be able to create new App passwords or read the values of any existing App passwords. Eventually, they will have to use multi-factor authentication with their next hardware refresh, unless they’ve securely stored the value of their App password(s). It’s something.

 

Disabling per-user multi-factor authentication and switching to a Conditional Access policy

Disabling per-user multi-factor authentication is the way to go. The best way to disable per-user multi-factor authentication is to remove the enforcement on the user objects in the PhoneFactor portal and build a replacing Conditional Access policy targeting the group of users that was previously enforced.

Perform these steps:

  • Start a browser and navigate to the Azure AD Portal.
  • Sign in with an account with Global Administrator privileges.
    Perform multi-factor authentication when prompted.
  • In the left navigation menu, click Azure Active Directory.
  • In Azure AD’s navigation menu, click Security.
  • In the Security navigation menu, click on MFA under Manage.
  • Follow the Additional cloud-based MFA settings link in the main pane.
    A new tab or browser window opens.
  • Near the top of the page click on Users. This word represents a different ‘tab’ in the management experience of the cloud-based MFA service.
  • In the field to the left of the bulk update button, select Enforced from the drop-down list of MFA statuses for Azure AD user objects.
  • Write down the accounts.
  • Now, in the field to the left of the bulk update button, select Enabled from the drop-down list of MFA statuses for Azure AD user objects.
  • Write down these accounts, too.
  • Select the option box to the left of DISPLAY NAME at the top of the list of user objects to select of filtered objects with the Enabled status.
  • In the quick steps area to the right of the list, follow the link Disable.
  • In the Disable multi-factor authentication modal screen, click the yes button.
  • Now, in the field to the left of the bulk update button, select Enforced from the drop-down list of MFA statuses for Azure AD user objects.
  • Follow steps 9 through 11 to disable the per-user multi-factor authentication requirement for these user objects, too.
  • Close the browser tab or browser window and return back to the Azure AD Portal.
  • In the Azure Portal tab or window, click Azure Active Directory in the left navigation menu and then click Groups in Azure AD’s navigation menu.
  • In the Groups | All groups main pane, click the + New group link to create a new group in Azure AD.
  • Leave the Group type as Security.
  • Enter a name for the group in the Group name field, following your organization’s naming policy for groups. Something like People with MFA Required might cover it. Optionally, enter a Group description.
  • Leave the Membership type to Assigned and click the No members selected link.
    The Add members blade appears.
  • Search for the user objects on the list you created in steps 9 and 11. Add them to the newly created group by selecting them.
  • When you’ve selected all user objects, click the Select button at the bottom of the Add members blade.
  • In the New Group pane, click the Create button at the bottom of the pane.
  • Now, in the left navigation menu, click on Azure Active Directory.
  • In Azure AD’s navigation menu, click on Security.
  • Click on Conditional Access in the Security Menu.
  • In the Conditional Access | Policies main pane, click the + New policy link in the top action bar.
    The New pane appears.
  • In the Name field, enter a name for the Conditional Access policy following your organization’s naming policy for policies.
  • Under assignments, click on the 0 users and groups selected status for Users and groups.
  • Select the Select users and groups option, then select the Users and groups option. In the Select blade, search for the group you’ve created in steps 19 through 25. Select it. Then, click the Select button to save your group selection.
  • Under assignments, click on the No cloud apps or actions selected link.
  • Select the All cloud apps option.
  • Then, under Access Controls, under Grant, click the 0 controls selected link.
    The Grant blade opens
  • On the Grant blade, select the Require multi-factor authentication option.
  • Click Select at the bottom of the blade to save the control.
  • At the bottom of the New pane, under Enable policy, select On.
  • Click the Create button.
    You will be linked back to the Conditional Access | Policies pane
  • In the right top corner of the Azure AD Portal, click on the accounts name or profile picture and click on Sign out from the context menu.
  • Close the browser.

 

Concluding

Please switch from per-user multi-factor authentication to Conditional Access to allow straightforward management of MFA settings, allow delegation and, eventually, get rid of App passwords.

0  

Recordings of the webinars with Netwrix are now available

Recording a webinar

Last month, on April 22nd, 28th and 30th, I hosted three 60-minute webinars with Netwrix on my three favorite chapters in my Active Directory Administration Cookbook.

Over 1800 people have registered for these webinars. Now, a mere week after the last webinar, the Netwrix team has done everyone a huge favor by already placing the three video recordings online for everyone to watch:

https://www.netwrix.com/ad_admin_cookbook.html

 

Enjoy! Thumbs up

Simply press the red Watch now buttons and enjoy!
The slides are also available for you to download, although these webinars were mostly demos-only.

Note:
These webinars and their videos are offered free of charge, thanks to the sponsoring by Netwrix. By accessing the webinars, full-length videos and slides you agree to their privacy policy.

 

About Netwrix

Netwrix logoNetwrix empowers information security and governance professionals to reclaim control over sensitive, regulated and business-critical data, regardless of where it resides.

Over 10,000 organizations worldwide rely on Netwrix solutions to secure sensitive data, realize the full business value of enterprise content, pass compliance audits with less effort and expense, and increase the productivity of IT teams and knowledge workers. Founded in 2006, Netwrix has earned more than 150 industry awards and been named to both the Inc. 5000 and Deloitte Technology Fast 500 lists of the fastest growing companies in the U.S.

 


Learn the intricacies of managing Azure AD, Azure AD Connect as well as Active Directory for Identity and Access Management (IAM) in the cloud and on Windows Server 2019.

Get up to date! Get your 620-page, 147-recipe copy of the Active Directory Administration Cookbook, today. Buy it from Packt directly, or through your favorite local reseller.

0