Windows Hello for Business 0x80090010 NTE_PERM
Hi all, I'm encountering an issue with Windows Hello for Business on the latest version of Windows (July 2025 update). The setup process fails during initialisation, and no biometric or PIN options are being provisioned for the user. Environment: Windows version: 11 24H2 Enterprise (latest update) Deployment mode: Hybrid Cloud Trust Hybrid joined devices Symptoms: Users are prompted to set up WHfB but the process fails at the last step with error 0x80090010 Users who already have WHfB authentication methods created can successfully login Event ID 311 & 303 in the User Device Registration logs Screenshots: Troubleshooting so far: Unjoined and rejoined to Entra ID Granted modify permissions on folder in which NGC container would be created Rolled back to June 2025 update (this worked) So it seems like this is caused or related to the latest Windows Update, which is rather unfortunate for us as we are just beginning to rollout WHfB for our organisation. I'm posting here to raise awareness of the issue, if there is a more appropriate place to post then please suggest.
What's the deal with Kerb3961?
Howdy, everyone! I wanted to write this blog post to discuss the new Kerb3961 library introduced in Windows Server 2025 / Windows 11 24H2. It is (hopefully) making encryption type (etype) usage within Kerberos much easier to anticipate and understand. Let's start with... What is Kerb3961? Kerb3961, named after RFC3961, is a refactor of the Kerberos cryptography engine in its own library. This library is now the authoritative source of: Etype selection Etype usage Etype management For the average IT administrator, the part that is going to be most interesting is #1. The Kerb3961 policy engine is what will authoritatively determine what etypes are available given different Kerberos key usage scenarios. Whereas in previous Windows releases, there were instances of hard coded etype usage due to technical limitations at the time of implementation. Kerb3961 still leverages existing Kerberos etype configuration group policy: Network security Configure encryption types allowed for Kerberos - Windows 10 | Microsoft Learn. However, it no longer honors the legacy registry key path of: HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Lsa\Kerberos\Parameters REG_DWORD SupportedEncryptionTypes As a reminder, the group policy mentioned above is used to configure the supported encryption types for a machine account. The machine then propagates this information into Active Directory (AD) where it is stored in the msds-SupportedEncryptionType attribute for the account. It has no effect on non-etype related Kerberos settings such as those outlined in Registry entries about Kerberos protocol and Key Distribution Center (KDC) with the exception of the DefaultDomainSupportedEncTypes registry key. The biggest change is the reduction of hard-coded etype usage. We have heard the frustrations of customers who are trying to eliminate RC4 usage, and the seemingly unexplainable instances of RC4 usage with their environments. This new library removes these hard-coded dependencies and aggregates all those decisions into one place. With the goal of: More secure Kerberos operations by default More predictable Kerberos etype usage More stable etype additions More stable etype removals For example, if we had not done this refactor, the DES deprecation and on-going work towards RC4 deprecation would not be possible. Why did this need to happen? Kerberos was added to Windows in the early 2000's as a part of beginning the move away from NTLM and into modern cipher usage. Over these decades, there have been incredible strides in security hardening that the original developers could not have foreseen. As a result, some of the design decisions made during that initial implementation impacted our ability to reliably change the way Kerberos operates. This can be seen in things like: Kerberos changes for CVE-2022-37966 Kerberos changes for CVE-2022-37967 Additionally, with the long tail of code in this area and the etype that has been historically used, it had become a near impossibility to add or remove a cipher due to how the etypes were directly associated in Kerberos. What does this mean going forward? The Kerb3961 library has key implications going forward. The biggest one is the removal of hard-coded cipher usage and a stronger adherence to the administrators’ configured encryption types. The environment will operate as configured. Meaning IT administrators can have a high degree of confidence that their configurations will be honored. This increases the amount of knowledge required by administrators. Misconfigurations, previously hidden by loose adherence to the configured etypes, will now be exposed. For more information about Kerberos etype selection, refer to the Kerberos EType Calculator. What needs to be done? To configure an environment requires understanding what etypes are used within an environment. To help aid in this endeavor, we have improved Key Distribution Center (KDC) auditing. 4768(S, F) A Kerberos authentication ticket (TGT) was requested. - Windows 10 | Microsoft Learn 4769(S, F) A Kerberos service ticket was requested. - Windows 10 | Microsoft Learn We have also published two PowerShell helper scripts that leverage these new events. The goal of these scripts is to allow for easier identification of both etype usage and account key availability. These scripts are published on the Microsoft Kerberos-Crypto GitHub repository, where, going forward, we will be using scripts and information published there to better interface with the community. We acknowledge that substantial changes can introduce regressions and friction points for those with mature environments. It is our goal to allow for a smooth adoption of these new features and prevent any unnecessary pain for our already overworked and under-appreciated system administrators. Please be sure to leverage Feedback Hub to share your experiences with us. If you would like to see any of these features early, we highly recommend leveraging the Windows Insider Program and opting into Continuous Innovation and sharing feedback directly with the development team. We understand that this can be challenging, and Microsoft is committed to ensuring that the knowledge needed to make an informed decision about what is right for your environment.
Profile photo component adds unwanted overlay
Component https://myaccount.microsoft.com Run command: ms-settings:yourinfo Environment Profile picture uploaded through https://myaccount.microsoft.com Profile picture uploaded through Run command (WIN+R): ms-settings:yourinfo Retrieved via Microsoft Graph SDK / Graph REST API endpoint /v1.0/me/photos/$value Steps to Reproduce Go to https://myaccount.microsoft.com. Upload a new profile picture (no presence, badge, or branding requested). Retrieve the profile picture using Microsoft Graph endpoint: GET https://graph.microsoft.com/v1.0/me/photos/$value Render the image in the client application. Expected Result The raw profile photo is shown exactly as stored—no overlays, rings, badges, or branding. Actual Result The component renders an overlay (e.g., presence badge/ring/branding) on top of the photo, altering the image. Impact Users see altered profile photos, leading to inconsistencies with expectations. Breaks brand/UX design guidelines that rely on unmodified profile images. Severity Medium–High (affects identity consistency across apps using Graph). Notes This happens even though no overlay option was requested in either the upload or retrieval flow. Alternative: Steps to Reproduce and working as expected Run command (WIN+R): ms-settings:yourinfo Upload a new profile picture (no presence, badge, or branding requested). Retrieve the profile picture using Microsoft Graph endpoint: GET https://graph.microsoft.com/v1.0/me/photos/$value Render the image in the client application. Expected Result The raw profile photo is shown exactly as stored—no overlays, rings, badges, or branding. Actual Result The raw profile photo is shown exactly as stored—no overlays, rings, badges, or branding.
My Azure login is stuck at MFA and cannot proceed
In August, I was still able to log in to Azure, and by logging in through GitHub I could bypass 2FA. But now, no matter how I try, logging in via GitHub always requires 2FA. I can’t access my Azure account anymore—nothing works. The system prompts me to use Microsoft Authenticator to confirm a two-digit code in real time. My Microsoft Authenticator on my iPhone is logged into the same Microsoft account, but I’m not receiving any verification requests for Azure login. No matter how much I refresh, nothing shows up. I’ve already updated the Microsoft Authenticator app to the latest version from the App Store. However, my personal Microsoft account works fine and can log in without any issues.Cant access admin panel
Hi Everyone, I have done something really silly and I don't mind if I get a laugh or two, I have locked myself out of our two admin accounts due to both had 2FA on and the phone that the notifications went to sadly has been reformated without the person checking with me first, I have an E5 Licence but without being able to access the admin page I can't access support to get this resolved 😞 - I'm kind of stuck and at the moment even though we only have a few licenses (mix of E5and F3) Feeling really silly about this but if anyone has an idea of how I can resolve this I would be really grateful Joe
BioEnrollmentHost.exe failes setting up Windows Hello (August 2025)
Hello, when trying to add another fingerprint, there is a failure. The editing interface does not open - it disappears without displaying an error message. The eventlog shows the error: Log Name: Application Source: Application Error Date: 25.08.2025 9:09:22 Event ID: 1000 Task Category: Application Crashing Events Level: Error Description: Faulting application name: BioEnrollmentHost.exe, version: 10.0.26100.4484, time stamp: 0x3a2c5e36 Faulting module name: Windows.UI.Xaml.dll, version: 10.0.26100.4946, time stamp: 0x4374ba0f Exception code: 0xc000027b Fault offset: 0x0000000000903d13 Faulting process id: 0x3B10 Faulting application start time: 0x1DC158F2982572A Faulting application path: C:\Windows\SystemApps\Microsoft.BioEnrollment_cw5n1h2txyewy\BioEnrollmentHost.exe Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll Report Id: da35663e-a5e8-4638-b202-5afed9fd901c Faulting package full name: Microsoft.BioEnrollment_10.0.19587.1000_neutral__cw5n1h2txyewy Faulting package-relative application ID: App There is no problem with OS integrity > PS C:\WINDOWS\system32> DISM.exe /Online /Cleanup-image /Scanhealth Deployment Image Servicing and Management tool Version: 10.0.26100.1150 Image Version: 10.0.26100.4946 [==========================100.0%==========================] No component store corruption detected. The operation completed successfully. PS C:\WINDOWS\system32> PS C:\WINDOWS\system32> DISM.exe /Online /Cleanup-image /Restorehealth Deployment Image Servicing and Management tool Version: 10.0.26100.1150 Image Version: 10.0.26100.4946 [==========================100.0%==========================] The restore operation completed successfully. The operation completed successfully. PS C:\WINDOWS\system32> PS C:\WINDOWS\system32> sfc /scannow Beginning system scan. This process will take some time. Beginning verification phase of system scan. Verification 100% complete. Windows Resource Protection did not find any integrity violations. PS C:\WINDOWS\system32> chkdsk c: /scan /perf The type of the file system is NTFS. ... Windows has scanned the file system and found no problems. No further action is required. ... PS C:\WINDOWS\system32> PS C:\WINDOWS\system32> systeminfo | findstr /B /C:"OS Name" /B /C:"OS Version" OS Name: Microsoft Windows 11 Enterprise LTSC OS Version: 10.0.26100 N/A Build 26100 PS C:\WINDOWS\system32> Any ideas?
Locked out because of bugged 2FA
Hello, I have one irritating problem. I did a reset of my microsoft authenticator app since it stopped working, i did not save the Authenticators security code, i got 2FA activated on my account. Now i have been trying to log in on my microsoft account for one month without succes. The 3 options i have for 2FA is Code to external my gmail - This works 2 times a day, then locked for 24h Code by text to my cellphone - This does not work when trying to log in, i get the error "Try another verification method, this method does not work at the moment". I know it works, its just in the combination with 2FA it wont work. Microsoft Authenticator - I cannot log into this one since the textmessage does not work on 2FA-login. I have been in a loop for the last month, i cant log into my ordinary e-mail, xbox and so on. Im still logged in on my computer and cellphone at the moment but im afraid it will time out very soon. Microsoft support says that they cannot do anything about it, it is only a server doing all the security. I cant remove 2FA on the account im still logged into, i need 2FA for that. Help!
Sign In Error 90072 with On Prem Accounts - How to mitigate?
We receive weekly reports from one of our security vendors regarding login failures across our environment. As of recent, we've noticed a spike in interactive login failures, particularly with Microsoft services. The application that produces many of these logs is Microsoft Office. Upon investigation, we've determined that many of these sign ins procure error code 90072 with the following error message: "User account '{user}' from identity provider '{idp}' does not exist in tenant '{tenant}' and cannot access the application '{application}'({appName}) in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account" As a disclaimer, I did not edit this message to insert the unfilled variables in brackets - that's how the error message appears in our Entra portal. We currently run a hybrid environment, and all of the users with high volumes of failed sign ins with the given error code and message are on-prem accounts. These logs produce a lot of noise that we would rather not have polluting our reports. Do you have any information we can use to help remediate this issue?TAP Question
Hi All I hope you are well. Anyway, I'm looking for some clarification over Temporary Access Passes (TAP) as our testing seems to reveal some different results from those listed in the MS documentation. Here's the scenario's. My understanding: Require MFA policy deployed via Conditional Access New user F3 user starts Issue TAP to user where they can then setup MFA themselves via My Security Info etc Testing results: Require MFA policy deployed via Conditional Access New user F3 user starts User can setup MFA themselves via MS Auth app on a mobile device or via My Security Info in a browser MS TAP Info page: "The most common use for a TAP is for a user to register authentication details during the first sign-in or device setup, without the need to complete extra security prompts." Ref: Configure a Temporary Access Pass in Microsoft Entra ID to register passwordless authentication methods - Microsoft Entra ID | Microsoft Learn Have I missed understood something here and if a new user can indeed still setup MFA is there any real need for a TAP for first time user? Info appreciated. SK
