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
  • Thanks for the detailed reply, Wally.

    Let me clarify:

    All resources (servers, not workstations) have been moved to the target. The only thing in the source is email.

    Users are still logging into the source. The trust in place allows users to still access those resources.

    All objects have been merged between source and target. (i.e. the target and all target objects already existed before the tool was stood up)

    So based upon your statement here: "even if target trusts the source, sid hisotry just doesn't work that way" tells me that we could have merged our objects and not included SIDHistory at all.

    Finally, it sounds like the RUM does not leverage SIDHistory at all. I was concerned about re-permissioning of workstations and that could get broken. Did I get that right?

    Thanks!

Reply
  • Thanks for the detailed reply, Wally.

    Let me clarify:

    All resources (servers, not workstations) have been moved to the target. The only thing in the source is email.

    Users are still logging into the source. The trust in place allows users to still access those resources.

    All objects have been merged between source and target. (i.e. the target and all target objects already existed before the tool was stood up)

    So based upon your statement here: "even if target trusts the source, sid hisotry just doesn't work that way" tells me that we could have merged our objects and not included SIDHistory at all.

    Finally, it sounds like the RUM does not leverage SIDHistory at all. I was concerned about re-permissioning of workstations and that could get broken. Did I get that right?

    Thanks!

Children
No Data