How is the guest account in SQL Server (2000, 2005, 2008) supposed to be used? What is it good for? I've tried enabling the account but I still can't get certain users to be able to refresh Excel 2007 PivotTables attached to views which I have given SELECT rights to GUEST.
What am I missing?
Guest is mostly just for allowing access to the database, using the Public role. Don't think it's meant to be something that users actually log in as...
When a database is created, the database includes the Guest user by default. Permissions granted to the Guest user are inherited by users that do not have a user account in the database.
It there for you to disable :)
You really shouldn't use it - grant rights explicitly.
http://sql-server-performance.com/Community/blogs/satya/archive/2007/07/31/126786.aspx
Related
How do I set up a database so that one does not have access to it? Even with installing SQL Server Management Studio on local machine.
In SQL Server with Windows user or sa can access all databases. How do you limit the access DB of the users?
For assuming that SQL Server is installed on the local machine, not on the server
You can try Single User Mode.
From the linked MSDN article:
Single-user mode specifies that only one user at a time can access the database and is generally used for maintenance actions.
Edit: You edited your question. Now it sounds more like you're asking about Security instead of how to limit the database to one user.
You can edit a user's security in SQL Server Management Studio by drilling down into Security > Logins. There you will see all logins to your instance. You can right click these entries and select Properties to made updates. The easiest way to completely bar a user from accessing any of the databases on the server is by selecting "Disabled" from the "Status" tab.
Well, if you really want to limit this to just one user, there is a simple way (but a bit risky).
Your Windows user is included in the group BuiltinAdministrators. If you really want to remove your Windows user, rerun the installation process and during the setup just change the users in those group.
But beware, you should provide another user, which has access to your database otherwise you end up with a database server without access to it.
Ater that, setup a database login and grant him access to the database you desire.
In the end, you can disable the sa login. This will prevent access with the sa account. But you should have a user which can manage logins and more. Otherwise you have no chance to recreate the password or any other administrative tasks.
I am setting up a new instance of Report Server on a new box and need to create a couple new roles. The problem is that I don't have permissions to access /reports or /reportserver:
/reports: User '<username>' does not have required permissions. Verify that sufficient permissions have been granted and Windows User Account Control (UAC) restrictions have been addressed.
/reportserver: The permissions granted to user '<username>' are insufficient for performing this operation. (rsAccessDenied)
The domain user through which I am trying to access these has been granted full local admin rights. I would assume there might be a ReportServer user group in Local Users and Groups, but one doesn't exist.
The service account is the built-in account 'Network Service'. I'm not sure if that's relevant.
Any idea how I'd access the server to begin granting these permissions?
Did you assign the permissions for the user on the report folder level? Doing this via report management URL (with Internet Explorer) by clicking the little arrow to the right of the report folder and selecting permissions.
There is a SQL Server 2005 database with mixed-mode authentication.
Among others, we have the following logins on the server: our-domain\developers-group-1, and our-domain\developers-group-2 which are AD groups.
The our-domain\developer-group-2 is added to the sysadmin role on the server, by virture of which all domain users of that group can access any database as SQL Server implictly maps the sysadmin role to the dbo user in each database.
There are two users our-domain\good-user and our-domain\bad-user
The issue is the following: Both the good-user and the bad-user have the exact same AD group memberships. They are both members of our-domain\developers-group-1 and our-domain\developers-group-2. The good-user is able to access all the databases, and the bad-user is not. The bad-user is able to login, but he is unable access any databases. By the way, I am the good-user.
How do I go about finding out why?
Here's what I tried so far:
When I do print current_user, I get dbo
When I do print system_user, I get my-domain\good-user
When I do select * from fn_my_permissions(NULL, 'SERVER'), I see permissions.
But if do execute as user='my-domain\good-user'; select * from fn_my_permissions(NULL, 'SERVER'), I dont see any permisisons.
And When I do, execute as user='my-domain\bad-user'; select * from fn_my_permissions(NULL, 'SERVER'), I dont see any permisisons.
Also, I was wondering if there is a sql command that will tell me, "hey! the current database user is able to access this database because he is a member such-and-such ad-group, which is a login that is mapped to such-and-such user in this database".
If you have the relevant permissions within Management Studio, this shouldn't take too long to work out. It sounds like the bad-user AD group has limited permissions within SQL Server.
You need to check the settings in Security in the GUI, and check the mappings for each of these AD groups - clicking on the databases to see what permissions they have on each database.
Is it possible that you simply have implicit permissions as the creator/owner of the objects, yet no explicit permissions have been granted on the AD groups/roles or to your user individually?
Is there a way to prevent users from getting into SQL Server Management Studio so that they can't just edit table rows manually? They still need to access the tables by running my application.
You can use the DENY VIEW ANY DATABASE command for the particular user(s). This is a new feature available in SQL Server 2008.
It prevents the user from seeing the system catalog (sys.databases, sys.sysdatabases, etc.) and therefore makes the DB invisible to them in SQL Management Studio (SSMS).
Run this command from the Master Database:
DENY VIEW ANY DATABASE TO 'loginName'
The user is still able to access the database through your application. However, if they log in through SSMS, your database will not show up in the list of databases and if they open a query window, your database will not appear in the dropdown.
However, this is not fool-proof. If the user is smart enough to run the Query Command:
USE <YourDatabaseName>
Then they will see the database in the Query Analyzer.
Since this solution is taking you 90% there, I would give the database some obscure name not let the users know the name of the database.
You DO NOT need to worry about them having access to the tool. Simply make sure they do not know any of the SQL logins for the specific Databases that have read/write permissions, if they do, change the password. If they have access to the DB via Windows Authentication, make sure that they are in a datareader role. You can use roles to manage what the users can do in SQL.
You can use a trigger.
CREATE TRIGGER [TR_LOGON_APP]
ON ALL SERVER
FOR LOGON
AS
BEGIN
DECLARE #program_name nvarchar(128)
DECLARE #host_name nvarchar(128)
SELECT #program_name = program_name,
#host_name = host_name
FROM sys.dm_exec_sessions AS c
WHERE c.session_id = ##spid
IF ORIGINAL_LOGIN() IN('YOUR_APP_LOGIN_NAME')
AND #program_name LIKE '%Management%Studio%'
BEGIN
RAISERROR('This login is for application use only.',16,1)
ROLLBACK;
END
END;
https://www.sqlservercentral.com/Forums/1236514/How-to-prevent-user-login-to-SQL-Management-Studio-#bm1236562
I would suggest you lock down the database and give appropriate read-only (or other) rights to the user. That way the user can still use management studio to run select queries and such.
If you don't want the user to have any rights at all then you could do that as well.
If your application is running as a service/user account then only that account requires access to the database. The individual users' account do not require any access to the database and therefore they won't even have read access. Your app will be the gateway to the data.
If the users are running the application under their user accounts then grant them read-only permission. You can simply add them to the db_datareader role.
Hope this helps!
You can deny 'Users' access rights to the ssms.exe executable file, while granting the relevant users/administrators rights to it.
If your application only used stored procedures to modify the data, you could give the end users access to run the stored procs, but deny them access to modify the tables.
Don't let them know what the database login is.
If you can't restrict the login, use stored procedures exclusively for updates and disable any CREATE,DELETE,INSERT, or UPDATE permissions for that user.
An Application Role will allow you to secure database objects to your application instead of the logged on user.
I agree with Jon Erickson as a general rule
do not allow any users access to the tables, but only allow access through stored procs
do not allow general user accounts access to stored procs, but only the account your app runs under (whether it's an integrated login or SQL login)
Make well usage of Database Roles, if Users should only have SELECT (read) access assign them the db_datareader Role. Even if they login using SSMS they will can execute only SELECT statements.
I have created a test user that has sysadmin right in SQL Server 2005 (sysadmin, because i want to profile with this user name also).But i want to restrict that test users access rights to production database.
It is under "logins" and also db name selected under the "User Mapping" tab of its properties with "db_denydatareader" default schema. But it is still can run select statements.
Sorry but once you give SysAdmin access, you've given away the farm. You'll have to create a different role for the test user and then grant access only to the databases you want.