I want to define all the acces rights in my SQL Server database so it is nice and centralized. I am implementing basic stuff like grant select on schemas and tables, encryption of columns and RLS.
On top of the database I build a Tabular model with SSAS with DirectQuery connection.
On top of the Tabular model I want to build a report with DirectQuery connection.
directQuery states:
Security can be enforced by the back-end source database by using row-level security features from the database.
Impersonation in Analysis Service Tabular states:
Impersonate Current User Specifies data should be accessed from the datasource using the identity of the user who sent the request. This setting applies only to DirectQuery mode.
Issue:
I cannot choose "use current user" as impersonation mode in my ssas tabular model. -> "ssas the datasource contains an impersonationmode that is not supported for processing operations"
changing the impersonation mode in ssms yields this error, VS2019 looks similar with the same content
I can deploy it as a specific user but that means that everybody uses the access rights of that specified user.
My tabular model uses compatibility level 1400. It is deployed to a Microsoft Analysis Server 15.0.32.50, Tabular Mode. (The model cannot use DirectQuery when in compatibility 1500 for some arcane reason. Please don't make this your topic unless you absolutely have to.)
SQL Server Version is 2019, 15.0.2000.5
The on-premise Report Server must be used.
SSAS, database and report server run on the same SQL Server.
Is it possible to implement this solution using database, ssas and report server on the same machine? If so, how?
Alrighty, so after messing around with this stuff for wayyy too long, I narrowed it down to the SQL-Server setup. Something there in the configuration is causing a bunch of issues.
Using direct query to pass down user information in the way described above is perfectly valid.
Related
I have a problem with an application which encompasses an SSAS project, with an OLAP cube, and a client project using ASP.NET Core and Blazor WebAssembly, and a SSRS project.
The ASP.NET Core app retrieves reports from the SSRS server, but the report parameters are written in C# and Blazor; and the problem I have is about how to get available values for these parameters.
For example, if a filter is about anesthesists, I want to display in a combobox all the anesthesists names, but from where do I get this information?
I have 2 choices: either from the OLAP cube, using the AdoMdClientNetCore Visual Studio extension, or from the source database in SQL Server.
I would like to know if there are some good practices concerning this subject; I googled here and there but without relevant results.
I would recommend to get data from SSAS. Reasons for this:
Working structure of your project - Client project <-> SSRS <-> SSAS <-> Some DB. And Some DB datasource is beyong the scope of the project. SSAS acts as a single point of contact with Some DB, if the Client App will access the DB - it will create another contact point to the DB. This extra contact point has to be configured, maintained etc.
SSAS updates its data, reading from its data sources, in timely batch manner during so called "Processing" jobs, unless you use special ROLAP mode. This means some delay in information passing from DB to SSAS. Report gets data from SSAS, so, reading directly from DB could bring in inconsistency some rare cases.
Separation of concern. SSAS accesses DB with some queries. If the Client App accesses the DB as well, modifications made to SSAS have to be transferred to the Client App, complicating development and support of the solution.
I am new to SSAS technologies for developing analytical models. I have to build several tabular models for a huge application in which security is quite relevant. What I would like to do is to re-use the row level security existing in the sources of the cube and apply it to the cube itself.
For example, if I build a tabular model from two tables of a schema, and these two table have RLS enabled, I would like the cube to take this security into account, so that when I access reports and log in as user, I will only see aggregated data according to the permissions I have.
Searching through the web I found ways of implementing RLS within the cube, but none about inheriting it from the sources. But again, I am new to the technology, so I preferred to ask here.
Thanks
The most obvious solution to your request is running SSAS Tabular in thin mode (called DirectQuery mode). As long as in the Existing Connections dialog in Visual Studio you set ImpersonateCurrentUser, when a user queries the SSAS model, SSAS will in turn send one or more SQL queries to the database under the end user's credentials. RLS in the SQL database will come into play here.
One caveat is that I would only recommend DirectQuery in SSAS 2016 not prior. Another caveat is that performance will be slow compared to a cached model in SSAS. So if performance isn't acceptable then turn off DirectQuery and reimplement RLS inside SSAS. Also DirectQuery uses zero caching of results currently so the load against SQL will not be offloaded to SSAS at all. Finally, if you use DirectQuery and ImpersonateCurrentUser you may have to setup Kerberos if your SQL server isn't on the same server as SSAS so that user credentials can double hop.
I have an Analysis Services database. The cube Storage Mode is MOLAP and Proactive Caching is set to Off. All dimensions, measures and partitions have MOLAP set as Storage Mode and Proactive Caching set to Off as well.
When I'm connecting to the cube through Excel or SQL Server Management Studio, everything works great.
But users connect to the cube through web pages. We use Office Web Components. They were working fine until recently, users encounter the below error randomly when filtering dimension, expanding, collapsing, etc...:
Current session is no longer valid due to structural changes in the database
First the PivotTable returns blank. When they try to refresh data, they get the below error message.
Help.
Thanks,
Mona
If it'is not a huge olap db I recomend process db in full processing mode (not incremental).
I typically build cubes in this manner: PREFIX_YYYYMMDD.
that way, when I build a new version of the cube, I can still use the old version of the cube.
And then I change the connection strings (from the XmlData method) using a simple UPDATE statement to change the cube name...
Can you revert to a backup, an older version of the cube?
I absolutely LOVE Office Web Components / SSAS.. I think that they are by far the coolest product to every come out of Microsoft.
I was trying my hands on building Cubes using AdventureWorksOlap database. I successfully build what I was trying to do. Now my concern is that I want to deploy the cube to a server so that rest of the team members can use this cube as a datasource while generating their SSRS reports (might be some other tools).
I have heard that SSAS does not allows Sql Authentication. So,
1) how will the members access the cube?
2) What authentication changes do I need to incorporate?
3) How can the other developer using his computer's SSMS access the cube and make changes to it (just like we can do it in the OLTP database)?
4) I need to prepare a dashboard using this cube. Any suggestions on this one.
Thanks in advance.
1) Windows Authentication
2) none.
3) Once the cube is deployed you cant change it. Actually you can change some things like partitions and roles, but you cant add a dimension for example. You need to change the project on BIDS and redeploy it
I would recommend starting with Excel Pivot Tables to learn what type of dashboard you will want to create. By working with the end-users, you can understand what information they want/need to see.
Regarding security, as mentioned, by design cubes use Windows auth only. Here's a blog that talks about circumventing standard security.
Also, I have posted a series of videos on how to create OLAP cubes SSAS in SQL Server 2008 using BIDS. You may find this series helpful.
I have been working with SQL Server for a couple of years. I have heard about SMO but I don't know anything about it. What are the benefits of using it? Should I learn and start using SMO in my SQL Server projects (mainly data warehouse development)? Why?
From Microsoft:
Overview (SMO)
SQL Server Management Objects (SMO)
are objects designed for programmatic
management of Microsoft SQL Server.
You can use SMO to build customized
SQL Server management applications.
Although SQL Server Management Studio
is a powerful and extensive
application for managing SQL Server,
there might be times when you would be
better served by an SMO application.
For example, the user applications
that control the SQL Server management
tasks might have to be simplified to
meet the needs of new users and to
reduce training costs. You might have
to create customized SQL Server
databases, or create an application
for creating and monitoring the
efficiency of indexes. An SMO
application might also be used to
include third-party hardware or
software seamlessly into the database
management application.
The SMO object model extends and
supersedes the Distributed Management
Objects (SQL-DMO) object model.
Compared to SQL-DMO, SMO increases
performance, control, and ease of use.
Most SQL-DMO functionality is included
in SMO, and there are various new
classes that support new features in
SQL Server. The object model is
intuitive and uses SQL-DMO
terminology, where it is possible, to
help transfer your skills.
You can download SMO here:
Microsoft® SQL Server® 2008 R2 Feature Pack
And for getting started programming:
Creating SMO Programs
It depends on what you're trying to do. SMO is SQL Server Management Objects. It is a set of libraries for managing SQL Server programmatically. For example if you're trying to build a clone of SQL Maangement Studio then SMO is something you probably want to look into. OR if you're trying to manpulate the structure of your database programmatically then that's the place to look.
Otherwise, I wouldn't bother.
I have used SMO to automatically script out object code and user permissions and add to version control.
By doing this I can save privileges or object DDL as of a point in time for my auditing team or my own research or for cloning a server.
I also use it so I can quickly compare object code from specific dates without needing a snapshot / backup.
Recently I used SMO in a Disaster Recovery Project to script out all Server Permissions and System Database Object Permissions and run the script on the replacement server.
I've recently created an POS/Work Order Management application with a SQL database backend and the SMO library. The SMO gave my a application a lot of flexibility to control the database in terms of work order records, user's records an even my own set of user roles. Helping me to differentiate SQL users when managing a specific database. So, my take is that it all depends on the extend of your use of SQL and how much you may need to automate and control certain aspects of your SQL database.