I'm working on a Windows application. When I give this software to the client it is necessary to give database also? I want to lock the database of SQL Server on his computer so that he can not open that database or copy or view its schema or anything by which he can access that database.
When he tries to access that, it must ask for a password. So, what is the solution for the above?
SQL Server databases cannot be password-protected - they're not just files that get opened (like dBase or SQLite)
"normal" access control is handled via permissions and users - you can define who can see what, modify what, delete what
This does not however prevent a system admin from looking at your database schema and contents; there's really no way to prevent this, a sysadmin can also just copy the .mdf file to another server and attach it there and circumvent all your "security"
if you really must hide all of this, don't deliver a database - hide the database in your own company and provide a web-service based interface to the customer who can then call those web services to do his work - then the schema and data is under your control, but also: the customer's data is no longer under his control so he might not like that.....
Related
On SQL Server 2008R2, we have a SQL login tagged with the sysadmin server role. Anytime a db is created, this login is automatically added as a user to the db. Is there a switch that will prevent this from happening?
EDIT:
Based on the answer below, I am adding more background info to explain why we want to do this.
When we publish to a new database from a Visual Studio SQL project, the publishing engine wants to add a user to the database. The username already exists as a login to the database (in the sysadmin server role -- and not much we can do about that), so the publish fails as the user gets auto-added by SQL server after the 'create database' statement. I was hoping for a switch that would tell SQL Server to not add the user automatically. So it seems we will have to find another solution on the VS side that tells the publishing engine to ignore the SQL DB user.
Assuming you're talking about the sql-server role, I don't think so. TBH if you're contemplating keeping a sys-admin out of a db, then you've got a different problem than the one you think you have...
I have a resolution to this. Download the latest SSDT package from MS and now there are new options under the Publishing Wizard Advanced... button to exclude the publishing of logins, roles, etc. The SSDT package I downloaded I found here...
https://msdn.microsoft.com/en-US/dn864412
Oracle SQL Developer 4.0.1.14
I currently have an Oracle database with a user who contains a set of tables, views, etc. However, I would like this schema to be shared among multiple people with different logins.
My company has a domain and each employee logs into their computers through this domain, for example
COMPANY_NAME/username
I am hoping to be able to use windows authentication to log each user into the database. This way everyone at the company will automatically have a login with a password they are used to.
In Oracle SQL Developer, I have tried ticking "OS Authentication", and received "Invalid username/password" upon testing the connection. Do I need to create an Oracle user for each domain?
I have also tried checking "Use OCI/Thick driver", but it cannot be checked unless "Use Oracle Client" is configured, which I'm also unsure about.
This question appears to be a duplicate:
Windows Authentication to Oracle for domain group, however the tutorial link is dead. I have not been able to find another tutorial for how to set this up anywhere.
There is a server-side parameter called os_authent_prefix that is typically set to OPS$, and the network user id needs to be prefixed with this in addition to having the IDENTIFIED EXTERNALLY option added to the create user statement.
So if your Windows account id is hambone, then your OS-authentication login would be OPS$hambone, and you don't need a password. I used it for years, and it never required the domain to be specified for a Windows account, which was nice because it meant the same credentials worked for my Unix account.
SQL*Plus, for example would look like:
sqlplus OPS$hambone/#myserver
Likewise, connection strings for applications just have nothing for the password.
For Toad, you would put OPS$hambone as userid and leave the password blank. SQL Developer, I'm honestly not sure -- I can't stand it; I use PL/SQL Developer, but with the various options they have I'd imagine you select OS authentication and/or put the OPS$hambone.
Read the caveats/security warnings on OS authentication. I think in a private network the risks are outweighed by the advantages, but that's for you to decide.
I have an ASP.Net MVC 3 application. I have created a setup for it and installed on my webserver.
When I access the application from a web browser at "http://localhost/myapp", it works.
But when I tried from another machine, like "http://mywebserver/myapp" it's giving an error:
The model item passed into the dictionary is of type 'System.Web.Mvc.HandleErrorInfo', but this dictionary requires a model item of type myapp.Models.ErrorModel'.`
As per:
http://blogs.msdn.com/b/dataaccesstechnologies/archive/2012/08/09/error-quot-the-underlying-provider-failed-on-open-quot-in-entity-framework-application.aspx
It could be a permissions issue on the new server, etc
Solution 1:
In the existing connection string to remove the “user Instance=true” and it works.
Probable cause of the issue could be as below:
The user instance cannot attach the database because the user does not have the required permissions. The user instance executes in the context of the user who opened the connection—not the normal SQL Server service account. The user who opened the user instance connection must have write permissions on the .mdf and .ldf files that are specified in the AttachDbFilename option of the connection string.
Another common issue is when you open a database file successfully when the database is attached to the SQL Server Express instance, but fails when you try to open it from the Visual Studio IDE. This might occur because the SQL Server Express instance is running as "NT AUTHORITY\NETWORK SERVICE," while the IDE is running as windows account. Therefore, the permissions may not work.
A variation of this issue is when the user that opens the user instance connection has read permissions on the database files but does not have write permissions. If you get a message saying that the database is opened as read only, you need to change the permissions on the database file.
The other main issue with user instances occurs because SQL Server opens database files with exclusive access. This is necessary because SQL Server manages the locking of the database data in its memory. Thus, if more than one SQL Server instance has the same file open, there is the potential for data corruption. If two different user instances use the same database file, one instance must close the file before the other instance can open it. There are two common ways to close database files, as follows.
User instance databases have the Auto Close option set so that if there are no connections to a database for 8-10 minutes, the database shuts down and the file is closed. This happens automatically, but it can take a while, especially if connection pooling is enabled for your connections.
Detaching the database from the instance by calling sp_detach_db will close the file. This is the method Visual Studio uses to ensure that the database file is closed when the IDE switches between user instances. For example, you are using the IDE to design a data-enabled Web page. You press F5 to run the application. The IDE detaches the database so that ASP.NET can open the database files. If you leave the database attached to the IDE and try to run the ASP page from your browser, ASP.NET cannot open the database because the file is still in use by the IDE.
I've used TEXT_IO package for creating files in the local(client) machine. From the documentation http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/u_file.htm#BABBBABB I see that it is "available for both client-side and server-side PL/SQL". What does this mean?. Does it mean I can use it to create file in both client and server side? If so, which method/option should I use to create a file in the client side. Thanks.
UTL_FILE is a PL/SQL database package. It can read from or write to any directory which the oracle OS account has the matching privileges on. In practice this means directories on the database server, although directories on other servers - or even your local PC - can be shared with that server, through the good graces of your network administrator, and the DBA creating the appropriate Directory object.
TEXT_IO is an Oracle Forms package for writing to the client. Naturally it only works in client/server versions of the product, although the webutils library provides an implementation which can work in webform deployments.
The oracle OS account is the user which installed the Oracle software. We create the account before running the OUI. The oracle user has no direct relationship to any database accounts.
Processes inside the database can only read or write files in directories which the OS account can access. These processes include UTL_FILE, Data Pump, external tables, Java stored procedures running OS commands and extprocs, as well as background things like the alert log, dumps and trace files .
No, I think it means that UTL_FILE and TEXT_IO provide equivalent functionality for server and client respectively.
Does anybody knows how could I make a trigger or anything else to prevent people to connect on my database with any kind of applications besides mine?
Note that the super-old-and-unsecure trigger to block few .exe such TOAD or watever does NOT really works, since you can just rename the EXE to MyApplication.exe.
Hints?
An easier method would be to move the security to a role that can be enabled only by your application - see a previous answer of mine here
WIth this method another application may create a session but has no other privileges since the role is not enabled.
You may wish to consider Oracle's Secure Application Roles -- it won't prevent people from logging into the database through a rogue application, but it can prevent them from accessing tables and packages if the application doesn't set the role using the password that only it knows.
You can find an tutorial on deploying it here, although to secure it, you'd have to create the role with a password, and your application would have to know the password when issuing the SET ROLE rolename IDENTIFIED BY rolepassword; statement.
I don't know that Oracle has any functionality to help with this (I could be wrong though) so the next best thing might be to write a small server app that lets you have much better control over the login process and acts as the middle-man between the client apps and the database server. That way, all connections to the database come through your server app, and you can control how your server identifies which client app is legit. This will add a bit of complexity to the system though.
If you don't trust the program name in v$session then the only options that come to mind are to have your application encode the password, so that what they type in isn't actually what's used to connect to the DB; or have your app log in with a private username/password and authenticate users against your own users table instead of having Oracle user accounts for them. Both options make management of accounts more complicated though.
When your application logs on, you call a stored procedure that associates the current oracle session as a "trusted" session. Do this by creating a trusted sessions table with a field for sessionID and trusted bit (and optionally a random hash to prevent user tampering).
Create a system wide trigger, that checks the your current session id (and random hash) to detect if it is trusted. If the session doesn't exist in the table, you don't allow the query, and log off the user.
You should also setup a shutdown trigger to clear the trusted session table on exit.