Submitted by Josh Shaul
A client recently asked me about Oracle’s Remote OS Authentication feature. What does it mean? How does it work? What’s the impact on the security of my database? There are a few interrelated components at play here, and the answers are neither simple nor well known.
Let’s start with the basics. Oracle supports a number of authentication mechanisms, the most commonly used being database authentication and operating system authentication. Database authentication accepts a username and password, then checks these against credentials stored in the database. Oracle ships with a number of default database accounts, all of which are setup for database authentication. It’s simple to setup accounts for database authentication, when you create the user give them a password:
CREATE USER SCOTT IDENTIFIED BY TIGER
Connecting to Oracle (via sqlplus) with database authentication looks like this:
sqlplus scott/tiger
Note that both a username (scott) and password (tiger) are provided. Also note that versions earlier then 11g, Oracle passwords are not case sensitive.
Operating System Authentication relies on the OS to validate a users logon credentials. Oracle trusts the operating system to do a good job with authentication, and assuming the OS user is a valid database user, they are allowed to login to the database without supplying a password. To create an OS authenticated user, tell Oracle that the user will be identified externally:
CREATE USER OSUSER IDENTIFIED EXTERNALLY
Connecting to Oracle with operating system authentication looks like this:
sqlplus /
Note that no username or password are provided. Oracle takes the username currently logged into the OS, looks up a database user of the same name, and then makes the connection.
There are two types of Operating System Authentication supported, Local OS Authentication and Remote OS Authentication. Local OS authentication is enabled by default, and uses the local operating system (the database server’s OS) to authenticate users. Remote OS authentication is just the opposite. It is disabled by default, but when switched on, it allows a remote OS (which is any client that can make a network connection to the database) to authenticate users. Consider that for a moment. Allowing any client that can make a network connection to the database authenticate users on behalf of the database. If I can get administrative access to any machine on the network, or if I can bring my own machine in, I can create OS users on my local box with the same names as database users and easily make connections to the database. It’s almost like disabling any security for any accounts that can login via OS authentication.
This brings us to another question. Which users can login via OS authentication? This depends on two factors. First is an initialization parameter call OS_AUTHENT_PREFIX (OS authentication prefix). When users connect via OS authentication, Oracle takes the OS_AUTHENT_PREFIX value and prepends it to the OS username to create the database username. By default, the OS authentication prefix parameter is set to OPS$. In this case if I want to allow an OS user named OSUSER to connect to the database, I would have to create a database user as follows:
CREATE USER OPS$OSUSER IDENTIFIED EXTERNALLY
OS_AUTHENT_PREFIX seems simple enough, but it has a dark side. When set to the default value of OPS$, it removes the Oracle security restriction that requires users to be IDENTIFIED EXTERNALLY in order to logon via OS authentication. This removes an important control and presents some security risk. The reason for this is backwards compatibility, with Oracle6!
What this means to our question about who can login via the OS is that if the OS_AUTHENT_PREFIX = OPS$, then any username that beings with the string OPS$ can logon via the OS. If OS_AUTHENT_PREFIX is set to any other value, only users that are IDENTIFIED EXTERNALLY (Password column in DBA_USERS/SYS.USER$ will read EXTERNAL) and whose username begins with the OS_AUTHENT_PREFIX can login via the OS.
Ok, so now we know who can authenticate via the OS. We can also check if remote OS authentication has been turned on by examining the init.ora file (REMOTE_OS_AUTHENT parameter). While we’re there we can grab the value for OS_AUTHENT_PREFIX as well. With this information you can figure out if your database has been left open to trust remote (client) operating systems to authenticate their own users, and if so, which users in the database are susceptible to attack via a remote OS authenticated connection.
From a best practices perspective, I recommend that you disable Remote OS authentication on all your Oracle systems. It represents a significant security risk that is almost always unnecessary. I also recommend changing the value of OS_AUTHENT_PREFIX to something other then the default value of OPS$, as this opens yet another security hole. Finally, I recommend checking these settings periodically, at least quarterly on your production systems. Just because the settings look good today doesn’t mean that someone isn’t going to change them tomorrow!