views:

2049

answers:

4

Hi,

We're having a hard time figuring how these credentials objects work. In fact, they may not work how we expected them to work. Here's an explanation of the current issue.

We got 2 servers that needs to talk with each other through webservices. The first one (let's call it Server01) has a Windows Service running as the NetworkService account. The other one (Server02) has ReportingServices running with IIS 6.0. The Windows Service on Server01 is trying to use the Server02's ReportingServices' WebService to generate reports and send them by email.

So, here's what we tried so far.

Setting the credentials at runtime (This works perfectly fine):

rs.Credentials = new NetworkCredentials("user", "pass", "domain");

Now, if we could use a generic user all would be fine, however... we are not allowed to. So, we are trying to use the DefaultCredetials or DefaultNetworkCredentials and pass it to the RS Webservice:

`rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials

OR

`rs.Credentials = System.Net.CredentialCache.DefaultCredentials

Either way won't work. We're always getting 401 Unauthrorized from IIS. Now, what we know is that if we want to give access to a resource logged as NetworkService, we need to grant it to "DOMAIN\MachineName$" (http://msdn.microsoft.com/en-us/library/ms998320.aspx):

Granting Access to a Remote SQL Server

If you are accessing a database on another server in the same domain (or in a trusted domain), the Network Service account's network credentials are used to authenticate to the database. The Network Service account's credentials are of the form DomainName\AspNetServer$, where DomainName is the domain of the ASP.NET server and AspNetServer is your Web server name.

For example, if your ASP.NET application runs on a server named SVR1 in the domain CONTOSO, the SQL Server sees a database access request from CONTOSO\SVR1$.

We assumed that granting access the same way with IIS would work. However, it does not. Or at least, something is not set properly for it to authenticate correctly.

So, here are some questions:

  1. We've read about "Impersonating Users" somewhere, do we need to set this somewhere in the Windows Service ?

  2. Is it possible to grant access to the NetworkService built-in account to a remote IIS server ?

Thanks for reading!

A: 

Fred, did you ever find a solution?

Ok, so I wrote a comment that was more than 600 characters, and it didn't let me post it. Instead, it deleted the whole post and I have to write it again, which I won't do.I didn't find a solution. It seems to be a double hop problem between the service and IIS. Kerberos could be a solution.However, in the meantime, I'm using a user account that I need to update the password once every month until I can go back to fixing the real issue.
Fred
A: 

Here are some things you could check out: - set an SPN (Service Principal Name) for the reporting service; you can find good examples in google; - Allow delegation (ClientCredentials.Windows.AllowImpersonationLevel)

Alex
A: 

Is the problem that you're failing to authenticate to IIS, or failing to authenticate to SSRS? The DOMAIN\MachineName$ account may need to be granted permission in SSRS to run the report you're trying to automate.

SSRS usually does a pretty good job of getting IIS configured correctly, so you shouldn't need to mess with those settings. I double-checked my installation (which is SSRS 2005, things may have worked differently in SSRS 2000 and you didn't say which version you're running), and it's set to use Windows authentication and has impersonation enabled. That means IIS should basically just be authenticating your credentials (validating a correct username/password), not authorizing (determining whether that user has permission to run the report in question). IIS then passes the credentials on to SSRS, which has its own settings for determining what accounts have permission to view reports.

Also, you can automate sending reports on a scheduled basis directly in SSRS, so you may not need the Windows service at all if your scheduling is fairly basic (i.e., daily, weekly, etc.).

Joel C
+2  A: 

All details you need are included in this very old article,

http://msdn.microsoft.com/en-us/library/ms998351.aspx

Hope every ASP.NET developers have time to read through it.

Lex Li
Excellent link :D
omglolbah