sysoper and sysdba (auth)

10g OS AUTHENTICATION

SYSOPER and SYSDBA

Two main administrative privileges in Oracle SYSDBA and SYSOPER.

SYSDBA and SYSOPER system privileges allow access to a database instance

even when the database is not open. SYS user is automatically granted the

SYSDBA privilege. Anyone log in as user SYS , must connect to the database

as SYSDBA. SYSDBA authorization allows to perform any database task.

SYSOPER authorization is a less powerful authorization that allows startup

and shutdown abilities but restricts other administrative tasks.

SYSOPER /SYSDBA Privileges

SYSOPER/ SYSDBA not a user and not a schema.

SYSOPER Privilege allows operations such as:

Instance startup, mount and database open ;

Instance shutdown, dismount and database close ;

Alter database BACKUP, ARCHIVE LOG, and RECOVER.

It allows the DBA to perform general database maintenance without viewing

user data. SYSDBA privilege includes all SYSOPER privileges plus full system

privileges (with the ADMIN option), plus 'CREATE DATABASE' etc.. SYSDBA

includes all system privileges (95 separate grants). SYSDBA is a special built-

in privilege to allow the DBA full control over the database.

We can grant SYSDBA authorization and SYSOPER authorization to give

others the ability to perform these tasks without connecting as the SYS user.

SYSDBA privilege can’t be granted to public. SYSDBA this schema is SYS ;

SYSOPER the schema is PUBLIC. When a database is initially installed, only

the SYS schema can connect to the database with the SYSDBA authorization.

OS Authentication Exploring by Thiyagu Gunasekaran of 14


v$pwfile_users - This view lists all users who have been granted

SYSDBA and SYSOPER privileges.

POINTS TO REMEMBER :

SYSDBA and SYSOPER connection accounts/authorizations for startup and

shutdown the oracle Database. SYSDBA and SYSOPER are ROLES .

SYSDBA and SYSOPER - not users and not schemas .

Two options for “SYS" Password Authentication

Operating System authentication

Password file authentication

A local user can connect to the database as SYSDBA using either OS

AUTHENTICATION or by using PASSWORD FILE AUTHENTICATION.

A local user can connect to the database as SYSDBA using password file

authentication for remote databases. “OS authentication takes precedence

over password file authentication.”

We can’t grant the SYSOPER or SYSDBA privilege to a user created with the

IDENTIFIED EXTERNALLY clause. SYSOPER or SYSDBA privilege can be without

the IDENTIFIED EXTERNALLY clause.

SQL> grant sysdba to ops$sona;

ORA-01997: GRANT failed: user 'OPS$SONA' is identified externally

We can change OS password authentication account to DB authentication

account (If we wish ). Lets discuss following chapter.



OPERATING SYSTEM AUTHENTICATION

OS authentication (identified externally or OPS$).

When a connection is attempted from the local database server, the OS

username is passed to the Oracle server. If the username is recognized, the

Oracle the connection is accepted, otherwise the connection is rejected

OS_AUTHENT_PREFIX parameter is used to configure Oracle External User

Environment . Oracle default value for OS_AUTHENT_PREFIX is set to OPS$.

Oracle user should be the OS user. If we want to create OS login account

should create as OPS$<user> according to parameter OS_AUTHENT_PREFIX.

SQL> show parameter OS_AUTHENT_PREFIX;

OS_AUTHENT_PREFIX OPS$

Externally Identified User definition given here ,

<Oracle user > = <value of OS_AUTHENT_PREFIX> || <OS user>

User sham = OPS$sham

This is creating a mapping user in Oracle database to map the OS username.

OS account name is sham, the database username would be ops$sham and

the CREATE command for the database user creation would be

SQL> CREATE USER ops$sham IDENTIFIED EXTERNALLY;

User created.

SQL> GRANT CONNECT TO ops$sham;

Grant succeeded.



SQL> alter user ops$sham identified by shamos;

User altered.

SQL> grant dba to ops$sham;

Grant succeeded.

POINTS TO NOTE :

Here , ops$user should have same account name in OS and Database.

If we set " Identified by some password " then it is NOT os authenticated.

DB authentication account Vs OS authentication account

Most common method for logging into database is by username/password.

Let’ s check how OS authentication user becomes DB authentication user ?

SQL> CREATE USER ops$sham IDENTIFIED EXTERNALLY;

User created.

ok, at this point , an os authenticated account is "ops$sham".

SQL> GRANT CONNECT TO ops$sham;

Grant succeeded.

Now, the os account "sham" should be able to connect with a simple "sqlplus“

SQL> grant dba to ops$sham;

Grant succeeded.

Now, using the os account "sham" can connect without a password and have



all the privileges listed in the role "dba".

SQL> alter user ops$sham identified by shamos;

User altered.

Now user altered account 'ops$sham' and gave it a password. ops$sham is

no longer an os authenticated account. It is now a database authenticate

account. “OS authenticated is defining the account as "identified externally”.

Local OS Authentication

I am explaining alternative to the username / password method by using OS

Authentication. A password is not required for a database connection i.e

when issuing sqlplus / OS has already taken care of authenticating the user.

Local OS authentication is performed using OS credentials on the local server

where the database resides. Ex : ( Guest OS , Local Testing Server ).

This method identifies users by the credentials supplied by the OS and uses

that information to allow authentication to the database without a password.

OS authentication allows Oracle to pass control of user authentication to the

operating system. When a connection is attempted from the local database

server, the OS username is passed to the Oracle server.

If the username is recognized, the Oracle the connection is accepted,

otherwise the connection is rejected. First, create an OS user, in this case the

user is called "sam". Should use useradd and passwd commands. Let’s

check how the user getting OS authentication when using “SQLPLUS”.



Just start by creating an OS user on the local database server. In a

UNIX/Linux environment. ( useradd with passwd ) options .

Useradd m useradd command doesn't create the home directory by

default. -m option switch to make it and create the home directory for sams.

LOGIN as “ORACLE” user and “NORMAL” user issue following command

$ find / -name libsqlplus\* -ls 2>/dev/null

when issuing that command normal user ( ops$user before added to oinstall

group) ops$user won’t get any output but oracle user got following output.

$ su - oracle

$ find / -name libsqlplus\* -ls 2>/dev/null

1378188 1296 -rw-r----- 1 oracle oinstall 1319436 Jun 22

2005 /u01/app/oracle/product/10.2.0/db_1/lib/libsqlplus.a

1378193 1028 -rw-r----- 1 oracle oinstall 1047293 Jun 22

2005 /u01/app/oracle/product/10.2.0/db_1/lib/libsqlplus.so

O/p shows "rw" for oracle , "r" for members of the oinstall group and no

permissions at all for anyone. libsqlplus.* files should be rw-r--r-- and

ops$user should be a member of the primary group ( oinstall or dba).

when we create ops$user , by default executable file by the name of 'sqlplus'

located in any directory listed in the current value of the environment

variable named PATH. So ops$user should be added to oinstall group.

# useradd -m -g oinstall sam

# passwd sam

Changing password for user sam.

New UNIX password:



Retype new UNIX password:

passwd: all authentication tokens updated successfully.

OS authentication prefix should be ops$ , So the database user to allow an

OS authenticated connection. To do this, the username must be the prefix

value concatenated to the OS username. So for the OS user "sam", user will

be "ops$sam" on a UNIX/LINUX platform.

SQL> SHOW PARAMETER os_authent_prefix ;

os_authent_prefix ops$

SQL> create user ops$sam identified externally;

User created.

SQL> grant connect to ops$sam;

Grant succeeded.

POINTS TO NOTE:

Before adding sam user with oinstall group check the following commands

“ oracle user vs sam” user.

$ id

$ env |grep ORA| sort

$ env |grep PATH

Setup a environment variables so that SQL*Plus

works correctly.

# su - sam



$ export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1

$ export PATH=$PATH:$ORACLE_HOME/bin

$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib

$ export ORACLE_SID=testdb

Let’s check OS authentication connection in UNIX /Linux environment

without password connecting to the Database.

$ sqlplus /

SQL*Plus: Release 10.2.0.1.0 - Production on Tue Dec 25 03:38:52 2012

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

SQL> show user;

USER is "OPS$SAM"

POINTS TO NOTE :

Ops$sam user is able to log into the database using OS authentication. Here

OS authenticated DB user is to hide passwords in order to tight security.

Generally accepted method is to create OS authenticated users without the

IDENTIFIED BY clause (without a password).

Mixing OS Authentication with Password Authentication

Already discussed OS authentication account became as DB authentication

account . Lets us see small demo here about how DB authentication

account(ops$) using oracle user environment.



SQL> create user ops$rose identified by rose;

User created.

SQL> grant create session to ops$sam;

Grant succeeded.

$ sqlplus 'ops$rose/rose'

SQL*Plus: Release 10.2.0.1.0 - Production on Wed Dec 19 07:10:34 2012


Connected to:



SQL> show user;

USER is "OPS$ROSE"

SQL> ! id

uid=500(oracle) gid=500(oinstall) groups=500(oinstall),501(dba)

SQL> grant sysdba to ops$rose;

Grant succeeded.

Disable OS Authentication

Possible to disable OS authentication by setting the initialization parameter

os_authent_prefix to null ('').

SQL> alter system set os_authent_prefix=' ' scope=spfile;

System altered.

SQL> startup force;



Database opened.

SQL> show parameter os_authent_prefix ;

NAME TYPE VALUE

os_authent_prefix string

Let’s check from ops$sam

SQL> show user;

USER is "OPS$SAM"

SQL> select * from tab ;

select * from tab * ERROR ORA-03135 : connection lost contact

If the os_authent_prefix is " " (Null), then the OS Authenticated accounts

cannot log in using the password.

OS Authenticated User OPS$ Role Authorization

$ . .bash_profile

$ sqlplus /

Connected to:



SQL> show user;

USER is "OPS$SAM"

SQL> select * from session_roles;

ROLE

CONNECT

DBA



SELECT_CATALOG_ROLE

HS_ADMIN_ROLE

EXECUTE_CATALOG_ROLE

DELETE_CATALOG_ROLE

EXP_FULL_DATABASE

IMP_FULL_DATABASE

GATHER_SYSTEM_STATISTICS

SCHEDULER_ADMIN

WM_ADMIN_ROLE

JAVA_ADMIN

JAVA_DEPLOY

XDBADMIN

XDBWEBSERVICES

OLAP_DBA

16 rows selected.

SQL> !id

uid=503(sam) gid=500(oinstall) groups=500(oinstall)

POINTS TO NOTE

OS user is 'oracle' is a member of the OS group 'dba'. Any user that is a

member of the 'dba' group can connect via OS authentication with sysdba

authority. It's the membership in the dba group that gives them this ability.

And these accounts cannot connect without sysdba authority .

OS authentication to authenticate by granting Oracle DBA privileges to that

group, and then adding the database administrative users to that group. OS



OS Users authenticated logon to the Oracle database as a SYSDBA

without having to enter a user name or password i.e. "connect / as sysdba"

On UNIX/LINUX platform.

User Authentication Methods

Oracle provides several options for authenticating users, applications, clients,

and servers. Passwords are the most commonly used form of authentication

Identified and authenticated by the database, which is called database

authentication. Authenticated by the operating system or network service,

which is called external authentication.

Authenticated globally by Secure Sockets Layer (SSL), called global users,

whose database access is through global roles, authorized by an enterprise

directory. Global Authentication and Authorization

Allowed to connect through a middle-tier server that authenticates the user,

assumes that identity, and can enable specific roles for the user. This is called

proxy authentication and authorization.

POINTS TO REMEMBER :

Oracle DB security system treats local connections and remote connections

differently. As for local connections, In UNIX/LINUX systems SQLNET.ORA

located at $ORACLE_HOME/network/admin dir can be quite important.

OS user group will be able to login to Oracle database as an administrator

without supplying a user_id and a password i.e. "connect / as sysdba").

If user belongs DBA group but same convenient security approach has not

adopted for remote connections. "connect /as sysdba" statement is not

workable for a remote administrative user. OS authentication is available for



“connect /as sysdba” locally from the same machine where the database

resides, or when login from a remote client over HTTPS , SSL and VPN.

Required Operating System Groups and User

OSDBA GROUP (DBA) identifies os user accounts that have database

administrative privileges (the SYSDBA privilege). The Default name is dba.

OSOPER GROUP (OPER) This is an optional group . if we want a separate

group of operating system users to have a limited set of database

administrative privileges (the SYSOPER privilege). By default, members of the

OSDBA group have the SYSOPER privilege. OINSTALL group owns the Oracle

inventory, which is a catalog of all Oracle software installed on the system.

External Role Authorization

SQL>create user sonar identified by sona1234;

User created.

SQL> create role developer identified externally;

Role created.

SQL> grant developer to sona;

Grant succeeded.

SQL> grant create session , create table to developer;

Grant succeeded.

SQL> alter user sona quota unlimited on users;

User altered.



OS User SONA with “DEVELOPER“ ROLE

$ sqlplus

SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jan 1 19:41:30 2013


Enter user-name: sona

Enter password:

Connected to:



SQL> show user;

USER is "SONA"

SQL> select * from session_roles;

ROLE

DEVELOPER

SQL> create table asdf(no number , name varchar(15));

Table created.


sysoper and sysdba (auth)

Documents