I am looking for an easy way to create logins and associated users into SQL Azure.
The thing is that, with Azure, one first needs to create a login in the master database.
Based on that login I need a user to be created in a specific database (DATABASE1)
After that roles need to be assigned:
CREATE LOGIN login1 WITH password='<ProvidePassword>';
CREATE USER login1User FROM LOGIN login1;
EXEC sp_addrolemember 'dbmanager', 'login1User';
EXEC sp_addrolemember 'somerole';
The thing is, since one cannot use the USE command to switch databases, this seems to become quite a tedious task. More so because the number of accounts per database can range from ten to a few hundred, databases and users are being added all the time.
So I need a solution that can be easily reused.
I would like to have a script of some sorts (powershell?) that will read a file (containing username, password and databasename) and then create the appropriate logins, users and rights.....
Icing on the cake would be some sort of job that would regularly check whether there are (new) files present in a certain folder and if so, read those files and create new accounts where needed.
I must admit that I do have TSQL knowledge, basic programming knowledge but no Powershell experience at all. How would you advise that I go about? Is powershell the way to go? Or are there any other mechanisms I could use?
Greetings, Henro
As described here you sure can use Powershell from your desktop machine to connect to SQL Database to manage SQL Database account in similar way you would connect to other SQL Server.
PowerShell scripts can run on an on-premise computer and connect to SQL Database using System Management Objects or Data-tier Applications Framework object.
The very first step in this direction is to get your Powershell commands connecting to SQL Database and you can use this article to get upto here.
After that you just need to use the Powershell script to create users login and searching quickly I found this article and this one promising which includes a few more functionalities along with your objective. You may need to tweak script to make it working with SQL database.
Finally you can search internet to read data form a file (or XML to be better) and feed user info to your SQL Database script. If you have any issue in between step, open specific question and you will be helped.
Related
My application have to create database and import data, this is done once the app is deployed.
I noticed that the database could be only created if my connection string specifies user sa, or other user with CREATE DATABASE privilege on master database. Well, the first time I created the database manually, then created a user for it, then used EF (via Package Manager Console) to create the structure.
Then I accidentally deleted the database, so I tried to recreate it with EF which failed with "create database failed" and that I need "create database" privilege on "master".
So I thought, well, I'll give it a try, I specify sa as the user. And no initial catalog, let EF Core create the database, right?
Here comes the surprise: it didn't create any databases, it created tables in my master database. This is definitely not what I wanted! How to specify the name of the database to use?
I know this question was asked before, with the answer "use the connection string name". NO - IT DOESN'T WORK in Blazor application with Identity. My connection has a name that is NOT USED, the database is not created, my tables goes to master. In this framework, the configuration sits in appsettings.json file. There is a special method to fetch connection strings, but their names are not special. It's just a configuration key as any other and I don't think its name is used for anything but finding the appropriate string in the file.
If I create the database manually, then create user, then grant privileges, then set the connection string to that user, with initial catalog set to my database - then it works, but there are several problems here. I try to do as much as possible within my application, I try to avoid manual actions as much as I can. I need the deployment process as simple as possible. First run on special privileges, to import data, second run on regular user privileges.
Then I'd like to make limit the concrete RDBMS dependence to the minimum. Let EF Core do everything it can automagically.
Is it even possible?
What is the best common practice?
Do you create databases and privileges manually, or can it be automated in EF?
How does EF create the database? Does it set any special options like default collation? What options should I set when creating the database manually?
I have a requirement to give a functionality for a non technical user to run the Agent job / stored procedure. It's just one stored procedure.
I do not want to the user to install SQL Server, nor do I want to give him any additional permissions. Indirect permissions (proxy or running through a server) are fine as long as the user won't be able to see the password.
I believe Osql does this but then I have to type username n password in batch file and that compromises security.
Is there any other way? Can this be achieved with SSRS?
To cut through you can script SP execution with Powershell and use integrated security to authenticate user on SQL server. Check this thread how to do that.
Please keep in mind that giving direct access to SQL server is a bad idea from security perspective, so you must limit its permissions with a specific role and grant execution only for that particular procedure.
Alternative to #Illia way is to create a simple web-app with (say) .net. It's probably less than 15 mins task for a .net developer to connect to SQL server and provide a button to execute one or more stored procedures. You can manage the access via integrated security of the app specific user id and password and is probably more easy for a non-tech user. See here.
I was finally able to achieve with less overhead using a SSRS report. Created a report to run the Stored proc whenever the report is opened. This way I was able to achieve the security part too. Thanks for the answers everyone.
I have a SQL Server which contains a table that needs to be updated by different people in different departments. The easiest solution that we came up was to create a MS Access file, and people can open the file to update the table using Trusted Conenction so each user will not need to input user/pw.
I have created a group with all the users' Windows Authentication account in SQL Server.
Now is when things did not work as planned: I am having trouble creating the MS Access file. When I create it on my machine, and e-mail it to another user, they get access issues.
Has anyone done something similar?
I'm working on an application right now that requires a link to a couple of SQL Server tables. My windows network account has permission to connect to this server, but I am not going to be the only one using this application. I'm going to send it out for people to save to their PC or just put it on the company shared drive to use (I know, that's asking for problems sometimes). It's inconvenient to make a windows account for users to share because they would need to log out and in to use the app, so I was wondering if the application or ODBC connection file itself can store the credentials to access the table.
Should I configure the connection object to use something other than the windows login information (maybe a SQL server username/password), and just store the connection object in a shared location? I don't have much experience with this and haven't tried out many different solutions and I am open to suggestions.
Thank you for the suggestions
As suggested in a comment to the question, one solution would be to
create a User Group in Windows on the SQL Server,
create a SQL Server login for that group,
assign permissions within SQL Server to that login,
and then just add or remove particular Windows Users from that group as required.
That way you don't need to mess with the various SQL Server permissions for each database user, and your application can connect to the SQL Server using Windows Authentication so you don't have to mess with saved SQL Server credentials (in connection strings, or elsewhere).
You certainly can specify the username & password in the connection string -- ConnectionStrings.Com is highly recommended if you are having trouble with connection strings -- their first example for Sql Server is
Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;
The issue is security, if users can see this in a configuration file, they can do anything that account can do. You have to handle security within you application if you do this. Most apps that handle their own security have to create users and passwords in a database table (best not to store password at all, much less plaintext -- a one way hash is recommended).
One good strategy is the create a "login user" account with well known name and password, grant no read / write, etc. for that account at all, and grant execute access to single stored proc
IsLoginPermitted #ID, #PASS
When successful, IsLoginPermitted returns the ID & PASS for subsequent use (of course these are hidden from the user) and you create your new connection string based on these.
I'm working on a short-term disaster recovery planning effort at my company, and we're planning on using replicated reporting servers as warm spares in case our primary transaction server dies.
Our web application can to write to that transaction server, but with only certain rights given by a SQL role. (webapplication) I want to give us a way of updating this role that also updates the same role as it exists on other servers. This way, if we fail over to another server, our webapplication role is reasonably close to the same, if not exactly the same. (I'm not really worried about someone updating it directly)
So, I have a MakeWebWriteable procedure that should generate and execute some code like what is below. Except, what's below clearly won't work. I'm at a loss for how to reference the role and update it on a remote server. I thought about using exec (#sql) at [reporting\server], but I'm not sure how I would reference a certain database's role object within that.
grant insert, update, delete on dbo.TableName to webapplication
grant insert, update, delete on [reporting\server].DBName.dbo.TableName to [reporting\server].DBName.dbo.webapplication
How might I do this, or are there any better ideas? (i.e. replication)
edit 1: We generally write migrations as SQL scripts, commit those to SVN, and have our databases updated with a syncing script - sort of like what the process in RoR is, only without a model->SQL translation. Ideally, we would just put a line at the end of a migration in which we added a table like so, if we want the table to be web-writeable.
-- Code to create NewTable...
if object_id('SetWebWriteable') is not null
exec SetWebWriteable #tableName = 'NewTable'
This way, nothing happens on our developer machines, but in our test and production environments, the correct actions occur. If the role can be replicated automatically, then naturally we wouldn't need to do this.
From what You are describing, You need SQLCMD utility. Connect to any server using the credentials it accepts (I usually use -E which represents windows authentication) and execute whatever scripts YOu need. If You are not trusted there, create an account with sufficient credentials.
The question is: What is the trigger of this script to execute? Do YOu execute it manually, or should it fire up automatically. In this case You are bound to write some code to achieve that (not very difficult though).
And You can leverage powershell built into SQL Server 2008 which can operate on objects on ANY server You can connect to (with your credentials). Look into that. It has a cmdlet Invoke-Sqlcmd which helps a TON.
luke