TITLE: Connect to Server
Cannot connect to tcp:ohimryXusa.database.windows.net,1433.
ADDITIONAL INFORMATION:
Hello,
I have a SQL Azure database. This database has a username / login that I want to use to access it. When I try to connect to the database by SQL Server Database Management Studio, I receive an error that says:
Cannot open database "master" requested by the login. The login failed.
Login failed for user 'mydbusername'.
This session has been assigned a tracing ID of '00000000-0000-0000-0000-000000000000'. Provide this tracing ID to customer support when you need assistance. (Microsoft SQL Server, Error: 4060)
I have other logins that I can successfully connect to the database with. I tried executing the following on my database, to ensure there was a user:
CREATE USER mydbusername
I receive an error that says:
Msg 15023, Level 16, State 1, Line 1
User, group, or role 'mydbusername' already exists in the current database
I verified the user existed by logging into the master database. Once there, I ran:
SELECT * FROM sys.sql_logins;
I wanted to ensure that 'mydbusername' had access on the database. So I logged in, with a more priveleged account, into my database and ran:
EXEC sp_addrolemember 'db_datareader', 'mydbusername'
EXEC sp_addrolemember 'db_datawriter', 'mydbusername'
EXEC sp_addrolemember 'db_owner', 'mydbusername'
The message said: Command(s) completed successfully.
At this point, we know a) There is a user with the name 'mydbusername'. b) There is a login with the name 'mydbusername'. c) We know that 'mydbusername' has 'db_datareader', 'db_datawriter', and 'db_owner' rights to the database.
I tried logging in via the management screen over the web. I was able to successfully login and execute queries. However, when I try to login via SQL Server Management Studio, I receive the message above. I am using
mydbusername#ohimryXusa for the "Login" field. I've verified that the password is correct. I also verified the Server Name is correct. What am I doing wrong? I really need this because I'm getting the error from my code. Thank you!
login failed is most probably cuased by wrong login/password combination.
Please make sure you are using the existing LOGIN, and not the USER while trying to login! Note that when you want to authenticate with SQL Server, you have to use the LOGIN created and not the USER. You have to find out which LOGIN is your "mydbusername" associated with.
It is good that you have the user, and that user is added to different roles, but a USER without associate login is nothing.
You may want to refer this documentation.
I know this is old thread, but I might help others who are facing the same problem...I created the user in master database without granting any special permissions - This resolved the problem. Looks like in Azure, all users that belong to user databases should also present in master database??!!
Because Azure uses database servers for multiple databases you can't just log into Management Studio (connect to the Object Explorer)
This would give you visibility to everyone's database whose on your same server.
To avoid this, simply close-out of the initial login prompt dialogue you're presented with on start-up and click 'New Query' once it closes.
You'll be prompted to connect - but if you go to connection settings and select your database as the initial catalog you'll be able to script your (and only your) database from there.
No object explorer - but at least you'll be able to directly script your DB.
Related
I've been searching everywhere but it seems as nobody has my problem. I recently created an Azure SQL Database and I have not had luck at all with figuring out what to do with the error 18456. I Many times I've seen the "Just right click the database and go to properties and security" but there is no security. In fact there seem to be a lot of things I don't have when I right click. I barely know anything about any of this though, so I've tried quite a few things. At one point I thought I needed to use the sample adventure works. but that wasn't it. So I'd be really grateful if anyone helped.
[SSMS Version: 16.4.1]
[Azure SQL Database: Server Version 12]
Picture of my properties menu in SSMS(SQL Server Management Studio)
]
Picture of my right click
]
Your error is common, but the way you solve it on-premise or using virtual machines (Infrastructure-as-a-Service, IaaS) is different than how you would solve it for Windows Azure SQL Database (WASD). WASD is a Platform-as-a-Service version of SQL Server. The SQL Instance is logical, so you have to change some of your thought processes. One of the chief ways you'll need to change your thought processes is in how you manage your SQL Databases.
When you're in WASD and you create a database, you're asked to create an administrative username and password. Using that account you can deploy the schema of your database as well as SQL Authenticated Users and permissions. You don't have permission to change the instance's authentication types, that's why you don't see an option for security when you right-click on the instance name and choose properties.
The following steps are how you would create a new LOGIN to allow this new user to authenticate to the virtual instance. After you've created a LOGIN, you then need to create a database USER for this LOGIN. With this USER, you can then assign permissions for what this USER can and cannot do.
Adding Logins for your Windows Azure SQL Database
A few notes before we get started. In the following code anything in angle brackets (< and >) mean this is a variable you can change. So would be the username you want to create for your Entity-Framework application. would be the password you want to use for your .
Use your administrative credentials to connect to your instance. This account has permissions to control everything about your database. When you connect, you should find that by default you've connected to the master database on that instance. If not, use the drop-down at the top of SSMS to change to master. "USE master" will not work.
From this connection, the following T-SQL will create your Entity-Framework's username and password.
CREATE LOGIN [<username>] WITH PASSWORD = '<password>';
At this point, if you were to try and connect to the virtual instance with this and , you could connect to your virtual instance, but not any database on this virtual instance. Your error message would say something like:
The server principal "" is not able to access the database
"" under the current security context....
You need to take at least one more step before this user can connect to your user database.
Now, from that same SSMS script window, change the database to the user database () you're granting access to. This will be the database you want your Entity-Framework application to use. Remember, use the drop-down at the top.
First we will create a database user for the login created in the previous step.
CREATE USER [<username>] FOR LOGIN <username>
Then, we will allow this to connect to your user database , the database you want the Entity-Framework application to use.
GRANT CONNECT TO [<username>]
At this point, your new username can log in to the virtual instance and connect to your user database.
Now, you will need to add any other permissions this user will need. For example, if your will only need read permissions, you could get away with adding the user to the db_datareader database role. Add those permissions now.
Special note about connection and connection strings
Your user is now setup to connect to your user database. That means in SSMS if you try and connect with your Entity-Framework user, there is an extra step to your connection dialog box. Before you click Connect, you have to hit the Options button.
Since your user cannot hit master, you have to tell SSMS you want to connect to the user database first and avoid hitting master. By default, SSMS will try to connect to your SQL instance's master database first.
You have to enter the name of the database in the "connect to database" entry. After you've entered the database, you can then hit connect.
I'll guess that in your application it already had the "Default Catalog=" value set to your user database, and you were able to connect. Setting this value in options is like setting that "Default Catalog=" value.
I hope this helps you in breaking into WASD a little more.
EDITS: attempting to add clarity to the differences between IaaS SQL Server instances and PaaS Windows Azure SQL Database. I previously missed the FOR LOGIN clause on the CREATE USER statement.
I'm trying to create a SQL Azure database. While the database successfully gets created, I can't login to it. The reason why is, I don't know what the default username / password is. Or, how to create the first user that can access the database.
There has to be something basic I'm missing here. How do I create the first user for a SQL Azure database.
The database exists on an Azure SQL Instance. You need the administrative loginid/password you assigned when you created the instance.
When you are in the Azure Management Portal (https://manage.windowsazure.com) go to "SQL DATABASES".
On the "DATABASES" page (along the top), find your database. Look for the name of your databases' server in the "SERVER" column, and click on the link for the server.
On the page for the server, along the right side under "quick glance", you will see the "ADMINISTRATOR LOGIN" and further up you see a link to "Reset Administrator Password". You can reset it if you don't remember it.
Now, you can login using those credentials (admin login/pwd) and create additional logins as needed.
Hope that helps.
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.
According to MSDN documentation this proc is supposed to grant login to a windows user, but when i run the following script, I cannot login using the specified user even though the account shows up under security.
exec sp_addsrvrolemember 'domain\user','dbcreator'
also is there a way to query if a particular login can actually login to the server or not ?
I should add that i know one should create login using CREATE LOGIN statement, just wondering if sp_addsrvrrole is behaving as it should
MSDN says to use CREATE LOGIN (which replaces sp_grantlogin and sp_addlogin) which says
Creates a new SQL Server login.
Once you have created the login, then you run sp_addsrvrolemember which says:
Adds a login as a member of a fixed server role.
This means the login should already exist before you run sp_addsrvrolemember
To test if a login exists at the SQL Server level, use SUSER_ID which will give the internal key from sys.server_principals
SELECT SUSER_ID('DOMAIN\User')
Edit:
Some system stored procs will create a sys.server_principals entry but it's not usable
You need to run this now. Or DROP LOGIN first and recreate as above
GRANT CONNECT SQL TO <login>
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.