I have the following scenario:
On one PC I have SQL db where the owner is local user e.g. \xyz. This db has a lot of users and they all are domain user. Now I have to make a copy of the db on another PC. I'm planning to backup it up and restore on the second computer. I think that domain users will be OK but local user \xyz likely will not be OK because is different and etc.
My question is: how could I change it and make \xyz valid on the second PC? Could I delete this user and create a new one with correct and likely assign ownership and roles it had on the first PC?
I have to do this procedure on 5 PC and I'm thinking of a way to save time and it came to my mind that backup/restore would be the best and simple approach ... but I am concern about local user.
Thanks
When you restore a db from one server to another, you may have "orphaned" database users. You'll need to re-map the db user to an existing (or new) server login. For instance:
ALTER USER \xyz
WITH LOGIN = loginName
Related
How do I set up a database so that one does not have access to it? Even with installing SQL Server Management Studio on local machine.
In SQL Server with Windows user or sa can access all databases. How do you limit the access DB of the users?
For assuming that SQL Server is installed on the local machine, not on the server
You can try Single User Mode.
From the linked MSDN article:
Single-user mode specifies that only one user at a time can access the database and is generally used for maintenance actions.
Edit: You edited your question. Now it sounds more like you're asking about Security instead of how to limit the database to one user.
You can edit a user's security in SQL Server Management Studio by drilling down into Security > Logins. There you will see all logins to your instance. You can right click these entries and select Properties to made updates. The easiest way to completely bar a user from accessing any of the databases on the server is by selecting "Disabled" from the "Status" tab.
Well, if you really want to limit this to just one user, there is a simple way (but a bit risky).
Your Windows user is included in the group BuiltinAdministrators. If you really want to remove your Windows user, rerun the installation process and during the setup just change the users in those group.
But beware, you should provide another user, which has access to your database otherwise you end up with a database server without access to it.
Ater that, setup a database login and grant him access to the database you desire.
In the end, you can disable the sa login. This will prevent access with the sa account. But you should have a user which can manage logins and more. Otherwise you have no chance to recreate the password or any other administrative tasks.
One of the users in our network needs access to one table of a sql server database. Since it's Windows Authentication, I created the user in Security\Logins and I've added the user in Security\Users for the database. I've also added the permissions.
Now I'd like to test it. How can I do this if I don't have this user's password? Obviously, he's not going to give it to me.
Thanks.
Execute As User = 'domain\Name';
-- Perform the test - use a Transaction if you need to test data modifications
Select * From schema.table;
Revert
What would be the best way to allow users to manage their own database restores from backup files? The reason I ask is because I have a user who is the db_owner for
a db. He loses access as soon as he restores the database from a backup file from another instance(of course because he does not have access on that instance), and
then someone with sa permissions has to restore his permissions. Is there anyway he can restore the backups, and then put back the db owner permission on the database that he already had?
Your best bet at this point is to create a custom stored procedure that does the following style pseudo code:
Take the database name, backup file name
Check to make sure the person requesting is the owner
Restore the database over the original
Set the owner back to the original in #2
Build in some logic to check and make sure people aren't trying to abuse it, give bad values, etc. Sign the procedure with a certificate and use a special account just for this purpose to lock down possible intruders/malicious people.
what is the need of user with out log in in SQL Server?
There is a contained database. I have created a user who can log into the contained database.
How to port the database to another server without additional user configuration?
Is the "user with out log" is going to help in this context?
Want to know more about users with out log in
Experts..please share your views
Users that don't have a login are users that exist only at the database level and therefore you cannot log in to the server with them.
They can however be assigned permissions and can be used to sign modules within those databases.
The most common uses I see for them during my day to day work are either loginless users that are created from a certificate which is then used to sign stored procedures, this means that the user actually logging in to SQL server requires very few permissions in the database and all the work is done in the context of the loginless user, helping to increase security.
I also see loginless users that are not created from certificates, but are made owners of schemas or procedures which then execute as owner, similar to the above, this means that the user lgging in only needs execute rights on the procedure, no table access at all.
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.