I am developing asp.net web application using VS 2008. I am using Windows Authentication. I am trying to capture the current user name from
HttpContext.Current.User.Identity.Name. It works absolutely fine on development system. After deploying the code to Test Environment(Windows server 2008R2), we notice that the
HttpContext.Current.User.Identity.Name is null intermittently.
After adding the <deny users="?">, I am getting "401 - Unauthorized: Access is denied due to invalid credentials." intermittently
IIS
Anonymous Authentication - disabled
Windows Authentication – enabled
web.config
<authentication mode="Windows"/>
<authorization>
<deny users="?"/>
</authorization>
Any help would be appreciated.
Related
I have implemented a custom authentication (based on Forms authentication) using Microsoft sample (https://github.com/Microsoft/Reporting-Services/tree/master/CustomSecuritySample).
It is sample for SSRS/SQL Server 2017. In my case the reporting Services are installed on a web test server with a domain address accessible from intranet network. The database engine is installed on a second server. On the web server we also have IIS installed.
It looks that it works fine except accessing the Web Portal.
When accessing the Web portal (https://somedomain/reports) I am always redirected to the logon.aspx page even though I am already authenticated (User.Identity.IsAuthenticated returns true and User.Identity.Name returns correct user name on logon_aspx.page_load). The Forms authentication cookie is set. When I am authenticated I return from the Page_Load because otherwise I would end up with infinite redirection loop.
But I noticed that I can access the reports using the Report Server Service (i.e. https://somedomain/ReportServer):
I can click a report and it will be displayed.
Furthermore I can connect to the Reporting Services using SSMS and Forms authentication:
And I can access the Reporting Services properties. So I have full access.
I am connecting using a user which have all permissions, i.e Authorization.IsAdmin is always true (see Authorization class in the sample). This class implements IAuthorizationExtension.
But I noticed that when accessing the web portal no Authorization.CheckAccess method is invoked at all! So this migt be a clue. Only methods from AuthenticationExtension class are invoked. Here is my custom logs from this class:
Invoked SetConfiguration.
Invoked GetUserInfo.
GetUserInfo. Setting user identity. Authenticated: 'True', type: 'Forms', user name:
Invoked SetConfiguration.
Invoked GetUserInfo 2.
GetUserInfo. Setting user identity. Authenticated: 'True', type: 'Forms', user name:
Invoked SetConfiguration.
Invoked GetUserInfo.
GetUserInfo. Setting user identity. Authenticated: 'True', type: 'Forms', user name:
I have turned on extended logging for the Reporting Services (also including HTTP) but there is no error.
I also have local (developer) implementation of this sample on my local machine and it works fine. I can access the web portal (although I have tested it accessing it from local).
So this is happening only on the test server. And this is happening for http and https (no matter which protocol is used).
I also compared logs from the local version to the test version but I did not found anything interesting.
So /reports requests is redirected to the logon.aspx even though forms auth cookie is set:
If I clear cookies I get few more requests until the cookie is set but the last request to /reports should be successful (as it is on the local env) but in my case it redirects back to the logon.aspx.
I have spent already two days troubleshooting this issue (trying various things) but with no luck.
Could anybody help me with this?
P.S. Sorry for my English.
There was a similar situation as you described, although before that everything worked on ssrs 2017! Launched last updated 9/12/2018, version 14.0.600.892, and lo and behold, it works!! I advise you to try to update SSRS 2017 to the latest version.
I had the same problem, the solution is in the reporting services configuration manager to change the web Service URL and the Report Manager URL, these should not be the same and the url that you must access must be the one that you configure as Report manager URL, sorry for my English
I have resolved the issue. I just reinstalled the SSRS and this helped. So it looks that my installation was corrupted somehow.
I am able to get into SharePoint site using browser but not able to connect it using SSIS ODATA Connector. I have admin rights in that site. We have multiple imports successfully running using same SharePoint Server right now. Using SSDT2012. I tried another site successfully to confirm I don't have issue with SSDT. Any idea what I am missing.
Error msg:
TITLE: OData Connection Manager Editor
Test connection failed
ADDITIONAL INFORMATION:
The remote server returned an error: (401) Unauthorized. (System)
The logon attempt failed (System)
BUTTONS:
OK
What is the Service Document Location URL, you are giving in your case? Here is mine which works well.
Are you using basic authentication or Windows authentication?
If the former, double and triple-check that your userid and password are correct, and that the credentials have the proper access.
If the latter, check to see what user the package is running as. Also, I've found that when using Windows Authentication, you have to go back and double check what the Basic Authentication settings are, and zero them out before going back to Windows Authentication. It sounds crazy, but sometimes it works.
am getting the following error when attempting to run an MVC website in VS2013 and SQl Server 2014 using the ReportViewer control and accessing a report from the report server:
RSExecutionConnection MissingEndpointException: The attempt to connect to the report server failed. Check your connection information and that the report server is a compatible version.
I am using the correct report server url foun in the Reporting Services configuration manager. When I attempt to run the report in the SSRS project, the system prompts me for a user name and password. I enter the computer admin user/password. The report then runs. By the way, the reportviewer control uses the same user/password.
I am also able to access both the report server and reports urls in a browser with the same prompt for user//password.
I tried fiddling around with the report server role settings and under folder settings, this user has all privileges checked (browser, content manager, my reports, publisher, report builder).
Also as a side issue, I cannot see site settings even if I invoke the browser as an administrator.
I also looked in the SSRS Configuration manager. The service account is "Local System". The same admin user is listed in "Execution Account".
When running the website, I see no error entries in the SSRS log.
Please help, I have been looking into this for 2 days.
I think these solutions can help
Change from Local System to Network Service in Service Account of Reporting Services Configuration Manager
Update the web.config of ReportServer for these settings as below
<authentication mode="Windows" />
<identity impersonate="true" />
I am working on setting up my report server to use a web service as an XML datasource. I seem to be having authentication issues between the web service and the report with I choose to use Integrated security. Here's what I have:
1) I have a website w/ an exposed service. This website is configured to run ONLY on Integrated Security. This means that we have all other modes turned off AND Enabled anonymous access turned off under directory security.
2) Within the Web.config of the website, I have the authentication mode set to Windows.
3) I have the report datasource set to being an XML data source. I have the correct URL to the service and have it set to Windows Integrated Security. Since I am making a hop from the Browser to the Reporting Server to the Web Service, I wonder if I am having an issue w/ Kerberos, but I am not sure.
When I try to access the service, I get a 401 error.
Here are the IIS logs that I am generating:
2011-01-07 14:52:12 W3SVC IP_ADDY POST /URL.asmx - 80 - IP_ADDY - 401 1 0
2011-01-07 14:52:12 W3SVC IP_ADDY POST /URL.asmx - 80 - IP_ADDY - 401 1 5
Has anyone worked out this issue before? Thanks!
It does sound like you are experiencing the "double hop" issue. Is it possible to create an account on your web service that the reporting server uses explicitly instead of passing through the users credentials?
There's a simpler solution if you dont want to muck around with Kerberos... although the user experience is less desirable.
On the Data Source...If you check the "Credentials supplied by the user running the report" and the "Use as Windows credentials when connecting to the data source" then the user will be promoted to log in when they run the report. Since the credentials are being supplied to the SSRS server it's only a single hop from SSRS to the webservice... thus avoiding the double-hop NTLM authentication problem.
It's less user-friendly, though, since you have to log in to run the report.
I have a website that works correctly under IIS 6.0: It authenticates users with windows credentials, and then when talking to the service that hits the DB, it passes the credentials.
In IIS 7.0, the same config settings do not pass the credentials, and the DB gets hit with NT AUTHORITY\ANONYMOUS.
Is there something I'm missing? I've turned ANONYMOUS access off in my IIS 7.0 website, but I can't get the thing to work.
These are the settings that I'm using on both IIS 6.0 and 7.0:
<authentication mode="Windows">
<identity impersonate="true">
What changed from 6.0 to 7.0?
There has been changes between IIS7 and IIS6.0. I found for you one blog post that might actually help you (click here to see it).
Are you running your application in Integrated Mode or in Classic Mode? From what I saw, putting the Impersonate attribute at true should display you a 500 error with the following error message:
Internal Server Error. This is HTTP
Error 500.19: The requested page
cannot be accessed because the related
configuration data for the page is
invalid.
Here is the workaround that is proposed:
Workaround:
1) If your application does not rely
on impersonating the requesting user
in the BeginRequest and
AuthenticateRequest stages (the only
stages where impersonation is not
possible in Integrated mode), ignore
this error by adding the following to
your application’s web.config:
<validation validateIntegratedModeConfiguration="false"
/>
2) If your application does rely on
impersonation in BeginRequest and
AuthenticateRequest, or you are not
sure, move to classic mode.
I hoped that was useful to understand how IIS 7.0 now works.
Is your IIS server set up to be trusted for delegation by the SQLServer? I've run into this before with WebDAV where we've had to have the server running IIS trusted by the file server to authenticate on the file server's behalf.
Interesting... I have the opposite problem - Not being able to get the authentication to be passed from the client browser, through the webserver and onto the database within a large corporate network over firewalls.
I also feel that "end to end user" authentication to the database is a bad idea and a potential security risk. There is nothing to stop the end user from loading up SQL Query and connecting directly to your database, so you'd better have your schema locked down!
#Esteban - Clarified my not very useful in helping you answer.
Typically if you are doing double hop authentication like this, Kerberos is typically involved unless the first authentication is Basic.
I would check the authentication on the IIS 6 servers and make sure that it's the same on IIS 7.
If the IIS 6 box is set to Windows Integrated, then you need to verify the kerberos settings - SPNs, Delegation etc.