Problems with Authentication in SCOM 2025

Aleksandr Aleksandr 45 Reputation points
2026-02-10T14:06:21.7366667+00:00

Hi everyone,

I’m running into an issue with Windows Authentication in the SCOM web console and would appreciate some guidance on where to look next.

Environment:

  • SCOM 2025
  • Windows Server 2025 Standard

What I’ve done so far:

Installed SCOM and completed the basic initial configuration.

Created a gMSA account and registered an SPN in the format: HTTP/SCOM-SERVER

Configured IIS so that the Operations Manager application pool runs under this gMSA instead of the default ApplicationPoolIdentity.

Configured constrained delegation for this gMSA account using msDS-AllowedToDelegateTo with values in the format: MSOMSdkSvc/SCOM-SERVER

In the Operations Manager website settings:

Windows Authentication is enabled
Extended Protection is disabled
Kernel-Mode Authentication is disabled

Expected behavior: After clicking Use Windows Authentication, I should be logged into the SCOM web console.

Actual behavior: When I click Use Windows Authentication, nothing happens in the UI. Looking at the browser network trace, I can see the following request:

URL: /OperationsManager/authenticate

Method: POST

Result: 500 Internal Server Error

I cant undertstand what the reason for it, I hope you can help me.
Thank you !

System Center Operations Manager
System Center Operations Manager

A family of System Center products that provide infrastructure monitoring, help ensure the predictable performance and availability of vital applications, and offer comprehensive monitoring for datacenters and cloud, both private and public.

0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-02-10T14:06:38.5366667+00:00

    It seems you are encountering a 500 Internal Server Error when trying to use Windows Authentication in the SCOM web console. Here are some steps you can take to troubleshoot and potentially resolve the issue:

    1. Verify SPN Registration: Ensure that the Service Principal Name (SPN) is correctly registered for the gMSA account. You can check the SPN registration by running the following command: 
         setspn -L <gMSA-account>
      Make sure that the SPNs for both NetBIOS and FQDN are registered correctly.
    2. Check Application Pool Identity: Confirm that the Operations Manager application pool is indeed running under the gMSA account. You can do this in IIS Manager by checking the application pool settings.
    3. Delegation Configuration: Double-check the constrained delegation settings for the gMSA account. Ensure that it is allowed to delegate to the MSOMSdkSvc service. You might need to verify the settings in Active Directory Users and Computers.
    4. IIS Settings: Since you have already disabled Kernel-mode authentication, ensure that Windows Authentication is properly configured in IIS. You can do this by navigating to the Authentication settings in IIS Manager and ensuring that Windows Authentication is enabled and configured correctly.
    5. Event Logs: Check the Windows Event Viewer for any related error messages that might provide more context on the 500 error. Look specifically under the Application and System logs.
    6. Browser Cache: Sometimes, browser caching issues can cause unexpected behavior. Clear your browser cache or try accessing the web console from a different browser or in incognito mode.
    7. Firewall and Network Issues: Ensure that there are no firewall rules or network issues that might be blocking the communication between the web console and the SCOM server.

    If you have gone through these steps and the issue persists, you may want to consult the official documentation or reach out to Microsoft support for further assistance.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. SChalakov 10,861 Reputation points MVP Volunteer Moderator
    2026-02-13T14:24:35.8766667+00:00

    Hi Aleksandr,

    A 500 on POST /OperationsManager/authenticate is almost always the Web Console failing server-side during Windows auth token handling / Kerberos delegation (the classic “double-hop”: Browser → Web Console (HTTP) → SCOM SDK (MSOMSdkSvc)). The fact that the UI does nothing usually means the request hits the server, but the server can’t complete the delegated call to the SDK.

    Here are a couple fo things to check out:

    1. Validate the exact URL you use in the browser and register matching HTTP SPNs

    You registered only HTTP/SCOM-SERVER. If you browse via FQDN (SCOM-SERVER.domain.tld) or an alias (DNS CNAME / VIP / friendly name), Kerberos will not match unless those names are also SPNs on the app pool identity (your gMSA).

    Example (adjust names):

    setspn -S HTTP/SCOM-SERVER DOMAIN\gMSA-WebConsole$

    setspn -S HTTP/SCOM-SERVER.domain.tld DOMAIN\gMSA-WebConsole$

    setspn -S HTTP/SCOM DOMAIN\gMSA-WebConsole$

    setspn -S HTTP/SCOM.domain.tld DOMAIN\gMSA-WebConsole$

    Then verify and check duplicates:

    setspn -L DOMAIN\gMSA-WebConsole$

    setspn -X

    1. Ensure the SDK (OMSDK) SPNs exist on the SDK service Run As identity

    Constrained delegation only works to SPNs that actually exist. Check what account “System Center Data Access Service” runs under on the management server(s), then register MSOMSdkSvc SPNs accordingly:

    If OMSDK runs as LocalSystem on SCOMMS:

    setspn -S MSOMSdkSvc/SCOMMS SCOMMS

    setspn -S MSOMSdkSvc/SCOMMS.domain.tld SCOMMS

    If OMSDK runs under a domain account (example DOMAIN\SDKSvc):

    setspn -S MSOMSdkSvc/SCOMMS SDKSvc

    setspn -S MSOMSdkSvc/SCOMMS.domain.tld SDKSvc

    Verify:

    setspn -L <SCOMMS or SDKSvc>

    1. Fix constrained delegation for the web console gMSA

    Your msDS-AllowedToDelegateTo must include the SDK SPNs (short + FQDN). Also, if the client side is falling back to NTLM (common when HTTP SPNs don’t match), you must enable protocol transition (“Use any authentication protocol”) on the gMSA; otherwise delegation will fail.

    Example PowerShell (adjust):

    Set-ADAccountControl -Identity gMSA-WebConsole$ -TrustedToAuthForDelegation $true

    Set-ADServiceAccount -Identity gMSA-WebConsole$ -Add @{'msDS-AllowedToDelegateTo'=@(

    'MSOMSdkSvc/SCOMMS',

    'MSOMSdkSvc/SCOMMS.domain.tld'

    )}

    If you guarantee Kerberos end-to-end (client uses Kerberos to HTTP), you can keep Kerberos-only and not enable protocol transition.

    1. IIS Windows Authentication provider order

    On BOTH:

    Default Web Site\OperationsManager

    Default Web Site\MonitoringView

    Check Windows Authentication Providers and ensure Negotiate is above NTLM (so Kerberos is attempted first).

    1. If it still returns 500: capture the real exception

    Enable IIS Failed Request Tracing for /OperationsManager/authenticate and check Event Viewer (Application/System + Operations Manager logs). The stack trace usually points directly to “cannot obtain Kerberos ticket / SPN / delegation” or a permission/config issue.

    Regards,

    Stoyan

    "If my response was useful, please consider marking it as the answer. It keeps the forum clean, structured, and more helpful for everyone. Thank you for supporting the community."

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

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.