Tom,

We need to suppress the OS authentication and enforce database authentication. A boundary line between network/system administrator (a guy) and database administrator (another guy) is required. So that connection to database having sysdba privilege without password must be barred. One should only connect to database with database authentication.

Thanks

Hi
What is oradba group?
Can you plese let me know what do you mean by
"remove them from the DBA group (the ability to connect / as sysdba goes away)"

Tom,

I feel I was unable to explain the scenario! -- Sorry for that.
We do need a network :)
Oracle 91 EE is running over Windows Server 2003.
Actually the network/system administrator cannot be barred from the server pc, as he is responsible for the OS, network etc. how can this person be removed from ora_dba group!
While the database administrator do manage the Oracle Server software installed on server machine remotely from his desktop pc. Occasionally he needs to work on server pc, as he is responsible for the Oracle Server software installed and the 'data' on that server pc.
This security breach may lead us to a 'blame game' in case of any disaster.
We need to protect the 'metadata and data' from intruders -- most likely they could be internal ones. That’s why I was asking about the suppression of OS authentication. We don't need it at all rather we need database authentication around the network i.e. at the server pc and all connected machines.

Thanks again.

When Oracle is installed on a Windows OS it creates a local group named 'ora_dba -- Oracle DBA Group' and the local user 'Administrator' with its member by default.
The membership of this local group grants its members the privilege to connect as sysdba without password -- as they are authenticated at OS level.

Tom, am I right?

To be honest, the ability to prevent your server administrator from logging onto the database probably isn't going to happen.

If you remove the system administrator from the ora_dba group then he's a system administrator and can just add himself back in again [its only a windows user group after all].

It might be a better idea to simply enable auditing to track who did what....

Tom,

Thanks once again for your great efforts for all of us.

I understand that as long as we are using 'Windows' as OS we'll have to face it 'boldly'. :)

As you told that one can draw a solid-line between the OS-Admin and the dba in UNIX.
What you say about Linux and Solaris?
We are planning for the OS migration. No doubt Linux is a strong candidate, but the Solaris 10 is getting more attention because it has become free and open-source. ;)

We need your thoughts upon Linux and Solaris both.

Thanks.

hi Dear Tom,
My Scenario is:
Previously to my database windows user admin was able to login to
the database without giving password : conn / as sysdba.
Then I changed the parameter REMOTE_LOGIN_PASSWORDFILE to 'NONE'
which was previously 'EXCLUSIVE'.
And Now with the same user admin i am unable to login
to my database : conn sys/sys as sysdba
or even by : conn / as sysdba.
Could you please help me out for this?
With Regards,
Navin

This sounds so much like the classic 'I do not want my dba to see my data' issue.
Must be wonderful to work in an organization where you cannot even trust your system administrator...

Well Frank, I think you're right, but...
I was asked yesterday to make it more difficult for the SysAdmin (on UNIX) to get into the database! Because root can do a "su - oracle", then do "sqlplus / as sysdba" and they are in. Ths is found to be insecure by the auditors (SOX, yes).

Tom, you said "I know on unix we can separate these capabilities (you can limit root privs, compartmentalize things)".
Is there any way on unix to prevent from su-ing to oracle?
I'm wondering what the easiest way to prevent all this is. Don't really feel like going down the orapwd road, but...

Regards, jan

"Don't really feel like going down the orapwd road, but..."
Wouldn't work anyway I think, now I'm playing around with it...

jan

I am not able to login as connect / as sysdba when I am logged in as root OS user .Is there a way to log in in this way

Actually Frank was never right and even Tom knew that very well too!

I was not distressed by this guy's remarks about a major security issue faced inside organizations to protect their data rather I was amazed that Tom didn't even bother to acknowledge the problem in its spirits and so was unable to present the solution too. Tom keeps on pouring the evil on Operating System rather than the Database. It’s crystal clear that Database possesses the Data not Operating System. One who holds should also be liable too.

So many thanks go to the Oracle Database Development Team, who not only felt the depth of this security issue and also presented a logical, nice and powerful solution named 'Database Vault'.

Mr. Tom, now what you say about it?
Hmmmmmm

Mr. Tom as per your thoughts, if Database Vault can’t solve the data security breaches being faced by the organizations then why Oracle Database Development Team has done such an effort?

What this Database Vault thing is about then?

//
Look the bottom line here is, has been, will be:

IF YOU GRANT SOMEONE THE PRIVILEGE TO DO "X", THEN THEY CAN DO "X".

I do not believe you read this thread - or if you did, you did not understand
the fundemental problem.


If you give me a privilege - then I can use it.
//

Yes sure, one can comprehend this veracity!

But, one can't afford a matchstick in monkey's hand either -- The suspects must not be privileged in any case.
A basic necessity -- The DBA is expected to do the "conn / as sysdba" thing but the OS-Guy should not exercise it in any way.
We can remove the OS-Guy's (the irrelevant one's) from the oradba group. They can add them back in the group again, after all they are OS Admin's -- a fruitless move.


//
This entire discussion was centered around:

Hey, I've given someone access to the oradba group. Now, I know that by being
in this oradba group they have the ability to use OS authentication. I don't
want them to use OS authentication - what can I do.
//

Yes indeed, this is what being asked in the thread repeatedly!

OS authentication -- a compulsion and hence a stone of contention.
It might be a useful feature for those who need it, but a pit for the others.
There should be a way to enable or disable it, according to the needs.
We need all users to be authenticated inside the database -- database authentication.

Sure indeed, this is what being asked in the thread repeatedly!

Just a comment on using "/ as sysdba". In the past, our DBAs were used to using "/ as sysdba" by habit for daily activities. The approach I implemented was establishing individual OS authenticated (NOT Remote OS authenticated) database accounts. I then created and assigned the necessary roles to those accounts. Our DBAs have the DBA role. That gives them all the power they need to perform daily functions as well as capture what they do in auditing. Could I stop them from using "/ as sysdba" since they are in the oradba group? No, this is essentially a policy which requires me to review the audit files for activities using "/ as sysdba", etc. As I see people logging in with "/ as sysdba", I question and make them justify using it versus their own account. I even have a script that captures anyone sudoing to the oracle account so I can question them on that as well. After awhile, the people break the old habit and use their own accounts. It's simply training/coaching DBAs on a different way to perform their work.

Note: There are times when the only way to get into the database is as "/ as sysdba". Do not block this completely even if you figure out a way. An easy example is filling up the auditing. Regular connections will not be allowed but "/ as sysdba" could still connect to fix the problem.

Please please be sure to disable remote OS authentication! That is very very risky to have open.

Given that you can't create an absolutely foolproof PREVENTIVE control (i.e. Sysadmins on UNIX su-ing to oracle or Windows admins granting themselves oradba).

If you add a layer of DETECTIVE controls, you should be able to keep SOX auditors happy.

In the Oracle audit trail, turn on:
1. uses of administrative privilege ( e.g. SELECT ANY TABLE, CREATE ANY TABLE, etc.)

2. user administration (e.g. CREATE USER FRED, GRANT XXX TO FRED)