Oracle is deprecating OS authentication according to the Oracle Database Security Guide, which says

Be aware that the REMOTE_OS_AUTHENT parameter was deprecated in Oracle Database 11g Release 1 (11.1), and is retained only for backward compatibility.

In addition, most security information and tools consider OS (external) authentication to be a security problem. I am trying to understand why this is the case. Here are some advantages I see of OS authentication:

  1. Without OS Authentication applications must store passwords in a variety of applications each with their own security model and vulnerabilities.
  2. Domain authentication already has to be secure because if it is not then database security just slows down access to the database, but cannot prevent it.
  3. Users that only have to remember one domain password can be made to create more secure domain passwords more easily than they can be made to create even less secure database passwords as the number of different databases they must connect to increases.
  • Where did you see that Oracle was deprecating external authentication? Jan 26, 2011 at 22:50
  • 1
    @Justin Cave I'll update the question with that information. Jan 27, 2011 at 3:17
  • 2
    Thanks for the update. Just for clarity, though, Oracle is not deprecating external authentication, it's deprecating remote external authentication which is generally much less secure (as Gaius discusses below) Jan 27, 2011 at 17:00

4 Answers 4


Consider the following scenario:

  1. There is a Unix user named gaius on the Oracle server with external authentication, so in Oracle there is a corresponding user called ops$gaius. When logged into a shell, I can also log straight into my Oracle schema, and my cron jobs don't need a password embedded in script either.
  2. Remote OS authentication is permitted, on the assumption that the LAN is 100% secure and the clients can be trusted (same as rlogin/rsh used to be normally allowed)
  3. An attacker gets his or her laptop onto the LAN by whatever means, knows that I work there, and creates a local user on their laptop called gaius and runs SQL*Plus as that user
  4. Oracle sees (i.e. OSUSER in V$SESSION) is gaius and logs that remote user in as ops$gaius

That's not only laughably easy to spoof, but putting on my cynic's hat, Oracle can't make any more money selling you their fancy single sign-on product... Which by the way does fulfill all the points you raise as advantages of OS-level auth. Two passwords better than one is entirely spurious; most people will set them to be the same anyway (there's no mechanism in Oracle to prevent this).

The general principle is that it is extremely difficult to defend in software when an attacker has physical access. And never trust the client.

  • 2
    It's even worse than that. See orafaq's 'Why are OPS$ accounts a security risk in a client/server environment?' (they blame windows, but you're right, it's anything on the network)
    – Joe
    Jan 27, 2011 at 15:40
  • 3
    How does the server being on a windows domain factor into this? i.e. Would the attacker have to join their computer to the domain in order to have an account that includes the domain, or could the attacker simulate the presence of the domain without actually having to join their computer? Jan 27, 2011 at 16:40
  • I am guessing that was written originally at a time when all servers were Unix and all desktops were Windows
    – Gaius
    Jan 27, 2011 at 16:51
  • 3
    @Leigh - You can make remote OS authentication more secure with Windows clients by setting OS_AUTHENT_PREFIX to be a trusted Windows domain. That requires that the remote client is (or appears to be) on that trusted domain. That substantially raises the bar over a trivial "plug computer into a spare port, add a local user, and you're in" attack but it's still quite beatable. Jan 27, 2011 at 17:08
  • 1
    compare and contrast with if it was doing actual AD/Kerberos authentication, and taking a ticket from the user and verifying it with the KDC, which I guess is what SqlServer does when set to use Windows authentication?
    – araqnid
    Jan 28, 2011 at 1:12

It increases single points of failure and enlarges the risk surface of your data.

An attacker who gains access to the system will, with OS Authentication, have access to the database. By requiring more secure access to the database, the potential attacker must escalate their privileges on the compromised system to gain root or oracle access, rather than any user.

This problem is a function of external access to the database. If there is no external access and the machine is fully secured then the question of permissions is moot. However, if developers have access, OS level user permissions increase the scope of potential security disasters.

Consider using multitier access to limit the scope of security breaches and give any user, application, or client the access they need without the need to create OS level accounts for every instance.

  • I see, so to oversimplify -- two username/password requirements are more secure than one --. Your points sound reasonable. Jan 6, 2011 at 16:05
  • This is a subtly incorrect answer - the issue is not external authentication but remote external authentication. I will explain below.
    – Gaius
    Jan 27, 2011 at 13:54
  • @Gaius Wouldn't external OS authentication be extremely limited almost to the point of being worthless if it weren't remote? Are you saying Oracle isn't deprecating authentication using the OS, but only deprecating OS authentication from a remote computer? Jan 27, 2011 at 19:16
  • @Leigh - The major use case for OS authentication of local accounts is for DBA-type tasks where you have a bunch of shell scripts running on the database server that need to access very powerful accounts on the database server. OS authentication lets you avoid having unencrypted DBA level passwords in those shell scripts. Jan 27, 2011 at 19:46
  • @Justin batch jobs in general, implemented as shell scripts or whatever, in individual crons
    – Gaius
    Jan 27, 2011 at 23:43

Gaius has already pointed out why remote operating system authentication (as opposed to vanilla operating system authentication where you are allowing local machine users to access the database without specifying a separate password) is relatively insecure.

I would expect that Oracle is moving in this direction because it wants to encourage people to use enterprise users (or the full-fledged identity management suite) rather than remote operating system authenticated users. Enterprise users have the same advantages as remote operating system authenticated users but Oracle is actually going out and hitting your Active Directory server to authenticate the user. You get the same single sign on benefits without leaving the security check up to the client machine.

  • LDAP authentication can open another can of worms ... I'll go post a longer answer.
    – Joe
    Jan 28, 2011 at 11:37
  • +1 Thanks for pointing out Enterprise User Security. We have already been considering Advanced Security and this makes it all the more appealing. Jan 28, 2011 at 12:46

You specifically point to ident-style authentication, but I'd also like to point out that other methods of tying database or any other logins to the OS's logins are just as bad. (be it local password files, LDAP, or whatever for the actual storage of the credentials)

If you allow remote connections to the database (or webserver, or whatever's doing the authentication), some OSes will ignore rules that might be set to make it difficult to brute force accounts (eg, blocking IPs where the failed attempts are coming from; locking users for a period after a set number of falures, etc). Normally, these rules are tied into sshd, and not the authentication system as a whole.

So, should someone be able to connect to the database / webserver / whatever remotely, they can brute force the password, as databases don't tend tend to have the same mechanisms to slow attempts, then ssh in once they find the necessary credentials.

  • 2
    I'm not sure I follow the reasoning here. If you have Oracle authenticate against LDAP, you'd have to break LDAP in order to get the password-- there would be no local copy of the password hash to brute force like there would be for a regular Oracle user. If you're concerned about attackers beating your LDAP authentication, you probably have bigger problems than how you're authenticating Oracle users. And it's easy enough to configure Oracle to lock accounts after a number of failed attempts, restrict the allowed IP addresses, etc. Much of that, in fact, is the default behavior in 11g. Jan 28, 2011 at 14:36
  • @Justin : it's only an issue if you tie it so the credentials for logging into the OS are the same as the credentials for logging into the database (or webserver, etc.). And it sounds like Oracle's gotten better about authentication than when I last used it, but most other databases haven't. (and Apache doesn't either, so MacOS X Servers users should swap out mod_auth_apple and mod_auth_digest_apple for the default versions, although I haven't tested if the problem still exists in 10.6)
    – Joe
    Jan 28, 2011 at 15:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.