My SQL Server is operating in mixed mode, and I am accessing all my databases with Windows authentication, but I want to restrict one of my database to be accessed by Windows authentication and it should be accessed by SQL Server login user.
I have created a new user and then assign him the rights to access database
from security tab. But this database is also accessible from Windows authentication.
You have to go to DB properties and then flag the security options in the authorization tab.
So, first of all, right click on db name and go to properties. It will pop-up another window with the authorizations tab. Here you can select every single user and decide to grant or not access/modifying ecc...
Related
Is it somehow possible to change the security setting for a single (already existing) user from SQL Server Authentication to Windows Authentication?
The security setting on server-level is set to mixed mode (so both SQL Server Authentication and Windows authentication). For a new login I can choose which authentication mode to set.
But for an existing user (a login that is, created with SQL Server Authentication) the radio-buttons are greyed out. I would like to change this for a number of users without having to recreate these users, but I can't seem to find how this can be done.
Any help would be greatly appreciated.
Using the example below, which is in my App.Config file, are the uid and password values for the SQL Server, or the SQL Server instance, or for the database that is on the SQL Server?
value="server=localhost;database=myDb;uid=myUser;password=myPass;"
Thanks,
ADawn
Sql Server separates the concept of a login from a user. A server instance itself has logins. Individual databases hosted on a server instance have users.
When you want to run a query or otherwise interact with a database, you generally first connect to the server. You supply a username (uid) and password that match a server login. This login in turn maps to a user in one (or more!) databases hosted by that server.
You can see the user mappings by opening Sql Server Management Studio and connecting to your server. In the Object Explorer area expand the Security and then Login folders (just under "Databases"). Double-click a login to open it's Properties window, and find the User Mappings section.
The connection string also includes a database. The purpose here is (again) because a login might map to more than one database. Specifying a database as part of the connection provides context, so you don't need a database name with every table reference in your SQL code.
There's also Windows/Active Directory authentication (Integrated Security). This makes things even messier, because you can set up Active Directory groups (in addition to users) as server logins to manage access for a number of people at once. An Active Directory user can belong to more than one of these groups... and thus map to more than one user in a single database. In my experience, when this happens you tend to get the union of the set of permissions from every database user you could claim, but I haven't studied that situation thoroughly.
server=localhost;
This is the location of the server. You can use the IP address or the name of the computer. Localhost means this code is on the same machine as the SQL server
database=myDb;
This is your database. Such as master (which is a system one)
uid=myUser;
This is a login on the SQL server. Make sure that login has permissions to the database you are trying to access (and subsequent tables). See the picture below, that is a login abc_test.
password=myPass;
The password for the above user
It is possible to have those Logins as Windows Authenticated logins but in my experience in code it's usually SQL Server authentication (mixed mode) logins.
As sniperd said You can create a new login with a new username and password by right clicking on Logins. Or you can use an existing Login name and change its password. Hope this gonna work!
See image.
How does a dba go about granting access to the screen shown.
This is for a generic user using their AD credentials to access the 'Reporting Services' on a particular server. This is so that the generic user is able to create new 'roles' for SSRS. Currently only the administrator has access.
The image you showed belongs to connection to SQL Server which manage sql databases.
In most cases the reporting services installed on the SQL SERVER but it not mandatory. The reporting services server can be a dedicated one apart of the SQL Server.
The image you shown is the connection window to SQL SERVER
There Two option to perform a login:
Windows Authentication - (Uses the loged on user to the machine) A DBA needs to allow this user or a group which this user is a memeber in to connect the SQL server. In addition he need to configure which database is available to him.
The second option is to set a SQL User and to give him permission to manage databases.
Setup a login on SQL SERVER
The Reporting services has Report manager URL, which allows to manage report existing or add new reports ect..
In order to allow users to access the URL, you need to allow a specific user or a group to access the report server manager
Granting permission to the report manager
How to grant YOU access to a database
Open SQL Management Studio
Your DBA should login with his permission (sa/admin permission)
Expand "Security" Tab
Right click on "Login" folder and choose "New Login"
Click on the "Search" button next to the "login name:" field
In the text area search for you AD username
Click "Ok"
Choose desire master database
On the left panel choose the "User Mapping" option
Choose desire Database on the upper section
Select proper permission on the bottom section for example "db_owner"
After this you can create a data source with Yours user name
Does it what have you looked for?
Looks to be assigned to the System Administrator System Role by default:
Connect to a Report Server in Management Studio.
So adding users/groups to that role should allow them to connect and create new roles. They'll be admins on the Report Server itself, but at least not on the underlying server.
I have a .NET application which connects to SQL Server 2008 for storing some data. I use SQL Server authenthication providing an sq username and a password to my end-user in app.config file. If something more needs to be changed I give to the end-user some other credentials.
How can I limit the sql user to only have permission to read/write data and executing existing stored procedures and everything else to be forbidden?
What is the best practice for setting permisions for a sql user that an application is using to connect to a database? Can I prevent somehow the user from logging in Management Studio and mess with my data?
I'm not searching for the perfect 100% reliable solution, but the best existing practice to do this. Thank you very much in advance.
Update: I work on a shared hosting SQL Server environment.
You'll need to create a new SQL user, something like 'LimitedUser'. To do this in SSMS, select the Security Folder of the server you are using, right-click, select New, select Login.
Select your authentication type (SQL server authentication is easily managed), and set the Default database to your database.
You'll need to set Server Roles so this new user only maps to your DB, and in the last page (Status), set Login to false so they cannot use these credentials to login to SSMS and 'mess with your data'.
Click OK, and you're done creating your limited user.
Assign it to your database, and then in SSMS, right-click on your db, select Properties, Permissions.
Select your user or role, and in the permission grid below, switch on only what need to be switched on.
As I see, your question is fully concerned with SQL server security.
You can limit user permissions on server, database or object scope, using GRANT statement, server or database roles. For example, you can assign db_datareader role for user, and then grant EXECUTE permission to this user for some stored procedures (or for entire database).
The current practice in my organization is to create the database roles (e.g. application admin, operator, and so on), adding the appropriate permissions to these roles and then assign these roles to database users.
I'm not completelly sure that you can prevent login into SQL Server Managent studio (SSMS), but SSMS wll not display information that must be invisible for user with user current permissions.
Shared SQL Server hosting where a single instance is shared among multiple customers is not compatible with with typical client-server applications. You are expected to perform all operations through a middle tier server such a WCF Data Service and maintain user accounts within your database in a table with Forms Authentication etc.
For your client-server application you need VPS hosting with your own instance of SQL server where you can create server-level logins. Without creating server-level logins there is no method to secure a client-server application. Any workarounds are just pseudo-security.
I'm trying to restrict access to a database on my server to only allow users from a specific Windows group.
I have enabled Windows authentication for the server, but it seems as if I can only allow access to specific users, not specific groups...
Is there any way I can do this?
Most of the resources I've found contain SQL Server 2005 specific instructions, and I have thus far been unable to translate them over to 2008.
Do the following:
In the New user Dialog click the Search button.
Then click Object Types.
Select Groups, deselect Users and Built-in Security Principals
Click Ok.
Then click on Find Now
At this point you should see a list of groups available.
Pick the one you want and click OK.
Assign rights as necessary.
SQL Server 2005 and 2008 are essentially the same here.
USE master
CREATE LOGIN [domain\group] FROM WINDOWS
GRANT CONNECT SQL TO [domain\group]
USE MyDB
CREATE USER [domain\group] FROM LOGIN [domain\group]
GRANT CONNECT TO [domain\group]
This will allow everyone in the windows group to connect to your database. Is that what you want?
Or do you want to deny some folk access, which I thought at first...