Recently, I have deployed the sample version of Adventure Works 2014 Multidimensional-EE using SQL Server Data Tools.The initial deployment did not cause any troubles, however I haven't been able to create any mining structures since then due to the following error:
OLE DB error: OLE DB or ODBC error: Login failed for user 'XYZ8'.; 28000.
In SSDT, the impersonation information is set to: Service Account
Nonetheless, what is interesting is that SSMS displays "Default" Instead:
1
Any help would be appreciated?
Have you checked the permissions on the service account?
There is an article on MSDN describing the required permissions. I've taken the following extract:
Granting permission to
read database metadata also grants permission to read the metadata of
all objects in the database. We suggest that you include the Read
Definition permission at the database level whenever you are setting
up roles for dedicated processing. Having Read Definition allows
non-administrators to view a model's object hierarchy in SQL Server
Management Studio and navigate to individual objects for subsequent
processing. In SQL Server Management Studio, connect to the instance
of Analysis Services, expand Roles for the appropriate database in
Object Explorer, and then click a database role (or create a new
database role). On the General tab, select the Read Definition option.
In the Membership pane, enter the Windows user and group accounts that
connect to Analysis Services using this role. Click OK to finish
creating the role.
Related
I'm using the Telegraf input plugin for SQL Server (https://github.com/influxdata/telegraf/tree/master/plugins/inputs/sqlserver) to gather metrics and report to InfluxDB. It works well for SQL Server, but though it supports Azure SQL Database the documentation is a bit sparse.
The database user should be created like this:
CREATE LOGIN [telegraf] WITH PASSWORD = N'password';
GRANT VIEW SERVER STATE TO [telegraf];
GRANT VIEW ANY DEFINITION TO [telegraf];
That works on SQL Server, but in Azure it fails:
Securable class 'server' not supported in this version of SQL Server.
I wonder what I need to grant instead in order to solve this in the best possible way. We have a large number of databases running on the same server in an elastic pool, so if it is possible I would like to use a single user that logs in to the master and collects metrics for all the databases at once (the way it works with SQL Server). If that is impossible I can configure multiple logins and process one database at a time.
Perhaps I can grant VIEW DEFINITION at the database level, but VIEW SERVER STATE does not seem to be supported at all.
So, how should I configure the SQL Database login(s) for Telegraf with the SQL Server plugin to make it work?
EDIT:
Running as the super user for the server works without errors, but only produces metrics for master and tempdb. I need metrics for the many application databases and they are missing. Plus running as the super user is less than ideal.
Running as the super user for the server but connecting to a specific application database (add database in connection string) crashes with a nil pointer dereference and the log complains about VIEW DATABASE STATE permission denied in database master (the super user has access, but apparently not when connecting to a spefic database).
Granting VIEW DATABASE and VIEW DEFINITION to telegraf in an application database and connecting directly to that database as telegraf crashes with a nil pointer dereference and the log says the connection was closed.
EDIT 2:
Created bug report https://github.com/influxdata/telegraf/issues/4222.
EDIT 3:
As of the latest release the plugin works if the server admin account is used, so the issue has been solved. There is still no way to run with a less privileged account in Azure DB.
The answer:
GRANT VIEW SERVER STATE is not supported in Azure SQL Database.
On SQL Database Premium Tiers requires the VIEW DATABASE STATE
permission in the database. Permissions can not be granted in Master,
but the views can be queried in user databases. On SQL Database
Standard and Basic Tiers requires the SQL Database server admin
account due to security requirements following from multi tenancy of
those tiers.
Reason:
SQL Azure SQL is PaaS solution, therefore the most "server" specific features, DMVs, settings are blocked by purpose
References:
Grant View Server State - is it possible for a none SA user to have in Azure SQL?
SQL Azure VIEW DATABASE STATE permission denied in database 'master'
Possible workaround: (which is, anyway does not work in ewramner case)
CREATE LOGIN [telegraf] WITH PASSWORD = N'password';
USE [yourDB]
GRANT VIEW DEFINITION TO [telegraf];
GRANT VIEW DATABASE STATE TO [telegraf];
Therefore, (IMHO), there is no way to make such application working in SQL Azure without changing application code
II am migrating an existing SQL Server 2014 DB to Azure. Always failing so I ran Data Migration Assistant to Assess the DB compactibility and I get this result.
Cannot still figure out how to solved that.
User: [eAgricDBUser] has an unresolved reference to Login [eAgricDBUser].
The error occurs because it's referring to logins that existed in the source SQL Server instance but not in your target Azure SQL DB instance (logical master).
Suggest you think about how your users should access the database now that it is in Azure SQL DB. Contained users are helpful here as they can be moved around to any server and still function. AD users are even better but you'll need to have your on-premises AD integrated with Azure AD. Both save you lots of headaches with login migrations.
Alternatively, you can create the required logins in master before you run the database migration scripts which contain create user statements. Note that you will be creating them with a new password so you will need to provide that to the users plus you'll need some way for the users to change that to their own password.
As part of the effort for developing a Windows Service, I restored a production database to a test database on the same SQL Server instance, and can access the test database just fine via SSMS. I gave db_owner role to the database to two other users that are unable to login, both getting SQL error
Error: 18456, Severity: 14, State: 38.
Login valid but database unavailable (or login not permissioned)
Here is the basic message which mentions the database in question as the problem.
Login failed for user 'NT AUTHORITY\SYSTEM'. Reason: Failed to open the explicitly specified database 'MedFile_TestDataServer'. [CLIENT: ]
The database is not in "Restoring" status.
First user is NT Authority\System and the second a Windows user. Both credentials are used to run the Windows service that access the database in update mode, the system user from the same server, the Windows user from VS2013 running the service as a command program on my desktop. Both can get at other copies of this same database just by changing the database name so don't think a connection string issue. I have compared every property on the databases that work and do not work and see no differences except the file names and these two logins have less permissions on the databases that they can access.
Almost like this database is being kept unavailable after being restore but I can find no such property set on the database and I can access via SSMS. I've restarted the server containing the database ergo SQL Server as well.
I also tried running the service as a database administrator and get the same error even though that user accesses the db just fine via SSMS.
Is there anything that can make the database "unavailable"?
This is part of software development for a Windows service trying to use a test database. I am using both EF 6.02 and the latest ADO.NET version as well.
Check if your database has "Auto Close" property set to "True". If so, change it to "False".
You can see it from SSMS: right-click on database - Properties - Options.
can you check what is the Default database for those two users?
If you have (accidentally / purposefully) set a default database for the SQL Server Login user, and the user does not ahve permissions to access the database, you'll get this error.
I'd like to browse data via excel and the data source is Analysis services database. After I grant my account to Roles->Membership in AS database in SQL Server, I can connect to the AS database and browse data from excel. But when I remove my account from the 'Membership' list, I can also connect to the AS database and browse data that makes me very confused. So I guess if there's cache in AS database or I should do other actions to make the configuration into effect?
If you are able to modify the SSAS roles you are probably in the admin list of the SSAS server. Here is a screenshot from Microsoft on how to edit the server admin list:
http://msdn.microsoft.com/en-us/library/ms174561.aspx
You can test the SSAS role functionality via MS SQL Server Management Studio by browsing the cube and changing the security context: http://easyroles.com/2014/02/testing-role-functionality/. This will allow you to have the 'look and feel' of the cube as if you were a user with limited access.
You should reconnect to the cube every time you change role definition to avoid weird caching issues.
I have a .NET application which connects to SQL Server 2008 for storing some data. I use SQL Server authenthication providing an sq username and a password to my end-user in app.config file. If something more needs to be changed I give to the end-user some other credentials.
How can I limit the sql user to only have permission to read/write data and executing existing stored procedures and everything else to be forbidden?
What is the best practice for setting permisions for a sql user that an application is using to connect to a database? Can I prevent somehow the user from logging in Management Studio and mess with my data?
I'm not searching for the perfect 100% reliable solution, but the best existing practice to do this. Thank you very much in advance.
Update: I work on a shared hosting SQL Server environment.
You'll need to create a new SQL user, something like 'LimitedUser'. To do this in SSMS, select the Security Folder of the server you are using, right-click, select New, select Login.
Select your authentication type (SQL server authentication is easily managed), and set the Default database to your database.
You'll need to set Server Roles so this new user only maps to your DB, and in the last page (Status), set Login to false so they cannot use these credentials to login to SSMS and 'mess with your data'.
Click OK, and you're done creating your limited user.
Assign it to your database, and then in SSMS, right-click on your db, select Properties, Permissions.
Select your user or role, and in the permission grid below, switch on only what need to be switched on.
As I see, your question is fully concerned with SQL server security.
You can limit user permissions on server, database or object scope, using GRANT statement, server or database roles. For example, you can assign db_datareader role for user, and then grant EXECUTE permission to this user for some stored procedures (or for entire database).
The current practice in my organization is to create the database roles (e.g. application admin, operator, and so on), adding the appropriate permissions to these roles and then assign these roles to database users.
I'm not completelly sure that you can prevent login into SQL Server Managent studio (SSMS), but SSMS wll not display information that must be invisible for user with user current permissions.
Shared SQL Server hosting where a single instance is shared among multiple customers is not compatible with with typical client-server applications. You are expected to perform all operations through a middle tier server such a WCF Data Service and maintain user accounts within your database in a table with Forms Authentication etc.
For your client-server application you need VPS hosting with your own instance of SQL server where you can create server-level logins. Without creating server-level logins there is no method to secure a client-server application. Any workarounds are just pseudo-security.