Trending Issues: Kerberos Failures in SharePoint and other applications starting April 2026

- - 14 Comments

In recent days we have seen several support cases where Kerberos authentication in SharePoint suddenly starts to fail.
In the SharePoint ULS logs you may see errors such as:

System.ServiceModel.Security.SecurityNegotiationException: A call to SSPI failed
System.Security.Authentication.AuthenticationException: A call to SSPI failed
System.ComponentModel.Win32Exception: The encryption type requested is not supported by the KDC

Cause

Starting with the April 14, 2026 Windows updates, Microsoft changed the Kerberos Key Distribution Center (KDC) behavior related to the DefaultDomainSupportedEncTypes setting.
A detailed explanation of this change is provided in the following article:

These updates are part of a security hardening effort addressing CVE‑2026‑20833, where Kerberos service tickets encrypted with the older RC4 algorithm could be used to perform offline attacks against service accounts.

With the April 2026 update, the KDC no longer assumes RC4 support for accounts that do not explicitly define supported encryption types. Instead, it assumes AES-only encryption.

Why this impacts SharePoint environments

Many SharePoint farms rely on service and application pool accounts using Kerberos.
In older environments (or farms that have been upgraded across SharePoint versions), these accounts often do not have AES encryption enabled in Active Directory.

Before April 2026:

  • Kerberos could fall back to RC4 if AES wasn’t configured.

After April 2026:

  • The KDC assumes AES-only, and RC4 fallback is no longer used.

If the SharePoint service account is not configured to support AES, Kerberos cannot negotiate a supported encryption type, which results in the errors shown above.

These issues may appear in several places, for example:

  • Accessing Central Administration
  • Opening Search Administration
  • Starting User Profile Synchronization Service
  • Other SharePoint service application operations

In short, this is not a problem in SharePoint. The failures occur because of a mismatch between the encryption types expected by the KDC and those configured on the SharePoint service account in Active Directory.

Solution

Enable AES encryption for all SharePoint service and application pool accounts in Active Directory:

  1. Identify all SharePoint service and application pool accounts.
  2. Open Active Directory Users and Computers.
  3. Open the Properties of each account.
  4. Go to the Account tab.
  5. Under Account Options, enable the following:
    • This account supports Kerberos AES 128 bit encryption
    • This account supports Kerberos AES 256 bit encryption
  6. Run iisreset and restart affected SharePoint services.

For more details and a PowerShell script to verify the currently supported encryption types for SharePoint accounts, see:

14 Comments


  1. Hi Stefan,

    thanks for the arcticle. Without this article, we would certainly have had this issue. Right now I have installed SharePoint CU April but the Windows Servers are still on March and are patched using SCCM. Because of that scenario I think that we were still using the fallback to RC4 because I could not find mentioned log entries on our system. Am I right with this assumption?
    I also ran the script which was listed in the linked MS article and saw that AES128/256 was not enabled for the managed accounts and so I enabled that. With that all done I think we are good to go for the Windows Update from April.

    Thanks and BR,
    Alex

    Reply

    1. Hi Alex,
      yes your assumptions are correct.
      Great that the article was helpful!
      🙂
      Cheers,
      Stefan

      Reply

  2. Hi Stefan!

    I have installed two new SE environments on Server 2025 and March CU. I have created all needed service applications and webapplications. Webapplications are not set to Kerberos at the moment. I then saw that some services (app management, distributed cache…) or not starting correctly and i try to fix this since days.

    So just to be sure, this could be the reason?

    Thanks!

    Br
    Rene

    Reply

    1. Hi Rene,

      its hard to confirm this without more information.
      But checking the ULS log for the exceptions listed at the top of my blog post should give you a confirmation.

      My recommendation would be to run the PowerShell script from the quoted article and verify if the service and application pool accounts have the required encryption settings.

      Cheers,
      Stefan

      Reply

      1. Thanks, accounts do not have this option enabled so i gues thats the reason on my problems.

        Reply

  3. Hi Stefan,
    In the article “SharePoint server configuration requirements to support Kerberos AES encryption if errors occur” it states:

    “When you configure the property setting Network Security: Configure encryption types allowed for Kerberos so that the server only supports AES encryption types and future encryption types, the server doesn’t support older Kerberos encryption types in Kerberos tickets. ”

    and also:

    “To check whether your SharePoint server is configured to only support AES encryption types or newer types:

    On the server, start the Local Security Policy Editor (secpol.msc).
    Expand Security Settings > Local Policies > Security Options.
    Locate Network Security: Configure encryption types allowed for Kerberos.
    Select Properties.
    If only the following Options are selected:

    AES128_HMAC_SHA1
    AES256_HMAC_SHA1
    Future encryption types
    Screenshot of encryption types allowed for Kerberos.

    Then you need to enable Support for Kerberos AES Encryption on the Active Directory user objects that are used to run SharePoint services and application pools.”

    So my question is: What if in the server’s Local Security Policy the setting “Configure encryption types allowed for Kerberos” is set to “Not Defined” and no encryption types are selected? Will this Tending Issue also affect our SharePoint environments if the accounts do not have the AES encryption support enabled in AD?

    Thanks in advance for your reply.

    Br
    Paul

    Reply

    1. Hi Paul,
      yes – if it is not defined the new Default AES is assumed by KDC with April 2026 Windows cumulative update.
      Cheers,
      Stefan

      Reply

  4. Hi Stefan,
    I enabled AES-128 and AES-256 for all our SP managed accounts and rebooted all servers in the farm.

    The error was still present.

    I opened a ticket with Microsoft and they made me enable AES-128 and AES-256 in Group Policy :
    Network Security: Configure encryption types allowed for Kerberos.

    We rebooted the servers and now search is working again (i can access topology. I have a warning on partition 0, have to check if it’s related to the Kerberos changes),

    But we also use Reporting Services with the service ClaimsToWindowsToken Service and since the modifications, Reporting Services doesn’t work anymore (it times out).

    If i enable RC4 again in Group Policy and reboot the servers, Reporting Services launch but gives me an error, but search gets broken.

    That’s where i am so far.

    Jeff

    Reply

  5. FYI: For our normal PowerShell auth to SharePoint 2016/2019 using certificate auth, after this Windows patch we had to add the attribute -UseDefaultCredentials to the Invoke-RestMethod cmdlet to successfully authenticate. This apparently sends both the certificate and the logged on Windows credentials to PowerShell’s authentication request.

    Reply

  6. It also break open Office365 documents. Sharepoint SE with Azure Ad trust sso. The same for Saml/wsfed and OIDC. Reinstalling to O365 from Januar solve the issue. How cretae issue ? Ooen internet options and clean cookies, new version get 403 error and back to main page, old version not have this versions.
    I created here this information , because I don”t found related topic.

    Reply

  7. Exception calling “ExecuteQuery” with “0” argument(s): “Cannot contact web site “SharePoint Online Site” or the
    web site does not support SharePoint Online credentials. The response status code is ‘Forbidden

    I am getting this issue while I am running Powershell..

    Can you please help on this

    Reply

    1. Hi Chinna,
      I do not see how this would be related to the Kerberos issues discussed in this blog post.
      Cheers,
      Stefan

      Reply

  8. Hello everyone,
    I’m trying to confirm whether the Kerberos issue only affects environments that were originally configured to use Kerberos during their initial setup.
    I’ve applied the April 2026 CU to our Dev environment and have been testing for the past three weeks. So far, I haven’t encountered any problems—service applications and sites are all functioning normally. I’m just trying to determine whether this issue is something we should expect to see in our environment.

    Reply

    1. I had no problems, my service accounts have always had AES256 ticked.

      That said, I’m having trouble understanding why this issue affected anyone at all.
      The change made to AD was to assume AES rather than RC4 in the case where a service account did not have msds-SupportedEncryptionTypes set. In that case when the domain controller updates where applied kerberos tickets against an account with no msds-SupportedEncryptionTypes set would’ve changed from RC4 to AES256 which is no different to ticking the box in the account properties.
      The only think that should be affected are third party devices/appliances that can’t deal with AES encrypted kerberos tickets.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.