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.
Related
I have a contractor who I want to give access to a website that connects to a database. I need to create a SQL Server user that can connect and read and write to the database.
However, I don't want this user to be able to connect to the SQL Server via something like Management Studio. Are there permissions that need to be enabled or disabled to accomplish this in SQL Server Management Studio?
SQL Server Management Studio (SSMS) is basically a normal client that makes SQL statements in the background. If you create a login in the SSMS, then no magic happens, but a CREATE LOGIN. This can be recognized by the fact that there is (almost) always the possibility to generate the appropriate SQL statement via "Script as", which is normally done in SSMS via the graphical user interface.
If you would lock out SSMS, then other clients as well. And even if there were a setting, there are other possibilities via Powershell and the like. So this is not the way to go.
I suppose you don't want the contractor playing around on the SQL server just because he got access to a database? He is allowed in the house, but not in all rooms....
In other words, it can only be done via permissions, where there is a login to connect to the SQL Server on the one hand and a database user who gets access to the database on the other hand. Therefore there are authorizations on SQL server level (login) and database level (user).
CREATE LOGIN testlogin WITH PASSWORD = 'wowThisIsKewl';
GO
USE [YourDatabase]
GO
CREATE USER [dbuserlogin] FOR LOGIN [testlogin] WITH DEFAULT_SCHEMA=[db_owner]
GO
Each login belongs first to the SQL Server role "public", unless additional or different authorizations are granted. You can connect to this role, but e.g. you can not create databases, perform backups etc.... Just try it out.... =)
At the same time DB_OWNER at database level allows the login to read and write data, etc. and more.
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.
I would like to change the default database for a login to support software that can access SQL Azure but does not allow easy alteration of a connection string. It appears that SQL Azure defaults to the master database.
I've already considered:
Stored procedures. I can't find a stored procedure that does this (sp_defaultdb is not implemented in SQL Azure as far as I can tell)
Alter Login. ALTER LOGIN does not permit the DEFAULT_DATABASE option.
SSMS. SSMS doesn't seem to allow much user control through the interface for SQL Azure.
Ideas?
Connection String:
Server=tcp:[serverName].database.windows.net;Database=myDataBase;User ID=[LoginForDb]#[serverName];Password=myPassword;Trusted_Connection=False;Encrypt=True;
You can change connect default database, when you write 'Database' property at connection string.
SSMS is connect to database box which is option->secont tab at conecct dialog.
In my case I managed to do it by creating a login directly in the master database:
CREATE LOGIN newlogin WITH password='password'
GO
CREATE USER newlogin FOR LOGIN newlogin WITH DEFAULT_SCHEMA=[dbo]
GO
Then I created a user in the database I wanted to gain access to:
CREATE USER newlogin FOR LOGIN newlogin WITH DEFAULT_SCHEMA=[dbo]
GO
At last adding it to a role in the particular database to gain the right permissions:
Alter role db_owner add member newlogin
Hope this works for you too.
As you already discovered the DEFAULT_DATABASE option is not available in SQL Azure. So if you cannot change the connection string of your application in which you would normally specify the database name, you are stuck to master.
However... is it possible to create an ODBC connection, and configure your application to use ODBC? Using ODBC would allow you to specify a default database.
By far the easiest way in SSMS is to use the additional parameters tab and supply the initial catalog, e.g.
You can easily change the default database when loging in with SSMS. Click the Options button on the Login Dialog then click on the Connection Properties tab. In the "Connect to database" box enter the name of your database.
You have to use use following to be able to change "default" Database
Use "SQL Server Native Client 10.0" or higher instead on using "SQL Server as Driver
Use full user id like UserName#AzureConnnectString
For me it is
NorthWind#w6ywertsd8h.database.windows.net
More details here
http://debugmode.net/2011/04/22/connecting-microsoft-access-to-sql-azure/
Another option is to create a mapped user in the master database and the hosted database. This will allow SSMS to connect to the server and use master as the default db, then the user can open the database. I am not a DBA so I do not know the implications of this, but that is how I solved it. My database is just being used for a POC project so it doesn't have many security requirements.
Recently I inherited a database from another programmer (created / stored with SQL Management Studio 2008), and I am having massive difficulties accessing, modifying, or even viewing the previously created databases.
Specifically, when I try to load one of the databases in SQL Management Studio I get the following error message:
"The database [database name] is not
accessible. (Object Explorer)"
I am connecting to the SQL server with windows authentication.
Anyway, is this a permissions issue left over from the last dev? (he's unavailable, unfortunately) And is there an easy work-around short of completely reinstalling SQL Management Studio?
Edit: Update:
Upon trying to access User Mapping, as suggested below, I got the following error message:
"One or more databases are inaccessible and will not be displayed in list."
Unfortunately, none of the databases I am trying to access appeared in the list, so I assume they are still inaccessible.
It could very well be a permissions problem. If you open Object Explorer in SQL Server Management Studio and expand the Security node (the one under the server instance, not the Security tab under the individual databases) and then expand the Logins node you'll see the list of logins that have been created on the server. Have a look at the properties of each of those and check out the User Mapping information. You'll be able to see which logins are mapped to which databases. It's possible the previous programmer only granted access to the database to certain logins. If you find a login that's mapped to the database you want, try changing the password of the login and then connecting to the database with that login and password. NOTE: be careful when changing the password as it may affect production applications that are using that login and password!
This message:
"One or more databases are inaccessible and will not be displayed in list."
Means that the user you are using right now cannot access to that db. If you can enter with a user that does have access and from that user change your actual user's rights through User Mapping, then you will see it.
You need a dba (or someone with dba equivalent access) to give you rights to the database.