Oracle under OpenVMS

[Mahmoud_1]

Hi to all,
I faced a problem with one of my biggest customers who have more than 40 alpha system running OpenVMS " He renewing his servers frequently" and he bought all alpah running OVMS because he wants the security features of the OVMS. After he implements the application ( Oracle Application ) he saw the OVMS is not there because the clients connect to the server using application & Oracle authentications not OVMS authentications so he wants to see all users connected to OVMS by issue SHOW USER or SHOW SYSTEM commands, he wants to use audit and account utility to check all users.
So can we do this by any way, Because he told me that I bought OVMS for this, so another time I will buy UNIX or any other platform if I can't use these features.

Please Advice.

[Wim Van den Wyngaert · Accepted solution]

If I understand correctly, you must get the info out of Oracle. The client opens a TCPIP socket on the server and via this socket you talk with the server. The user name is validated by Oracle and not VMS.

Check http://www.integrigy.com/info/IntegrigySecuringOracleApplications.pdf
(I haven't used Oracle for 7 years)

[Willem Grooters]

If your customer uses RDB, that will authenticate agains SYSUAF by default. Otherwise, think of using the ACME authentication module in VMS, but you'll need to do some specific programming. If you're running VMS 7.3-2, LDAP as another possibility, and Oracle can handle that.
I don't know Oracle that well, but I can think of the method that database usage is something else than system usage - and so Oracle will keep authentication to itself - INCLUDING user names, that doe NOT have to exist on the system, itself. The very same will apply to Unix, so swithing to Unix won't help!

Willem

[Willem Grooters]

Mahmoud,
To clarify:

You're mixing two, in principle unrelated authentications: data access and system access.

Oracle runs it's DBMS under it's own username. Part of this is control over external connections (typically SQL*NET) that will take care of all connections.
The 'ordinary' user starts his application and will access the database using the middleware - running, indeed, as "ORACLE" (or similar), and will not login into the system to access the database. That means, Oracle has to take care of authentication. You won't see these users by their system names, since they do not log in, so SHO USERS or SHO SYSTEM won't help, simply because the do not own a process on the machine.

For database maintenance - so to acess the databasefiles themselves - you need to login onto the system, so these users - typically DBA or SYSMGR - will be traceble by SHOW USER or SHOW SYSTEM. Of course they can access the data inside the database itself, but even then, this access will NOT be traceble using OS-sepcified tools. It's even possible to block data access using (e.g) SQL, but still database files can be accessed directly.

In short:

* Accessing the DATA inside the database is controlled by the DBMS, not by the OS, since this has no means of awareness of this access.
* Accessing the SYSTEM on which the database runs, is controlled by the system; the database is not aware of the system's authentication.

This allows data access by users that have no access to the system itself, and it allows to disallow data access by users that do have access to the system.

These two are UNRELATED - but you may be able to link Oracle authentication to the OS (for VMS, you could think of ACME + LDAP). yet, I doubt you'll see the users show up in SHOW SYSTEM - unless they really logged in into the machine. It will definitely require some programming.

Having said that, you will understand that switching to another OS won't help you. Under Unix, you'll face exactly the same problem.

Willem