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
  • I was never good with one way trusts, but in my opinion in your current setup

    • Remember that we have a 1-way trust from target to source (target=trusting, source=trusted)

    I would think the sid history in target is useless anyway, because the source is not trusting target and target users cannot use the sid when accessing resources in the source.

    They can still use the sid history when accessing resources located in target, but we all know that sid history is a temp solution and needs to be removed and cleaned up sooner or later. I would suggest to sync or migrate all objects to target, so they all are present in the ADAM DB, and then re-permission computers, in source and in target.

    Plan could be: use ADPW and remove sid history for a few users and see what happens. If anything goes wrong you can quickly re-migrate or resync them and add it back, or use RUM and process the resources. If all is good you proceed and use ADPW and remove sid history for another batch of users, or for all of them.

    https://support.quest.com/SolutionDetail.aspx?id=SOL22583

    This one-way trust still confuses me a lot . If source doesn't trust target then target users have no chance to access resources there, no matter via sid history or because you repermissioned resources and gave target users direct access.

    PS: sid history is also useless when users from source are accessing resources in the taget, even if target trusts the source, sid hisotry just doesn't work that way. Unless source user has as sid history the sid of target user, but I doubt you have done this.

Reply
  • I was never good with one way trusts, but in my opinion in your current setup

    • Remember that we have a 1-way trust from target to source (target=trusting, source=trusted)

    I would think the sid history in target is useless anyway, because the source is not trusting target and target users cannot use the sid when accessing resources in the source.

    They can still use the sid history when accessing resources located in target, but we all know that sid history is a temp solution and needs to be removed and cleaned up sooner or later. I would suggest to sync or migrate all objects to target, so they all are present in the ADAM DB, and then re-permission computers, in source and in target.

    Plan could be: use ADPW and remove sid history for a few users and see what happens. If anything goes wrong you can quickly re-migrate or resync them and add it back, or use RUM and process the resources. If all is good you proceed and use ADPW and remove sid history for another batch of users, or for all of them.

    https://support.quest.com/SolutionDetail.aspx?id=SOL22583

    This one-way trust still confuses me a lot . If source doesn't trust target then target users have no chance to access resources there, no matter via sid history or because you repermissioned resources and gave target users direct access.

    PS: sid history is also useless when users from source are accessing resources in the taget, even if target trusts the source, sid hisotry just doesn't work that way. Unless source user has as sid history the sid of target user, but I doubt you have done this.

Children
No Data