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
  • Wally-

    Due to the scope and impact of this issue, I've been told to take the path of expediency and remove SIDHistory from all these objects. Additional testing will be done but let's assume that it is indeed SIDHistory that is the culprit. My concern is the impact by removing this attribute. Please consider:

    • All our resources (file servers, app servers etc.) now reside in the target.
    • All user, group objects are matched between source and target.
    • About 50% of the workstations reside in the TARGET but users log into the source for email (email has not been migrated yet..still working through permissions etc..) The balance of workstations reside in the SOURCE
    • Remember that we have a 1-way trust from target to source (target=trusting, source=trusted)

    By removing this attribute, how will it affect the RUM's operation on workstations? If at all? I'm just trying to think this all the way through before doing anything so drastic.

    Your input is greatly appreciated.

    Eric

Reply
  • Wally-

    Due to the scope and impact of this issue, I've been told to take the path of expediency and remove SIDHistory from all these objects. Additional testing will be done but let's assume that it is indeed SIDHistory that is the culprit. My concern is the impact by removing this attribute. Please consider:

    • All our resources (file servers, app servers etc.) now reside in the target.
    • All user, group objects are matched between source and target.
    • About 50% of the workstations reside in the TARGET but users log into the source for email (email has not been migrated yet..still working through permissions etc..) The balance of workstations reside in the SOURCE
    • Remember that we have a 1-way trust from target to source (target=trusting, source=trusted)

    By removing this attribute, how will it affect the RUM's operation on workstations? If at all? I'm just trying to think this all the way through before doing anything so drastic.

    Your input is greatly appreciated.

    Eric

Children
No Data