We are getting started to use TFS in our company, but I am having some issue with our IT-department.
The TFSReports account is a service account, and thus the IT guy will not allow Local logon, because it is service account. Not sure if he is right, but what other options do I have?
There's no way around that -- it's listed as a requirement because it's a requirement.
You can consider not setting up reporting services; a lot of the newer features in the past 3-5 years aren't stored in the data warehouse or analysis cubes (builds and releases, as a major example) because the push has been to make the reporting capabilities in TFS itself as good or better than what's stored reporting services.
You can find documentation here: Service accounts and dependencies in Team Foundation Server
TFSReports, which can be a local account, a domain account, or Local Service in a workgroup.
Required Permission and Group Membership: Allow log on locally on the application-tier server and on the server that is running SQL Server Reporting Services
TFSWareHouseDataReader on the report server
Related
Let me first describe the actual situation: We want to build a new SQL Server enviroment based on SQL Server 2016. AS you may know, in SQL Server 2016 the mobile reports from Datazen are integrated. So far so good. The Problem: In our current Enviroment, there is one internal Datazen Server and one external server. The external Datazen server exists only to read data from the internal one. So there is no direct Data Access (to Data Sources), the administration part is disabled and only the needed Services (to read from internal server) are installed. We want to build that same archtiecture in SQL Server 2016 Reporting Services. Do you know any way to do that?
I thought the best solution was a second SQL Server with Reporting Services but only read access on the other SQL Server (didn't found any setting like this).
We don't want the internal server to be accessible over the web beacause of security.
interesting question, but not sure i understand correctly ;) what do you mean with "the external datazen Server exists only to read data from the internal one"? How does this configuration look like? Do you have a sale out Deployment where the external Servers hosts "Web Application" and "Share Cache Instance" while internal Server hosts "Data Acquisition" and the same roles as the external Server?
In SSRS you can also Scale out web frontends, but all Servers will act as "data acquisition server" to stay in datazen terminology. Do you have security concerns with this topology? Whats the difference to have the data "read only" in DMZ or connect from DMZ/external Server to internal datasources? One Option would be to do a secure Application Publishing of internal SSRS Server with a Firewall like Microsoft ISA Server
I have a website (ASP.NET MVC 4) that has users that need access to SQL Server Reporting Services. In the database for our website we have our user info and the user names are emails (Not sure if emails are allowed as login credentials for SSRS or not?). What I would like is for a user to be authenticated for the website and SQL Server Reporting services so that we may use the roles, which are also stored in our database, to control which reports users view.
I have read the documentation for implementing a SQL Server Reporting Services Extension but most of the examples implement a logon page for logging onto the SSRS ReportServer site. Whereas I would like my users to be authenticated to view/export reports on my website using a Reporting Services Service. At the very least I would like to authenticate when they log in and be able to redirect them to the Reporting Services Report Manager.
So my question is, is implementing an extension for authentication going to be necessary to view reports on my site?
I'm new to the realm of Reporting Services and am currently educating myself further on the subject, so please feel free to go into unnecessary detail.
Note: The website is being hosted on the same machine as Reporting Services, also SSRS is 2012 edition.
Can one easily 'plug-in' an existing credentials repository to use when authenticating users on a DotNetNuke web site and can we then take advantage of the DNN authorization framework?
More specifically: we have a database of user credentials (mySql) used to authenticate users. We're investigating using DNN for a new web site but are restricted to using the existing credentials repository. We can easily make the repository accessible but will we need to do any 'tweaking in the MS-Sql database that DNN uses etc?
Btw, am complete DNN newbie and just investigating feasability.
Pointers appreciated.
DotNetNuke has an authentication provider and membership provider, both of which you would probably need to implement to be able to use a separate database for credentials (though if it's just for credentials, you would just write an authentication provider to check that database upon login, then user regular DNN users for the membership part, if you're not pulling profile info from there).
As Brian Dukes mentioned there is a provider model that makes this really easy. And I might be able to get your 99% of the way there. I have a commercial product External Database Authentication Provider that connects to any external SQL Server for this type of thing. Now it only communicates to SQL Server, but you can either grab the source and make 2-3 changes and be set, or I know other users in the past have actually created a SP in SQL Server that went to MySQL and used my module as is.
I have a SQL 2008 developer edition with SSRS and the report manager is only available from the local machine. If I try to access it from any other machine I get challenged for my domain u/name and pwd 3 times and then the screen stays blank.
I have made changes to some config files (originals copied out) in order to get a 3rd party application to run but that is now uninstalled and the config files are all back to vanilla (originals copied back in)
I feel its something to do with authentication but am stuck ...
any suggestions welcomed
Jonathan
I have just stumbled on the answer.
I changed the Report Server Service Account to use the built-in Local System account and its all accessible from remote browsers.
Anyone any ideas why?
You may need to change the SSRS Configuration (through the GUI) (Start - Microsoft SQL Server 2008 - Configuration Tools - Reporting Services Configuration Manager) and set it to allow connections from outside the box it is on.
Also don't forget that it's using domain credentials / local machine credentials, so if you're not on a domain, you'll have to provide credentials to log onto that machine (i.e. MACHINE1 where SSRS is installed, from MACHINE2, log on with MACHINE1\username and password for MACHINE1).
Or you may need to open up your SQL Server instance to permit connections from other boxes.
In SQL 2005 Reporting services we were able to spoof a user when calling a report. This doesn't seem to work in 2008 and the technet articles that appear relevant seem to be implying that you need to create a seperate security extension( Technet Article )if you're wanting to expose reports to the internet. Is this what people are using in production? Or is this simpler than I'm makint it out to be?
Not sure what you mean by "spoof a user".
Every version of SSRS to date has used Windows Authentication as the default (and in fact the only "out of the box") authentication scheme. If you wanted to do Forms Authentication you have always had to write your own Custom Authentication Module.
I have done both in Production environments depending on the situation, and their sample is a very good place to start building your own custom auth module
Simple Solution
in the rsreportserver.config add in the the Windows Basic Authentication:
Install apache >= 2.2 in the same machine (use other port than 80 for ReportServer) or on a other machine
activate mod_prox_http
Create a Browser User for Reporting service (for example "reportusr" with password "this#yourMachinepassw0rd")
define in http.conf
ProxyPass http:///ReportServer
ProxyPassReverse http:///ReportServer
AuthBasicFake reportusr this#yourMachinepassw0rd
Order deny allow
Allow from all
Now you can access the reportserver and all Reports over the apache Webserver with no authentication, because always the AuthBasicFake user connects to the reportServer with BasicAuthentication