HOWTO: Troubleshoot Windows Hello for Business Hybrid Access

Windows Hello for Business

Windows Hello for Business on Azure AD-joined devices is capable of providing single sign-on access to Active Directory domain-joined services and servers in Hybrid Identity setups.

Microsoft provides guides to configure this access in several ways: Certificate Trust, Key Trust and Hybrid Cloud Trust. Each of the three Windows Hello for Business Hybrid Access trust models have their own pros and cons and their own manual and their own artifacts. They also have things in common. Knowing these aspects of the Hybrid Access trust models helps you troubleshoot each of them.

In this blogpost, I'll share my sequence for troubleshooting Windows Hello for Business Hybrid Access:

  • Check if the user object in Azure AD is assigned an Azure AD Premium license
  • Check if the user object in Azure AD has permissions to configure Windows Hello for Business methods
  • Check if the right multi-factor authentication method is configured for the user object in Azure AD
  • Check if the device is correctly configured for Windows Hello for Business
  • Check if the user profile is correctly configured for Windows Hello for Business
  • Check the Event log
  • Check the Cloud Trust's Read-only Domain Controller
  • Check if the Domain Controllers are configured with the right certificate
  • Check if the device is configured with the root CA's certificate
  • Check if the user object is enrolled for the right certificate

 

Check if the user object in Azure AD is assigned an Azure AD Premium license

One of the big requirements for Windows Hello for Business Hybrid Access is Azure AD Premium licensing. While multi-factor authentication is available as part of Azure AD Free through the Security Defaults functionality, Windows Hello for Business requires Azure AD Premium licensing. Every person in the organization that you want to have access to Windows Hello for Business from Azure AD-joined devices to on-premises resources should have the Azure AD Premium P1 license assigned. As the P1 license is included in the Azure AD Premium P2, the Microsoft EMS E3/E5 and the Microsoft 365 E3/E5 licensing, assigning Azure AD Premium P1 as part of these licensing suites also works.

To check if the user object in Azure AD is assigned an Azure AD Premium license, perform the following steps:

  • Navigate a browser to the Entra portal.
  • Sign in with an account that has either the Global Administrator, License Administrator, Directory Writers, Groups Administrator or User Administrator, or Partner Tier1 Support role assigned or is eligible to activate the role.
    Perform multi-factor authentication when prompted.
  • If the organization uses Azure AD Privileged Identity Management (PIM), activate the role from the list of roles in step 2 with the least administrative privilege.
  • In the Entra portal, in the left-hand navigation menu, click Show more….
  • In the menu, expand Billing.
  • Underneath the Billing node, click Licenses.
    The Licenses | Overview pane opens.
  • In the licenses sub menu, click All products.
    The Licenses | All products pane opens.
  • From the list of license products, click the Azure AD Premium P1 license plan, or click the license suite that includes this license.
    The Licensed users pane for the license opens.
  • At the top of the list, use the Search box to search for the user object(s) you are troubleshooting Windows Hello for Business Hybrid Access for.
  • Make sure the user object for the person is activated for the feature. For license suites, click through on the Enabled Services to make sure the Azure Active Directory Premium P1 license is assigned. If not, assign it either through a (dynamic) group or assign it to the user object(s) individually.

If you change a user object(s) license(s) or license feature(s), allow for some time to have Azure AD replicate the change throughout the Azure AD infrastructure.

 

Check if the user object in Azure AD has permissions to configure a Windows Hello for Business method

Even if the user object in Azure AD has the right license and the right authentication method, you may have settings that contradict the use of that method as a passwordless method. This applies specifically for the Microsoft Authenticator app and FIDO2 security keys. To check if the Authenticator app can be used for Passwordless sign-ins, perform the following steps:

  • Navigate a browser to the Entra portal.
  • Sign in with an account that has either the Global Administrator, Authentication Administrator or Privileged Authentication Administrator (when troubleshooting user objects with roles assigned) role assigned or is eligible to activate the role.
    Perform multi-factor authentication when prompted.
  • If the organization uses Azure AD Privileged Identity Management (PIM), activate the role from the list of roles in step 2 with the least administrative privilege.
  • In the Entra portal, in the eft-hand navigation menu, click Show more….
  • In the menu, expand Protect & secure.
  • Underneath the Protect & secure node, select Authentication Methods.
    The Authentication methods | Policies pane opens.
  • From the list of methods, click Microsoft Authenticator.
    The Microsoft Authenticator settings pane opens on the Enable and Target tab.
  • For the All users group (if included) or any group that is included as a target (and includes the user account for the person you are troubleshooting Windows Hello for Business for) for the Microsoft Authenticator method, make sure that the Authentication mode column displays Any or Passwordless, specifically. If there is no group included that contains the user object, add a group, or include the All users group alternatively.
  • At the bottom of the Microsoft Authenticator settings page, click Save.
  • From the navigation breadcrumbs, click Authentication methods | Policies.
  • From the list of methods, click FIDO2 security key.
    The FIDO2 security key settings pane opens on the Enable and Target tab.
  • Make sure that the Enable option is enabled.
  • Make sure that a group that includes the user account for the person you are troubleshooting Windows Hello for Business for, or the All users group is selected to enable FIDO2 security keys as Windows Hello for Business (WHfB) method.
  • At the bottom of the Microsoft Authenticator settings page, click Save.

 

Check if the user object in Azure AD has a multi-factor authentication method configured

Windows Hello for Business authentication are considered multi-factor authentication (MFA) methods in Conditional Access. In the Authentication Strengths context it's considered a phishing-resistant MFA method. To securely onboard to Windows Hello for Business, the person using the user object should be required to perform multi-factor authentication at least once during the deployment process. A good way to do this is to require multi-factor authentication for the Register or join devices action in Conditional Access.

For this, the user object needs to be configured with at least one multi-factor authentication method. To check if the user object in Azure AD has a multi-factor authentication method configured, perform the following steps:

  • Navigate a browser to the Entra portal.
  • Sign in with an account that has either the Global Administrator, Authentication Administrator or Privileged Authentication Administrator (when troubleshooting user objects with roles assigned) role assigned or is eligible to activate the role.
    Perform multi-factor authentication when prompted.
  • If the organization uses Azure AD Privileged Identity Management (PIM), activate the role from the list of roles in step 2 with the least administrative privilege.
  • In the Entra portal, in the eft-hand navigation menu, expand Users.
  • Underneath the Users node, click All users.
    The Users pane opens.
  • At the top of the list, use the Search box to search for the user object(s) you are troubleshooting Windows Hello for Business Hybrid Access for.
  • Click the user object.
    The users Overview pane opens.
  • In the menu, click Authentication methods.

Note:
If you haven't activated the new user authentication methods experience, yet, activate it now by clicking on the purple banner offering to switch to the new user authentication methods experience.

  • Make sure the user object for the person has at least one authentication method in the list of Usable authentication methods.

If the person does not have a usable authentication method or has lost the means to perform the authentication method, add an authentication method as an admin, require the person to reregister a multi-factor authentication method, or have the user register a multi-factor authentication method.

 

Check if the device is correctly configured for Windows Hello for Business

Azure AD-joined device can be manually configured with the required settings to configure Windows Hello for Business (WHfB) or through a Mobile Device Management (MDM) solution like Microsoft Intune. It all boils down to registry settings on the device itself, so we can check any result there as the most reliable end-to-end deployment verification means.

To manually check if a device is configured for Windows Hello for Business, look at the following registry keys and values:

Use Windows Hello for Business

The setting Use Windows Hello for Business enables the device to provision Windows Hello for Business using keys or certificates for all users. If you disable this policy setting, the device does not provision Windows Hello for Business for any user.

In the registry, this setting is represented by the Enabled and DisablePostLogonProvisioning values underneath HKLM\SOFTWARE\Policies\Microsoft\PassportForWork. Enabled should be configured with 1 as its data. DisablePostLogonProvisioning should be configured with 0 as its data or not be present.

Use biometrics

Windows Hello for Business enables users to use biometric gestures, such as face and fingerprints, as an alternative to the PIN gesture. However users must still configure a PIN to use in case of failures.  If you enable or do not configure the Use biometrics setting, Windows Hello for Business allows the use biometric gestures.

In the registry, this setting is represented by the Domain Accounts value underneath HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WinBio\Credential Provider. This value needs to be configured with 1 as its data.

Use certificate for on-premises authentication

For Hybrid Certificate Trust, specifically, the UseCertificateForOnPremAuth value underneath HKLM\SOFTWARE\Policies\Microsoft\PassportForWork needs to present and configured with 1 as its data.

Use cloud trust for on-premises authentication

For Hybrid Cloud Trust, specifically, the UseCloudTrustForOnPremAuth value underneath HKLM\SOFTWARE\Policies\Microsoft\PassportForWork needs to present and configured with 1 as its data.

 

Check if the user profile is correctly configured for Windows Hello for Business

To manually check if the user profile is configured for Windows Hello for Business, look at the following registry keys and values:

Use Windows Hello for Business

Even when on the device level, the Use Windows Hello for Business setting is enabled, provisioning Windows Hello for Business may be blocked on the user profile.

In the registry, this setting is represented by the Enabled value underneath HKCU\SOFTWARE\Policies\Microsoft\PassportForWork. The Enabled value should either be absent, or when it is present, it needs to be configured with 1 as its data.

Use certificate for on-premises authentication

Even when on the device level, the Use certificate for on-premises authentication setting is enabled, Hybrid Certificate Trust may still not work when it is blocked on the user profile.

The UseCertificateForOnPremAuth value underneath HKCU\SOFTWARE\Policies\Microsoft\PassportForWork needs to either be absent, or when it is present, it needs to be configured with 1 as its data.

 

Check if the device has the correct hardware for the Windows Hello for Business settings

With default settings, a Windows device needs a configured Trusted Platform Module (TPM) chip. The use of a TPM chip to store keys for Windows Hello for Business provides additional security. Keys stored in the TPM may only be used on that system while keys stored using software are more susceptible to compromise and could be used on other systems.

While definitely not recommended, this requirement can be disabled through the Use a hardware security device Group Policy settings. If the device does not have a suitable TPM 1.2 or TPM 2.0 chip, this setting needs to be disabled to offer Windows Hello for Business provisioning. In the registry, this setting is represented as the RequireSecurityDevice registry key underneath HKLM\SOFTWARE\Policies\Microsoft\PassportForWork.

Configure this registry setting with the value 0 for testing on devices without suitable TPM chips.

 

Check the Event log

When the correct settings are present, Windows' Event log is capable of providing insights in why Windows Hello for Business provisioning is not happening.

Over the years, events related to Windows Hello for Business provisioning have been written to logs with various names, but on Windows 11 22H2, the Microsoft\Windows\HelloforBusiness\Operational and Microsoft\Windows\User Device Registration\Admin logs provide detailed information.

When troubleshooting hybrid access, specifically, the Microsoft\Windows\Security-Kerberos\Operational log provides detailed information.

When using FIDO2 security keys, additional information can be found in the Microsoft\Windows\WebAuthN\Operational log.

Tip!
These logs can be accessed in Event Viewer (eventvwr.exe) by selecting the Applications and Services Logs node in the left navigation pane and then drilling down to the log file you're interested in.

 

Check the Cloud Trust's Read-only Domain Controller

Applies to: Hybrid Cloud Trust scenario, only

When you've chosen the Hybrid Cloud Trust scenario for Windows Hello for Business Hybrid Access, a read-only Domain Controller object is created in the on-premises Active Directory environment. Its read-only domain controller account is named AzureADKerberos and is placed in the Domain Controllers Organizational Unit (OU). Kerberos tickets are issued by Azure AD, based on the password of its specific krbtgt account. This account is named krbtgt_AzureAD and is placed in the Users container.

By using the Active Directory users and computers MMC snap-in (dsa.msc) or the Active Directory Administrative Center (dsac.exe), the presence of these two objects can be checked.

Furthermore, the status of the read-only domain controller can be checked using PowerShell. Use the following commands to get the status on a Windows Server installation in your infrastructure that runs Azure AD Connect:

Import-module "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\AzureAdKerberos.psd1"

$domain = "domain.tld"

Get-AzureADKerberosServer

 

Check if the Domain Controllers are configured with the right certificate

Applies to: Certificate Trust scenario, Key Trust scenario

When you've chosen the Certificate Trust scenario or the Key Trust scenario for Windows Hello for Business Hybrid Access, Domain Controllers need to be configured with the right certificates. You'll need to Upgrade the Certificates for your Windows Server 2016-based Domain Controllers (and up) to enable Windows Hello for Business Hybrid Scenarios.

To check if the Domain Controllers are equipped with the right type of certificates, perform the following steps:

  • Sign in interactively to a Domain Controller.
  • Right-click the Start button and select Run from the context menu.
    The Run window appears.
  • Type certlm.msc and press OK to close the Run window and start the Certificates MMC snap-in for the Local Computer.
    The certlm – [Certificates – Local Computer] window appears.
  • In the left navigation pane, expand Personal. Then expand the Certificates node underneath it.
  • In the main pane, sort on the Certificate Template column.
  • Look at the presence of certificates, based on the certificate template that you specified.
    In the Microsoft Docs, the template name Domain Controller Authentication (Kerberos) is used.
  • When done, close the certlm – [Certificates – Local Computer] window.

Tip!
If you've configured automatic certificate enrollment, and the Domain Controller hasn't picked up the settings, yet, you can run the following command to trigger certificate enrollment: certutil.exe –pulse

 

Check if the device is configured with the root CA's certificate

Applies to: Certificate Trust scenario, Key Trust scenario

When you've chosen the Certificate Trust scenario or the Key Trust scenario for Windows Hello for Business Hybrid Access, devices need to be configured with the certificate of the Root Certification Authority (CA). To check the presence of the Root CA certificate, perform the following steps:

  • Sign in interactively to the device.
  • Right-click the Start button and select Run from the context menu.
    The Run window appears.
  • Type certlm.msc and press OK to close the Run window and start the Certificates MMC snap-in for the Local Computer.
    The certlm – [Certificates – Local Computer] window appears.
  • In the left navigation pane, expand Trusted Root Certification Authorities. Then expand the Certificates node underneath it.
  • In the main pane, sort on the Certificate Template column.
  • Search for the certificate of your Root CA.
  • When done, close the certlm – [Certificates – Local Computer] window.

 

Check if the user object is enrolled for the right certificate

Applies to: Certificate Trust scenario, only

When you've chosen the Certificate Trust scenario  for Windows Hello for Business Hybrid Access, authentication is based on user certificates. To check the presence of the user certificate, perform the following steps:

  • Sign in interactively to the device.
  • Right-click the Start button and select Run from the context menu.
    The Run window appears.
  • Type certmgr.msc and press OK to close the Run window and start the Certificates MMC snap-in for the Current User.
    The certmgr – [Certificates – Current User] window appears.
  • In the left navigation pane, expand Personal. Then expand the Certificates node underneath it.
  • In the main pane, sort on the Certificate Template column.
  • Look at the presence of certificates, based on the certificate template that you specified.
    In the Microsoft Docs, the template name WHfB Certificate Authentication is used.
  • When done, close the certmgr – [Certificates – Current User] window.

Posted on February 23, 2023 by Sander Berkouwer in Active Directory, Azure Active Directory, Windows Hello for Business

0  

Microsoft Graph PowerShell Tips and Tricks, Part 4: What you need to know about Microsoft Graph PowerShell SDK v2

Microsoft Graph Giraffes

The AzureAD, MSOnline and AzureADPreview PowerShell modules are scheduled for deprecation. The schedule has changed a couple of times. To be prepared, admins should get going with the new Microsoft Graph PowerShell SDK module. However, the Microsoft Graph PowerShell SDK works differently. There's a learning curve that has proven steep. Many admins who have walked the path before you have reported many issues.

This blogpost series aims to help you on your journey. Together with Aleksandar Nikolic, a Microsoft MVP with an extensive background in PowerShell, we're providing tips and tricks on finding your way through typical questions, situations and annoyances.

In the previous blogpost in this series, Aleksandar and I shared how to install the generally available v1 of the Microsoft Graph PowerShell SDK. However, there is also the  v2 of the Microsoft Graph PowerShell SDK.

 

About Microsoft Graph PowerShell SDK v2

v2 of the Microsoft Graph PowerShell SDK was released as a Public Preview on December 21st, 2022. v2 is a pre-release version of the next version of the Microsoft Graph PowerShell SDK that aims to enhance the experience while interacting with the Microsoft Graph API.

In terms of interacting with the Microsoft Graph API, v2 offers separate cmdlets targeting the two different versions of the Graph API, v1.0 and beta. v1 of the Microsoft Graph PowerShell SDK contains the Select-MgProfile cmdlet and offers interactions to both Graph API versions through the same *-Mg* cmdlets. Because the way this is built, both the v1.0 and beta API functionality is part of the Microsoft.Graph module. If you ever wondered why v1 of the Microsoft Graph PowerShell SDK requires that huge amount of disk space… there's your answer.

In v2, the Select-MgProfile cmdlet is no more. When you install the Microsoft.Graph module, only the functionality to interact with v1.0 of the Graph API is installed. If you want to interact with the beta version of the Microsoft Graph API, you'll (also) need the Microsoft.Graph.Beta module.

The Get-MgUser cmdlet simply targets v1.0 of the Graph API. The Get-MgBetaUser cmdlet targets the beta version of the Graph API.

Note:
The beta version of the Graph API is unsupported. In the context of the Microsoft Graph API, this means that Microsoft may change, break, redirect or even remove functionality without notifications in advance.

Splitting up Microsoft.Graph and Microsoft.Graph.Beta isn’t just good news for hard disk space. It also makes sense when interacting with the Graph API to access relatively new functionality in Azure AD.

Let’s use an example based on a common scenario for Azure AD admins; report on the usage of self-service password reset (SSPR) and multi-factor authentication (MFA). For this purpose, the Get-MgReportCredentialUserRegistrationDetail cmdlet is available.

With v1 of the Microsoft Graph PowerShell SDK, you’d use the following commands:

$userPrincipalName = Get-MgUser -Filter "startswith(displayName,'Diego')" | Select-Object -ExpandProperty UserPrincipalName

Get-MgReportCredentialUserRegistrationDetail -Filter "UserPrincipalName eq '$userPrincipalName'" -All

 

However the latter command would fail, because The term 'Get-MgReportCredentialUserRegistrationDetail' is not recognized as the name of a cmdlet, function, script file, or operable program. Instead, what we need to do is:

$userPrincipalName = Get-MgUser -Filter "startswith(displayName,'Diego')" | Select-Object -ExpandProperty UserPrincipalName

Select-MgProfile -Name beta

Get-MgReportCredentialUserRegistrationDetail -Filter "UserPrincipalName eq '$userPrincipalName'" -All

To get the point across for v2 of the Microsoft Graph PowerShell SDK, you’d use the following commands:

$userPrincipalName = Get-MgUser -Filter "startswith(displayName,'Diego')" | Select-Object -ExpandProperty UserPrincipalName

Get-MgBetaReportCredentialUserRegistrationDetail -Filter "UserPrincipalName eq '$userPrincipalName'" -All

We specifically specify to use the cmdlet from the Microsoft.Graph.Beta module to avoid any problems.

 

Our recommended practices for v2

In the second part of this blogpost series, we discussed the different requirements for the Microsoft Graph PowerShell SDK in Windows PowerShell 5.x and PowerShell 7.x. The requirements haven’t changed for v2 of the Microsoft Graph PowerShell SDK.

If you want to get going with v2 of the Microsoft Graph PowerShell SDK, it is our recommendation to:

  • Use v1 of the Microsoft Graph PowerShell SDK in Windows PowerShell 5.1
  • Use v2 of the Microsoft Graph PowerShell SDK in PowerShell 7.

That way you will avoid any potential conflict between v1 and v2. And, have both versions installed on your system, so that you can easily use and test the latest preview v2 version of the Microsoft Graph PowerShell SDK while still having access to the stable v1 version of the Microsoft Graph PowerShell SDK.

Posted on February 21, 2023 by Sander Berkouwer in Microsoft Graph API, PowerShell

0  

I'm a 2023 Veeam Vanguard

Veeam Vanguard

Today, I received an e-mail from Rick Vanover from Veeam congratulating me with being selected for the 2023 Veeam Vanguard Program as part of the Veeam100 family of programs.

For me, it means I successfully renewed my previous seven Veeam Vanguard Awards, dating back to 2016.

I feel honored.

Thank you! 

 

 

About Veeam Vanguards

The Vanguard program is led by the Veeam Technical Product Marketing & Evangelism team and supported by the entire company. It’s a program around the community of Veeam experts that truly get Veeam’s message, understand Veeam’s products and are Veeam’s closest peers in IT.

Veeam Vanguards represent Veeam’s brand to the highest level in many of the different technology communities. These individuals are chosen for their acumen, engagement and style in their activities on and offline.

The full list of Veeam Vanguards will be available shortly here.

FURTHER READING

I’m a 2022 Veeam Vanguard
I’m a 2021 Veeam Vanguard
I’m a 2020 Veeam Vanguard
I am a 2019 Veeam Vanguard
I am a 2018 Veeam Vanguard
I am a 2017 Veeam Vanguard
I am a 2016 Veeam Vanguard

Posted on February 20, 2023 by Sander Berkouwer in Veeam, Veeam Vanguard

0  

Happy 23rd Birthday, Active Directory!

Twenty Three

Today, The DirTeam.com / ActiveDir.org Weblogs are celebrating the 23-year anniversary of Active Directory Domain Services as a released product.

 

Windows 2000 Server

The introduction of Active Directory to the world was part of the release of Windows 2000 Server on February 17, 2000. At the launch event, Bill Gates ushered in the Next Generation of PC Computing. Today, this is 23 years ago:

 

Posted on February 17, 2023 by Sander Berkouwer in Active Directory

0  

What's New in Veeam Backup and Replication v12 for Identity Admins

Yesterday, Veeam released version 12 of its Backup and Replication (VBR) product.

This version is a huge milestone for the company as it contains no less than 585 new and improved features, when compared to VBR version 11, released on March 23rd, 2021. In these (almost) two years, Veeam has done a lot of work to make sure VBR works securely and stable in any environment, whether it's IPv6-only, Kerberos-only or doesn't allow the use of SQL Server databases… It's all documented in Veeam's official What's New in V12? document.

Not every feature is as interesting as other features, so I decided to provide you with the five features that sparked my interest as an Identity admin:

 

Multi-factor Authentication

Veeam introduced the Multi-factor authentication feature as part of the Cyber Resiliency pilar of VBR v12:

Secure access to the backup console with optional two-factor authentication (2FA) that’s based on Time-Based One-Time Passwords (TOTP) as per RFC 6238. You can enable 2FA for individual accounts in the Users and Roles settings of your backup server and enroll in an authenticator application of your choice to receive these one-time codes.

To access the Veeam Backup & Replication console interactively, multi-factor authentication can be required. In VBR v11, multi-factor authentication could not be required. In VBR v12, multi-factor authentication can be required per user or per group, assigned roles in VBR through the Require two-factor authentication for interactive logon option.

After entering the username and password, this feature supports multi-factor authentication based on a time-based one-time passcode (TOTP) from apps like the Google Authenticator and Microsoft Authenticator app. However, beyond the rolling code, there are no possibilities to use phishing-resistant multi-factor authentication or go passwordless…

 

Automatic Console Lockouts

Also part of the Cyber resiliency pilar, are automatic console lockouts:

A configurable console lockout/timeout has been added to automatically close idle backup console sessions. Worry not if picking up that coffee is taking longer than expected!

In the same screen where you assign users and groups to roles, and where you configure multi-factor authentication requirements, there is also the option to configure idle session logoffs. In VBR v12, idle session logoff can be configured per user or per group and for assigned roles in VBR through the Enable auto logoff after x min of inactivity option.

 

gMSA support

In the Cyber Resiliency pilar, the technical text of the gMSA accounts for windows feature shines bright:

Perform application-aware processing of Microsoft Windows guests through password-less group Managed Service Accounts (gMSA) without having to store full credentials, including passwords in the backup server configuration. In Microsoft’s own words, “Group Managed Service Accounts are the most secure type of service account for on-premises needs. If you can move to one, you should!"

In VBR v12, it is now supported to use group Managed Service Accounts (gMSAs) for user credentials. This drastically improves security as gMSAs automatically change passwords every 30 days.

 

Kerberos-only support

Under Cyber Resiliency we also find the long-awaited Kerberos-only authentication feature:

V12 can be deployed in environments with NTLM authentication disabled for enhanced security. This includes all backup infrastructure components, backup agents, enterprise application plug-ins and proxy appliances. Kerberos-only authentication is supported by V12 right out of the box as long as managed servers and protected machines are registered with the backup server through valid, resolvable DNS names (IP addresses are not supported by Kerberos). NFS workloads require additional NFS Server and Client configurations, please refer to the User Guide for more information.

Note: If you have already been using our existing capability that allows application-aware guest processing in a network with NTLM disabled, please refer to the KB4393 before performing the upgrade.

Many IT environments still feature a lot of NTLM authentication traffic. With VBR v12, all components and backup tasks work using Kerberos only. NTLM is no longer required for creating application-aware backups of virtual machines, like (oh irony…) Domain Controllers.

 

OAuth 2.0 support for email notifications

In terms of Backup Infrastructure, Veeam now offers Modern authentication for email notifications:

In addition to basic SMTP authentication, V12 now supports secure authorization and access-token-based authentication for Google Gmail and Microsoft 365 through the modern OAuth 2.0 protocol.

Notifications help backup admins to quickly identity backup, replication and/or restore job failures. However, Microsoft 365 no longer supports SMTP with basic authentication as a protocol to send mail through. The S in SMTP does not stand for Secure, so Microsoft also recommends disabling the protocol on on-premises and self-hosted Exchange Server implementations. In VBR v11, SMTP was the only supported option to e-mail notifications. In VBR v12, modern authentication to Microsoft 365 and Google Gmail are now also options.

Posted on February 15, 2023 by Sander Berkouwer in Veeam, Veeam Vanguard

0  

KnowledgeBase: You receive error 'AuthorizationManager check failed' when importing Synchronization Settings in Azure AD Connect

Azure AD Connect

Sometimes, the installation of Azure AD Connect can mess up your project deadlines in mere seconds. In this blogpost, I want to share an error that kept the admins of an organization occupied for quite some time, while it was relatively easy to fix.

 

The situation

An organization wants to perform an Azure AD Connect swing migration from another Azure AD Connect server.

An admin exports the configuration of the existing Azure AD Connect installations, downloads Azure AD Connect, and runs it on the new Windows Server installation.

On the Welcome to Azure AD Connect page, the admin selects the I agree to the license terms and privacy notice. option and hits the Continue button. On the Express Settings page, the admin clicks Customize.

On the Install required components page, the admin selects the Import synchronization settings option, browses to the previously exported settings and hits the Install button.

 

The issue

On the Install required components page, the admin clicks Install. Instead of being taken to the User Sign-in page, the admin is confronted with an error message:

AuthorizationManager Check Failed

An error occurred while importing your synchronization settings. Details: 'AuthorizationManager check failed.'

 

The cause

This issue is caused by a policy on the system that restricts PowerShell script execution.

At the organization where the error was encountered, a Group Policy object was in place that configured Allow only signed scripts for the Turn on Script Execution policy setting, underneath Windows PowerShell, underneath Windows Components, underneath Administrative Templates.

 

The solution

To solve this issue, we excluded the new Azure AD Connect server from the scope of the Group Policy that restricted PowerShell script execution.

We then had to update Group Policy settings, uninstall Azure AD Connect and reinstall Azure AD Connect. After these changes, we could import synchronization settings successfully.

 

Concluding

Secure Windows Server settings sometimes block the usage of Microsoft Identity-solutions. We've learned this with the November 2022 Windows Updates, and we're seeing it again in the above situation…

Posted on February 14, 2023 by Sander Berkouwer in Azure AD Connect, KnowledgeBase Articles

0  

Microsoft Graph PowerShell Tips and Tricks, Part 3: Installing, updating and uninstalling the Microsoft Graph PowerShell SDK

Microsoft Graph Giraffes

The AzureAD, MSOnline and AzureADPreview PowerShell modules are scheduled for deprecation. The schedule has changed a couple of times. To be prepared, admins should get going with the new Microsoft Graph PowerShell SDK. However, the Microsoft Graph PowerShell SDK works differently. There's a learning curve that has proven steep. Many admins who have walked the path before you have reported many issues.

This blogpost series aims to help you on your journey. Together with Aleksandar Nikolic, a Microsoft MVP with an extensive background in PowerShell, we're providing tips and tricks on finding your way through typical questions, situations and annoyances.

After you’ve met the requirements, you can install the Microsoft Graph PowerShell SDK on your system.

Note:
The Microsoft Graph PowerShell SDK is currently available for installation on your local system, Azure Function runners, Azure Automation workers, CI/CD agents… However, it is not available in the Azure Cloud Shell in the Azure portal.

    

Installing the PowerShell SDK

You can install the Microsoft Graph PowerShell SDK, with the following line of PowerShell:

Install-Module -Name Microsoft.Graph -Scope CurrentUser

Tip!
If you’re installing the Microsoft Graph PowerShell SDK on a shared system, like a remote management server that is used by other admins as well, change the scope from CurrentUser to AllUsers and run the PowerShell command with elevated privileges. This will install the Microsoft Graph PowerShell SDK for all users.

The above line of PowerShell installs the Microsoft.Graph wrapper module and 40 Microsoft.Graph.* modules.

 

Using a scoped PowerShell SDK installation

However, you could opt to only install the PowerShell modules that are actually in scope of your work.

The Microsoft.Graph.Authentication module is always needed. Next to that, you can opt to install the following modules to gain access to the cmdlets you need, while reserving hard disk space for other things:

The PowerShell modules that should be of special interest for Azure AD admins are:

  • Graph.Identity.DirectoryManagement
  • Graph.Users
  • Graph.Groups
  • Graph.Identity.SignIns
  • Graph.Users.Actions
  • Graph.Identity.Governance
  • Graph.SchemaExtensions
  • Graph.DirectoryObjects

Use the following PowerShell command to install only these modules:

Install-Module -Name Microsoft.Graph.Authentication, Microsoft.Graph.Identity.DirectoryManagement, Microsoft.Graph.Users, Microsoft.Graph.Groups, Microsoft.Graph.Identity.SignIns, Microsoft.Graph.Users.Actions, Microsoft.Graph.Identity.Governance, Microsoft.Graph.SchemaExtensions, Microsoft.Graph.DirectoryObjects -Scope CurrentUser

Tip!
If you’re installing the Microsoft Graph PowerShell SDK on a shared system, like a remote management server that is used by other admins as well, change the scope from CurrentUser to AllUsers and run the PowerShell commands with elevated privileges. This will install the Microsoft Graph PowerShell SDK for all users.

 

Other PowerShell modules available in the Microsoft Graph PowerShell SDK are:

  • Graph.Intune
  • Graph.Planner
  • Graph.Teams
  • Graph.Applications
  • Graph.Devices.CorporateManagement
  • Graph.DeviceManagement
  • Graph.DeviceManagement.Enrolment
  • Graph.DeviceManagement.Administration
  • Graph.Bookings
  • Graph.Security
  • Graph.Mail                
  • Graph.Education
  • Graph.CloudCommunications
  • Graph.Files
  • Graph.Sites
  • Graph.People
  • Graph.CrossDeviceExperiences
  • Graph.PersonalContacts
  • Graph.Notes
  • Graph.Reports
  • Graph.Financials
  • Graph.Search
  • Graph.DeviceManagement.Functions
  • Graph.DeviceManagement.Actions
  • Graph.Compliance
  • Graph.Calendar
  • Graph.Devices.CloudPrint
  • Graph.ChangeNotifications
  • Graph.WindowsUpdates
  • Graph.Devices.ServiceAnnouncement
  • Microsoft.Graph.ManagedTenants

 

Updating the PowerShell SDK

In contrast to the AzureAD, MSOnline and AzureADPreview PowerShell modules, the Microsoft Graph PowerShell SDK actually supports the Update-Module cmdlet. To update the SDK, simply run the following PowerShell command:

Update-Module -Name Microsoft.Graph

Tip!
Run the above PowerShell command with elevated privileges when the Microsoft Graph PowerShell SDK is installed for all users.

 

Uninstalling the PowerShell SDK

One of the things you might want to do when you’re done with the Microsoft Graph PowerShell SDK – and believe us, we had this feeling multiple times in the past months! – is to uninstall the Microsoft Graph PowerShell SDK.

To uninstall the SDK and all the dependency modules, run the following commands: 

Uninstall-Module -Name Microsoft.Graph

Get-InstalledModule Microsoft.Graph.* | ForEach-Object { if ($_.Name -ne "Microsoft.Graph.Authentication") { Uninstall-Module $_.Name } }

Uninstall-Module Microsoft.Graph.Authentication

Tip!
Run the above commands with elevated privileges when the Microsoft Graph PowerShell SDK is installed for all users.

 

Let’s Start!

With the Microsoft Graph PowerShell SDK installed on the local system, we can start exploring the possibilities that it unlocks. To quote Windows: ‘Let’s Start!’.

Posted on February 13, 2023 by Sander Berkouwer in Azure Active Directory, Microsoft Graph API, Tips and Tricks

0  

Pro Tip! How to quickly find out if a YubiKey is still alive

YubiKey

Windows Hello for Business Security Keys are Microsoft’s name to FIDO2-based security keys, when you use them with Windows Hello for Business on a Windows 10-based device.

Fido Alliance LogoAs the FIDO alliance strives to develop and promote authentication standards, FIDO2-based security keys work in many passwordless scenarios.

Yubico, one of the founding members of the FIDO Alliance, offers great Windows Hello for Business security keys with many options: YubiKeys. YubiKeys are designed and made to be resilient. However, sometimes, you may encounter a key from a bad batch (like with the early YubiKeys Bio) or you might just put a little too much strain on one. In that case, you might be wondering if the YubiKey is still alive.

 

Yubikeys

There is an easy way to quickly find out if a YubiKey is still alive or is dead, using the Yubico One-Time Password (YubiOTP) functionality that is found in every YubiKey, except for the FIDO2-only Security Keys. You don’t even have to install a Yubico tool to do this. All you need to do is perform these steps on a Windows-based or MacOS-based device:

  1. Open a browser and navigate to https://demo.yubico.com
  2. Click the Verify OTP tile.
  3. On the Test your YubiKey with Yubico OTP web page, put your cursor in the Yubico OTP field (marked as required).
  4. Insert the YubiKey into a USB port.
  5. Touch the YubiKey button.

If the YubiKey is still alive, it’ll fill in a hash-based OTP, starting with cccc*. If the YubiKey is dead, the field remains empty.

 

FIDO2-only Security Keys

For FIDO2-only Security Keys, the same website can be used:

Note:
As many organizations don't want to miss out on all the goodness Yubico has to offer, only a small percentage of all Yubikeys are (FIDO2-only) Security Keys at the moment.

  1. Open a WebAuthN-capable browser and navigate to https://demo.yubico.com
  2. Click the Test WebAuthn tile.
  3. On the Test your YubiKey with WebAuthn web page, click Next to perform a registration.
  4. Insert the Security Key into a USB port.
  5. Follow the on-screen instructions.
  6. Touch the Security Key button.
  7. Enter the PIN for the Security Key (if one has been configured for it, previously).

 

Device verified

If the FIDO2-only Security Key is still alive, the website will present you with a message including a green check mark, like in the above image.

Posted on February 9, 2023 by Sander Berkouwer in Tips and Tricks, Yubico

0  

Graph API PowerShell Tips and Tricks, Part 2: Requirements

Microsoft Graph Giraffes

The AzureAD, MSOnline and AzureADPreview PowerShell modules are scheduled for deprecation. The schedule has changed a couple of times. To be prepared, admins should get going with the new Graph API SDK. However, the Graph API SDK works differently. There's a learning curve that has proven steep. Many admins who have walked the path before you have reported many issues.

This blogpost series aims to help you on your journey. Together with Aleksandar Nikolic, a Microsoft MVP with an extensive background in PowerShell, we're providing tips and tricks on finding your way through typical questions, situations and annoyances.

When you want to get started with the Microsoft Graph SDK, you'll need to meet the requirements:

 

Recommendation: Use PowerShell v7

When you use PowerShell v7 on either Windows, MacOS or Linux, you're good to go with the Graph SDK. There are no additional prerequisites to using the Graph SDK with PowerShell 7 and later.

On Windows, you can install PowerShell 7 from the Windows Store, through winget. The following command on an elevated Command Prompt install PowerShell 7 next to the existing PowerShell version on the device:

winget.exe install PowerShell

 

Using the Graph SDK with the built-in PowerShell version

Installing and using PowerShell v7 is not a mandatory requirement to the Graph SDK. It shortens the list of prerequisites. When using the version of PowerShell that came with the Operating System, make sure to:

  • Upgrade to PowerShell 5.1, or later.
  • Install .NET Framework v4.7.2, or later.
  • Update PowerShellGet to the latest version using the following command in an elevated PowerShell window:

Install-Module PowerShellGet -Force

 

Done!

Now that we have met the prerequisites, let's discover how to install the Graph SDK in the next blogpost in this series!

Posted on February 8, 2023 by Sander Berkouwer in Azure Active Directory, Microsoft Graph API, Tips and Tricks

0  

On-premises Identity-related updates and fixes for January 2023

Windows Serrer

Even though Microsoft’s Identity focus moves towards the cloud, Windows Server 2016, Windows Server 2019 and Windows Server 2022 still receive updates to improve the experiences and security of Microsoft’s on-premises powerhouses.

This is the list of Identity-related updates and fixes we saw for January 2023:

 

Windows Server 2016

We observed the following update for Windows Server 2016:

KB5022289 January 10, 2023

The January 10, 2023, update for Windows Server 2016 (KB5022289), updating the OS build number to 14393.5648, is a monthly cumulative update that includes two Identity-related improvements:

  • It addresses an issue that might affect authentication. It might fail after you set the higher 16-bits of the msds-SupportedEncryptionTypes attribute. This issue might occur if you do not set the encryption types or you disable the RC4 encryption type on the domain.
  • It introduces a Group Policy setting that enables and disables HTML Application (HTA) files. If you enable this policy, it stops you from running HTA files. If you disable or do not configure this policy, you can run HTA files.

 

Windows Server 2019

We observed the following updates for Windows Server 2019:

KB5022286 January 10, 2023

The January 10, 2023, update for Windows Server 2019 (KB5022286), updating the OS build number to 17763.3887, is a monthly cumulative update that includes one Identity-related improvement. This update addresses an issue that might affect authentication. It might fail after you set the higher 16-bits of the msds-SupportedEncryptionTypes attribute. This issue might occur if you do not set the encryption types or you disable the RC4 encryption type on the domain.

 

Windows Server 2022

We observed the following updates for Windows Server 2022:

KB5022291 January 10, 2023

The January 10, 2023, update for Windows Server 2022 (KB5022291), updating the OS build number to 202348.1487, is a monthly cumulative update that includes two Identity-related improvements:

  • It addresses an issue that might affect authentication. It might fail after you set the higher 16-bits of the msds-SupportedEncryptionTypes attribute. This issue might occur if you do not set the encryption types or you disable the RC4 encryption type on the domain.
  • It addresses issues that affect the Local Session Manager (LSM). These issues might allow users who do not have admin rights to perform actions that only an admin can.

Posted on February 7, 2023 by Sander Berkouwer in Active Directory, Security Updates

0