As part of a recent project involving the latest technologies from Microsoft including Entra ID, Windows Server 2022 and Windows Hello for Business, we faced a somewhat odd challenge. In two words the issue was Internet Explorer. Yes, even though IE was retired as a desktop browser it is still part of Windows Server 2022 and in some cases there is no way to ignore it when working with PowerShell and Entra ID. Below we have provided the details about one such instance of not being able to use browser other than IE.
When implementing and deploying Windows Hello for Business in cloud Kerberos trust mode, Microsoft Entra Kerberos server object needs to be created within the on-premises Active Directory instance and subsequently published to Entra ID. This object facilitates the generation of so-called Kerberos Ticket Granting Tickets (TGTs) for the Active Directory domain by Entra ID.
The creation of a Kerberos server object requires the installation of AzureADHybridAuthenticationManagement PowerShell module. It uses AzureADPreview to provide advanced Microsoft Entra management features. After the module is installed, the Set-AzureADKerberosServer cmdlet must be executed to create the server object in AD. And this is where IE comes into play unfortunately.
When Internet Explorer Enhanced Security is enabled (and it should of course) there is no possibility to authenticate to Entra ID. This is because Set-AzureADKerberosServer requires a connection to the Azure tenant, and it prompts for Azure credentials. Regardless of whether Microsoft Edge or another browser is configured on the system as the default one, Internet Explorer consistently opens. That is because the cmdlet uses AzureAD mode in background. This presents two main concerns:
Internet Explorer is no longer supported as browser but at the same time Microsoft have not removed it yet even from the latest version of Windows Server due to its deep integration with the OS.
Usually, Internet Explorer Enhanced Security Configuration is enabled, and its settings are managed through Group Policies. To successfully authenticate with Azure, access to specific websites is required. Failure to modify the Internet Explorer settings will result in an inability to sign in to Azure.
Mitigating the inconvenience posed by these challenges requires careful preliminary planning or the implementation of workarounds, which may not always be effective. Here is one such workaround that could be used if there is a GPO that prevents adding sites as trusted:
Modify the Internet zone to enable Active Scripting.
Update the Privacy options to allow the following sites:
Note:Â These settings must be configured temporarily because they increase the attack surface. Once the authentication with Azure is successful, they must be reverted.
Another concerning point is that Microsoft announced initially that Azure AD Preview as well as Azure AD and MSOnline PowerShell modules are planned for deprecation and should have stopped functioning after June 30, 2023. As per this article we should migrate to Graph PowerShell. However, scripts written in AzureAD PowerShell, including some of Microsoft’s own cmdlets, won't automatically work with Microsoft Graph PowerShell. There are other scenarios for which the legacy modules are required because certain methods and capabilities are not yet supported with the Microsoft Graph PowerShell SDK. Thus, the deprecation date for the MS Online, AzureAD, and AzureAD Preview PowerShell modules has been postponed to March 30, 2024. Following the deprecation, these modules will remain functional for at least six months before retirement. Consequently, only security fixes will be provided for these PowerShell modules.
Despite the coming deprecation deadline, it is evident that there are still scripts and cmdlets used even in the Microsoft’s official documentation reliant on the legacy PowerShell modules. It is likely that they will need to remain active, and their lifespan extended again for the time being.