My company just finish set up a reporting services server 2017.
The service run under a domain name.
At the same server, an IIS has been setup to run a web application in ASP.NET which will server the report from a report viewer. The IIS is currently running with default App Pool.
GOAL : We want client to be able to access the report from the web application without having to fill in the username and password from anywhere be it on intranet or internet.
Before this, we have ssrs 2008 with similar setup but for authentication we go with anonymous authentication, which is what we want, they can view report from anywhere.
But from microsoft site, they stated that authentication isn't supported anymore in the latest version, and we have tried doing it which results in error 401: Unauthorized.
Currently, I'm trying to do a kerberos authentication,
Things that I have done :
SPN for reporting services account.
Delegation for reporting services account.
Web application web.config I've added authentication mode="Windows" identity impersonate="true"
On IIS, I've enabled windows authentication and impersonate.
But when I try to request a report from the web application, I still got the prompt for username and password, when I fill in my domain and password, I still got the same error 401: Unauthorized.
Am I doing something wrong? Is Kerberos really suitable for my GOAL?
Thanks in advance.
EDIT : Sorry, If I am posting in the wrong section. I don't know where is the correct section for this question.
When you are planning to deploy the reporting service on the internet its batter to use the custom authentication instead of the windows authentication. Creating a custom authentication extension requires custom code and expertise in ASP.NET security.
If you do not want to code a custom authentication extension, you can use Microsoft Active Directory groups and accounts, but you should greatly reduce the scope of a report server deployment. The following guidelines describe how to support this scenario:
Create a low-privileged domain user account with read-only permissions. The account must have access to the computer hosting the report server. Provide a custom Web form so that users can log on using the low-privileged domain account.
Create role assignments that map the user account to specific items in the report server folder hierarchy. You can limit access to read-only operations by choosing as the role assignment the Browser predefined role.
Configure reports to use stored credentials to get data for the report. This approach is useful if you want to query the external data source using an account that is different from the account that allows access to the report server.
you could refer to the below links for more detail:
https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2005/bb283249(v=sql.90)?redirectedfrom=MSDN#configuring-authentication-for-extranet-and-internet-access
https://learn.microsoft.com/en-us/sql/reporting-services/security/authentication-with-the-report-server?view=sql-server-ver15
https://forums.asp.net/t/2095478.aspx?401+Unauthorized+SSRS+authentication+from+NET+IIS
https://forums.asp.net/t/1273411.aspx?Setting+up+Reporting+Services+with+IIS+Access+Denied+Error
Related
I'm currently experiencing an issue with some users of an ASP.NET 4.8 Web API application hosted on Windows Server 2012 and IIS. The following properties are not returning that user's correct user name, and instead returning the name of a service account used for this server:
HttpContext.Current.User.Identity.Name
HttpContext.Current.Request.LogonUserIdentity.Name
I have no idea how to begin troubleshooting this - myself and most other users do not experience this issue, but for a handful of users the above does not return the correct username, returning the username of a service account used to remotely connect to the server in question. Forcing a login via a browser private window does rectify the issue, and the application correctly returns the expected username for each of the above properties.
What could be a cause for Windows Authentication not returning the correct user name and what is the best way to troubleshoot an issue like this?
edit: I was able to resolve the issue, see my answer below
After some additional research and troubleshooting, I determined that the users experiencing the issue described above had the service account in question stored in the Windows Credential Manager:
Removing the service account in question allowed them to be authenticated with the Intranet site with their normal Windows domain\username. As #pcalkins suggested, at some point the affected users had used these credentials on their machine, and Chrome, Edge, IE were using that saved credential when authenticating with the Intranet site.
Please check the following steps:
Make sure that windows authentication is enable and Anonymous Authentication is disable for the website.
Enable integrated security in Interner Explorer (Options/Advanced and checkin the "Enable Integrated Windows Authentication" option).
Add your website to Local Intranet zone and select at least "Automatic logon only in Intranet Zone" option under Options/Security Settings/Local intranet/Custom level).
Aake sure the user and application server are in the same domain.
I have deployed some reports and my users wish to do away with the logon prompt when getting to the reports manager homepage.
I have an account which is local to the server and I want to run all of the SSRS site under the context of that account. This account is a "browser" in the reports site.
Prior to 2008, when SSRS site was still listed in IIS you could disable anonymous authentication and provide an account. All requests to the reports site would go in under that account which was configured with readonly access. It worked quite well this way. The only downside was that it made publishing new reports or doing updates a bit more difficult.
How do I accomplish this same thing using reporting services configuration tool? The service account and the execution account don't provide this functionality when I configured them.
Individually setting up users for access to the reports site is a maintenance sinkhole and my server is on someone else's domain so I don't have access to info like usernames and being able to create groups.
Also, I tried the "anonymous access for 2012 reporting services" steps and while this takes care of the logon prompt issue for me it also makes it to where users can delete data sources and reports entirely.
If you are using Windows authentication then you will need two accounts on the local server to satisfy your needs. One would be a "ReportUser" account and one would be a "ReportAdmin" account.
If you can provision or use two existing windows accounts for those roles then use SSRS manager to set the "ReportUser" as a browser user and "ReportAdmin" as an admin user in SSRS manager. Always deploy using the "ReportAdmin" user. The "ReportAdmin" could be the admin account for that box. You could deploy with that account.
Since you did not link the article you used to configure anon access I have no idea how your "ReportUser" is connecting.
This particular customer wanted no login prompts at all and agreed to pay support costs for re-deploying any reports which their workers may delete by accident.
To comply with their request I used the steps outlined in the "Anonymous access for 2012 reporting services" article referenced above.
Generally I would set up two accounts in the exact manner as Irb described. This is actually the first time that someone has not wanted that setup 0.o
Short version:
For IIS 7.5 web applications with Windows Authentication does the end
user need to have Read file access?
Long version:
I have an intranet ASP.NET web app that uses windows authentication. It's installed at dozens of different companies and normally the authentication works fine: users navigate to the site e.g. http://appserver/MyApp, the app recognizes who they're logged in as and displays pages accordingly. I just installed it at a new client and encountered a problem:
When connecting e.g. to http://appserver/MyApp I'm prompted for windows credentials but after entering them I'm repeatedly prompted. After several re-entering credentials I'm shown a 401 error page saying "401 - Unauthorized: Access is denied due to invalid credentials.". So not only is it not passing through my identity but even when entering the username & password it's still denying access.
Giving Read & Execute permissions to the end users of the app solves this problem, but I don't think this should be necessary at all.
In the windows Application Event Log there's a message "File authorization failed for the request" along with Thread account name: NT AUTHORITY\NETWORK SERVICE and User: [the correct workstation users's domain account]. This suggests that the file access is being performed with the User's identity, not the AppPool identity of Network Service. Sure enough if I grant the end user Read & Execute permission (I didn't try Read only) to the application's directory then everything works correctly: when the user browses to the site they're authenticated automatically, not prompted, and the web site correctly recognizes their identity! Therefore my workaround solution is to give Read & Execute permission to Everybody on the application directory...but this is not an ideal solution.
This seems very strange. I've never needed to do this before in IIS 7.5, so far as I recall, and definitely never needed to in IIS 6 or IIS 7. Is this a new IIS7.5 thing? The documentation says that Impersonation is turned off by default. I added a element to the web.config to be sure, removed file permissions other than Network Service, but the problem remained.
Any thoughts? Is it normal for Windows Authenticated sites on IIS 7.5 for end users to need file permissions on the web server files?
Some relevant details:
Network Service
has Full Control file permissions to the app folder.
When connecting from the server itself I was prompted for credentials
but after entering them i'm authenticated and the application works
correctly including displaying my windows login and connecting and
retrieving data from the db. I later determined that it was prompting
for credentials because http://localhost was in the trusted sites
and therefore not recognised as the Intranet Zone and thus not
passing identity through. I also determined that it was working as
this user identity because it's an admin user who has file
permissions.
The web server is running Windows Server 2008 R2 / IIS
7.5. It didn't have IIS on it until I installed it. I installed the default features as well as Windows Authentication, ASP.NET, and
possibly a couple of other items. A separate WCF app I installed that
uses IIS, anonymous authentication & .net 2.0 is working fine on
that web server.
The app install process is a manual copy of files,
creation of IIS App Pools & web apps, updating connection strings,
etc.
I checked the IE security settings. It was recognizing the
server as in the Intranet zone and had the option 'Automatic logon
only in Intranet zone' selected. Also on Advanced Settings the
'Enable Integrated Windows Authentication' option was checked.
After
installing IIS I ran aspnet_regiis -i for .net 2.0 and
aspnet_regiis -iru for .net 4.0.
Anonymous authentication is
disabled for my app and Windows Authentication enabled.
The app is
running on ASP.NET v4 but there's another app I installed
experiencing the same issue running ASP.NET v2.
The app is running
with Identity = Network Service and in 32-bit mode.
Database
connection string includes Trusted Connection=True and database
permissions are granted to the web server account [domain]\[server]$
e.g. DGM\MyServer$.
In IIS > Authentication > Windows Authentication > Providers the list was Negotiate first then NTLM. I tried reordering so NTLM is first.
In the Windows Security Event Log there
were a series of Microsoft Windows security auditing events: Logon
and Logoff. They indicated that the Logon was successful and was
displaying the User Id of the workstation user. This are from when
I'm connecting from another workstation and receive a 401
Unauthorized after several attempts.
I see someone has had this problem reported here but with no solution. Originally I posted in the ASP and then the IIS forums with no answers so far.
Update:
This msdn article says
When Windows authentication is enabled but impersonation is disabled, ASP.NET performs file access checks in the file authorization module using the credentials that are sent from the browser (my emphasis). Impersonation does not need to be enabled, because the FileAuthorizationModule module ensures that the requesting user is allowed read access or write access to the resource, depending on the request verb (for example, GET or POST) before executing the request. This behavior applies to any requests that enter managed code. In earlier versions of ASP.NET, accessing files based on URIs such as "Default.aspx" triggered the access check. In ASP.NET MVC applications, where access to resources is typically performed using extensionless URLs, this check typically does not apply, because there is not a physical file to check. In that case, the FileAuthorizationModule class falls back to checking access-control lists (ACLs) for the folder.
This does suggest that the end user needs permissions to the files (in the case of .aspx) or the folder (for MVC) ... although still this seems slightly tucked away and non-definitive. This article about App Pools says they're used as the identity for securing resources, which contradicts the idea of needing to grant privileges to end users. Unless the rules are different for App Pools and NETWORK SERVICE, which could be the case but would be surprising.
Are authenticated users allowed to the app folder?
We were also fighting with this issue, and started setting up security groups so we could give our users file level permissions. Then one of our server admins stumbled across a couple of new properties that allow the app to authenticate to the file system under set credentials, and resolved the need for the users to have access. Here is what he came up with…
There are two IIS settings that control this:
Physical Path Credentials Physical Path Credentials Logon type
By default, Physical Path Credentials is set to Application User
(Pass-through authentication). This means that IIS doesn’t do any
impersonation when handling Windows Authentication requests. This can,
however, be set to a specific user (though not, unfortunately, the
application pool identity, which would be ideal). Physical Path
Credentials Logon Type is set by default to Clear-Text. For my testing
I set this to Interactive (though this may not be the correct value).
Possible values are Clear-Text, Batch, Interactive, and Network.
To set this up I did the following:
Created a local account (IIS-AccessUser)
Granted IIS-AccessUser read and execute access to the /home directory of the site.
Added IIS-AccessUser to IIS_IUSRS group (necessary for accessing .NET temporary files)
Set IIS-AccessUser as the Physical Path Credentials
Set Physical Path Credentials Logon Type to Interactive
Doing the above allowed me to log in to the application directly,
without having to allow Authenticated Users, or me having to be a
member of any of the groups in the /home folder. It also still
preserved .NET Authorization roles, so I still could not access parts
of the site that I was not allowed to.
The short answer is NO. You are not required to grant file access permissions when using Windows Authentication in IIS 7.0 and IIS 7.5.
We were only able to discover this because our server admin smelled the security and management issues that arise from taking the route of granting file level access to users and groups.
For anyone dealing with this issue or if you are setting up a new IIS7/IIS7.5 server and/or moving from IIS 6, here is an article that gives you all of the Windows Authentication options and configurations that need to be modified to avoid granting file level access to individuals or groups.
Please read the two comments in at the end of the POST for some valid critiques of the methods used in this article.
http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk
In addition to the information in the article, please be aware that IIS 7.5 is not using the web configuration tags for system.web (at least not in my MVC 4 application).
It is looking in the system.webserver tags for authorization configuration (where you will need to list the windows domain\groups a user needs to be in to access your application).
-- DSB
I have implemented web service with Basic Authentication with .Net 4. To implement basic authentication I have implemented HttpModule. When I call my web service via Internet Explorer, it prompts for Username password, I enter valid username/password and it works perfectly fine.
However when I deploy me web service on Dev Environment and call my service in internet explorer. That gives me user prompt; I enter valid username/password but it keeps prompting me username/password, eventually after three tries I get Error message 401.2 - access is denied.
My Authentication settings are:
Anonymous Access Enabled
Basic Authentication Disabled
Windows Authentication Disabled
In my HttpModule every time User is authenticated, I log if authentication was successful. And I can see in log file, all three times authentication was successful. But it still error out. :(
By the way If I run web services in Integrated mode, it works fine. Unfortunately my requirement is to run web services in Classic mode.
Environment Details:
OS: Windows Server 2008 R2,
IIS: 7.5 Classic mode
I am stuck with this from last 4 days. Please help!
Call me crazy, but wouldn't you have to have Basic Authentication Enabled to be authenticating anyone successfully?
I'm guessing that you have identity impersonation turned on and anonymous turned on which is causing your ASP.Net application to execute as the "IUSER_" account. The "IUSER_" account does not have access to a specific resource you are trying to access (could be API call, file, bla, bla).
If you do have identity impersonation turned off and you have anonymous turned on then your ASP.Net code should be running as the application pool account. Which means that account does not have access to a specific resource you are trying to access (bla, bla, bla).
Here is an old skool MSDN article that discusses IIS and ASP.Net security. Like I mentioned it is old, but the concepts still ring true.
I'm trying to set up SSRS 2008 on my desktop machine for development purposes.
The following is working fine:
Report deployment on local server
Previewing the report in BIDS
Access to htpp://localhost/Reports panel
But when I point the ASP.NET Reportviewer to the Report URL, I get the following error:
The permissions granted to user 'NT-AUTHORITY\NETWORKSERVICE' are insufficient for performing this operation. (rsAccessDenied)
How can I get around this error? Is there any dialog where I can grant SSRS access rights to certain forms authentication roles? I've googled quite a bit on this, but what I have found so far was either outdated or quite confusing.
Edit: Several users of my web app are going to have access to the same database, so I need the UserID build-in field (User!UserID) to reflect the user's Forms authentication ID. I guess the only way to achieve this is making SSRS work with forms auth?
You web application is running as Network Service so that is the user you are trying to connect to Report Server as. You have several options. One, you can grant Network Service permission to execute the report you are trying to run. Two you can have your web application impersonate a windows user and give the correct users permission to the report. Three you can impersonate impersonate a different user when connecting to RS. I believe to do the last one you will have to write some extension code for the viewer to tell it how to impersonate before connecting, but for the other two there would be no code change.
You could also look into using Report Server in Forms auth mode if your web site is not an internal site, but this is more complicated.
EDIT for 2nd Question:
Yes, you will need each user to be unique when they access RS so you will need to use Forms Auth or windows auth or write your own custom authentication extension.