Jump to content


Recommended Posts

Hi Anyweb,

I’ve started noticing an issue with our SSRS reporting portal. When attempting to run certain reports, I receive the following error:

“The DefaultValue expression for the report parameter 'UserTokenSIDs' contains an error: A specified logon session does not exist. It may already have been terminated. (rsRuntimeErrorInExpression)”

At the same time, I’m seeing the following entries in the sccmreporting.log on our SQL server (which also runs SSRS):

08/05/2025 17:11 EnableRbacReporting key exists.  Value = 1  
08/05/2025 17:11 A specified logon session does not exist. It may already have been terminated.

The timestamps in the logs appear to align with the error, and based on similar reports I’ve read, these messages seem to be related.

Some background on the setup:

  • SQL Server and SSRS are running under a domain account (not a domain admin).

  • The service account is a member of the Windows Authorization Access Group.

  • The service account has read access to the Users container/OU in Active Directory.

  • SSRS authentication is configured to use Windows Negotiate.

  • The service account has SPNs correctly configured.

  • The account is enabled for Kerberos AES encryption (128-bit and 256-bit) in Active Directory.

  • The service account is configured for “Trust this user for delegation to any service (Kerberos only)” in AD.

  • The SSRS shared data source is configured to use the service account credentials.

  • All custom reports and default SCCM reports use the same shared data source.

As a workaround, I disabled RBAC by setting the EnableRbacReporting registry key to 0 on the SSRS server. This resolved the issue and allowed the reports to run properly, effectively forcing SSRS to bypass RBAC.

That makes me think the problem may be related to Kerberos authentication or token delegation in some way, but I'm unsure how to proceed further with troubleshooting it.

Let me know if you've seen this before or have any guidance on what to look into next.

Share this post


Link to post
Share on other sites

Issue Resolved: SSRS Kerberos Authentication Failure Due to Protected Users Group

I successfully resolved the above issue by removing the SSRS service account from the Protected Users security group. During the investigation, I uncovered several critical configuration requirements necessary for enabling Kerberos authentication with a domain-based service account in SSRS.

Key Findings and Configuration Requirements:

  1. Windows Authorization Access Group

    • The service account must be a member of the Windows Authorization Access Group to read token information (e.g., user attributes) required for Kerberos delegation.

  2. Read Access to Active Directory Objects

    • The service account must have read permissions to the Active Directory users, OUs, and computers it attempts to authorize through SSRS.

  3. Account is Sensitive and Cannot Be Delegated

    • This property must be disabled for the service account in Active Directory.

  4. Delegation Settings (Kerberos Only)

    • The service account must be configured in Active Directory for "Kerberos only" delegation to specific services.

    • Delegation should be strictly scoped to only the required services (If possible).

  5. Service Principal Name (SPN) Registration

    • Proper SPNs must be registered for the SSRS service (e.g., HTTP/reportserver.domain.com, MSSQLSvc/reportserver.domain.com, MSSQLSvc/reportserver.domain.com:1433) under the service account.

  6. SSRS Configuration Settings

    • SSRS was configured to use Kerberos only by setting the authentication mode appropriately in RSReportServer.config.

    • ExtendedProtectionLevel was also enabled. This is optional but strongly recommended for environments with strict security requirements.

References and Resources:

 

Share this post


Link to post
Share on other sites

great findings and glad you got it sorted

are you sure with the changes made that it's going to work security wise ?

Share this post


Link to post
Share on other sites

21 hours ago, Cerberus24 said:

Now, given that I am using a password for the shared data source. It should not be trying to delegate. At this point, I am not completely sure how to attack this issue. Any ideas would be greatly appreciated. 

So just to be clear did you change the default ConfigMgr datasource? if so it will get reset, in the future. 

Share this post


Link to post
Share on other sites

On 8/7/2025 at 3:01 AM, anyweb said:

great findings and glad you got it sorted

are you sure with the changes made that it's going to work security wise ?

From a security perspective, on the SQL and SSRS host (which is the same server), I’ve turned on Extended Protection for Authentication (EPA) and SMB signing across the environment. These help block Kerberos attacks like replay attacks and pass-the-ticket attacks across systems.

Replay attacks could only happen if someone’s already on the SSRS host or inside the same secure channel. Plus, they’d have to know the complex password for the service account, which I only use for SQL/SSRS stuff. I’ve also blocked RDP access for that account, cutting off a common way attackers move laterally.

Also, my SCCM setup uses HTTPS only, so all traffic is encrypted.

On top of that, I’m planning to use a different account for client push. That way, if one of my endpoints gets compromised, it limits the damage and keeps my critical service account safe.

If you have any suggestions on how I can improve my security posture, I’d really appreciate it.

Share this post


Link to post
Share on other sites

On 8/8/2025 at 7:29 PM, Cerberus24 said:

Not sure I am following. But all my custom reports and default SSRS reports for the config manager are using the same shared data source. 

How did you change the PW for the default datasource used by ConfigMgr? Did you do something like this? Changing ConfigMgr Report Account Password, How do I do it?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.