Understanding SQL*Net
Support for Operating System Authorized Logins
In SQL*Net version 1, Oracle provided support for operating system authorized logins across a network using the special database login accounts. This support continues in SQL*Net version 2 on the same platforms and protocols for compatibility of function, but is not expanded to additional platforms and protocols.
Operating System Authorized Logins
Operating system authorized logins to a database allow a user who has operating system privileges on a machine to get automatic access to an Oracle database on the machine without supplying a database password. The assumption is that having supplied a password to the operating system, that user can be trusted to access his data in his own operating-system-authorized user account on that machine. The default prefix for this account is OPS$; however, the database administrator may assign some other prefix.
Extending this notion over a network, operating system authorized logins allow users to log into a database on a remote machine using their local userid, without supplying a database password. The operating system user account must match the username of the operating system authorized account.
For further information about user authentication, see the Oracle7 Server Distributed Systems, Volume I.
Warning about Operating System Authorized Logins
It is not uncommon for many employees to have DOS or other types of workstations on their desks over which they have complete control. It is a trivial task for such a person to create a username of any valid string of characters. If John Doe is the president of a company and uses operating system-authorized logon accounts across the network, any user can create a JDOE account on a personal workstation and access John's data without a password. On some server platforms this is more difficult than described, but never impossible. This is a particularly serious problem where an OPS$ account has DBA privileges. In such cases, it is very easy to masquerade as an Oracle DBA.
Oracle's Recommendation Regarding Operating System Authorized Logins
Because of these security implications, Oracle Corporation recommends against using operating system authorized logins to remote databases. This does not mean you cannot use operating system authorized login accounts in your database; it simply prevents them from being used across the network. The same OPS$ account can still be accessed if a password is supplied in connections over the network.
If you have applications that rely on operating system authorized logins across a network, you should consider altering them to require the user to supply a password when connecting over the network.
In SQL*Net version 1 the ability to perform operating system authorized logins exists in some SQL*Net TCP/IP and SQL*Net DECnet drivers on UNIX and VMS systems. The default setting is for operating system authorized logins to be enabled unless explicitly disabled. We recommend that you explicitly disable operating system authorized logons where they exist in any version 1 drivers you have installed. For information regarding your platform and SQL*Net Version 1 drivers, and how operating system authorized logins can be disabled, see your Oracle operating system specific manuals regarding SQL*Net version 1.
In SQL*Net version 2, operating system authorized login support is enhanced to make it more difficult to act as an imposter, but it is still not impossible. By default, operating system authorized logins are disabled in SQL*Net version 2.
Note: If externally authenticated logins are enabled (by setting the REMOTE_OS_AUTHENT parameter to TRUE), it will be possible to connect without a password even though the underlying SQL*Net protocol cannot verify the identity of the user. For this reason, REMOTE_OS_AUTHENT should always be set to FALSE (the default value).
If it is necessary to make externally authenticated logins, then a secure protocol such as the Bequeath (Pipe) driver should be used.
In all cases with SQL*Net version 1 or version 2, Oracle recommends leaving remote DBA privileges disabled.