We are migrating some servers across regions, not easy for a Synapse Workspace. We have a working solution in several steps but the last thing is to copy the logins (with the passwords).
We have found some documentation that shows how you can script this.
On Server A in the aster database from the Synapse Workspace we can login with the sqladmin user assigned in the portal, that user is able to execute that script that creates the stored procedures.
But the sqladmin user is not granted execute permission, so we can't find a way to grant execution permission to (another/the) user that could execute the script.
Any suggestions?
Related
I have created a RDS instance for Microsoft SQL Server, while creating the instance I have master user named admin.
Now the issue is I have created a new user with these privileges added to it:
PROCESSADMIN
SETUPADMIN
DB_OWNER
According the documents given in the below link
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.MasterAccounts.html, we should have access to create databases with the above privileges, but I am not able to create a new database with this user.
Can anyone guide me if I am missing something here?
Is it possible to get SQL Server Management studio to use Azure Keyvault to get the connection parameters (server and credentials)?
I've created a key vault, added username and password secrets, now I'd like SSMS to go and get those values so the user never knows them.
I fear the short answer is no but there might be a better way of doing this than using a KeyVault.
I think the solution would be to add the user to the database as an Azure Active Directory user. There are instructions here Add Azure Active Directory User to Azure SQL Database
Go to the SQL server, select Active Directory Admin in the Settings
section
Click Set Admin and choose a user (I'm assuming you if you're setting
all of this up)
Click Save. I forgot this bit first time round.
Now you can sign in to the database with Azure Active Directory -
Password or Azure Active Directory - Universal with MFA
Right click on System Databases/master and create a new query
Run CREATE USER [a.name#example.com] FROM EXTERNAL PROVIDER;
And the user will be added to the database. I'm assuming that you'll still need to set permissions and the like but I think this would give you a simpler solution with more control over what people can do.
Your users might find Azure Data Studio even easier.
https://learn.microsoft.com/en-us/sql/azure-data-studio/download-azure-data-studio?view=sql-server-ver15
This has an Azure section where you can log in with your Azure credentials. Once signed in you can at least discover resources on your Azure subscription and if your account has been granted access as above it's then possible to run queries without any further authentication.
SQL 2014. I have deployed an SSIS project into SSISDB, the project consists of three packages. If I schedule a job to execute the three packages in the project, it doesn't pickup the flat file to process. It finishes and thinks nothing is there to process. But, if I manually execute the first package (right click in SSISDB and select Execute) it processes the flat file and moves it (correctly). The SQL Job step Configurations are identical to the package configurations in SSISDB. Windows Application, Security, and System event logs are clean. SQL Logs are clean. The SQL Agent account has full access to the folder (a unc share). Also changed the share to a mapped network drive, but still nothing. The SQL Agent account is also a sysadmin, just for testing purposes. I am guessing this is permissions related but not sure what else there is to check?
Thanks for the comments everyone. It was a fileshare permissions issue. I gave the SQL Agent account permissions to the folder, but needed sysadmin to give permissions to the fileshare. Thanks!
i want to run exe file from stored procedure. But, output is 'Access is denied'.
how can i do? my sql query is as the following. It is just testing query
EXEC master..xp_CMDShell 'C:\Users\myo.minlin\Downloads\Firefox Setup Stub 33.1.1.exe'
The reason is because your SQL-Server process runs, if not specified other, not with your myo.minlin account. The account which started the process does not have permissions on the file you provided. This is good so, because the database should not be able to access your private files. There are three or even more possible solutions:
Move the file to a location where the SQL-Server has access to.
Make sure that the account on which the SQL-Server is running has the right permissions to execute your file
Launch the SQL Server process with the myo.milin account.
I do not reccommend solution 3. Solution 2 is also not reccommended if the file is in your home directory.
See Configure Windows Service Accounts and Permissions.
I just installed ssms on my local computer.
When I try to create a database or a database table it gives me an error stating that I don't have the right permissions. I tried granting permissions for this user by going to Security->Logins->myUser. But again it told me I didn't have the right permissions. I then tried adding a new login/user which gave me the same error.
What can I do to give myself the correct permissions if I installed the ssms and there are no other users except sa, which has "login with this user" disabled by default. I can't login as another user and I can't change my current user permissions. VERY CONFUSED - someone please help!
During the installation you (or somebody else) had to add an user besides the SA to login with Windows authentication. Use this user.
Your user is a simple user that does not have enough permissions.
If you are not the guy who installed the server, ask whoever installed this to set the right permission for your user.
Also please check recover-sa-password and Disaster Recovery: What to do when the SA account password is lost in SQL Server 2005
You should check that you are placing the files in a folder where the SQL Server account (not the one you are logging on as, but the service account) has rights to write.
For starters, and not to be kept in a production environment, try to make sure that the default path for placing the database files has Read/Write set to Everyone.