SSAs permission control is based on role, while role members can only be Windows users or domain users. Unlike SQL Server, database-level users can be created, if you use Excel as the OLAP client, the trouble is that the server where SSAs is deployed is mostly not in the same domain environment as the client PC, and the firewall is not convenient to implement domain trust, the resulting mainstream solutions are as follows:
1. http access. If the configured web server is anonymous, no permission control is available. All access client permissions are the same.
2. netonly RunAs is used to write credential information to startupinfo before the Excel process is created. Then, the Excel process can access SSAs as the login user identity, the disadvantage is that you need to perform a login authorization every time you create an Excel file. When you double-click an existing Excel report, you will find that you cannot modify or update the External table, because the Excel process does not have login authorization at this time, it is really annoying for the user experience.
3. the configuration of the Windows user password on the client is the same as that on the SSAS server. This solution perfectly solves the problem of the above solution. You can complete the configuration of user permissions. End users do not need to verify their identities every time, however, the actual production environment may cause unnecessary troubles. For example, if the client user changes the password and the password of the user with the same name on the server is inconsistent, the access permission will be terminated.
The following describes the solutions used by the author in the project. An Excel plug-in developed with vsto provides the cross-origin login authorization function, some functions that are useful in OLAP analysis will be gradually extended and integrated in the future. If you have time, several topics will be opened to detail specific functions. This article only describes cross-origin login authorization.
First, you must configure the server to open port 2383 to the client (if the server has multiple SQL instances installed, the SSAS server open port may not be the default 2383 ), verify that port access is normal on the client, as shown in.
Create two Windows users on the server, and create two SSAs role to authorize access to different country
On the client side, I use excel2010, which is theoretically compatible with excel2013. In the future, I will perform some compatibility tests and install plug-ins, for example (the plug-ins are at the bottom of the article)
First, use source config to configure one or more cube data sources, and select the current data source from the drop-down box control above.
Click the New Login tTable button. If this is the first time you use it, the login window will pop up. Enter the SSAS Server user password to support Windows users and domain users.
If you select the checkbox in the logon window and confirm the login, the login identity will be bound to the PC. This identity will be used by default no matter when you open the Excel file.
After login verification, a new PivotTable is created with the current identity to check whether the permission is normal:
Click the X button to switch to Test2, and the current PC is not selected.
After you confirm that the data is automatically refreshed after login, the results are as follows:
Save the Excel file. When the file is opened again, the test1 identity data is automatically refreshed.
Free Download is now available:
Http://pan.baidu.com/s/1c05urok
[Original] cross-origin authorized access to SSAs