Creating Required Operating System Groups and Users

If you are installing Oracle software for the first time and on the products that you are installing, create several operating system groups and users.

You can choose to create one administrative user and use one group for operating system authentication for all system privileges on the storage and database tiers. For example, you can designate the oracle user to be the Oracle Installation user for all Oracle software and use only the ORA_DBA group for authentication. You can also create custom configuration groups and users based on job role separation that divide access privileges.

Log in as an Administrator user, and use the following instructions to create the Oracle Installation user for Oracle Database.

About the Oracle Installation User

To install Oracle Restart or Oracle Database software, you must use either a local or a domain user that is also a member of the Administrators group.

This user is the Oracle Installation User. The Oracle Installation User can be either a local user or a domain user.

Creating Oracle Home User

During Oracle Database installation, you can specify an optional Oracle home user associated with the Oracle home.

For example, assume that you use an Administrator user named OraSys to install the software (Oracle Installation user), then you can specify the ORADOMAIN\OraDb domain user as the Oracle home user for this installation. The specified Oracle home domain user must exist before you install the Oracle Database software.

Oracle home user can be a Windows Built-in Account (LocalSystem for Server and LocalService for Client), Virtual Account, or a regular (not an administrator) Windows account. If you specify an existing user as the Oracle home user, then the Windows User Account you specify can either be a Windows Domain User or a Windows Local User.

A Windows User Account need not be created by the Administrator if a Virtual Account or a Windows Built-in Account is used during installation.

If you specify a non-existing user as the Oracle home user, then the Windows User Account you specify must be a Windows Local User. The installer creates this account automatically to run the Windows services for the Oracle home. Do not log in using this account to perform administrative tasks.

Starting with Oracle Database 12c Release 2 (12.2), the Group Managed Services Account (gMSA) and Virtual Accounts enables you to install Oracle Database, and create and manage Database services without passwords. The gMSA is a domain level account that can be used by multiple servers in a domain to run the services using this account. Windows User Account can be a Windows Local User, Windows Domain User, Managed Services Account (MSA), or Group Managed Services Account (gMSA).

If you want to create a new user during installation, then it can only be a Windows Local User. It cannot be a Windows Domain User, an MSA, or a gMSA. The new user that is created is denied interactive logon privileges to the Windows computer. However, a Windows administrator can manage this account like any other Windows account. Oracle recommends that you use Virtual Account or a standard Windows User Account (instead of Windows Built-in Account) as the Oracle Home User for enhanced security.

Note:

You cannot change the Oracle Home User after the installation is complete. If you must change the Oracle Home User, then you must reinstall the Oracle Database software.

When you specify an Oracle Home user, the installer configures that user as the Oracle Service user for all software services that run from the Oracle home. The Oracle Service user is the operating system user that the Oracle software services run as, or the user from which the services inherit privileges.

Silent installation is enhanced to support password prompt for the Oracle home user. So, customers and independent software vendors (ISV) can use response files without hard coding the password into the source code.

Oracle recommends using Virtual Account or a standard Windows User Account (not an Administrator account) as the Oracle Home User for typical installation, software-only installation, and cloning.

If an existing Windows User Account is used as the Oracle home user for software-only installation, then a password is not required. Thus, you can perform a silent, software-only installation using Windows User Account.

If you use a Windows User Account as the Oracle home user for cloning individual Oracle Database installations, then a password is not required.

Virtual Account is the Oracle home user for Oracle Database Single Instance database installation. The account enables you to install Oracle Database, create, and manage Database services without passwords. The gMSA is a domain level account that can be used by multiple servers in a domain to run the services using this account. The gMSA is a low privilege user account.

Understanding the Oracle Inventory Directory and the Oracle Inventory Group

The Oracle Inventory directory is the central inventory location for all Oracle software installed on a server.

By default, the location of the Oracle Inventory directory is C:\Program Files\Oracle\Inventory.

When you install Oracle software on the system for the first time, Oracle Universal Installer creates the directories for the Oracle central inventory and the Oracle Inventory group, ORA_INSTALL. The ORA_INSTALL group contains all the Oracle Home Users for all Oracle homes on the server.

Whether you are performing the first installation of Oracle software on this server, or are performing an installation of additional Oracle software on the server, you do not need to create the Oracle central inventory or the ORA_INSTALL group; the Oracle Universal Installer creates them automatically. You cannot change the name of the Oracle Inventory group - it is always ORA_INSTALL.

Operating System Groups Created During Oracle Database Installation

During installation, the user groups listed in the following table are created, if they do not already exist.

The HOMENAME variable refers to the generated HOMENAME for a software installation, which is of the form OraproductmajorVersionHomenumber. For example, OraDB12cHome1.

Table 4-1 User Groups Created During Oracle Database Installation

Operating System Group Name Related System Privilege Description

ORA_DBA

SYSDBA system privileges for all Oracle Database installations on the server

A special OSDBA group for the Windows operating system.

Members of this group are granted SYSDBA system privileges for all Oracle Databases installed on the server.

ORA_OPER

SYSOPER system privileges for all Oracle databases installed on the server

A special OSOPER group for the Windows operating system.

Members of this group are granted SYSOPER system privileges all Oracle Databases installed on the server. This group does not have any members after installation, but you can manually add users to this group after the installation completes.

ORA_ASMADMIN

SYSASM system privileges for Oracle ASM administration

The OSASM group for the Oracle ASM instance.

Using this group and the SYSASM system privileges enables the separation of SYSDBA database administration privileges from Oracle ASM storage administration privileges. Members of the OSASM group are authorized to connect using the SYSASM privilege and have full access to Oracle ASM, including administrative access to all disk groups that the Oracle ASM instance manages.

ORA_ASMDBA

SYSDBA system privileges on the Oracle ASM instance

The OSDBA group for the Oracle ASM instance.

This group grants access for the database to connect to Oracle ASM. During installation, the Oracle Installation Users are configured as members of this group. After you create an Oracle Database, this group contains the Oracle Home Users of those database homes.

ORA_ASMOPER

SYSOPER for ASM system privileges

The OSOPER group for the Oracle ASM instance.

Members of this group are granted SYSOPER system privileges on the Oracle ASM instance, which permits a user to perform operations such as startup, shutdown, mount, dismount, and check disk group. This group has a subset of the privileges of the OSASM group. Similar to the ORA_HOMENAME_OPER group, this group does not have any members after installation, but you can manually add users to this group after the installation completes.

ORA_HOMENAME_DBA

SYSDBA system privileges for all instances that run from the Oracle home with the name HOMENAME

An OSDBA group for a specific Oracle home with a name of HOMENAME.

Members of this group can use operating system authentication to gain SYSDBA system privileges for any database that runs from the specific Oracle home. If you specified an Oracle Home User during installation, the user is added to this group during installation.

ORA_HOMENAME_OPER

SYSOPER system privileges for all instances that run from the Oracle home with a name HOMENAME

An OSDBA group for the Oracle home with a name of HOMENAME.

Members of this group can use operating system authentication to gain SYSOPER system privileges for any database that runs from the specific Oracle home. This group does not have any members after installation, but you can manually add users to this group after the installation completes.

ORA_HOMENAME_SYSBACKUP

SYSBACKUP system privileges for all instances that run from the Oracle home with a name of HOMENAME

OSBACKUPDBA group for a specific Oracle home with a name of HOMENAME.

Members of this group have privileges necessary for performing database backup and recovery tasks on all database instances that run from the specified Oracle home directory.

ORA_HOMENAME_SYSDG

SYSDG system privileges for all instances that run from the Oracle home with a name of HOMENAME

OSDGDBA group for a specific Oracle home with a name of HOMENAME.

Members of this group have privileges necessary for performing Data Guard administrative tasks on all database instances that run from the specified Oracle home directory.

ORA_HOMENAME_SYSKM

SYSKM system privileges for all instances that run from the Oracle home with a name of HOMENAME.

OSKMDBA group for a specific Oracle home with a name of HOMENAME.

Members of this group have privileges necessary for performing encryption key management tasks on all database instances that run from the specified Oracle home directory.

ORA_HOMENAME_SYSRAC

SYSRAC system privileges for all instances that run from the Oracle home with a name of HOMENAME.

OSRACDBA group for a specific Oracle home with a name of HOMENAME.

Members of this group have privileges necessary for performing a limited set of Oracle Real Application Clusters administrative tasks to create a separate group of operating system users.

ORA_HOMENAME_SVCACCTS

Contains Virtual Accounts for all Oracle Database Windows Services that run from Oracle home with a name of HOMENAME.

SVCACCTS group specific to a Oracle home. It contains virtual accounts for all the services running under that virtual account based HOMENAME.

ORA_DBSVCACCTS

Contains Virtual Accounts for all Oracle Database Windows Services that run for all Virtual Accounts based Oracle homes.

DBSVCACCTS system-wide group that contains virtual accounts for all the database services for all Virtual Accounts based Oracle homes.

During the installation of Oracle Database, all groups mentioned in the table are populated for proper operation of Oracle products. You must not remove any group member populated by Oracle. However, if you want to assign specific database privileges to new Windows operating system users, then you can manually add users to these groups after the installation completes.

Oracle creates other groups, such as, ORA_INSTALL, ORA_CLIENT_LISTENERS, ORA_GRID_LISTENERS, ORA_HOMENAME_SVCSIDS, ORA_HOMENAME_SVCACCTS, and ORA_DBSVCACCTS during installation and you must not change these groups, memberships, and ACLs associated with various Oracle created groups.

Operating System Groups and Users for Job Role Separation

A job role separation configuration of Oracle Database and Oracle ASM is a configuration with groups and users to provide separate groups for operating system authentication.

About Job Role Separation Operating System Privileges Groups and Users

During the Oracle Database installation, the ORA_DBA, ORA_OPER, ORA_HOMENAME_DBA, ORA_HOMENAME_OPER, ORA_HOMENAME_SYSBACKUP, ORA_HOMENAME_SYSDG, ORA_HOMENAME_SYSKM, and ORA_HOMENAME_SYSRAC groups are created and users assigned to these groups.

Members of these groups are granted operating system authentication for the set of database system privileges each group authorizes. Oracle recommends that you use different operating system groups for each set of system privileges.

Oracle Software Owner For Each Oracle Software Product

You can create a single user (for example, oracle) to own both Oracle Database, and Oracle Restart installations.

However, Oracle recommends that you create one software owner to own each Oracle software installation (typically, oracle, for the database software and grid for the Oracle Restart owner user).

You must create at least one software owner the first time you install Oracle software on the system.

Note:

In Oracle documentation, a user created to own only Oracle Grid Infrastructure software installations is called the grid user. A user created to own either all Oracle installations, or only Oracle database installations, is called the oracle user.

Standard Oracle Database Groups for Job Role Separation for Oracle Database

Review the standard Oracle Database groups.

The following is a list of standard Oracle Database groups. These groups provide operating system authentication for database administration system privileges:

Note:

All these groups are automatically created as a part of Oracle Database installation on Windows.

  • The OSDBA group (ORA_DBA)

    Use this group the first time you install Oracle Database software on the system. This group identifies operating system user accounts that have database administrative privileges (the SYSDBA privilege) for all database instances running on the server.

    Members of the ORA_DBA group do not have SYSASM privileges on Oracle ASM instances, which are needed for mounting and dismounting disk groups.

  • The OSOPER group for Oracle Database (ORA_OPER)

    Use this group if you want a separate group of operating system users to have a limited set of database administrative privileges for starting up and shutting down the database (the SYSOPER privilege).

  • The OSDBA group for a particular Oracle home (ORA_HOMENAME_DBA)

    This group is created the first time you install Oracle Database software into a new Oracle home. This group identifies operating system user accounts that have database administrative privileges (the SYSDBA privilege) for the database instances that run from that Oracle home.

  • The OSOPER group for a particular Oracle home (ORA_HOMENAME_OPER)

    Use this group if you want a separate group of operating system users to have a limited set of database administrative privileges for starting up and shutting down the database instances that run from a particular Oracle home (the SYSOPER privilege).

Extended Oracle Database Groups for Job Role Separation

In addition to the SYSOPER privilege to start up and shut down the database, you can create new administrative privileges that are more task-specific and less privileged than the ORA_DBA/SYSDBA system privileges to support specific administrative privileges tasks required for everyday database operation.

Users granted these system privileges are also authenticated through operating system group membership.

During installation, you are prompted to provide operating system groups whose members are granted access to these system privileges. You can assign the same group to provide authentication for these privileges (for example, ORA_DBA), but Oracle recommends that you provide a unique group to designate each privilege.

The OSDBA subset job role separation privileges and groups consist of the following:

  • The OSBACKUPDBA group for Oracle Database (ORA_HOMENAME_SYSBACKUP)

    Use this group if you want a separate group of operating system users to have a limited set of database backup and recovery related administrative privileges (the SYSBACKUP privilege).

  • The OSDGDBA group for Oracle Data Guard (ORA_HOMENAME_SYSDG)

    Use this group if you want a separate group of operating system users to have a limited set of privileges to administer and monitor Oracle Data Guard (the SYSDG privilege).

  • The OSKMDBA group for encryption key management (ORA_HOMENAME_SYSKM)

    Use this group if you want a separate group of operating system users to have a limited set of privileges for encryption key management such as Oracle Wallet Manager management (the SYSKM privilege).

  • The OSRACDBA group for Oracle Real Application Clusters Administration (ORA_HOMENAME_SYSRAC)

    Use this group if you want a separate group of operating system users to have a limited set of Oracle Real Application Clusters (RAC) administrative privileges (the SYSRAC privilege). To use this privilege:

    • Add the Oracle Database installation owners as members of this group.

Note:

All these groups, ORA_HOMENAME_SYSBACKUP, ORA_HOMENAME_SYSDG, ORA_HOMENAME_SYSKM, and ORA_HOMENAME_SYSRAC are applicable only to the database instances running from that particular Oracle home.

Oracle Automatic Storage Management Groups for Job Role Separation

Review the operating system groups.

Create the following operating system groups if you are installing Oracle Grid Infrastructure:

  • The OSDBA group for Oracle ASM (ORA_ASMDBA)

    This group grants access for the database to connect to Oracle ASM. During installation, the Oracle Installation Users are configured as members of this group. After you create an Oracle Database, this group contains the Oracle Home Users of those database homes. Any client of Oracle ASM that needs to access storage managed by Oracle ASM needs to be in this group.

  • The OSASM group for Oracle ASM Administration (ORA_ASMADMIN)

    Use this separate group to have separate administration privilege groups for Oracle ASM and Oracle Database administrators. Members of this group are granted the SYSASM system privilege to administer Oracle ASM. In Oracle documentation, the operating system group whose members are granted privileges is called the OSASM group. During installation, the Oracle Installation User for Oracle Grid Infrastructure and Oracle Database Service IDs are configured as members of this group. Membership in this group also grants database access to the Oracle ASM disks.

    Members of the OSASM group can use SQL to connect to an Oracle ASM instance as SYSASM using operating system authentication. The SYSASM privilege permits mounting and dismounting disk groups, and other storage administration tasks. SYSASM system privileges do not grant access privileges on an Oracle Database instance.

  • The OSOPER group for Oracle ASM (ORA_ASMOPER)

    This is an optional group. Create this group if you want a separate group of operating system users to have a limited set of Oracle ASM instance administrative privileges (the SYSOPER for ASM privilege), including starting up and stopping the Oracle ASM instance. By default, members of the OSASM group also have all privileges granted by the SYSOPER for ASM privilege.

    To use the Oracle ASM Operator group to create an Oracle ASM administrator with fewer privileges than those granted by the SYSASM system privilege you must assign the user to this group after installation.

Windows Group Managed Service Accounts and Virtual Accounts

Group Managed Services Account (gMSA) and Virtual Accounts are now supported and enable you to create and manage Database services without passwords.

Microsoft Hyper-V

Microsoft Hyper-V enables you to create and manage a virtualized computing environment by running multiple operating systems simultaneously on a single computer and isolate operating systems from each other.

Microsoft Hyper-V enables built-in integration services for supported guest operating systems to improve the integration between a computer and a virtual machine.

See Also:

http://www.oracle.com/technetwork/database/virtualizationmatrix-172995.html for more information about Microsoft Hyper-V support