I have backed up and restored a MS SQL Server 2005 database to a new server.
What is the best way of recreating the login, the users, and the user permissions?
On SQL Server 2000's Enterprise Manager I was able to script the logins, script the users and script the user permissions all seperately. I could then run one after the other and the only remaining manual step was to set the login password (which do not script for security reasons)
This does not seem possible in SQL Server 2005's Management Studio, making everything very fiddly and time consuming. (I end up having to script the whole database, delete all logins and users from the new database, run the script, and then trawl through a mixture of error message to see what worked and what didn't.)
Does anyone have any experience and recommendations on this?
The easiest way to do this is with Microsoft's sp_help_revlogin, a stored procedure that scripts all SQL Server logins, defaults and passwords, and keeps the same SIDs.
You can find it in this knowledge base article:
http://support.microsoft.com/kb/918992
Run this:
EXEC sp_change_users_login 'Report'
This will show a list of all Orphaned users, for example:
Now execute this script here for each user, for example
exec sp_change_users_login 'Update_One', 'UserNameExample', 'UserNameExample'
This fixed my problem.
I use the SQL Compare product from Red Gate (http://www.red-gate.com/products/SQL_Compare/index.htm). There are other similar products around but I've had no reason to look for one as SQL Compare has never let me down.
You'll find it is useful for a lot more than the your current requirement as it will help synchronize all types of database object, not just login and permissions.
Related
I have been asked to maintain a site created in ASP classic that uses a SQL Server database.
I was given the database in the form of a backup. I restored the database on my local computer and created a DSN connection to it. However when I attempt to load my site, the stored procedures the site relies on give an error that execute permission was denied.
The stored procedures in question have a user named UserSecure showing as the only person with EXECUTE permission, I have tried creating a user by that name but that does not work, even though I can manually login to SQL Server Management Studio using UserSecure trying to connect from the web page using those credentials gives a login failed error.
If I run sp_helplogins my Windows credentials are shown as being owner of the database, and I can in fact execute from within SSMS but not from an ADO connection.
On another note the connection in the webpage was coded like this, I am not familiar with the application part of the connection. Perhaps this is part of the problem? I have tried connecting with a DSN and DSN-less connection and can connect but not do anything with the database?
You should make sure the database server login is mapped to the appropriate database user (this problem crops up often when dealing with database backups). If it is not, then you need to fix the mapping. Fortunately, there is a command called sp_change_users_login that you can use to fix this problem.
First, check if your login is mapped to your database user. Using SQL Server Management Studio (assuming SQL Server 2008), look under Security/Logins for UserSecure. If you see it in the list, double click on it and select User Mapping. From there, locate the database you are trying to connect to, and see if UserSecure is mapped to that database. If it is not, you may be able to fix it using the following command (assuming UserSecure is the name of both the login and the user):
EXEC sp_change_users_login AUTO_FIX, UserSecure
See MSDN for more info on sp_change_users_login:
http://msdn.microsoft.com/en-us/library/ms174378.aspx
One issue that has bitten me a few times:
If your stored procedure (or view) requires permission from a user (let's say userA), and the stored procedure calls another database's table or view (say viewB), it is not sufficient to just make a login on viewB's database, you must also explicitly grant userA permission to select/execute/etc. on viewB (which in turn requires a user on viewB's database)
So in your case, you may need to explicitly grant UserSecure execute permission on a stored procedure on an existing database referenced by the one you restored.
This may not be the most elegent fix, but I quit focusing on the one procedure and instead granted execute permission to the guest user on the entire DB. Since this is only running on my personal machine security is not an issue and it seems to have fixed the problem.
Know the problem all too well,
The ID of the user(name) will be different from the backed up database to the restored one. MSSQL stores the ID of the user and not the username (text), so the ID will be different (99% of the time) per machine and backup. So when the ID does not match you don't have access.
All you need to do is delete the user and recreate it, make sure you do it in both places:
Delete the user from the database first:
DATABASE -> SECURITY -> USERS -> Right click (username) + delete
Then goto
SECURITY -> LOGINS -> Right click (username) + delete
Then recreate the user and give the account the correct permissions and you're all good.
I got an error message in my Log Reader Agent:
The process could not execute 'sp_replcmds' on 'Database Name'.
I created another agent profile with a large query timeout and a min value to batch, but it still doesn't work.
Can someone help me?
I'm using SQL Server 2008 and I'm trying to do a replication between databases on different servers.
It could be possible that owner of the database could be someone other than what you have permissions for. Below there's a simple command to change ownership...if you have the rights to do so.
--TSQL Code--
USE PublishedDatabase
GO
EXEC sp_changedbowner 'sa'
GO
There are a lot of things that can cause this error (which include, but is not limited to):
The database has been publication disabled
The account trying to run the log reader agent doesn't have the ability connect to the publisher server
The account trying to run the log reader agent doesn't have permission to run sp_replcmds
In my experience, there's a little more to the error in the replication monitor. Is this the case for you?
This could be due to Owner is not set for the database.
You can check by right clicking on database then choose Property and go to File Table and the Owner selection should be there.
I am attempting to migrate from SQL Server 2005 to SQL Server 2008. Both of these database instances are hosted on 3rd party shared servers that I do not have full permissions to. They are using mixed mode authentication.
I am running into trouble setting up the new database the same way the old one was set up. Specifically, the new web-based control panel doesn't allow a dbo to be specified when creating a new database and then when using Red Gate SQL Compare to sync up the schemas I am having problems because some objects (that don't explicitly specify dbo in the script) are being created with the prefix of the user account rather dbo.
I have poured over the documentation trying to find a way to force my login "user1" as dbo to the "db1" database. I came to the conclusion that the script should look like this:
ALTER AUTHORIZATION ON DATABASE::db1 TO user1
Before running this script, the login "user1" already exists, but is not a user for database "db1". Note I had to submit this script to the support of my hosting company in order to run it. According to the hosting company the statement successfully executes, however when I compare the databases using SQL Compare the user "user1" has not been physically added to the database like it was under SQL Server 2005. When trying to add it using the script:
CREATE USER [user1] FOR LOGIN [user1] WITH DEFAULT_SCHEMA=[dbo]
I get the error message:
"The login already has an account under a different username"
I have tried dropping all of the other users from the database, but the error message still persists - which I find odd.
While I could just fix the scripts by explicitly specifying dbo, this would inevitably be a time bomb waiting to go off because if any new script were introduced that didn't explicitly specify dbo there would be a failure during synchronization. Since some of the scripts are from 3rd parties, this is not a good solution.
So my questions: Is there another statement that I need to run in order to add "user1" to the database as a user that is dbo? Is there anything that has changed in the implementation between SQL Server 2005 and SQL Server 2008 R2 that could cause these inconsistencies?
I am unfortunately not able to test to find an answer to the second one because I don't have another SQL Server 2008 database to test with and I don't have full access to do anything I want on this one.
The old database was created through a control panel which forced dbo to be specified and the new one doesn't allow dbo to be specified when creating a database.
From what i have gathered the following should suffice.
ALTER USER [user1] WITH DEFAULT_SCHEMA=[dbo]
The create wasnt working as it already existed.
Have a SQL Server 2008 db which I connect to the Windows Authentication .. has worked good for 7-8 months .. but now when I come to work today it no longer worked to connect, without that I had done something
Error message was:
Can not open user default database. Login failed.
Login failed for user 'Jimmy-PC \ Jimmy'.
where the first is the computer name and the second is the user. The problem seems to be that it tries to connect to the default database. Have tried to change it without success .. I do not have sql server management tools for sql 2008 but only to 2005, someone who has similar experience? who have not touched anything said over the weekend and it worked last Friday without any problems.
The user's default database is offline. the thing that changed since yesterday is that your database had failed, for whatever reason.
You need to log in with a different account, one that does not have a default database, and inspect the state of the database. If you do not have such an account, then you can use an administrator account. If the administrators group is not granted login into SQL Server then see this article Troubleshooting: Connecting to SQL Server When System Administrators Are Locked Out.
Once you can log in, the only tool you need is sqlcmd.exe, which is installed on your machine. Look into sys.databases, the state_desc column will tell if a database is offline. You can try a to ALTER DATABASE ... SET ONLINE and see if it recovers, but that would be unlikely. Your best choice will be to apply your disaster recovery plan and restore the database from the backups you keep for it.
It is strange that it just stopped working. Have you checked the status of the user's default database? Make sure the database exists and is online.
To find the user's default database run the following command using sqlcmd.exe
select dbname from syslogins where name = 'Jimmy-PC \ Jimmy'
I have seen this error when recovering a system and the user's default database hadn't been restored yet and another time when a database was in "Recovery" mode.
I would also make sure that the windows account is not disabled.
If you find that you need to change the user's default database you can use a T-SQL command, see the following question:
How do I set the default database in Sql Server from code?
I have taken a copy of a database home with me so I can do some testing. However when I try to run a stored procedure I get Cannot open user default database. Login failed..
I have checked and checked and checked I can open tables in the databases login to sql management studio and access the default as well as other databases any ideas?
Possibly a corrupt user it was from sql 2000 at work to 2005 at home
EDIT: Mine was from 2005 to 2005. Not sure if this will work for your case...
I had a similar problem. For me, when I detach or create a back up and then re-create the database, it will loose connection to users. User I've been using is still there under Login but it would fail to log in.
In my case, I was able to log in by deleting the User under the database -> security -> users, not the user that's in the root sql server users list.
Then go to root users list and reassign database mapping or create user if not exists.
Hope this helps.
This is a shot in the dark, so forgive me if it just wastes your time.
Another poster mentioned that a given user has an id for the system and an id for any given database. This can be proven out by comparing sid's between the master.sys.syslogins and dbname.sys.users for the same login / user name. If you restore a backup from another sql server that has it's own copy of the master databases, the sids won't match.
Sql Server 2005 doesn't allow direct editing of system tables with out a lot of pain. To help out with these mis matches, they added a stored procedure to help you fix them:
USE dbName
GO
sp_change_users_login #Action='Report'
That will show you what users have a dbName.sys.users entry, but no master.sys.syslogins one - or where the name exists in both, but differ by sids.
If it shows that your user is out of synch, the procedure also has a mode to change the linking:
USE dbName
GO
sp_change_users_login 'Update_One', 'userNameInDbUsers', 'UserNameInLogins'
If the sid mis-match isn't your problem, I've also seen really screwy stuff with Sql Server 2005. The gui is especially buggy. To fix a problem like this, I had to actually drop the syslogins entry (via the gui or DROP LOGIN command )
sp_change_users_login: http://msdn.microsoft.com/en-us/library/ms174378(SQL.90).aspx
Drop Login syntax: http://msdn.microsoft.com/en-us/library/ms188012(SQL.90).aspx
I had the same issue and I fixed it with:
C:\> sqlcmd -E -d master
1> ALTER LOGIN ***** WITH DEFAULT_DATABASE=master
2> GO
Where ***** is your username.
(If you are using a domain username: [*****])
Edit:
Where ***** could be:
username if the user is local
[username] if the user belongs to the actual domain
[domain\username] if the user belongs to another domain (not tested)
I moved 8 databases from SQL Server 2000 to SQL Server 2005 and onto a whole different computer. I normally like to know what stored procs are doing so I dug a little bit and found that the actual command is ALTER USER.
It's what everybody else has been saying. The users get disassociated when you detach and reattach databases in SQL Server 2005. I find this behavior most annoying, as I didn't see that behavior in SQL Server 2000.
The T-SQL to fix this issue looks like this:
USE AdventureWorks;
ALTER USER Mary5 WITH NAME = Mary51;
GO
This MSDN article talks a bit more about this:
http://msdn.microsoft.com/en-us/library/ms176060.aspx
I just solved this issue. My default database was AdventureWorks2008, so as an Administrator, I ended up removing my login from the server. Then running the following to recreate my user
CREATE LOGIN [NT\mylogin] FROM WINDOWS WITH DEFAULT_DATABASE=[Master], DEFAULT_LANGUAGE=[us_english]
GO
My understanding is that Logins are stored in the server, whereas a User is an assignment of a login to a database (correct me if I'm wrong).
Therefore, you cannot move Logins by detaching/attaching databases, and the solution would be to create a database User connecting a (valid) login to the copied database.
http://benharrell.wordpress.com/2007/01/15/cannot-open-user-default-database-login-failed-login-failed-for-user-username-microsoft-sql-server-error-4064/
ALTER LOGIN works only in SQL 2005 and up.
To change the default database for a user in 2000 use
EXEC master.dbo.sp_defaultdb #loginname = N'BuiltIn\Administrators', #defdb = N'master'
I found this out the hard way when I set the builtin\administrators account to default to the application db and it went Offline somehow and I could no longer login. Using Management Studio, you can set the option to login to master but you must run the above command before any other operation will work, less you get the default database is unavailable error.
As was mentioned before, the login mapping to that user account probably became disassociated during the move. Or, you moved it without creating the credentials it was expecting, in which case, you'd need to create the login first...
If it was a backup set and you are restoring it, however, there is no way (that I know of) to reassociate the login to the user via the management UI. Instead, you have to use:
exec sp_change_users_login update_one, 'user', 'login'
to get it to restore the link.