psuedo setup on openVMS

[SAMI AHMAD]

our requirement is for auditing .if two dba's login into oracle account we can't audit who did what, but if a dba first login into his/her own account and then do a sudo to the oracle account then we can audit that usage right?
I am testing the HGLOGIN and will let you know if it gives the complete oracle enviornment or not .

[Robert Gezelter]

Sami,

There may be a variety of ways of accomplishing that particular goal if it is only a documentation requirement.

In that case, the information could possibly be derived from the accounting or login records (in the case of a DECnet login, for example, the ID of the remote session -- DECnet Node ID and Username) is available as a JOB logical and using F$GETDVI, if I recall correctly.

This could be written to the log during the login process.

- Bob Gezelter, http://www.rlgsc.com

[Willem Grooters]

In advance: I'm not familiarc with Oracle on VMS and it's requirements (and quirks) (though I've done DBA work on other platforms) so I may be completely wrong in my views as a "system manager".

I severely doubt it is needed that the DBA needs acces to the Oracle account for the work to be done.
When the Oracle and user accounts are set up with the right identifiers and privileges, the DBA should be able to login into his own account, and stay there. Be sure to have the privileges, required to access the database, be set as authorized privs, not default, so the DBA will have to SET PRIV before accessing the database environment. You could even think of a captive, or resticted account for this type of access, which disallows the DBA extending the high-privilege situation outside the environment.

[Karl Rohwedder]

Sami,

another useful tool would be JUMP. It allows for fine-grained control, who could JUMP to which user and provides e.g. mail notification and recording sessions.
You find it on the freeware CD.

regards Kalle

[Hein van den Heuvel]

Sami>> if a dba first login into his/her own account and then do a sudo to the oracle account then we can audit that usage right?

NO. WRONG.

Sami, you are looking entirely in the wrong direction. Forget about sudo or anyting like that. And forget about havign your DBA's do "connect / as sysdba" and such.

Create proper Oracle user accounts for each DBA, identified by passwords or by OS username (my preference).

OpenVMS + Oracle has all the features needed for full accountability.

Re-read Richard Hunt's advice very carefully. He hits on most problems and has the workaround suggestions.

Good luck!
Hein.

[SAMI AHMAD]

hi Karl!

where can I find this 'freeware CD' containing JUMP utility ?

[Hoff]

SAMI, if you don't know where the OpenVMS Freeware is located, then please read the OpenVMS Frequently Asked Questions (FAQ). Or work with Google. Or both.

http://www.google.com/search?q=openvms+freeware+jump

http://mvb.saic.com

http://www.hoffmanlabs.com/vmsfaq

[SAMI AHMAD]

thanks!
I found the source code and binaries but the binaries are for 7.1 , does any one have compiled binaries for JUMP for vms alpha
7.3-2 ?

[Richard W Hunt]

I will be more specific. In our environment, we created a special user group for each major product that had separate administrators. I.e. ORACLE has its own OpenVMS group number. Then we added individual user accounts in the same group with ORACLE but different member numbers.

We then gave each user the same privs as ORACLE. Within ORACLE, we defined each user to have the DBA role and all the other accessory roles that go with that. We relaxed the ORACLE directory permissions so that GROUP had the same permissions as owner. We assured that each user logged in as ORA_SAM or ORA_JACK or ORA_SALLY, etc.

ORACLE will REPEAT will work just fine and yet everyone has distinct logins. By making ORACLE its own group that isn't within the boundaries of MAXSYSGROUP, you can run the utilities you need from any of the ORAxxx accounts described above, because the ORACLE warnings about "SYSTEM not allowed to issue this command" don't ever kick in. You might have SYSPRV when you do your work as ORAxxx, but you aren't a "true" member of SYSTEM.

If you think YOU have auditing issues, just imagine what I have with a Dept. of Defense system. Yet because of our design and the care we exhibit in splitting out our users as described above, we have a 3-year Authority To Operate on a Dept. of Defense network. That's as much as anyone ever gets. You haven't SEEN auditing until you've had to provide DoD auditing reports.

Sami, I most strongly urge you to consider the above line of thinking, even if you don't do it exactly like I described. Just come close and you won't have an issue.

Another trick we played was that the ORAxxx accounts come up with all the ORACLE privileges but not by default. They are authorized but not enabled. The ORACLE DBAs have to issue a second command to enable their privileges, just to sort of force them to pay attention to what they are doing. AND they know I've got auditing turned on and operator logging wide open. So anything they do, I'll know about.

[Robert Gezelter]

Sami,

I would agree with what Richard said in his post. Assuming another persona is always FAR less preferable than granting access. Additionally, the audit log records will always contain the correct ID, something that is not always true otherwise.

- Bob Gezelter, http://www.rlgsc.com