In the big picture, you need to:
- Download the free Microsoft SQL Server Management Studio and install it, accepting the defaults
- Connect to your SQL Server
- Create a low-privileged login so that you don’t accidentally drop objects
- Learn to switch back & forth between the low-privileged account and your regular one
Let’s get started!
1. Download and install SSMS (but not on the server itself)
The first step is really easy: go here to get the latest version of SSMS and install it. If you already have a version of SSMS, the installer will automatically update it to the latest version. It doesn’t matter what version of SQL Server you’re running in production: as long as you’re running a currently supported version of SQL Server (2012 & newer as of this writing), you always wanna run the latest version of SSMS, which will include a ton of bug fixes.
Do this installation on your desktop or laptop, not on the SQL Server itself. Over time, you’ll learn that running SSMS (as with any other app) on the SQL Server itself will slow it down. You wouldn’t remote desktop into the SQL Server and start playing Fortnite, now, would you? Don’t answer that. You probably would. You’re the kind of person who reads this blog, after all, and I … let’s just stop there. Install SSMS on your desktop.
2. Connect to your SQL Server
After launching SSMS, you get a connection dialog:
Server name – the DNS name or IP address where your SQL Server answers connection requests. This is usually the same as the server name itself, but if you have fancier setups like named instances or non-default port numbers, you’ll need to specify those here.
Authentication – probably Windows, try that first. If that fails, you either don’t have access to the server, or it’s configured with SQL authentication. You might have a username & password on a post-it note somewhere, like from the person who installed it, and it might have a username of “sa”. In that case, go ahead and use that for now. In the next step, we’ll set you up a low-privilege account.
Click Connect, and you’ll be handsomely rewarded with a window that looks like this:
At this point, you’re able to do … all kinds of dangerous things, actually. We need to fix that so you don’t do something stupid.
3. Create yourself a low-privileged login.
Start a new query by clicking File, New, Database Engine Query, or right-click on the SQL Server name and click New Query:
You’ll get an empty new-query window. Copy/paste the below into your new query window so we can find out if you have Windows-only authentication turned on:
SELECT SERVERPROPERTY('IsIntegratedSecurityOnly')If the result is 1, that means your SQL Server only allows Windows logins. In that case, I deeply apologize, but I’m not covering that yet in the scope of this blog post.
If the result is 0, good news! You can create SQL logins. To do that, copy/paste the below into your new-query window, and note that you have some changes to make:
USE [master] GO CREATE LOGIN [brent_readonly] WITH PASSWORD=N'changeme', DEFAULT_DATABASE=[tempdb], CHECK_EXPIRATION=ON, CHECK_POLICY=ON GO GRANT VIEW SERVER STATE TO [brent_readonly]; GO
Change brent_readonly to be whatever username you want: typically your regular username, but append _readonly to it so you know that it’s your less-privileged account. Note that you have to change “brent_readonly” in two places.
Change the password from “changeme” to whatever you want.
If you get an error that says:
Msg 15118, Level 16, State 1, Line 3 Password validation failed. The password does not meet the operating system policy requirements because it is not complex enough.
Then you need to use a more complex password.
Finally, let’s make sure the new login can’t write anything in your existing databases. Copy/paste this in, change brent_readonly to your login name (note that it’s in 3 places), and run it:
sp_msforeachdb 'USE [?]; CREATE USER [brent_readonly] FOR LOGIN [brent_readonly]; ALTER ROLE [db_denydatawriter] ADD MEMBER [brent_readonly];'
That only affects the databases you have in place today. If someone restores a database into this environment, you’ll be able to write to it. If you’ve got some time and you’re willing to roll up your sleeves a little, here’s how to deny writes in all new databases long term.
4. Learn to switch back & forth between accounts.
Now that you have a low-privileged account, you’re going to want to use this by default when you connect into SQL Servers with Management Studio. This helps prevent you accidentally causing a resume-generating event.
Close SSMS, and reopen it again. This time, at the connection dialog:
Choose SQL Server authentication because we created a new SQL login, and then type in your low-privileged username and password. Click Connect, and you’re now working a little more safely, without the superpowers of your regular domain login.
If you do need to switch over to your regular high-permission account, you could close SSMS entirely and reopen it, but there’s an easier way. To change accounts for the current query window, click the change-connection button at the top right. It looks like a plug/unplug button:
That’ll give you the connect-to-server dialog box. Note that the login change only affects the currently open query window: that’s the safest way to minimize the damage. Then, as soon as you’re done doing high-permissions stuff, close that window, and you’re back to your regular low-permission stuff.
Next steps for learning
Now that you have an account that’s safe to use for learning, here are a few next steps of tools to explore on how to get to know your SQL Server better.
- How I Configure SQL Server Management Studio – my setup tips
- sp_Blitz – totally free health check script that warns you about dangerous things in your SQL Server that may present problems later
- How to do a health check – my free process for writing up a SQL Server’s health and performance issues
This week's sponsor: Get your free e-book and learn a reliable and repeatable method for analyzing and addressing performance issues in your SQL Server environment.