Share via

Unable to sign in as an administrator user

川上　泰弘 20 Reputation points
2026-04-22T23:38:29.1366667+00:00

After KB5082063 was automatically applied to Windows Server 2025 (AD server), I am unable to sign in as an AD administrator user.

Neither local nor remote desktop sign-in to the server is possible. The same issue occurs on client PCs.

Windows Update history shows that KB5082063 was installed on April 15, 2026, and the problem has been occurring since then.

Regular user account sign-in is possible.

The message displayed when attempting to sign in is: "Incorrect username or password. Please try again."

Windows for business | Windows Server | User experience | Other
0 comments

Answer accepted by question author

  1. Jason Nguyen Tran 17,025 Reputation points Independent Advisor
    2026-04-23T09:25:38.49+00:00

    Hi 川上　泰弘,

    Based on your description, the issue began right after KB5082063 was applied to your Windows Server 2025 domain controller, and it’s affecting both local and remote sign‑ins for AD administrator accounts. Regular user accounts still work, which suggests that the patch introduced changes to authentication policies or account control mechanisms.

    Here are a few steps you can try:

    • First, confirm whether KB5082063 is listed in Installed Updates and attempt an uninstall to see if administrator sign‑in is restored.
    • If uninstalling is not possible, boot into Safe Mode and test administrator sign‑in there. This can help isolate whether the issue is tied to normal authentication flows.
    • Check if the administrator account has been locked out or disabled by reviewing AD Users and Computers from another healthy domain controller.
    • Review the domain controller’s security logs for failed logon attempts, sometimes the patch enforces stricter password or Kerberos policies.
    • If you have a backup of the system state prior to April 15, restoring it may be the fastest way to recover administrator access.
    • As a temporary workaround, create a new domain admin account from another DC (if available) and use that to regain control.

    In short, KB5082063 appears to have introduced an authentication regression, and rolling back the update or using Safe Mode/new admin accounts are the most reliable paths until Microsoft releases a fix.

    I hope this helps If you find this answer helpful, please consider clicking Accept Answer so others can benefit too.

    Jason.

    1 person found this answer helpful.

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jason Nguyen Tran 17,025 Reputation points Independent Advisor
    2026-04-26T01:07:43.4966667+00:00

    Hi 川上　泰弘,

    I’m following up to check whether the issue has been resolved. Feel free to reply if you need further information. If the information provided was helpful, please click "Accept Answer" to help others in the community. Thank you!

    0 comments
  2. Q&A Assist
    2026-04-22T23:38:45.6066667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    KB5082063 is not mentioned in the provided context, but there is closely related information about Windows updates causing domain sign‑in and Kerberos authentication issues, especially for specific account types after recent security updates.

    From the context, the most relevant pattern is:

    • After certain security updates on domain controllers, Kerberos authentication can fail selectively (for example, for domain users, gMSA, or specific accounts) while others continue to work.
    • The known issues for the November 8, 2022 security‑only updates describe scenarios where:
      • Domain user sign‑in can fail.
      • Remote Desktop connections using domain users can fail.
      • The error is tied to Kerberos keys after password changes, and resetting the password regenerates a suitable key.

    In those cases, the System event log on the domain controller shows Microsoft‑Windows‑Kerberos‑Key‑Distribution‑Center Event ID 4 with text similar to:

    While processing an AS request for target service <service>, the account <account name> did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 3. The accounts available etypes : 23 18 17. Changing or resetting the password of <account name> will generate a proper key.

    And the issue is resolved by installing the corresponding follow‑up update (for those specific KBs) or by resetting the affected account’s password so that a proper key is generated.

    Based on that pattern, the concrete steps that align with the documented behavior are:

    1. On a working machine (or via out‑of‑band access such as another DC or management console), open Event Viewer on the domain controller where sign‑in is failing and check:
      • Event Viewer → Windows Logs → System
      • Look for Microsoft‑Windows‑Kerberos‑Key‑Distribution‑Center Event ID 4 entries around the time of failed administrator sign‑ins.
      • If the event text includes “the missing key has an ID of 1” and mentions the administrator account, this matches the known Kerberos key issue.
    2. If that event pattern is present, follow the documented remediation pattern:
      • Change or reset the password of the affected administrator account(s) so that a new Kerberos key is generated.
      • After the password reset, attempt sign‑in again (both local console and RDP) using the new password.
    3. If the environment is running a security‑only or cumulative update set similar to those described (where a follow‑up KB is provided to fix Kerberos issues), install the corresponding fix update for the platform once it is available for the specific build. In the documented cases, Microsoft addressed the issue with follow‑up updates such as KB5021657, KB5021652, and KB5021651 for the November 8, 2022 updates.
    4. If sign‑in is still not possible for administrator accounts after password reset and there is no Event ID 4 with “the missing key has an ID of 1,” use out‑of‑band management (for example, console/iLO/DRAC/Hyper‑V/VMware console) to:
      • Verify that the update is indeed the only recent change.
      • Check whether uninstalling the problematic update from the domain controller is possible and supported in the environment, then reboot and test sign‑in again.

    Because regular user sign‑in still works, focus on:

    • Kerberos key issues specific to the administrator accounts (password reset to regenerate keys).
    • Event ID 4 diagnostics on the domain controller.
    • Applying any follow‑up fix update from Microsoft that specifically addresses Kerberos/sign‑in regressions for the same update train as KB5082063.

    If the server is completely inaccessible via normal sign‑in, use directory tools from another domain controller or management workstation (for example, Active Directory Users and Computers) to reset the administrator account password and then test again.

    References:

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.