SQL Server Reporting Services (SSRS) and SIDHistory problem

Hello all-

We are in the middle of a migration and have run into a very strange issue with SQL Server Reporting Services (SSRS).

Here is the AD environment:

Source:

  • Windows 2008 R2 running in 2008 R2 mode
  • Domain: MNPS

Target:

  • Windows 2008 R2 running in 2008 R2 mode
  • Domain: SCHOOLS
  • SQL Server 2008 R2 box running SSRS
  • One-way trust is in place. Target is trusting, Source is trusted

Note the attached graphic.

Capture.JPG

Essentially these roles are explicitly added using accounts from the source (mnps\username) and in the span of 10 minutes, the account changes to the target (schools\username).  All AD accounts have been merged to the target with SIDHistory preserved. Once this occurs, users get denied access to this reporting engine.

Initially I stopped DSA Sync and the issue persisted. Then I rolled back a sample user account, we re-added the source object to SSRS and the account did not change. I then re-merged the object, this time not including SIDHistory and the account did not change.

This system was moved to the target manually. The RUM was not used nor was the SQL Processing Wizard. This due to the nature of the application and the application owner was more comfortable with this approach.

Can you shed any light on would could be happening here?

As always, thanks in advance.

Eric

Parents
  • Here are my findings:

    1. I can re-produce the problem – with or without a trust in existence.  This confirms that the issue is linked to the SID history value itself and not the trust.
    2. With all resources stored in the Target environment, the potential value of SID history is diminished.  If you have dual-permissioned everything already then there is greatly reduced risk.
    3. The SQL Processing Wizard can both re-permission for users using their Target accounts and revert permissions users still logging on using their SOURCE accounts.  This will correct any discrepancies in SSRS after you remove SID history.  You will need to create separate SQL processing tasks and use Custom Maps for each with different repermissioning options.
Reply
  • Here are my findings:

    1. I can re-produce the problem – with or without a trust in existence.  This confirms that the issue is linked to the SID history value itself and not the trust.
    2. With all resources stored in the Target environment, the potential value of SID history is diminished.  If you have dual-permissioned everything already then there is greatly reduced risk.
    3. The SQL Processing Wizard can both re-permission for users using their Target accounts and revert permissions users still logging on using their SOURCE accounts.  This will correct any discrepancies in SSRS after you remove SID history.  You will need to create separate SQL processing tasks and use Custom Maps for each with different repermissioning options.
Children
No Data