Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 
 
 

The role of the OS Oracle user

 

There is a lot of misconceptions about the purpose of the UNIX/Linux "Oracle" user and the need for the "dba" UNIX group.

At Oracle install time, the dba group and the oracle user are created.  This user is created as part of the the dba group and the oracle user.  This user and group, in turn, will create all of the administrative directories within the $ORACLE_BASE directory.

Security problems arise when the OS user id defined with external authentication, such that anybody with the password for the OS oracle user ID, may enter the Oracle database without internal authentication:

Two very important init.ora parameters need to be set for all databases in the SQL*Net environment:

  • remote_os_authent (default is false) – This is a very important parameter because it can allow external Oracle users to connect to the database without supplying a password.  This value is set to “false”, meaning that Oracle will require a password, or “true”, meaning that Oracle will assume that the user has been pre-authenticated by the operating system.
  • os_authent_prefix (default is ops$) – This specifies a group of Oracle users who will be able to connect remotely without supplying a password when remote_os_authent=”true”.  Normally, this is set to null “” meaning that all users may connect without a password, or “ops$”, meaning that any user ID that begins with ops$ will be able to connect without supplying a password.

The reason for preventing external identification from Oracle SQL*Net clients should be clear.  Anyone with administrative privileges on a Windows or UNIX/Linux server could easily create a user ID with the same name as the one that is identified on the remote servers.  They could then breach security by connecting without a password.

  • You are allowed to implement external authentication via either ops$ or IDENTIFIED EXTERNALLY. 
  • External authentication only works from non-PC clients.  If you want external identification between non-PC servers and access to the PC GUY tools, you must define the user as ops$ and specify a password.

UNIX/Linux OS user management

UNIX users are controlled by a special file called /etc/passwd.  This file contains a series of strings separated by colons “:”.  The values are:

username  :  password  :  user_nbr : group_nbr :  default shell
root> cat /etc/passwd

oracle:x:108:102::/export/home/oracle:/bin/ksh
oradev:x:109:102::/export/home/oradev:/bin/ksh

From the above listing we can determine that the oracle user has a encrypted password in /etc/shadow, that they are user 108, and they are in group 102.  The oracle user has /export/home/oracle for a home directory, and they are using the Korn shell as a default shell.

UNIX passwords on Oracle servers

UNIX passwords are notoriously vulnerable to hacking.  In UNIX, users can change their passwords by invoking the passwd command.  Note that the listing of /etc/passwd above does not contain the encrypted passwords for the user IDs, and the password column is denoted with an “x”.  This indicates that the system administrator is storing the passwords in another special file called /etc/shadow.

Unfortunately, protecting passwords in a /etc/shadow file is not always enough to ensure security.  Several tools such as John the Ripper can be used to easily crack into these UNIX files, stealing access to the Oracle server, and all database data.  To learn how to protect yourself from UNIX password hacking, see the UNIX password cracker at  http://www.openwall.com/john/.

The power of root

In UNIX, the “super user” is always called root.  The root user may sign-on as any UNIX user without supplying a password by using the super user (su) command.  For example, the root user can sign-on as the oracle user by entering su – oracle. 

The root user may also change any password in the system by entering passwd command followed by the userid.  For example, the root user could change in oracle password by entering passwd oracle.

 




 

 

��
 
 
 
 

 
 
 

 
Oracle performance tuning software 
 
oracle dba poster
Oracle Linux poster
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright ? 1996 -  2014

All rights reserved by Burleson

Oracle ? is the registered trademark of Oracle Corporation.