Adding a User to a Database
- Adding a User to a Database
- Understanding the Guest Username
- About this Article
Everything you do in SQL Server is authenticated, including creation of the databases and files. Understanding SQL Server security is critical to the successful operation of your SQL Server.
After you configure login security and establish your logins, you can begin to configure access to databases. Having a login to SQL Server doesn't give you access to any databases in the server. For that, you must have a database username.
Each database has a separate access path, which is stored in the sysusers system table in each database. Logins are essentially mapped to a username in each database the user needs to access. You can create that mapping or create a user in a database by using the sp_grantdbaccess system stored procedure or the SQL Server Enterprise Manager.
Using sp_grantdbaccess
To add a user to a database, run the sp_grantdbaccess system stored procedure:
sp_grantdbaccess [@loginame =] 'login' [,[@name_in_db =]'name_in_db'] OUTPUT
In this syntax,
-
login is the login name you added earlier (either as a SQL Server login or a Windows NT/2000 login or group).
-
name_in_db is the name you want an individual to have while he is in this database (the username). If you don't specify a name, it's set to be the same as the login name.
I recommend that you set the username to the login name at every opportunity so that it's easier to follow security from logins to users in each database. You don't have to, but isn't it a bit confusing to log in as Richard but have a username of Bill in the sales database and Johnny in the pubs database? Keeping the names the same eliminates confusion (which is in everyone's best interest in a complex product like SQL Server). Of course, none of this is an issue if you use Windows users and groups.
For example, if you want Bob to be able to access the pubs database on your server, run
Use pubs EXEC sp_grantdbaccess 'RHOME\Bob'
In this case, you should get
Granted database access to 'RHOME\Bob'.
You can do the same thing with a group:
EXEC sp_grantdbaccess 'RHOME\Marketing'
Again, you should receive a success message. After you add a group, every member of the Windows group can access the database, but only the group has a database user—that is, an entry doesn't exist for every user of the group, but simply the group itself, just as was the case for logins.
To remove someone's database access, you would run the sp_revokedbaccess system stored procedure:
sp_revokedbaccess [@name_in_db =] 'name_in_db']
In this stored procedure, name_in_db is the name of the database user to remove.
Only members of the db_accessadmin and db_owner roles (or the sysadmin fixed server role) can run either of these system stored procedures.
To see which users are in your database and which login they belong to, you can run the sp_helpuser system stored procedure:
sp_helpuser [[@name_in_db =] 'username']
Here, username is optional and is either a username or role name.
If you don't specify a username, a report of all users and roles is produced. Otherwise, you get a report for a specific user or role.
When you create a database, one user is already there. One of these users is named dbo (for dataBase owner). The dbo user is mapped to the sa login by default. When you install SQL Server, the sa login is considered the owner of all databases. If another login were to create a database, that login would be the owner of the database. Within a database, there is nothing the dbo user can't do. This user is as powerful as the sysadmin role members within each database. However, only members of the sysadmin fixed server role have certain systemwide privileges.
NOTE
In SQL Server 7.0, another user known as INFORMATION_SCHEMA existed by default in each database. This username exists as the owner of several views used to provide system catalog information compliant with the American National Standards Institute (ANSI) specification. In SQL Server 2000, the views owned by INFORMATION_SCHEMA exist only in the master database, although if you query them, they always show you information about the database you're now working in.
Now try to create a user in the pubs database. You should already have a login named Don in your SQL Server. Start the SQL Server Query Analyzer, and run the following T-SQL statements:
USE pubs EXEC sp_grantdbaccess Don
This example adds the new user Don to the pubs database, mapped back to the login ID of Don in the sysxlogins table in the master database. You can verify it by running sp_helpuser in the pubs database (see Figure 1).
){kind=link}
The results of sp_helpuser.
You can see that Don has been added as a user to the database, with a login name of Don. You can probably see why it would be confusing to use different names here.