Before I go into the issue let me first explain the architecture I'm working with.
DB-Server - SQL Server 2019, Windows 2019
SSRS-Server - SSRS 2019, Windows 2019
Web-Server - IIS v10, Windows 2019
All servers are on the same domain.
The application rendering the report is written in ASP.NET using the rsweb:ReportViewer control.
Requirement: I need the ability to access reports from the ASP.NET application using a machine level account.
Current Error: The request failed with HTTP status 401: Unauthorized.
What I've done so far...
Added machine account to SSRS. I've given it permissions at all levels: site settings, folders, reports. Once I get it working I'll dumb down the rights but for now I need it working. This machine level account is the Web-Server. My assumption is any access from the Web-Server to the SSRS-Server will be granted.
Changed the application pool's identity to LocalSystem. Yes this may violate least privilege but again I'm viewing this as a POC at this point. I've also tried NetworkService.
Web.config. There may be something I need to do here to make this work. I've tried using identity impersonate but I had no success but it's possible I didn't use it in combination with another setting. When I have the authentication mode set to Windows the Windows Identity used by ASP.NET is NT AUTHORITY\IUSR. Removing this line gives me NT AUTHORITY\NETWORK SERVICE as the Windows Identity. I would think the NETWORK SERVICE account would be granted; however, this still results in a 401 error.
Modified the "rsreportserver.config" file (C:\Program Files\Microsoft SQL Server Reporting Services\SSRS\ReportServer\rsreportserver.config)
ASP.NET ReportViewer setup:
ReportViewer1.ServerReport.ReportPath = rc.report_ssrs_path;
ReportViewer1.ServerReport.ReportServerUrl = new System.Uri(rc.report_ssrs_url);
SqlConnectionStringBuilder conString = new Database().conBuilder;
List<ReportParameter> parameters = new List<ReportParameter>();
parameters.Add(new ReportParameter("ConString", conString.ConnectionString));
ReportViewer1.ServerReport.SetParameters(parameters);
DataSourceCredentials dsc = new DataSourceCredentials();
dsc.Name = ReportViewer1.ServerReport.GetDataSources()[0].Name;
dsc.UserId = conString.UserID;
dsc.Password = conString.Password;
ReportViewer1.ServerReport.SetDataSourceCredentials(new DataSourceCredentials[] {
dsc });
ReportViewer1.ShowCredentialPrompts = false;
ReportViewer1.ServerReport.Refresh();
If anyone could help it would be greatly appreciated. I've scoured the internet for a solution to this with no luck. It seems like it should be possible and a lot of the things I've read make it sound like it is. I'm sure I'm just missing something minor.
Related
I'm tried to pull some SharePoint 2013 list data I created which works fine when running locally on my machine and when run locally one the server. I'm user the same credentials when running both locally and locally on the server. The issue is when I publish and navigate to my ASP.NET app on the server I get the "The remote server returned an error: (401) Unauthorized." Error...
I've looked at a bunch of the posts on stackoverflow and some other articles on the web
This points out that the context seems to be using IUSR:
http://blogs.msdn.com/b/sridhara/archive/2014/02/06/sharepoint-2013-csom-call-from-web-part-fails-with-401-for-all-users.aspx
This one mentions to try setting the default network credentials:
https://sharepoint.stackexchange.com/questions/10364/http-401-unauthorized-using-the-managed-client-object-model
I've tried using the fixes mentioned in the article as well as trying to force the context to use DefaultNetworkCredentials but no luck. I would like for the app to use the credentials of the logged in user and not the machine...
Here is the code I'm using:
SP.ClientContext context = new SP.ClientContext("MySPDevInstance");
context.Credentials = CredentialCache.DefaultNetworkCredentials;
Entity entity = context.Web.GetEntity(collectionNamespace, collectionName);
LobSystem lobSystem = entity.GetLobSystem();
LobSystemInstanceCollection lobSystemInstanceCollection = lobSystem.GetLobSystemInstances();
context.Load(lobSystemInstanceCollection);
context.ExecuteQuery();
LobSystemInstance lobSystemInstance = lobSystemInstanceCollection[0];
FilterCollection filterCollection = entity.GetFilters(filter);
filterCollection.SetFilterValue("LimitFilter", 0, 1000);
EntityInstanceCollection items = entity.FindFiltered(filterCollection, filter, lobSystemInstance);
The server is running IIS 6.0
Any advice would be much appreciated!
Thank you
I presume your ASP.NET web site is using Windows Integrated (NTLM) authentication. A user authenticated this way cannot authenticate to a second location from the server side (the web server.) You are experiencing what is known as the "double-hop" (1) limitation of NTLM. You must use a dedicated account on the server side, or if you really do want to use the logged-in user's identity, you must use an authentication scheme that permits delegation, such as Kerberos.
If you really need the user's identity to access SharePoint data and you cannot change the authentication scheme, then the best way to do this is to use the JavaScript CSOM. This means the user is authenticating directly to the SharePoint server (a single hop, not double) and your ASP.NET site serves the page containing this script to the user.
(1) http://blogs.msdn.com/b/knowledgecast/archive/2007/01/31/the-double-hop-problem.aspx
Use Default Credentials worked for me:
HttpWebRequest httpWebRequest = (HttpWebRequest)WebRequest.Create(url);
httpWebRequest.UseDefaultCredentials = true;
Setup the crendentials by code:
SP.ClientContext context = new SP.ClientContext("MySPDevInstance");
context.Credentials = new NetworkCredential("username", "password");
You should put this at the configuration file to change it without publishing or recompiling the application.
Just to add one more setting that I encountered. If the account is restricted to access only certain servers than add the client machine to that account as well. For example if a web application is hosted on Server A and trying to connect to SharePoint 2010 on Server B with account ABC then make sure that account has access to Server A in Active Directory. Normally the AD account doesn't have restrictions to connect to machines but in my case the account was restricted to only certain machines. I added my web application hosted server to the account and it worked.
I've an application that connects to Reporting Services in SQL Server 2008 R2.
The error is the following:
System.Net.WebException: The request failed with HTTP status 401: Unauthorized.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse
(SoapClientMessage message, WebResponse response, Stream responseStream,
Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke
(String methodName, Object[] parameters)
at Microsoft.SqlServer.ReportingServices2005.Execution.ReportExecutionService.LoadReport
(String Report, String HistoryID)
The application is running in production fine in 2 different customers, so it's not a codeing issue.
I'm trying to install it now on a customer's server, which is using AD. The SQL Server and the IIS is all in the same machine though, so I don't really care about AD.
It runs if I run IE as Administrator, but it doesn't work with other users. The ASP.NET app is connecting to SSRS using a user created in the local machine (called ReportingServicesUser), member of the ReportingServicesUser group.
Things I've tried:
Adding ReportingServicesUser to the Site Settings in the RS website (did the same for Network Service, IUSR, the Authenticated Users group, Local Service, etc)
Adding ReportingServicesUser to the folder permissions in the RS website (did the same for Network Service, IUSR, the Authenticated Users group, Local Service, etc)
Added permissions for that users to the databases (app database and RS related dbs)
Added NTFS permissions to the RS folders (I will double check though).
Connecting to the RS using http://localhost, http://computername and http://domain.com
For reference, the code is this (simplified version):
var service = new ReportExecutionService();
service.Credentials = new NetworkCredential("ReportingServicesUser", "password");
service.Url = "http://computername:90/ReportServer/ReportExecution2005.asmx";
service.ExecutionHeaderValue = new ExecutionHeader();
var execInfo = new ExecutionInfo();
execInfo = service.LoadReport("path-to-the-report", null);
===> Here it throws the exception
I've read a lot of posts and pages about this but I cannot get an answer that works for me.
OK, I've finally had to change the code to:
rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;
and it worked. Probably there's another solution but I couldn't find it out.
Are you sure you gave "ReportingServicesUser" browse permissions for the specific report in ssrs? The request never made it to the server it seems but I would check \Reporting Services\LogFiles just to be certain.
Also, Your "report user" user needs to be defined on the reporting server with the credentials you send.
I'm working on an ASP.NET webforms app that will serve as a simple intake form to create work items in TFS 2010.
The app works correctly when I run it locally in debug mode--the submission completes and the work item is created.
When I publish the form to our dev server, it yellow screens and throws the following error:
[SecurityException: TF50309: The
following account does not have
sufficient permissions to complete the
operation: DOMAINNAME\SERVERNAME$. The
following permissions are needed to
perform this operation: View
collection-level information.]
In my code, I'm attempting to access TFS using a service account, and from what I can tell the service account is being used correctly when I run in debug mode.
Here's what my C# looks like:
string tfsServerUrl = "http://servername:8080/tfs";
string tfsProject = "Web Team Projects";
NetworkCredential tfsCredential = new NetworkCredential("ServiceAccountName", "password", "DOMAIN");
TeamFoundationServer tfs = new TeamFoundationServer(tfsServerUrl, tfsCredential);
tfs.Authenticate();
WorkItemStore workItemStore = new WorkItemStore(tfsServerUrl);
If I set a breakpoint at the tfs.Authenticate() line, the server object shows the service account name as the current user and IsAuthenticated = true.
The line in the exception that mentions SERVERNAME$ is what's stumping me. It's seems like IIS is deciding to try to access TFS with the app pool identity instead of the credentials that I'm explicitly supplying.
Our dev server is a Server 2008 box running IIS 7.
Any suggestions?
The TeamFoundationServer class is obselete. Have you tried using the TfsTeamProjectCollection (TFS 2008) or TfsConfigurationServer (2010) class instead?
string tfsServerUrl = "http://servername:8080/tfs";
System.Net.NetworkCredential tfsCredential = new System.Net.NetworkCredential("ServiceAccountName", "password", "DOMAIN");
TfsConfigurationServer tfs = new TfsConfigurationServer(new Uri(tfsServerUrl), tfsCredential);
tfs.Authenticate(); // You should be able to omit this
WorkItemStore workItemStore = (WorkItemStore)tfs.GetService(typeof(WorkItemStore));
I'm running IIS5.0 and I am trying to change the ASP.NET process account to my domain user account.
I have followed everything possible here.
When I browse the .svc file (this is a wcf service) I am getting this error:
Server Application Unavailable The
web application you are attempting to
access on this web server is currently
unavailable. Please hit the "Refresh"
button in your web browser to retry
your request.
Administrator Note: An error message
detailing the cause of this specific
request failure can be found in the
application event log of the web
server. Please review this log entry
to discover what caused this error to
occur.
Eventlog says:
aspnet_wp.exe could not be started.
The error code for the failure is
80070522. This error can be caused when the worker process account has
insufficient rights to read the .NET
Framework files. Please ensure that
the .NET Framework is correctly
installed and that the ACLs on the
installation directory allow access to
the configured account.
When I run the client, I get the following error:
The content type text/html;
charset=utf-8 of the response message
does not match the content type of the
binding (application/soap+xml;
charset=utf-8). If using a custom
encoder, be sure that the
IsContentTypeSupported method is
implemented properly. The first 872
bytes of the response were: '
From ASP.NET 2.0 onwards, the correct method to ensure that a user account has the correct rights to run as the worker process identity is to run this command:
aspnet_regiis -ga [account]
You need to run the aspnet_regiis command that matches the ASP.NET version you plan on running:
ASP.NET 2.0 -
%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -ga [account]
ASP.NET 4.0 -
%SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -ga [account]
If you put your Domain Account under IIS_WPG group, it should ideally work. If it doesn't work, there is a sure shot way of fixing it.
In IIS 6... step 1 is applicable... since you are on IIS 5, ignore step 1
Run it with Local System to begin with. If the applications runs, it means your IIS is configured well and you can proceed with the step 2.
Change the account to your domain account, and ensure that you have put the account in IIS_WPG as well. After that, run the tool called Process Monitor http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Browse the application now. If you still get the error, switch to the Process Monitor and stop capture [menu option].
Search for Access denied and fix it. Link
I have a Windows 2003 server running IIS 6 and have some scripts that do automated setup and creation of websites. They are not working on a new server I cam commissioning (they already work happily on 3 other W2K3 servers). The problem appear to boil down to WMI security on the IIS provider. The ASP code below represents the problem (although it is not the original code that causes the problem - this is a simplified demonstration of the problem).
Set wmiProvider = GetObject("winmgmts:\\.\root\MicrosoftIISv2")
If wmiProvider is Nothing Then
Response.Write "Failed to get WMI provider MicrosoftIISv2<br>"
End If
Response.Write "Querying for IISWebService...<br>"
Set colItems = wmiProvider.ExecQuery("Select * From IISWebServer",,0)
Response.Write "Error: " & Hex(Err.Number) & " (" & Err.Description & ")<br>"
If I run this in my browser, I get an access denied error reported after the ExecQuery call. I have set WMI access for the IUSR_ user from the Root branch all the way down. In fact, I can query for IP address information using the CIMV2 provider quite happily. If I put the IUSR user in the machine admins group it all works, but I don't really want to do that.
This must be a DCOM/WMI security problem, but I can't work out what else there is. Can anyone shed any light?
After reading G. Stoynev's comment asking if any events were logged in the Windows Logs, I checked the event logs on the server to which I'm attempting to access IIS remotely via WMI, and lo and behold I found an event with the following text:
Access to the root\WebAdministration namespace was denied because the namespace is marked with RequiresEncryption but the script or application attempted to connect to this namespace with an authentication level below Pkt_Privacy. Change the authentication level to Pkt_Privacy and run the script or application again.
See the code in this answer to the related SO question c# - "Access is denied" Exception with WMI.
Here's some example C# code that I added that seemed to resolve this issue for me:
ConnectionOptions options = new ConnectionOptions();
options.Authentication = AuthenticationLevel.PacketPrivacy;
ManagementScope managementScope = new ManagementScope(#"\\remote-server\root\WebAdministration", options);
// ...
If this is something that you intend to run as a tool for yourself or your admin (as opposed to the unwashed anonymous masses), here is a way I have used in the past (YMMV):
Set up a new directory in your website (e.g. /SiteCreate) and place your WMI scripts there
Configure a Windows user that has appropriate rights (probably admin in this case but you should use whatever is pertinent to your app)
Turn off the anonymous access to the directory you created in step 1 and then set the security to allow access only to the user you created in step 2 (turn on the authentication for that directory)
Now, when you navigate to that directory in your browser, you should get a login prompt. When you enter the username/password you created in step 2 your script will have the appropriate rights to perform your WMI requests.
Not a DCOM issue, more so a WMI security and encryption issue. Try changing the GetObject moniker to include impersonation and pktPrivacy, eg:
Set wmiProvider = GetObject("winmgmts:{impersonationLevel=impersonate;authenticationLevel=pktPrivacy}!\root\MicrosoftIISv2")
Refer to the follow MS article for more info:
http://msdn.microsoft.com/en-us/library/aa393618(v=vs.85).aspx