I have a website on a shared server . it uses Sql server as database ( also shared ) with an account limited to execute procedures . now I wonder if anyone who has access to sql server could read and manipulate my data without having my credentials ( by using thier own ) ? if so how can I track users logged into my database and more importantly stop them ?
There are two ways to connect to SQL using a SQL login or using windows authentication. These are your logins to the server. To then connect to the database you have to be granted rights to the database. So as long as your login is the only one that has been granted rights to the DB then you have no need to worry.
Depending on the rights you have on the DB could set up roles within the DB and allocate user(s) to the roles. This way the only way anyone can do anything in your db is if they are a member of the roles you have set up (or they have an SA account on the server or have also been set up with dbo rights on the database).
Again depending on what rights you have on the server you could set up a trace (google sp_trace_create and sp_trace_setevent) to capture logins to your database this writes to the harddrive of the server and then you can use fn_trace_gettable to query this data.
The problem goes beyond Execute permissions and logging access...
The bottom line is that you and your data are at the mercy of the the host. If they can be trusted and are competent, your data should be safe. However, if you are unsure, or if you are storing data that is too valuable to risk, your only choices are to either encrypt the data so that nothing useful can be gleamed from it and make sure you have a backup, or find a different host who will provide appropriate safeguards.
Related
I have a database that somebody else has built and I need to attach it on my SQL Server. The main user that owns schemas is named 'LSadmin'.
I want to use that same name for login to the server, and then have the rights for that login to access the database.
For some reason a login already exist LSadmin but it does not have any rights to access the attached database. When I want to Map the login to the database and give it datawritter and datareader for example, SQL Server shows that a user already exists.
When I try to delete the user to recreate it, then I can't because it owns schemas.
I found two ways to resolve this. One is to give the login a sysadmin rights, which of course is not desirable, and the other one is to move schemas ownership to another user, and then give database rights through mapping.
Is there any other solution that is not so "complicated"?
I am developing a multi-user-application windows desktop application.
For User Management i use the DMBS (Oracle, MySQL, MSSQL, Postgre).
So each user has an database user account.
I do not want the user to connect to the database directly and read / write data.
The data should only be accessible connection should only be valid if they use my application.
I found this website by SQLDUDE where he describes some techniques.
One way to access the data only through a specific application is a logon trigger that checks for application_name.
However he also describes that this method can easily be spoofed as the user can specify the application_name once he knows it in the connection string.
(detailed explanation here - see Solution for Scenario #2)
He also mentions Application Roles.
A more secure approach you could use for this is called "Application
Roles". When connecting from an application you assume a particular
role and only that role is granted privileges required in the
database.
So basically the user logs in with his login credentials but has no rights at all (only connect).
Then inside the application i call sp_setapprole with a password, once the connection is established so the application rules are granted.
Once this call succeeds then the connection gets the privileges of the
application role and loses privileges of the actual user, which is
what we want. So if someone tried to connect to the database from SSMS
or SQLCMD, they will access the DB using their credentials, which
won’t have the required permissions on the tables, since only the
application role has the rights on the tables. This is more secure &
reliable approach, but one that requires application code change and
as a DBA you will have to create the application role in SQL Server.
So Application Roles sounds like the way to go.
My question is:
Are application roles DMBS standard and available to most DBMS systems?
Is there way to trace the sp_setapprole login (e.g. with WireShark)?
Of course someone could reverse-engineer the application and get the credentials for the application role - but i guess that's unavoidable :)
I've seen one simpler solution in place and it worked fine. Here it is:
The application is responsible for creating users at the database
Before creating the user, the application hashed/encrypted their password, so if you chose password "123456" it would be created as "RRU2992191910" (just an example)
If the user tried to connect to the database with "123456" it wouldn't be successful
Only the application was able to connect to database, because it hashed/encrypted the password informed by the user
This is not the most secure solution in the world, but it's very simple and does what you want. And it could be ported to different RDBMS's with no extra cost.
On my production system I login to SQL Server with CPSDOM\mconnors. When I execute 'SELECT CURRENT_USER;' it returns 'CPSDOM\mconnors'.
On my test system I login to SQL Server with CPSDOM\mconnors. When I execute 'SELECT CURRENT_USER;' it returns 'dbo'.
Can someone help me understand what is going on? Is this difference based on a configuration setting?
Thanks in advance.
There's a difference between a login and a user on SQLServer.
Each database has a set of users and a set of logins. Logins are server-wide, users are per-database. The login can be your Windows user account or a SQLServer internal one (eg sa).
The login is mapped to a user for each database, so in the production system you have your windows user (the login) mapped to a user with the same name. In the test system they just mapped your login to the inbuilt dbo user.
You should not rely on your login being the same name as the windows account, when you setup security for the sql server, it will default-map your windows user to a new sql user of the same name, but sometimes people map it to pre-defined sql users, and sometimes for dev/test to one of the 'admin' users that already exist.
You can see this mapping in the security section of SQLServer management studio, or in the users section of the individual database.
How do I prevent WAN access to a particular database in SQLyog? I am able to grant full access to particular DB's, but not able to prevent them. I have a Web APP that runs on an internal server and accesses MySQL on the same server. I have created a SQL user with my workstations IP, but I am receiving access denied from dbconnect when I run the APP from my workstation.
Thanks,
Tony Cripps
MySQL does not allow connections from anything other than what you've specified. If you want to disallow access from a particular IP or network, then that mean that you've already gone and granted access to them.
Review the CREATE USER syntax, particularly the section on specifying hostnames.
Review the user accounts that you've already created:
SELECT user, host, password FROM mysql.user;
And then re-create them as necessary.
Other than than that, if you want to completely disallow WAN access then you should be looking at your firewall settings, not MySQL.
I am working on an application which bulk-loads data into a SQL Server 2008 database. It writes a CSV file to a network share then calls a stored procedure which contains a BULK INSERT command.
I'm migrating the application to what amounts to a completely new network. In this new world bulk insertion fails with this error:
Msg 4861, Level 16, State 1, Line 1
Cannot bulk load because the file "\\myserver\share\subfolder\filename" could not be opened. Operating system error code 5(failed to retrieve text for this error. Reason: 15105).
I connect to the database using Windows Authentication, using the same account which wrote the file. The file, and the folder in which it resides, grant read and modify rights both to my user account and the database server's domain service account. That service account apparently has constrained delegation permitted, which is mentioned on MSDN. Still no good. If I connect using a SQL Server account then bulk insertion succeeds, but we are trying to stick exclusively to Windows Authentication.
Does anybody have a handle on what needs to be done to make this work? How exactly does SQL Server go about accessing data on network shares, hopping between its service account and that of the connected user? I know that I can bulk insert in a similar situation in our current infrastructure, but it is so crufty with age that it would be hard to track down what has been done to enable this in the past.
Recently we had this issue for a number of our Devs. I've come up with a number of ways to allow testing of bulk inserts.
Our preference was to use a SQL service account. We set the SQL server and SQL agent to run as a service account and then allowed the devs to trigger agent jobs. The service account was granted permission to the UNC shares and this all functioned correctly. Note that the service account will always been fine running these agent jobs (assuming UNC permissions are set). It's the Devs trying to test that will come across these issues.
Another method is to create a share on the SQL server itself and point the bulk insert path at the local directory. These errors seem to only occur when accessing UNC paths. Regardless of whether the UNC path has the correct permissions to allow you access. For example we create C:\test\ as a folder on the SQL server itself and permission it to allow a dev to drop test files there. These are then called via the bulk insert command.
A command may need to be run against master to allow a SQL login group permission to bulk insert. This is as below.
GRANT ADMINISTER BULK OPERATIONS TO "domain\usergroup"
Adam Saxton's blog (about Kerberos and bulk inserts from a share) should be read: http://blogs.msdn.com/b/psssql/archive/2012/09/07/bulk-insert-and-kerberos.aspx. Adam offers two approaches:
Enable constrained delegation for the machine (as opposed to the sqlservr.exe startup) account, or use a SQL Server login. Adam mentions two other approaches (which he does not recommend).
An aside, the latter half of the OP's message "(failed to retrieve text for this error. Reason: 15105)" may be related to a SQL Server startup account lacking rights documented within SQL Server's "Configure Windows Service Accounts and Permissions" topic, such as SeAssignPrimaryTokenPrivilege.
Did you ever resolve this issue? I recently had a similar problem and discovered that the best way to resolve it was to use a SQL login.
Initially, having read the notes here I thought if I just granted read permissions to the Windows account with which I was connecting to the SQL Server that would be okay, but even when I granted read access to Everyone, I still couldn't read in the file.
I believe the reason is something to do with SQL Server impersonating the windows user and attempting to access the UNC share, which is delegation and which is not allowed unless explicitly enabled. There are some notes here which may help. This is the constrained delegation of which you speak and I couldn't get it to work either!
Bottom Line: I just used a SQL Login and made sure the SQL Server Process account had read permissions on the share (by granting read to Everyone in my case) and it worked.
In order to bulk insert with AD users, the SQL service it self has to be running as a domain user and has to have the AD permission to be able to delegate authentication. Same if you wanted to run linked servers with ad users. Here is the link for AD and linked servers, but the permission are the same.
Linked Servers and Active Directory
The server must have an SPN registered by the domain administrator.
The account under which SQL Server is running must be trusted for delegation.
The server must be using TCP/IP or named pipes network connectivity.