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.
Related
I have two users on windows server
Administrator
devUser
Both can use SQL Developer to connect to Oracle 11g Server (Oracle e-Business suite) but in the same query (from synonym) they got the difference result: devUser got the correct result and Administrator got null in first three columns.
SELECT * from XXAUTO.XXFND_OU_COMPANY_V
where ou_name like 'ASL%'
Query Result from Administrator(Windows User)
Seems like the view has some form of VPD in place. Oracle supports Fine-Grained Access Control through its DBMS_RLS package, which despite the name allows us to implement security policies on columns as well as rows (since 10g). Find out more.
The common model is, when users connect to the database a LOGON trigger populates an application context with details about them. These details are used to generate as additional filters on tables and views which have security policies in place. You can confirm this by using the pertinent views: start with ALL_POLICIES and drill down depending on what you find.
It's possible the view implements a hand-rolled version of this (FGAC is an Enterprise Edition feature) but if you're using EBS that seems unlikely.
Another option is that your database is protected by Oracle Database Vault. This product is a chargeable extra to the EE license. It is a very powerful tool, and one of its uses is to prevent super users like sysadmins or DBAs abusing their privileges to look at sensitive data. It seems unlikely that an organisation would put Database Vault in place on a server that developers have access to but I offer this suggestion for completeness. Find out more.
Thank you for all.
Now I found the problem that is both user set the different Windows locale.
We have a requirement to make our products work on Oracle as well as SQL Server (around which they were originally built). Unfortunately we don't have any in house Oracle development experience to speak of but as a senior dev it has fallen to me to lead the project. So far I have managed to make our app connect to an Oracle database (I'm using Oracle XE 11.2) by using the following connection string:
Data Source=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=VS010-ORA11GR1)(PORT=1523))(CONNECT_DATA=(SERVICE_NAME=DEVORA)));User Id=dbo;Password=dbo;
The reason we decided to use this type of connection string is because we do not want to rely on changing tnsnames.ora on every client machine. However, as you can see this specifies an Oracle user and associated password. We also need to provide the ability to use the equivalent of SQL Server integrated security.
According to the literature I have read, to do this I simply need to specify / as the user id and then omit the password portion (as this is ignored anyway for Windows authentication). I also created the user in Oracle, making sure it matched the Windows user, with the following snippets:
CREATE USER "OPS$<DOMAIN>\<user>" IDENTIFIED EXTERNALLY;
GRANT CONNECT,RESOURCE TO "OPS$<DOMAIN>\<user>";
I also checked that the sqlnet.ora file on my local machine which hosts the XE instance and my dev environment contained the line:
SQLNET.AUTHENTICATION_SERVICES= (NTS)
I understood that this would enable my app to connect to the Oracle database uing Windows Authentication. However what actually happens is that I get the following Oracle error message:
ORA-01005: null password given; logon denied
this doesn't make much sense because of course its null - it's supposed to be, according to the tutorials I've read.
The app targets .Net Framework 3.5, we are using the System.Data.OracleProvider and the actual connecting and so on is handled by Enterprise Library 5. Incidentally, I am aware of the deprecation of the OracleClient component but I just want this to work before I go into the extra complexities of changing providers.
Can anyone tell me what I'm missing? Have I chosen the wrong type of connection string? I apologise for any basic mistakes but I have always managed to avoid Oracle until now so my knowledge of it is close to zero.
Many thanks
I had the same problem and solved after adding this to conn. string:
Integrated Security=yes
To expand on the answer above by #Stikut. I tested this out with NHibernate 3.3.3.GA and it works.
user id=/;password=;Integrated Security=yes
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.
We want to allow DB access (Oracle) to our users only through our own application - let's call it "ourTool.exe", installed locally on the users computers. Currently, the users must provide username/password whenever they start "ourTool". The provided password password gets decrypted and we use username/decrypted-password to finally log in to the Oracle DB. This approach prevents the users from directly accessing our DB using third party tools (SQLplus, Excel, Access, ...) and everything in the DB is guaranteed to have been entered/edited using "ourTool".
Now, one of our clients wants to allow its users "single sign-on" (with SmartCards/Oracle PKI). With this, the user will be able connect to our DB without providing any password every time they start "ourTool". But the same will be true for the potentially dangerous tools like SQLplus, Excel, Access, etc.
Is there a way to prevent this? How can we make sure that every record in our DB is only created/edited/deleted using "ourTool" in this scenario?
Since it's your application and you have control of the source, you can use either password protected database roles or Secure Application Roles that are enabled from ourTool.exe. (see http://www.oracle.com/technology/obe/obe10gdb/security/approles/approles.htm ).
For example, with a password-protected database role, the initial connection would be with only the CREATE SESSION privilege, and then ourTool.exe would issue the SET ROLE with password known only to you. Any other application doesn't have the information to set the role. Obviously, the privileges are granted only to the role and not directly to the user in this configuration.
By default, OCI transmits the calling application EXE name and you can access it by querying v$session:
SELECT program
FROM V$SESSION
, which you can do in an AFTER LOGON trigger.
But this can be easily overriden and should not be relied upon.
I renamed my sqlplus.exe to myTool.exe and after making a connection with myTool.exe
SELECT program
FROM V$SESSION
where username = 'SYSTEM';
Returns:
myTool.exe
So be aware, as Quassnoi said: although usable in some circumstances it's certainly not bullit proof.
I know that it is possible to use "OS authentication" to authenticate Windows users in Oracle database. The process is basically passing current Windows user id to Oracle for authentication.
The question is - is it possible to authenticate domain group in Oracle (as it is possible with SQL Server integrated security), so that there would be no need to create separate database user for each domain member?
It is possible.
Oracle has a whitepaper on this, and here's a tutorial,
I don't think this is possible, but I would love to be proven wrong.