I have some "kiosks" that run under machine specific AD accounts that I would like to deploy reports on. For security reasons I need to verify individual user credentials before allowing access to the reports. Is there a way to do this with reporting services?We are running Reporting Services 2005, but will be upgrading fairly soon.
How about using a custom security extension:
http://technet.microsoft.com/en-us/library/ms152899(SQL.90).aspx
Related
How can I RDP to an Azure box using an account I created in Azure? I don't want to go down the route of syncing directories or anything. Just simply want to be able to create accounts in Azure that can be used to access Azure servers.
This is a basic centralised authentication model and I am sure I am just missing something. Surely Microsoft can't expect us to add a bunch of users and service accounts on EACH server we create and manage passwords etc as entirely separate entities.
By "Azure Box" I assume you mean an Azure VM running Windows. There's nothing "magical" about these VMs. If you want central user management instead of relying on local user accounts you need to add it to an Active Directory domain. And if you want sync between this Active Directory domain and the Azure Active Directory for your tenant, you need to set up Directory Sync.
One cannot do this (without resorting to directory synchronisation). A Configuration Management tool such as SaltStack/Chef/Puppet seems a leaner fit than creating a traditional AD infrastructure.
I have been allocated the responsibility at work of revising the current reporting services authentication process. The aim is to maintain the necessary level of security and also simplify the maintenance/configuration of granting access to the individual reports.
I do NOT have access to the domain controllers to be able to modify or create new AD groups. I have to work with the groups/users that currently exist.
In terms of authentication, it seems that I have the option of using either:
Windows authentication
SQL Server authentication.
Both the report server and the report database will reside on the same server. With this in mind, I understand that Windows authentication is probably a better solution as there is no need to maintain a separate SQL Server table of Users (and their passwords). Granting access to a report once it has been deployed on the report server, would simply involve adding the user/group to the report (load the report in a browser and access the Properties\Security option).
Using the second option of SQL Server authentication does not seem as appropriate as using Windows authentication for the reason the report server and report database are on the same box.
I am using SQL Server 2000 databases. The version of reporting services I have installed is Microsoft SQL Server 2008.
Please could someone let me know if my thinking is correct (i.e. I should go for Windows authentication). Cheers.
Jimmy
Sql Server authentication is not an option for users connecting to SSRS. It is an option for SSRS connecting to databases where it will get its data.
So bottom line, yes, you need to use Windows Authentication for user connections to SSRS. You can use special user names such as "Authenticated Users" or "Everyone" in SSRS to allow broad access.
I understand that you don't have access to AD, but managing the user accounts' membership in AD groups would be much easier than tracking and managing individual access in SSRS.
But without the AD access you can still add Windows/AD accounts to the report permissions and use those. You just create a more complex system, since you need to manage permissions for every individual separately. You can group the reports in folders and secure the folders: the reports can inherit that security.
I'm trying to connect a web forms application to an SSAS Cube. The app is using web forms authentication and it is using web roles in Azure. The SSAS cube is on a Virtual Machine within Azure. There is no domain installed. The web app is using GrapeCity's Active Analysis control. When running the app i get the error "An existing connection was forcibly closed by the remote host". While profiling on the server I get an "Anonymous Logon" attempt.
How can I set this up?
SSAS uses Windows authentication only, so either:
1) You somehow get your web app's application pool to run under a windows account that can access the cube box (Sounds unlikely).
2) You have your application pool run under a windows account and create a windows account with the same username/password on the cube box, and assign it the permissions (Used to work, I think it still does).
3) You allow Anonymous Logon read permissions to your cube. I know you can do this at the server level (Dev enviroments..), I haven't tried it at the cube role level.
These are the ones I know of, best of luck.
EDIT: Sorry, thought I'd forgotten one, there is basic authentication if you add IIS as an extra layer, you have to set it up to go via the MSDMPump.dll, full explanation here: http://msdn.microsoft.com/en-us/library/gg492140.aspx
I am having a problem with SSRS data sources being mysteriously disabled in a SharePoint 2010, SSRS integrated-mode environment.
When I set up the data source, it is saved and I verify that it is enabled. I can also successfully execute a report that uses that data source. At some point later, it is disabled. I can't figure out why, and it's driving me crazy.
Has anyone else experienced this?
My environment:
SharePoint 2010 Farm
One WFE
Two SharePoint-integrated SSRS app servers
One database server
Read this two articles:
Sharepoint dropping link to Data Source for SSRS reports
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/91016bff-20e7-446a-bb70-7be407096faf/sharepoint-dropping-link-to-data-source-for-ssrs-reports
Reporting Services Data Source are getting disabled when deployed on SSRS Integrated mode
http://connect.microsoft.com/SQLServer/feedback/details/742238/reporting-services-data-source-are-getting-disabled-when-deployed-on-ssrs-integrated-mode
In a nutshell:
It was related to some sort of problem with the Encrytion Keys set up in Reporting Services Configuration Manager .... Sharepoint Integration was also showing as Not Configured (despite the fact that it was working in Integration mode)
When I put in the Windows Account password under Windows Service Identity it once again prompted for saving the Encryption Key to a file ... once this was done Sharepoint Integration shows as Configured and the nightly problem (2AM when the Reporting Services daily maintenance programs run) goes away ....
What are the required steps to properly allow domain users access to reports via the Reporting Services web site?
What I've tried:
Added users through Reporting Services site (i.e. http://servername/Reports)
Given users access through SQL Management Studio
Result:
users are continuously prompted by the browser for their credentials and can't log in
I don't know why I didn't think of this before but I:
Added desired domain users to the "SQLServer2005ReportServerUser*$InstanceName*" group on the Windows 2008 machine running SQL Server Reporting Services
Added users to specific roles through reporting services web site (http://servername/reports)
AND now users are able to access the reporting services site!
I've been dealing with this exact issue recently. I still don't know the answer, but I think that at least part of it is to add the users to SSRS-specific groups (create them if needed through the SSRS Configuration manager).