We are trying to shape up an old, 2 tier, Delphi based application. It originally uses database authentication, we'd like to transform the db user accounts to global users, so an OID server could perform the authentication instead of the database.
The Delphi program can no longer log into the database if the account is a global user. I'm trying to understand the login protocol, so far without results.
Similar thing happens with SQLDeveloper, I can't connect as a global user. SQLPlus however works with both kinds of users. We checked the information flow with Wireshark. When the dbserver asks back for a password, the SQLPlus sends it, while the SQLDeveloper doesn't send a password when attempting to connect as a global user.
The client sends the application name too in the login request. Is it possible that we have to store the client app name in the LDAP itself?
To connect to Oracle using OID, application must properly configure OCI (Oracle Call Interface). The data access components (which one ?), you are using, must set OCI_ATTR_DISTINGUISHED_NAME session attribute. If that is not done, then you will be not able to connect to Oracle server using ODI and OCI.
You should check your components documentation for this feature. And if it is not implemented, then discuss this issue with the components vendor. Actually, there is not much work to implement, but some work to setup testing environment is required ...
Related
I'm trying to see if I can use VS Code to connect to the Oracle databases we use at my job. I installed the Oracle Developer tools extension for VS Code, but when I click to add a connection it is required that I use a service name.
VS Code Oracle Connection Form
Does anyone know of a way I can use SID instead of a Service Name? All of our connections use SID.
I've tried the different options for connection type, however they all ask for fields that are not required of me to connect to the db. I've also used the SID as the Service Name, but was still unsuccessful in connecting.
All of our connections use SID.
is something you should be looking at addressing as a side project. Services over SID became recommended in Oracle 8i (yeah you read that right...20 years ago)
But every database has an implicit service name equivalent to the SID so just entering the SID value should still get you connected without issue.
Of course, now that we're in the world of pluggable databases, this will pretty much force your organisation to move to services, because the SID is typically going to point to the root container whereas you will want to connect to the pluggable(s) that sit underneath it.
I need to create a user in an oracle database that only allows connections through JDBC and not through some IDE for example, is this possible?
There's no good, foolproof way to do what you're asking (limit connections based on connection protocol, or other client-side parameters). Any of the session parameters that you could base a database logon trigger or smart application role on can be spoofed or altered to bypass your security filter. The generally accepted approach is to secure a user account's permissions so that it doesn't matter how they connect - their access to and view of the data is always the same.
If you want to limit access just to your application server, do this using firewall rules on the database server that only allow inbound connections from the app server IP on the database port, or (if you have Enterprise Edition) use Oracle Connection Manager to filter access by IP address and Oracle Service Name.
Basically it hard to set this up really securely.
You can use such an approach:
Create DB user with no privileges on Application schema (except for connect)
Grant user password protected ROLE: APP_ROLE. Having access to APP_SCHEMA tables.
In your app, after DB logon execute:
SET ROLE APP_ROLE IDENTIFIED BY "some role's password";
Then execute:
ALTER SESSION SET CURRENT_SCHEMA='APPL_SCHEMA';
So even if anybody know username and password for database, he can connect, but is not allowed to see any data. APP_ROLE's password is hard-coded in your app, or is passed to your app from outer source (config file or databases global context).
So basically you need two passwords to access database data:
user's password
role's password
We are in the planning phase of configuring our soon-to-be-upgraded databases (19c) to authenticate directly against AD (no oracle proxy). I have read a handful of documents from Oracle on how to do this. Most of the documentation focuses around using passwords (password filter/verifier). The only problem is that our AD administrators are dead-set against implementing Oracle's password filter into our existing AD infrastructure. That being said, one of the security guys said we could implement the oracle authentication using Kerberos instead. From what I have read, and the documents are scattered all over the place, and nothing that detailed, to use Kerberos:
1) The client no longer uses a username/password - they connect using a wallet-style connection (e.g. /#dbname)
2) Not only does the Oracle DB need some configuration changes, but so does every client that plans on using Kerberos
I don't know anything about Kerberos, how it works, and what goes on when you implement this, but I was hoping for, at the end of this is:
1) No client changes/installs (only the oracle DB would have config changes)
The user will continue to provide credentials as before - completely transparent
2) No need for the password filter as our admins have a "beef" against it
So my question is:
If using Kerberos directly against AD on >=18c:
1) Does the client user still provide a username and password to authenticate against AD, or does the client simply get "accepted" due to the tickets/tokens/configuration that occurs on the client (i.e. the client is simply trusted)?
2) Is there client config changes that need to occur, or does the client reach out to the DB and the DB, with its config changes, does all the legwork to authenticate against AD based off of client info being passed
3) Does any additional manual component need to occur on occasion (periodically retrieving a ticket/token/something) (because, say, it expires)
So in the end, we want to have complete transparency with every client and using something other than the password verifier with AD.
Thanks in advance.
-Jim
It sounds like you want to authenticate Windows clients against an Oracle database over a network using Active Directory without making any client changes.
This is pretty open-ended and complex StackOverflow question.
Probably you've been reading the docs about Third Party Network Authentication using Oracle Advanced Security. You can use Kerberos, SSL, RADIUS, PKI, etc. For most of these options, you need to do some setup on the client, because both the Oracle client and server need to authenticate or verify with the third-party system.
I think you need Enterprise User Security (using Oracle Internet Directory). Assuming you go with password-based authentication, you don't need client changes. In this scenario, Oracle Internet Directory can synchronize its user directory with AD, so your users can use their same username/password. However, when they change their AD password, they'll need to change their Oracle password separately.
On a different note, you may be able to alleviate your AD admins' fears about Oracle password complexity requirements, since you can change or remove those to fit your AD requirements.
To understand the question, consider this scenario. Two employees log in to an Application server via Windows Remote Desktop Client. Both use the same username e.g., Salesmen. From the Application Server, they launch the ERP application that connects to a Database (located in the Database Server).
Now, if we want to record a log of some of the activities made by each individual salesmen, we can't use SYS_CONTEXT('USERENV','OS_USER') in Oracle because it will return the same OS name i.e., Salesmen.
What I am looking for is to know the Terminal RDP Client Name, who has logged in as "Salesmen" into the Application Server. I tried dbms_system.get_env to get %CLIENTNAME% environment variable but it is also of no use as it is returning null. Is there any other way of identifying who is remotely logged in to the Server having Oracle Client..
I am trying to setup Kerberos authentication for my Oracle database and I have a situation where I need to maintain different versions of sqlnet.ora for each kerberos user connection. My application is using OCI driver (a single unix process does more than one user connection to the same Oracle database). And I am not able switch sqlnet.ora between user connections using setenv(TNS_ADMIN) call programmatically. I am assuming once the contents of sqlnet.ora gets loaded to process, it remains unchanged for the rest of its life.
Is my case a practical one, has anyone encountered?
When it comes to kerberos, I am not sure why Oracle client restricts the sqlnet.ora to one principal kerberos user. Maybe Oracle does not have a clean support for kerberos as I dont see OCI API's?
Thanks
Srivatsan