Cerberus24

Yep, that is precisely what I did when setting up the SSRS.

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.

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.

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: 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. 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. Account is Sensitive and Cannot Be Delegated This property must be disabled for the service account in Active Directory. 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). 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. 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: Microsoft Docs – Reports Not Run as Expected Recast Software – Windows Authorization Access Group, SSRS, and SCCM Blake Drumm – How to Change Reporting to Use Kerberos Instead of NTLM

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.

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.

@anyweb, thank you for your availability and troubleshooting. I have figured out the problem. The issue stemmed from the fact that I was primarily working with headless computers in my environment. Even though I was running MSTSC with the /admin or /console switch, I never properly checked if the established session was, in fact, a console session. This is why the policy would fail, and we would see errors in the logs when the policy attempted to launch the MBAM UI. I didn’t realize this until I revisited my VMs and accessed them through the console, instead of connecting via MSTSC. On existing, imaged devices, I was able to resolve the issue by manually interacting with a few devices using SCCM's remote control viewer, which establishes a console session. After logging in via SCCM’s remote viewer, the BitLocker policy executed and encrypted the drives without any issues. For anyone else in your community facing a similar problem, I addressed the headless computer issue by creating a task sequence during OS deployment. This ensures that devices are imaged with the appropriate BitLocker settings that align with my BitLocker policy. This way, all imaged devices are compliant from the start, and SCCM can still report compliance for these devices, since the policy settings are consistent and encryption is not required. Since I will mostly be accessing the headless computers via MSTSC, this solution works well for my environment.

I replicated the same process on my test VM (decrypting with the policy and then re-encrypting using the policy), but for some reason, I’m encountering the same error message as I did on the other devices. Initially, I deployed the BitLocker policies in a smaller controller environment with VMs, and everything worked fine. I’m not sure what might be causing this issue now. The only difference I can think of is that the previous environment was running with self-signed certificates, whereas now it’s running with proper certificates. - Device status before the decryption policy is deployed. - Device status after the decryption policy was deployed and enforced. - Trying to re-encrypt after a successful decryption. - BitlockerManagemetHandler.log file after encryption policy is deployed - After rebooting the VM, the next console login via the MSTSC.exe client shows the following: It’s important to mention that I was able to successfully encrypt and decrypt this same VM while the system was running under self-signed certificates.

The endpoints are running Windows 11 24H2. The severs infrastructure for the MP and DP are running Windows server 2019 1809.

"Apologies for not seeing your reply sooner. This doesn’t apply to the current environment, as there was no previous MBAM infrastructure. However, I did decrypt the devices using the decryption policy, since the machine was imaged and BitLocker had been enabled with a weaker encryption algorithm. The decryption policy worked flawlessly, but as previously mentioned, the encryption policy is not functioning as expected. I have made sure that the targetted devices are no longer targetted by the decryption policy.

Yes, I’ve tried that as well, but I’m still getting the same error message. One thing I didn’t mention earlier is that I’m running this ENV on HTTPS, but as far as I can tell, the certificates are all working properly.

Hi, there is no CD/DCD in the tray, nor is there an ISO mounted on the system. Correct, I initiated a console login through Microsoft RDP to check the encryption process, but I always receive the following error message described below.

Sorry to hear that. Thank you for the reply.

Hi Anyweb, I’ve deployed BitLocker using your setup articles, but I’m encountering an issue where the devices aren’t encrypting the drives as expected. Any assistance you can provide would be greatly appreciated. It’s worth mentioning that the devices I’m testing with are all located in the same device collection where the MBAM encryption policy has been deployed. Additionally, all the devices have TPM 2.0, TPM is enabled and ready, and Secure Boot is also enabled. As for the logs, everything appears to be working as expected, except for the MBAM admin logs, which indicate that it cannot connect to the MBAM and hardware recovery services. However, according to Microsoft’s documentation, "Starting in version 2103, the implementation of the recovery service changed. It no longer uses legacy MBAM components, but is still conceptually referred to as the recovery service." Given this, I assume this error log should not affect the encryption process, correct? For reference, my environment is running Configuration Manager version 2409. I have attached a few screenshots for your reference. Thank you!

Hi Nscott, I wanted to check in and see if you were able to find a solution to this issue. I’m experiencing the same problem and have gone through Anyweb's SCCM BitLocker setup and troubleshooting steps, but I still can't seem to identify the cause. Any insights you might have would be greatly appreciated!