sql server reporting services: I have a Reporting Server setup in a lab and one setup on my development
machine. Both use to run Reporting Services 2000. We recently upgraded to
Reporting Services 2005. I am having a problem on both machines impersonating
the logged-in user in my custom assembly that is called from the report.

Details
--------

In many of my reports, I call a custom module that filters data based on the
logged-in user. This worked well when running under 2000. Now, after the
upgrade, I don't seem to be impersonating the user correctly.

In my custom code, I call:

WindowsIdentity winUser = WindowsIndentity.GetCurrent();

This used to get me the logged in user. Now, it always gets me
MACHINENAME\ASPNET.

The Reports web application is configured for Window Integrated
Authentication (and no other methods). The ReportServer\web.config file
specifies Windows Authentication and Impersonate = "true".

I don't know if there is a difference in the new platform or there is a
configuration problem after the upgrade that I haven't been able to track
down. Any help would be GREATLY appreciated. I've spent several days on this
already and can't find any reason that I am 'ASPNET' when I get to my custom
code.

Hello Bob,

Have you changed the correct web.config file?

Also, did you follow this article to deploy the custom assembly correctly?

http://msdn2.microsoft.com/en-us/library/ms155034.aspx

Sincerely,

Wei Lu
Microsoft Online Community Support

==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Wie,

Thanks for your reply.

Yes. I think I checked the correct web.config file. I checked both the
ReportServer\web.config and the ReportManager\web.config. Incidentially, I
get the same issue wether I hit the Report Manager or the Report Service
directly.

As for code deployment, I think it is correct. I can debug into my
custom code. So I'm pretty sure it's in the right place. Also, I had it
running fine under 2000.

I did have to add a bunch of permissions to a permission set and assert
them. That was new. (I didn't have them under 2000 and was running.) I
stepped through the code and deteremined what wasn't working and added
permissions to the set until I was running. I don't know if this could be a
manifestation of a missing permission. But I don't know how to run down which
one. The permissions I am asserting are as follows:

- UnmanagedCode (attribute on the method)
- ControlPrincipal (attribute on the method)
- SqlClientPermission (I am checking for region-specific rights in the
database)
- FileIOPermission (I am reading from the web.config file)
- PrincipalPermission (I think this is the one that should allow me to
impersonate?)
- DirectoryServicesPermission (I need to lookup the logged-in user
against the AD to check for regions, etc)

I do the actual AD lookup and database access in another assembly called
by this one. I don't think I need to also assert in that assembly, right? It
should pass down the call stack. Also, when I do the
WindowsIdentity.GetCurrent in this (parent) assembly, it still gives me
ASPNET, even before I call the other assembly. So I just don't think it is
working correctly at all.

Sorry for the long-winded response. I appreciate any help you can give
and want to acurately describe what I've done so far.

I also ran down the "is this a delegation issue" road, even though that
should be impossible (it's all running on the same machine). No luck there.

I'm almost sure it's either a permission issue or a configuration issue.
But I am beating myself up and can't find evidence of either.

Thanks again,

Jason


[quoted text, click to view]