Oracle provides another method to connect users
using the authentication provided by the operating system, known as
ops$ accounts. In this case, the following parameters in
the initialization file control the authentication process.
NAME TYPE VALUE
------------------------------------ ----------- -----
os_authent_prefix string OPS$
remote_os_authent boolean TRUE
os_roles boolean TRUE
remote_os_roles boolean TRUE
Note the use of ops$ as the value of the
operating system prefix. The user is created as
Create user ops$judy
Identified externally;
In this case, the user JUDY exists in the
operating system and is authenticated there using a password, token
card, or some other means. Oracle does not authenticate Judy, as
indicated by the use of externally identified keywords. When Judy
decides to connect, she issues
connect /
Note there is no password. Oracle assumes that
the OS has properly authenticated Judy,
so there is no need to authenticate further to access the database.
This is reminiscent of
the old days, where the world was much more secure and servers were
still islands unconnected by the internet. Hackers typically needed
to get to the physical network to do the damage. The advent of the
internet changed the rule. A hacker halfway around the world can
launch an attack while sipping coffee in his basement. The intent of
user access
control is to place as many barriers to
unauthorized access as possible.
It is probably unnecessary to show how
dangerous the above practice is. If a malicious user ever gets into
the operating system, getting into the database is easy. Of course,
the security aspects of the underlying OS make the call – if it is
substantially secure, then this type of authentication can be
trusted. Otherwise, getting into the database is less of a challenge
for a hacker.
Therefore, the OS Authorized accounts should be
used with extreme caution. The usual rule of thumb is granting just
enough privileges to the account to do the job, no more than that.
Moreover, powerful accounts with sweeping privileges, such as DBA,
alter system, etc. should never be able to be identified externally.
There are two types of authentication used
externally – one is done on the same server, and the other is done
outside the server. There are different levels of security
requirements for each, so they will be discussed separately.
Many people aren't aware of the feature in the
user creation process that can lead to security challenges. This is
better explained through an example. Suppose the os_authent_prefix is ops$ and a user is created as
externally identifiable too. The OS user SCOTT
can login as
