I am running Report Service Manager - Web portal for accessing the Reports. For Development and Testing purpose, Report service is running from my computer.
Whenever Testing Team tries to access the web from their end, report service is asking an Initial Authentication of my computer account. ( Windows Authentication ). How to skip this authentication mode ? This is an Internal Application, i want Report service to run on any computer without asking any authentications.
If you are all on the same domain, simply add "DomainName\All Users" with the appropriate role to the portal. The testers may also need to add your site as a trusted site in their browsers. "All Users" is exactly as it sounds - any user account on that domain will have the access you grant.
Alternatively, if you need to disable security entirely (bad idea), you'll have to configure a new security extension - it's relatively simple to do, especially with all the samples you can find online (google "SSRS custom authentication" or "SSRS anonymous authentication"), but if you've never done anything like this before, you may struggle if you run into any unexpected issues.
See here for one example on how to enable anonymous access:
http://blogs.msdn.com/b/jameswu/archive/2008/07/15/anonymous-access-in-sql-rs-2008.aspx
Related
I'm new to Federation Services and I'm trying to understand how ADFS works as a whole and I've started to get down into the details. I followed along with creating an app using OIDC to authenticate a user, however, within the tutorial, they specified using a "Server Application" when setting up an Application Group. This ended up not working for me so I tried setting up a "Native Application" application group for kicks and was able to successfully login.
The thing that threw me off is, I ended up hosting ADFS on a server outside of the domain in which I had my application running, so I'm confused as to how that is "native" in terms of ADFS.
I went looking for this answer within microsoft's documentation but I didn't find the information very clear.
Native Application:
"Sometimes called a public client, this is intended to be a client app that runs on a pc or device and with which the user interacts."
Server Application:
"A web application that runs on a server and is generally accessible to users via a browser. Because it is capable of maintaining its own client 'secret' or credential, it is sometimes called a confidential client."
This may seem simple to some, but I'm trying to really get a grip on what would be used when. To me it sounds like a native application is used when you're running the application natively on a pc in which the user is also using the same pc, and the server application is run remotely in which the user would not be using the same machine. Is it really that simple or am I misunderstanding?
A native application (in Microsoft speak) is something that is not browser based e.g. mobile. The code runs client side. It may use JavaScript in which case the secret key is publicly accessible. (The secret key is one of the OAuth parameters). You use ADAL / MSAL to access it.
A server application runs server side e.g a web API. The secret key is not publicly accessible. You use OWIN to access it.
These terms have no relevance to where ADFS is actually installed. Native applications typically are not domain joined.
I need to control who can log into the SQL server web portal.
I'm running SSRS 2016.
I tried going to Site Settings > Security and removing all users/groups listed and adding just my windows account as an admin, but other people can still login without any problems. I googled around but I can't seem to find anything. Most of the sites I go to tell me to do what I've already done.
I need to be able to lock it down to just a couple people that can log into the server, and only one account that can deploy the solution.
(We've been having problems with people creating their own RDL's uploading them and using them instead of using the solution which is in SVN).
Just change the security of all folders and all site settings to only allow YOUR user. That way even if they get on the site they will have no access to any folders.
Been trying to get SSRS reporting service set up for a while now, and been stuck on the issue with UAC.
After setting up the Reporting Service Configuration Manager settings, with service account using my PC's login account, Database using ReportServer$SQLEXPRESS, etc. when launching the server # 127.0.0.1/Reports it directs me to 127.0.0.1/Reports/Pages/Folder.aspx and then after login with my PC's login this is what I get on my browser -
"User 'OCTETHP\Support' does not have required permissions. Verify that sufficient permissions have been granted and Windows User Account Control (UAC) restrictions have been addressed."
And I have done my researches online, I turned off UAC, I am on the administrator account, and I also tried to run the browser with right click to run as administrator option on both chrome and IE. Still does not solve this problem. Could anyone help me out with this??
I am currently running on windows 8.1. Thanks so much!
It is likely the problem is with the account the reporting server is running under (OCTETHP\Support). You may need to add this user to the web user group (IIS_WPG depending on your OS version). If that doesn't work, you can set the user to be a local administrator and work the permissions back from there.
If you want to run the reporting services from another account you'd want to follow these steps:
Open IIS Manager
Under websites locate the SSRS website (/Reports in your case)
In basic properties check the App Pool the site is running under
Go to the App Pools section of IIS and open the advanced properties
Setup the user that the App Pool runs under
You'll need to make sure the user is assigned to the web user group, and has permissions to access the folder that the website points to.
We have an active directory domain (let's call it foodomain) and a domain user account (foodomain\fooAppPoolUser) used for the IIS application pool identity.
We want to run the app pool under this user account and not under Network Service or the new AppPoolIdentity as we have to access SQL server and have multiple applications on IIS (with own app pools) accessing different databases.
The problem is that I can't find a clear HOW-TO explaining, which user rights have to be set for this user account and how IIS has to be setup so that this will work.
First I got errors (unfortunately I can't remember which ones), then I added fooAppPoolUser to the local admin group (Administrators, I know, was only to test), then it worked. Now I removed the user again, restarted IIS and it still works.
So I'm confused a bit and would like to know, how the configuration/setup has to be to have it working.
Somwhere I read, that the account needs to have the "Impersonate a client after authentication" user right. That's the reason I added the account to the Admin group (the user rights assignment is blocked via group policy, but this can for sure be changed if really needed.
I hope I was clear enough what the question is and hope somebody has an answer.
It's frustrating that this information is so hard to find, since some security admins seem to enjoy the cruel and unusual punishment of changing default policy settings to thwart installing apps within IIS.
Here's what I believe you should do to enable an account to work as an ApplicationPool identity:
Run aspnet_regiis -ga DOMAIN\USER to add permissions to access the IIS Metabase. (Exactly what that means, who knows?) aspnet_regiis reference
Add the user to the IIS_IUSRS group. This may be done automatically depending on the IIS configuration setting processmodel.manualGroupMembership but easiest to add it yourself.
If security policy is using windows defaults that's about it. If the security policy is locked down you may need to enable specific user rights for the account. The ones you have by default for ApplicationPoolIdentities (which seems a good place to start but not necessarily all required):
Access this computer from the network
Adjust memory quotas for a process
Allow log on locally
Bypass traverse checking
Generate security audit details
Impersonate a client after authentication - (Often not available by default on locked-down environments)
Log on as a batch job - (Often not available by default on locked-down environments)
Log on as a service - (I'm not sure this is needed)
Replace a process level token
If you're using windows auth and Kerberos (provider=Negotiate) then depending on the URL and if kernel-mode auth is on you might need to set up an SPN. I suggest switching to NTLM if possible. Otherwise, see articles below about SPNs and find a friendly domain admin to add them for you.
Fun reading:
Default permissions and user rights for IIS 7.0, 7.5, 8.0. This is the best reference, see the user rights at the bottom.
User Rights (on Windows Server 2008, but still interesting and helpful as it's a long article you can CTRL+F to find IIS-related comments)
User Rights Assignment on Server 2008 R2+. You have to drill into each right to see what it mentions about IIS.
How To: Create a Service Account for an ASP.NET 2.0 Application - pity there's no more recent version of this article.
SPN Checklist for Kerberos on IIS7/7.5
How to use SPNs - applies to IIS6 or to 7/8 if Kernel-mode authentication is turned off.
The reason why you application worked AFTER removing Administrator rights is that your application was compiled to the Framework temp folder using the administrator rights - Your application worked after removing the administrator rights because the application was compiled. If you update your application and it requires recompilation, the app pool account will need trusts again.
First I got errors (unfortunately I can't remember which ones), then
I added fooAppPoolUser to the local admin group (Administrators, I
know, was only to test), then it worked. Now I removed the user again,
restarted IIS and it still works.
I found the following link answered a similar question I had: http://www.iis.net/learn/manage/configuring-security/application-pool-identities
Basically, ApplicationPoolIdentity is a virtual user account that still behaves like NETWORK SERVICE, but without some of the down-sides; each app pool has it's very own ApplicationPoolIdenity account created with it.
More detailed information can also be found that is also specific to IIS 7.5 Application Pool Identities.
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.