Azure AD Web Sign-in Security Feature Bypass Vulnerability (CVE-2021-27092, Important)

Today, for its April 2021 Patch Tuesday, Microsoft released an important security update for the Azure AD web sign-in feature in Windows and Windows Server. This vulnerability is known as CVE-2021-27092 and rated with CVSSv3.0 scores of 6.8/5.9.

About Azure AD Web Sign-in

Web Sign-in is a new way of signing into a Windows system. It enables Windows logon support for non-AD FS federated providers (e.g. SAML). Web sign-in enables you to set multifactor authentication before signing in to Windows. Web Sign-in is only supported on Azure AD Joined PCs.

About the vulnerability

An elevation of privilege vulnerability exists in the way Azure Active Directory web sign-in allows arbitrary browsing from the third-party endpoints used for federated authentication.

It allows an attacker with physical access to the device to gain unauthorized access.

DISCLOSURE

The vulnerability was responsibly disclosed to Microsoft.

AFFECTED OPERATING SYSTEMS

The following Operating Systems (OSs) are affected:

  • Windows 10, version 1803
  • Windows 10, version 1809
  • Windows 10, version 1909
  • Windows 10, version 2004
  • Windows 10, version 20H2
  • Windows Server 2019
  • Windows Server, version 1909
  • Windows Server, version 2004
  • Windows Server, version 20H2

The Web Sign-in feature was introduced with Windows 10, version 1809 and  does not affect other supported Operating Systems, like Windows Server 2012 and Windows Server 2016.

Recommendation

Azure AD-joined devices that have the Web sign-in feature enabled through the Authentication CSP, should be updated with the April 2021 Cumulative Update to prevent unauthorized access.

Further reading

Azure AD Web Sign-in Security Feature Bypass Vulnerability    
What's new in Windows 10, version 1809 – Web Sign-in

0  

HOWTO: Get an overview of Azure AD Application Permissions

Azure Active Directory

Applications in Azure AD offer people access to functionality that is integrated into your Azure AD tenant. The default behavior in Azure AD is that everyone can register applications and grant access to their data to applications. Microsoft now offers functionality to streamline the process of application management.

When onboarding to this new functionality, admins regain control over application permissions and get a handle on application permissions going forward. However, how do you, as an admin, get an overview of Azure AD application permissions set by your colleagues in the past?

 

Getting ready

First, we need to install the Windows PowerShell modules we need. Perform the following lines of Windows PowerShell in an elevated Windows PowerShell session:

Install-Module AzureAD -Force

Install-Module MSOnline -Force

Install-PackageProvider NuGet -Force

Install-Module PowerShellGet -Force

&(Get-Process -Id $pid).Path -Command { Install-Module MSAL.PS }

Install-Module AzureADIncidentResponse

 

Note:
We need to install both the AzureAD and MSOnline modules, as the output of these modules differs. This is the state of Azure AD PowerShell today. The above lines update the PowerShell modules, if you don’t run the latest versions.

Note:
If you receive error ‘Unable to download’ when you try to install the AzureAD or MSOnline PowerShell Module, use these steps to resolve the situation.

 

Getting Azure AD Application Permissions

Microsoft shared its Azure AD Incident Response Windows PowerShell module on the PowerShell Gallery. Using the cmdlets in this Windows PowerShell module, we can easily get an overview of Azure AD Application Permissions.

Run the following lines of Windows PowerShell to do so:

Import-Module AzureADIncidentResponse

Import-Module AzureADIncidentResponse (click for original screenshot)

Connect-AzureADIR <YourTenantId>

Sign in with an account with sufficient permissions to read application permissions within your Azure AD tenant. This account must be assigned the built-in Global Administrator, Global Reader, Application Administrator, Cloud Application Administrator, Directory Readers, Hybrid Identity Administrator and/or Security Administrator role.

Get-AzureADIRPermission <YourTenantId> | Out-GridView

 

These lines of Windows PowerShell result in a GridView window displaying the PermissionType for the permission (typically delegated), ClientObjectId, ClientDisplayName and ClientAppId for the application, ClientAppOwnerTenantId, ResourceObjectId, ResourceDisplayName, ResourceAppId and ResourceAppOwnerTenantId for the resource (typically Microsoft Graph or Windows Azure Active Directory), Permission and ConsentType for the permission granted and finally PrincipalObjectId, PrincipalDisplayName and PrincipalUserPrincipalName for the object that is specifically delegated permissions (if ConsentType is not AllPrincipals).

This information can be used to:

  • Find out more information per application, based on the ClientAppId and ClientAppOwnerTenantId.
  • Seek out applications where only a few people have consented to, but to which no admin provided admin consent.
  • Seek out dangerous permissions delegated to applications, beyond the typical User.Read, email, profile, offline_access and openid permissions.

 

Concluding

While initially conceived as an incident response tool, Microsoft's Azure AD Incident Response Windows PowerShell module proves useful for many other investigations.

0  

Your Active Directory Pre-production environment: Restore from Backup or Deploy as Code?

Active Directory

Active Directory Domain Services act as the cornerstone of every on-premises Microsoft-oriented networking infrastructure. It is important to get things right when it comes to your Domain Controllers, user objects and access controls.

An obvious solution to getting things right the first time is offering one or more pre-production environments to develop and test scripts,

I see two main strategies to creating pre-production environments for Active Directory Domain Services:

  1. Create an environment from backup
  2. Deploy an environment following the Infrastructure as Code (IaC) principles

Each strategy has its own strengths and weaknesses (in the short term). They also face vastly different opportunities and threats (in the long term).

Choosing the right strategy is important to reach the goals set out for the pre-production environment. Below, I provide an overview of each strategy. I also analyse the strengths, weaknesses, opportunities and threats through SWOT analyses.

Restore from Backup

In this strategy, you create a pre-production environment for Development, Test and/or Acceptance (OTA) purposes by restoring a backup of all relevant systems, services and applications in a separate networking environment.

When you’re using VMware vSphere and Veeam Backup & Replication, you can easily achieve this through the SureBackup feature in Veeam. Veeam and other backup vendors also offers solutions for environments using other hypervisors and for physical servers, but these solutions aren’t as streamlined as SureBackup.

Strengths

This strategy possesses the following strengths (in the short term):

  • The pre-production 100% represents the production environment.
  • The pre-production environment can be used to test and/or automate administrative actions and scripts before implementation in production.
  • Creating the on-premises components of an Active Directory implementation is completely automatable with solutions like Veeam’s SureBackup.

Weaknesses

This strategy exhibits the following weaknesses (in the short term):

  • The pre-production environment is 100% identical to the production environment in terms of DNS domain name, etc. This could lead to confusion around changes; people might think they are making changes in pre-production, but actually making them in production as the two environments cannot be adequately distinguished.
  • The pre-production may not be GDPR/CPAA compliant when working with an outside vendor, as all the production data for employees is available in the pre-production environment.
  • All changes in the production environment need to be repeated in the pre-production environment to keep both environments in sync and keep the pre-production environment 100% representative.
  • Pre-production environments need to absolutely be separated from the production environment.

Opportunities

This strategy offers the following opportunities (in the long term):

  • Every time a pre-production environment is created, restore from backups is tested.

Threats

This strategy faces the following threats (in the long term):

  • The period of time in which a pre-production environment needs to be available after creation dictates the cost level of the pre-production environment. Complexity, administrative repeat actions all add up.

Infrastructure as Code

In this strategy, you create a pre-production environment for Development, Test and/or Acceptance (OTA) purposes by deploying a relevant networking infrastructure from scratch, defining each aspect of the environment through code.

As every aspect, including the DNS domain name for the Active Directory forest can be defined, you need not separate the pro-production environment from the production environment. It helps, but is not necessary.

When you’re using Azure Infrastructure as a Service (IaaS) to host your pre-production environment(s), you can use ARM templates and Azure DevOps pipelines to set things up, so that when there’s a need for a pre-production environment, you can deploy one with a single click.

Strengths

This strategy possesses the following strengths (in the short term):

  • A pre-production Active Directory environment with multiple Domain Controllers and member servers can be deployed in as little as 45 minutes.
  • Pre-production environments can be deployed using test-specific values, including the DNS domain name to test all sorts of scenarios.
  • Pre-production environments can be deployed with a test-specific population. This way, pre-production environments can be GDPR/CPAA compliant. Temporary insecure settings for the pre-production environment would not necessarily lead to a data leak that is traceable to the organization or affect the people in the organization.
  • Pre-production environments don’t lead to running costs. A pre-production environment can be torn down when it is no longer needed and redeployed when it’s needed again.

Weaknesses

This strategy exhibits the following weaknesses (in the short term):

  • Pre-production environments are not identical or representative for production environments.
  • Not all Hybrid Identity components can be deployed as code. Azure AD Connect and GPOs are notorious components to automate.

Opportunities

This strategy offers the following opportunities (in the long term):

  • Using the right Infrastructure as Code solution means you can deploy wherever you want to deploy. Solutions like Terraform allow you to deploy to Microsoft Azure, Amazon AWS and VMware vSphere platforms.
  • Active Directory pre-production environments can be set up per vendor. This way, an organization can provide an environment to correspond with the vendor’s release process, whether its staging/production or develop/test/accept/production.

Threats

This strategy faces the following threats (in the long term):

  • The Infrastructure as Code pipeline requires maintenance.

Concluding

Restore from Backup and  Infrastructure as Code are both valid strategies to create Active Directory pre-production environments. However, depending on the goal of the pre-production environment, following one strategy works better than following the other.

Infrastructure as Code is typically the better strategy for development and test goals, where restoring from backup is typically better to meet Acceptance goals.

Whichever strategy you choose is OK. It’s better than having only a production test environment…

0  

On-premises Identity-related updates and fixes for March 2021

Even though Microsoft’s Identity focus moves towards the cloud, they are not forgetting their on-premises roots. Windows Server 2016 and Windows Server 2019 still receive updates.

These are the Identity-related updates and fixes we saw for March 2021:

 

Windows Server 2016

We observed the following update for Windows Server 2016:

KB45000803 March 9, 2021

The March 9, 2021 update for Windows Server 2016 (KB5000803), updating the OS build number to 14393.4283 is a security update that includes quality improvements.

Hot on the heels of the March 2, 2021 updates for Microsoft Exchange Server, this update addresses seven Windows Server DNS vulnerabilities, alongside

  • CVE-2021-26411, an Internet Explorer memory corruption zero-day vulnerability
  • CVE-2021-27077, a Windows Win32k Elevation of Privilege Vulnerability, that was publicly disclosed by Trend Micro’s Zero Day Initiative in January after Microsoft initially said they would not fix it
  • CVE-2021-26867, a critical Windows Hyper-V Remote Code Execution vulnerability

This update contains the following quality improvements:

  • It turns off token binding by default in Windows Internet (WinINet).
  • It addresses an issue in which a principal in a trusted MIT realm fails to obtain a Kerberos service ticket from Active Directory Domain Controllers. This occurs on devices that installed Windows Updates that contain CVE-2020-17049 protections and configured PerformTicketSignature to 1 or higher. Ticket acquisition also fails with the error, KRB_GENERIC_ERROR, if callers submit a PAC-less Ticket Granting Ticket (TGT) as an evidence ticket without providing the USER_NO_AUTH_DATA_REQUIRED flag

KB50001633 March 18, 2021

The March 18, 2021 update for Windows Server 2016 (KB50001633), updating the OS build number to 14393.4288, is an out-of-band update to address an issue that fails to print the graphical content in a document after installing the March 9, 2021 update.

Windows Server 2019

We observed the following update for Windows Server 2019:

KB5000822 March 9, 2021

The March 9, 2021 update for Windows Server 2019 (KB5000822), updating the OS build number to 17763.1817, is a security update.

Hot on the heels of the March 2, 2021 updates for Microsoft Exchange Server, this update addresses seven Windows Server DNS vulnerabilities, alongside

  • CVE-2021-26411, an Internet Explorer memory corruption zero-day vulnerability
  • CVE-2021-27077, a Windows Win32k Elevation of Privilege Vulnerability, that was publicly disclosed by Trend Micro’s Zero Day Initiative in January after Microsoft initially said they would not fix it
  • CVE-2021-26867, a critical Windows Hyper-V Remote Code Execution vulnerability

This update also incorporates the quality improvements that were released in Preview with the February 16, 2021 update (KB4601383):

  • It turns off token binding by default in Windows Internet (WinINet).
  • It addresses an issue that displays a User Account Control (UAC) dialog box unexpectedly when you turn on speech recognition.
  • It removes the history of previously used pictures from a user account profile.
  • It addresses an issue that prevents the Trusted Platform Module (TPM) from starting. As a result, TPM-based scenarios do not work.
  • It addresses an issue with Key Distribution Center (KDC) code, which fails to check for an invalid domain state when the domain controller restarts. The error message is:

STATUS_INVALID_DOMAIN_STATE

  • It addresses an issue in which a principal in a trusted MIT realm fails to obtain a Kerberos service ticket from Active Directory domain controllers (DC). This occurs on devices that installed Windows Updates that contain CVE-2020-17049 protections and configured PerformTicketSignature to 1 or higher. These updates were released between November 10, 2020 and December 8, 2020. Ticket acquisition also fails with the error, KRB_GENERIC_ERROR, if callers submit a PAC-less Ticket Granting Ticket (TGT) as an evidence ticket without providing the USER_NO_AUTH_DATA_REQUIRED flag.
  • It addresses an issue that fails to report an error when the Elliptic Curve Digital Signature Algorithm (ECDSA) generates invalid keys of 163 bytes instead of 165 bytes.
  • It addresses an issue with updating to Windows Server 2019 using a .iso image. If you renamed the default administrator account, the Local Security Authority (LSA) process might stop working.

KB50001568 March 15, 2021

The March 15, 2021 update for Windows Server 2019 (KB5001568), updating the OS build number to 17763.1821, is an out-of-band update to address an issue that might cause a blue screen when attempting to print to certain printers using some apps and might generate the error, APC_INDEX_MISMATCH

KB5001638 March 18, 2021

The March 18, 2021 update for Windows Server 2019 (KB5001638), updating the OS build number to 17763.1823, is an out-of-band update to address an issue that fails to print the graphical content in a document after installing the March 9, 2021 update.

KB5000856 March 5, 2021 Preview

The March 25, 2021 update for Windows Server 2019 (KB5000854), updating the OS build number to 17763.1852 is a preview update that offers the following quality improvements:

  • It allows administrators to use a Group Policy to enable extended keyboard shortcuts, including Ctrl+S, for users in Microsoft Edge IE Mode.
  • It addresses an issue with RSA key generation that generates a damaged key.
  • It addresses an issue that might prevent Hypervisor-Protected Code Integrity (HVCI) from being enabled when you configure it using a Group Policy
  • It addresses an issue that prevents Server Message Block 1 (SMB1) clients from accessing the SMB share after restarting the LanmanServer service
  • IT addresses an issue with signing in to a device that is in the current domain by using the default user profile of a device that is in a different, but trusted domain. The profile service of the current domain cannot retrieve the default user profile from the trusted domain and uses the local default user profile instead.

These quality improvements are also included in the next cumulative update on April 13, 2021.

0  

What's New in Azure Active Directory for March 2021

Azure Active Directory

Azure Active Directory is Microsoft's Identity Management-as-a-Service solution, offering seamless access, easy collaboration, efficiency in IT processes and improved security and compliance. In its Release Notes for Azure Active Directory, Microsoft communicated the following planned, new and changed functionality for Azure Active Directory for March 2021:

What’s Planned

Guidance on how to enable support for TLS 1.2 in preparation for upcoming Azure AD TLS 1.0/1.1 deprecation

Service category: N/A
Product capability: Standards

Azure Active Directory will deprecate the following protocols in Azure Active Directory worldwide regions starting June 30, 2021:

  • TLS 1.0
  • TLS 1.1
  • 3DES cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA)

What’s New

Staged rollout to cloud authentication General Availability

Service category: AD Connect
Product capability: User Authentication

Staged rollout to cloud authentication is now generally available. The staged rollout feature allows organizations to selectively test groups of users with cloud authentication methods, such as Passthrough Authentication (PTA) or Password Hash Sync (PHS). Meanwhile, all other user objects in the federated domains continue to use federation services, such as AD FS or any other federation service to authenticate.

User Type attribute can now be updated in the Azure admin portal General Availability

Service category: User Experience and Management
Product capability: User Management

Organizations can now update the user type of Azure AD user objects when admins update user profile information from the Azure admin portal. The user type can be updated from Microsoft Graph also.

Replica Sets for Azure Active Directory Domain Services General Availability

Service category: Azure AD Domain Services
Product capability: Azure AD Domain Services

The capability of replica sets in Azure AD DS is now generally available.

Collaborate with partners using Email One-Time Passcode in the Azure Government cloud General Availability

Service category: B2B
Product capability: B2B/B2C

Organizations in the Microsoft Azure Government cloud can now enable their guests to redeem invitations with Email One-Time Passcode (OTP). This ensures that any guest users with no Azure AD, Microsoft, or Gmail accounts in the Azure Government cloud can still collaborate with their partners by requesting and entering a temporary code to sign in to shared resources.

Header-based authentication SSO with Application Proxy General Availability

Service category: App Proxy
Product capability: Access Control

Azure AD Application Proxy native support for header-based authentication is now in general availability. With this feature, admins can configure the user attributes required as HTTP headers for applications without needing to deploy additional components.

Azure AD Entitlement management now supports multi-geo SharePoint Online Public Preview

Service category: Other
Product capability: Entitlement Management

For organizations using multi-geo SharePoint Online, admins can now include sites from specific multi-geo environments to Entitlement management access packages.

Restore deleted apps from App registrations Public Preview

Service category: Other
Product capability: Developer Experience

Admins can now view, restore, and permanently remove deleted app registrations from the Azure portal. This applies only to applications associated to a directory, not applications from a personal Microsoft account.

New "User action" in Conditional Access for registering or joining devices Public Preview

Service category: Conditional Access
Product capability: Identity Security & Protection

A Register or join devices user action in Conditional access is available. This user action allows organizations to control Multi-factor authentication (MFA) policies for Azure AD device registration.

Currently, this user action only allows organizations to enable MFA as a control when users register or join devices to Azure AD. Other controls that are dependent on or not applicable to Azure AD device registration are disabled with this user action.

Optimize connector groups to use the closest Application Proxy cloud service Public Preview

Service category: App Proxy
Product capability: Access Control

With this new capability, connector groups can be assigned to the closest regional Azure AD Application Proxy service an application is hosted in. This can improve app performance in scenarios where apps are hosted in regions other than the home tenant’s region.

External Identities Self-Service Sign-up in AAD using Email One-Time Passcode accounts Public Preview

Service category: B2B
Product capability: B2B/B2C

External users will now be able to use Email One-Time Passcode (OTP) accounts to sign up in to Azure AD 1st party and Line-of-Business (LoB) apps.

Availability of AD FS Sign-Ins in Azure AD Public Preview

Service category: Authentications (Logins)
Product capability: Monitoring & Reporting

AD FS sign-in activity can now be integrated with Azure AD activity reporting, providing a unified view of hybrid identity infrastructure. Using the Azure AD Sign-Ins report, Log Analytics, and Azure Monitor Workbooks, it's possible to perform in-depth analysis for both Azure AD and AD FS sign-in scenarios such as AD FS account lockouts, bad password attempts, and spikes of unexpected sign-in attempts.

New Federated Apps available in Azure AD Application gallery

Service category: Enterprise Apps
Product capability: 3rd Party Integration

In March 2021 Microsoft has added the following new applications in the Azure AD App gallery with Federation support:

New provisioning connectors in the Azure AD Application Gallery

Service category: App Provisioning
Product capability: 3rd Party Integration

Organizations can now automate creating, updating, and deleting user accounts for these newly integrated apps:

What’s Changed

Introducing MS Graph API for Company Branding

Service category: MS Graph
Product capability: B2B/B2C

MS Graph API management for the Company Branding is available for the Azure AD or Microsoft 365 login experience to allow the management of the branding parameters programmatically.

What’s Deprecated

Two-way SMS for MFA Server is no longer supported

Service category: MFA Server
Product capability: Identity Security & Protection

Two-way SMS for MFA Server was originally deprecated in 2018, and will not be supported after February 24, 2021. Administrators should enable another method for users who still use two-way SMS.

0  

Azure Active Directory now offers a 99,99% uptime SLA

As announced by Nadim Abdo on December 18th, 2020, Azure Active Directory has an updated public service level agreement (SLA) to promise 99.99% uptime per April 1st, 2021.

 

April Fools' joke?

I deliberately didn’t share this news on April 1st, 2021, to make sure that people didn’t see the blogpost as an April Fools’ Day joke. After last months Azure AD outage, it doesn’t seem like the best moment to make this change, but the Azure AD engineering team is confident that these outages are a thing of the past.

 

What the updated SLA means to you

When looking at the updated Azure AD service level agreement (version 1.1), the following changes appear:

 

Uptime guarantee

The tiers for service credits have changed to reflect the 99,99% uptime guarantee.

In March 2021, the 45-minute outage referred to as LN01-P8Z by Microsoft, resulted in a 25% service credit (that organizations can claim until May 31st, 2021). If a similar outage would occur under the new uptime guarantee, this outage would result in the same service credit.

However, if an outage would occur in the context of the new SLA that would impact organizations for anything between five and forty-three minutes, the new SLA provides a 10% service credit. The old SLA would not provide any service credit.

 

Definition update

Another noteworthy change is the new definition of Azure AD for the public service level agreement (SLA): It merely includes user authentication and federation.

In version 1.0 of the SLA (dated June 2015), downtime is defined as:

Any period of time when users are not able to log in to the service, log in to the Access Panel, access applications on the Access Panel and reset passwords; or any period of time IT administrators are not able to create, read, write and delete entries in the directory and/or provision/de-provision users to applications in the directory.

In version 1.1 of the SLA (dated April 2021), downtime is defined as:

Any period of time when users are unable to log in to the Azure Active Directory service or Azure Active Directory fails to successfully emit the authentication and authorization tokens required for users to log into applications connected to the service.

In the new SLA, administrative features have been removed from the wording for downtime. It no longer includes:

  1. Users being unable to sign in to the Access Panel
  2. Users being unable to access applications on the Access Panel
  3. Users being unable to reset passwords
  4. Admins being unable to create, read, write and delete entries in the directory
  5. Admins being unable to provision and/or de-provision users to applications in the directory
0  

Azure AD Connect version 1.6.4.0 fixes a bug in the previous release

Twelve days after the release of Azure AD Connect version 1.6.2.4, the first release in the 1.6 branch, Microsoft has released version 1.6.4.0, fixing a bug in the 1.6.2.4 release.

 

What’s fixed

This release fixes a bug in version 1.6.2.4 where, after upgrade to that release, the Azure AD Connect Health feature was not registered correctly and did not work.

Organizations who have deployed build 1.6.2.4 are requested to update their Azure AD Connect server(s) with this build, which will correctly register the Health feature.

Note:
Version 1.6.2.4 was released for download only. If you have not yet upgraded to version 1.6.2.4, then upgrade to version 1.6.4.0, skipping version 1.6.2.4.

Note:
Version 1.6.4.0 of Azure AD Connect is released for download only.

 

Version information

This is version 1.6.4.0 of Azure AD Connect.
The version of Azure AD Connect was made available for download on March 31, 2021.

The download weighs 104,5 MB.

0  

Microsoft 365 Backup in terms of your organization’s exit scenario

Microsoft 365 Backup

Organizations flocking to Microsoft 365 services like Exchange Online, SharePoint Online and Teams have many reasons to make this transition.

 

Reasons to transition to the Microsoft cloud

Whether it’s upgrading the IT real estate to the 21st century, the desire to eliminate technical debt, avoiding the upfront cost of a renewed on-premises implementation, or simply the latest spur of out of band hotfixes for products like Windows Server and Exchange Server… the answers these days all point to the cloud. When moving to the cloud, is there a better way than using the services of the vendor who you’re already familiar with? Now you understand why Microsoft 365 is the choice of many organizations.

 

Begin with the end in mind

One of Stephen Covey’s seven habits of highly effective people is to begin with the end in mind. Mister Covey isn’t an IT genius and expressed the end in mind principle as thinking before acting. As an IT Pro with dozens of 100+ page designs under my belt, I’ve come to appreciate another interpretation of this principle: Start with an exit scenario, before anything else. This philosophy has already gathered a lot of Dutch government organizations behind the idea of introducing Microsoft 365 services to extend and embrace their on-premises infrastructures.

Sudden vs. predictable exit scenarios

Exit scenarios should be part of data privacy impact analyses. These documents should cover the need to suddenly and unexpectedly execute exit scenarios due to breaches at Microsoft or its 50 subcontractors, regulatory changes between our and Microsoft’s jurisdictions, a hostile take-over of Microsoft 365, Microsoft signing over its intellectual property or even Microsoft going out of business. Additionally, the exit scenarios include situations in which Microsoft 365 services simply are no longer cost-effective or aren’t offering the levels of availability, performance and/or trust as perceived during the initial use period.

 

Ownership of data during exit

In all of these exit scenarios, the continued ownership of the data that the organization stores in Microsoft 365 services is a cause for concern. From a practicality point of view, the following questions are commonly asked:

  • How does an organization get hold of its data?
  • How can the organization handle the data? What 3rd party tools may be necessary?
  • Where can the organization restore the data to or reuse the data?
  • How can the organization resume business with the restored data?

Backup

This is usually the time to talk about backup of data in Microsoft 365 to a location that is not impacted by the recognized exit scenarios. Yes, usually this means erecting a system on-premises to make backups of data in cloud services to reuse hardware and storage that sits idle after moving mailboxes, files and folders to Microsoft 365.

These discussions on continuity at the beginning of deployment projects build trust. These discussions also reinforce the business case of transitioning to the cloud beyond the initial reasons found in the first paragraph of this blogpost.

 

Backup and restore of Microsoft 365 data

There are many vendors offering backup of Microsoft 365 data. I have two favorite solutions with two distinctly different approaches:

Veeam Backup for Microsoft Office 365

See the source imageFor organizations who want to setup a system under their own control, Veeam's Backup for Microsoft Office 365 product offers everything they need.

It offers backups of Exchange Online, SharePoint Online, OneDrive for Business and Teams.

More importantly, it allows to restore into the same cloud services, but also to on-premises Exchange Servers and SharePoint Servers. Setting up a new Exchange or SharePoint infrastructure on-premises to restore data to, without the need for additional tools, sounds like the ultimate exit scenario… at least while Microsoft still offers these on-premises products.

Veeam Backup for Microsoft Office 365 is the perfect solutions for organizations that don’t necessarily need to go all cloud and organizations that need their data asap to resume business.

Altaro Office 365 Backup

See the source imageAltaro's Office 365 Backup service is a fully-managed service for Microsoft Office 365 data backup.

It offers backups of Exchange Online, SharePoint Online and OneDrive for Business. There’s only a handful of settings that organizations need to configure. Altaro takes care of everything else, scales Azure storage to meet your backup needs and has packaged everything in a subscription with one all-inclusive fee.

Altaro Office 365 Backup is the perfect solution for organizations that want to go all-in with cloud services and don’t bet on Microsoft losing its cool. As the solution leverages Azure storage, organizations continue on the Microsoft path that they have traveled on so far already.

Restore possibilities by Altaro offers the ability to restore to the same mailbox, onedrive location and site, but also include *.zip and *.pst files, so for predictable exits everything is available. Getting the data might take some time as it needs to be downloaded and/or transferred from Altaro’s service to the organization’s cloud service and/or its on-premises systems.

 

Backup and restore of Azure AD objects

Both solutions, however, lack the ability to backup and restore objects and their attributes in Azure AD. Azure AD serves as the common authentication and authorization platform for all Microsoft 365 services. Most organizations will tell you that they only synchronize objects from Active Directory to Azure AD. Their conclusion is that they don’t need to backup Azure AD.

In terms of exit scenarios, it’s not a terribly big deal to not backup objects and their attributes in Azure AD. Indeed, user objects and groups are synchronized and can be used to provision another cloud identity platform if need be. Multi-factor authentication settings and license assignments also don’t play a role in exit scenarios as these are platform-specific.

However, backing up and restoring guest users and their access to shared files and folders may prove to be critical. Without the ability to restore all of Azure AD’s authentication and authorization mechanisms, all access control entries (ACEs) will need to be reprovisioned for restored data. In a world where people in different organizations don’t meet physically, this might be equivalent to cutting the umbilical cord of your organization’s revenue stream.

 

Exit

Talking about backup before entrusting even the first byte of data to a cloud service seems counterintuitive, but it has proven to be a good approach for me and my customers. Getting things clear beforehand makes all the difference when the cloud licensing agreement goes sour and you want to step out of it.

 

Concluding

For this year's World Backup Day, I decided to look at backups of Microsoft 365 data from a different perspective.

Related blogposts

A webcast with Redmond Magazine on typical Disaster Recovery gaps in Hybrid Active Directory environments
A webinar on Picking the Right Backup and Restore Solution for your Active Directory Domain Services needs

0  

Knowledgebase: Azure AD Connect Health Agents are not registered on Azure AD Connect installations running version 1.6.2.4

Azure AD Connect

Version 1.6.2.4 of Azure AD Connect that was released just last week seems to have an issue with the Azure AD Connect Health agent.

 

The situation

You intend to synchronize objects from one or more on-premises Active Directory Domain Services implementations to an Azure AD tenant.

You install Azure AD Connect version 1.6.2.4 to act as the synchronization tool. Azure AD Connect is Microsoft's free tool to synchronize objects from Active Directory and LDAPv3-compatible identity stores to Azure AD.

 

The issue

After installation of Azure AD Connect version 1.6.2.4, the Health services are not registered.

 

The cause

The issue is caused by an error in Version 1.6.2.4 of Azure AD Connect. This error will be resolved in subsequent versions of Azure AD Connect.

 

The solution

If the Azure AD Connect Health for Sync agent registration fails after you successfully install Azure AD Connect, then you can use a line of Windows PowerShell to manually register the agent.

Important!
Use this PowerShell command only if the agent registration fails after you install Azure AD Connect.

Manually register the Azure AD Connect Health agent for Sync by using the following line of Windows PowerShell:

Register-AzureADConnectHealthSyncAgent -AttributeFiltering $false -StagingMode $false

 

The command takes following parameters:

  • AttributeFiltering: $true (default) if Azure AD Connect isn't syncing the default attribute set and has been customized to use a filtered attribute set. Otherwise, use $false.
  • StagingMode$false (default) if the Azure AD Connect server is not in staging mode. If the server is configured to be in staging mode, use $true.

When you're prompted for authentication, use the same Global admin or Hybrid Identity admin account (such as admin@domain.onmicrosoft.com) that you used to configure Azure AD Connect.

The Azure AD Connect Health services will start after the agent has been successfully registered.

0  

Four things you should know about Selective Password Hash Synchronization

In Azure AD Connect version 1.6.2.4, Microsoft introduced the Selective Password Hash Synchronization feature.

Formerly, Azure AD Connect would apply Password Hash Synchronization to all objects in scope for synchronization. In Azure AD Connect version 1.6.2.4, and up, a subset of users can be specifically included or excluded to having their password hashes synchronized to Azure AD. This feature is known as selective password hash synchronization.

 

Five things you need to know

Selective Password Hash Synchronization sounds like a nice solution, but in reality, there are a couple of things you’ll want to know before deploying it to address your organizations’ needs:

 

Selective Password Hash Synchronization is available since Azure AD Connect v1.6.2.4

When your organization has been using Azure AD Connect in the past, you may or may not have enabled the Password Hash Synchronization option. In these previous versions, Password Hash Synchronization was an all or nothing setting: (hashes of) password hashes in Active Directory were synchronized to Azure AD for either all user objects in scope, or none of the user objects in scope.

You can only use the setting and configure the attribute for scoping the users for which password hash synchronization is either explicitly scoped, when all your Azure AD Connect installations run version 1.6.2.4, or above.

When a Staging Mode Azure AD Connect installation does not yet run version 1.6.2.4 or above, it will not respect the scoping. When you switch to this Staging Mode server, you might end up synchronizing (hashes of) password hashes in Active Directory for all user objects in scope.

 

Password Hash Synchronization is a prerequisite for Azure AD Domain Services

Password Hash Synchronization is a prerequisite for Azure AD Domain Services. When you enable Azure AD Domain Services, Azure AD Connect will start synchronizing the password hashes for user objects in scope, next to the hashes of password hashes. This way, the same passwords can be used within Azure AD Domain Services as on-premises.

Selective Password Hash Synchronization can play a role in limiting the number of password hashes synchronized, when the scope of objects needed in Azure AD Domain Services is used as a scoping mechanism.

However, as organizations lift and shift functionality from on-premises to Azure Infrastructure-as-a-Service and convert these from Active Directory on-premises to Azure AD Domain Services, eventually all user objects will need to have their password hashes synchronized.

A user object for which Selective Password Hash Synchronization prevents synchronization of the password hashes will not be usable with Azure AD Domain Services.

 

Selective Password Hash Synchronization has three distinct use cases for end-users

Password Hash Synchronization is managed to either one of the below settings in Azure AD Connect:

  • Password Hash Synchronization is configured as the sign-in method on the Sign-in method page of the Azure AD Connect configuration wizard.
  • Password Hash Synchronization is configured as an optional feature on the Optional Features page of the Azure AD Connect configuration wizard.

In the first case, you cannot use the Selective Password Hash Synchronization feature. In the second case, you can use Selective Password Hash Synchronization in two ways:

  • You can use it in conjunction with the Staged Rollout feature to gradually synchronize password hashes for user objects you are converting from federation or pass-through authentication to the PHS sign-in method.
  • You can use it in conjunction with converting DNS domain names from federated sign-in to PHS. Verified DNS domain names in Azure AD can be converted from federated domain to a managed domain. Per DNS domain name, corresponding to userPrincipalName suffixes when Alternate Login ID is not enabled, you can configure (hashes of) password hashes to by synchronized.
  • You can use it to scope access to Azure AD Domain Services.

Eventually all user objects in scope would have (hashes of) their password hashes synchronized, so Selective Password Hash Synchronization would be postponing the inevitable.

Note:
(hashes of) password hashes or never synchronized for user objects that are not in scope for synchronization by Azure AD Connect.

Note:
Selective Password Hash Synchronization should not apply to privileged users, as Microsoft’s new recommendation is to use cloud-only privileged accounts, not synchronized privileged accounts.

 

Synchronized values don’t magically disappear

When you have already enabled Password Hash Synchronization for your users, don’t expect these previously synchronized values to magically disappear.

When your organization switches from a previously configured sign-in method to password hash synchronization, users may be confronted with passwords that are months or years old. The same scenario applies to re-enabling access to Azure AD Domain Services after Selective Password Hash Synchronization has been configured for specific users.

0