An available approach is the use the “identified externally” account creation and set the parameter file parameter REMOTE_OS_AUTHENT to true. This approach enables and account that has been created using the same name as the client account to connect to the database via SQL*Net without the use of a password. Let’s say the account on a computer is identified with the name James and an account is created in the PROD database for “james identified externally”. James can now select SQL*Plus from his PC start/program menu and, at the username prompt, type and execute /@prod and connect to the SQL command line utility without giving password. If James is logged on directly to the operating system on which PROD is running, he can still just type sqlplus / to access database.
In the scenario in the last section, the security danger is that James will walk away from his PC without locking his terminal. Anyone would then be able to access the database without knowing James’s username and password and have James’s privileges on the system.
The second security risk is that you trust a remote operating system over which you may have no control. All somebody needs to do is determine an Oracle user in your database who has the desired role – including DBA – with an account that has been IDENTIFIED EXTERNALLY. Then, the person creates an account with the same username as the privileged database account, executes SQL*Plus, and BLA,BLA,BLA. That person is in your database with the highest possible privileges and there is nothing you can do, except set REMOTE_OS_AUTHENT=false.
These two security risks are biggest headache considering in Oracle services and database administration. We cannot eliminate these kinds of risk factors if we use REMOTE_OS_AUTHENT parameter without having knowledge and create operating system authentication user login in Oracle database. If we need to set this security then during remote dba services, it should be monitored regularly and audited.
In the scenario in the last section, the security danger is that James will walk away from his PC without locking his terminal. Anyone would then be able to access the database without knowing James’s username and password and have James’s privileges on the system.
The second security risk is that you trust a remote operating system over which you may have no control. All somebody needs to do is determine an Oracle user in your database who has the desired role – including DBA – with an account that has been IDENTIFIED EXTERNALLY. Then, the person creates an account with the same username as the privileged database account, executes SQL*Plus, and BLA,BLA,BLA. That person is in your database with the highest possible privileges and there is nothing you can do, except set REMOTE_OS_AUTHENT=false.
These two security risks are biggest headache considering in Oracle services and database administration. We cannot eliminate these kinds of risk factors if we use REMOTE_OS_AUTHENT parameter without having knowledge and create operating system authentication user login in Oracle database. If we need to set this security then during remote dba services, it should be monitored regularly and audited.
