OCA/OCP Oracle Database 11g All-in-One Exam Guide 206 In the first example in the figure, a username JOHN is created. This was entered in lowercase, but is converted to uppercase, as can be seen in the first query. The second example uses double quotes to create the user with a name in lowercase. The third and fourth examples use double quotes to bypass the rules on characters and reserved words; both of these would fail without the double quotes. If a username includes lowercase letters or illegal characters or is a reserved word, then double quotes must always be used to connect to the account subsequently. TIP It is possible to use nonstandard usernames, but this may cause dreadful confusion. Some applications rely on the case conversion; others always use double quotes. It is good practice to always use uppercase and only the standard characters. A username can never be changed after creation. If it is necessary to change it, the account must be dropped and another account created. This is a drastic action, because all the objects in the user’s schema will be dropped along with the user. Default Tablespace and Quotas Every user account has a default tablespace. This is the tablespace where any schema objects (such as tables or indexes) created by the user will reside. It is possible for a user to create (own) objects in any tablespace on which they have been granted a quota, but unless another tablespace is specified when creating the object, it will go into the user’s default tablespace. There is a database-wide default tablespace that will be applied to all user accounts if a default tablespace is not specified when creating the user. The default can be set when creating the database and changed later with: ALTER DATABASE DEFAULT TABLESPACE tablespace_name ; If a default tablespace is not specified when creating the database, it will be set to the SYSTEM tablespace. TIP After creating a database, do not leave the default tablespace as SYSTEM; this is very bad practice as nonsystem users could potentially fill up this tablespace, thus hampering the operation of the data dictionary and consequently the entire database. Change it as soon as you can. A quota is the amount of space in a tablespace that the schema objects of a user are allowed to occupy. You can create objects and allocate extents to them until the quota is reached. If you have no quota on a tablespace, you cannot create any objects at all. Quotas can be changed at any time by an administrator user with sufficient privileges. If a user’s quota is reduced to below the size of their existing objects (or even reduced to zero), the objects will survive and will still be usable, but they will not be permitted to get any bigger. Figure 6-2 shows how to investigate and set quotas. Chapter 6: Oracle Security 207 PART I The first command queries DBA_USERS and determines the default and temporary tablespaces for the user JOHN, created in Figure 6-1. DBA_USERS has one row for every user account in the database. User JOHN has picked up the database defaults for the default and temporary tablespaces, which are shown in the last query against DATABASE_PROPERTIES. The two ALTER USER commands in Figure 6-2 give user JOHN the capability to use up to 10MB of space in the USERS tablespace, and an unlimited amount of space in the EXAMPLE tablespace. The query against DBA_TS_QUOTAS confirms this; the number “–1” represents an unlimited quota. At the time the query was run, JOHN had not created any objects, so the figures for BYTES are zeros, indicating that he is not currently using any space in either tablespace. EXAM TIP Before you can create a table, you must have both permission to execute CREATE TABLE and quota on a tablespace in which to create it. TIP Most users will not need any quotas, because they will never create objects. They will only have permissions against objects owned by other schemas. The few object-owning schemas will probably have QUOTA UNLIMITED on the tablespaces where their objects reside. Temporary Tablespace Permanent objects (such as tables) are stored in permanent tablespaces; temporary objects are stored in temporary tablespaces. A session will need space in a temporary tablespace if it needs space for certain operations that exceed the space available in the session’s PGA. Remember that the PGA is the program global area, the private memory allocated to the session. Operations that need temporary space (in memory Figure 6-2 Managing user quotas OCA/OCP Oracle Database 11g All-in-One Exam Guide 208 if possible, in a temporary tablespace if necessary) include sorting rows, joining tables, building indexes, and using temporary tables. Every user account is assigned a temporary tablespace, and all user sessions connecting to the account will share this temporary tablespace. The query against DBA_USERS in Figure 6-2 shows user JOHN’s temporary tablespace, which is the database default temporary tablespace. This is shown by the last query in Figure 6-2, against DATABASE_PROPERTIES. Space management within a temporary tablespace is completely automatic. Temporary objects are created and dropped as necessary by the database. A user does not need to be granted a quota on their temporary tablespace. This is because the objects in it are not actually owned by them; they are owned by the SYS user, who has an unlimited quota on all tablespaces. EXAM TIP Users do not need a quota on their temporary tablespace. To change a user’s temporary tablespace (which will affect all future sessions that connect to that account), use an ALTER USER command: ALTER USER username TEMPORARY TABLESPACE tablespace_name; TIP If many users are logging on to the same user account, they will share the use of one temporary tablespace. This can be a performance bottleneck, which may be avoided by using temporary tablespace groups. Profile A user’s profile controls their password settings and provides a limited amount of control over resource usage. Use of profiles is detailed in the later section “Create and Manage Profiles.” Profiles are a useful way of managing passwords and resources but can really only apply in an environment where every application user has their own database user account. For example, if many users connect to the same database user account, you would not want the password to be invalidated by one of them, because that would lock out everyone else. Similarly, resource usage will often need to be managed on a per-session basis rather than for the account as a whole. Account Status Every user account has a certain status, as listed in the ACCOUNT_STATUS column of DBA_USERS. There are nine possibilities: • OPEN The account is available for use. • LOCKED This indicates that the DBA deliberately locked the account. No user can connect to a locked account. Chapter 6: Oracle Security 209 PART I • EXPIRED This indicates that the password lifetime has expired. Passwords can have a limited lifetime. No user can connect to an EXPIRED account until the password is reset. • EXPIRED & LOCKED Not only has the account been locked, but its password has also expired. • EXPIRED (GRACE) This indicates that the grace period is in effect. A password need not expire immediately when its lifetime ends; it may be configured with a grace period during which users connecting to the account have the opportunity to change the password. • LOCKED (TIMED) This indicates that the account is locked because of failed login attempts. An account can be configured to lock automatically for a period after an incorrect password is presented a certain number of times. • EXPIRED & LOCKED (TIMED) • EXPIRED (GRACE) & LOCKED • EXPIRED (GRACE) & LOCKED (TIMED) To lock and unlock an account, use these commands: ALTER USER username ACCOUNT LOCK ; ALTER USER username ACCOUNT UNLOCK ; To force a user to change their password, use this command: ALTER USER username PASSWORD EXPIRE; This will immediately start the grace period, forcing the user to make a password change at their next login attempt (or one soon after). There is no such command as “alter . . . unexpire.” The only way to make the account fully functional again is to reset the password. Authentication Methods A user account must have an authentication method: some means whereby the database can determine if the user attempting to create a session connecting to the account is allowed to do so. The simplest technique is by presenting a password that will be matched against a password stored within the database, but there are alternatives. The possibilities are • Operating system authentication • Password file authentication • Password authentication • External authentication • Global authentication OCA/OCP Oracle Database 11g All-in-One Exam Guide 210 The first two techniques are used only for administrators; the last requires an LDAP directory server. The LDAP directory server may be the Oracle Internet Directory, shipped as a part of the Oracle Application Server. Operating System and Password File Authentication To enable operating system and password file authentication (the two go together) for an account, you must grant the user either the SYSDBA or the SYSOPER privilege: GRANT [sysdba | sysoper ] TO username ; Granting either (or both) of these privileges will copy the user’s password from the data dictionary into the external password file, where it can be read by the instance even if the database is not open. It also allows the instance to authenticate users by checking whether the operating system user attempting the connection is a member of the operating system group that owns the Oracle Home installation. Following database creation, the only user with these privileges is SYS. To use password file authentication, the user can connect with this syntax using SQL*Plus: CONNECT username / password [@db_alias] AS [ SYSOPER | SYSDBA ] ; Note that password file authentication can be used for a connection to a remote database over Oracle Net. To use operating system authentication, the user must be first logged on to the database server after being authenticated as an operating system user with access to the Oracle binaries before connecting with this syntax using SQL*Plus: CONNECT / AS [ SYSOPER | SYSDBA ] ; The operating system password is not stored by Oracle, and therefore there are no issues with changing passwords. The equivalent of these syntaxes is also available when connecting with Database Control, by selecting SYSDBA from the Connect As drop-down box on the Database Control login window. To determine to whom the SYSDBA and SYSOPER privileges have been granted, query the view V$PWFILE_USERS. Connection with operating system or password file authentication is always possible, no matter what state the instance and database are in, and is necessary to issue STARTUP or SHUTDOWN commands. A third privilege that operates in the same manner as SYSDBA and SYSOPER is SYSASM. This is a privilege that is only applicable to ASM instances and is detailed in Chapter 20. TIP All user sessions must be authenticated. There is no such thing as an “anonymous” login, and some authentication method must be used. Chapter 6: Oracle Security 211 PART I Password Authentication The syntax for a connection with password authentication using SQL*Plus is CONNECT username / password [@db_alias] ; Or with Database Control, select NORMAL from the Connect As drop-down box. When connecting with password authentication, the instance will validate the password given against that stored with the user account in the data dictionary. For this to work, the database must be open; it is therefore logically impossible to issue STARTUP or SHUTDOWN commands when connected with password authentication. The user SYS is not permitted to connect with password authentication; only password file, operating system, or LDAP authentication is possible for SYS. Usernames are case sensitive but are automatically converted to uppercase unless specified within double quotes. In previous releases of the database, passwords were not case sensitive at all. With release 11g, passwords are case sensitive and there is no automatic case conversion. It is not necessary to use double quotes; the password will always be read exactly as entered. When a connection is made across a network, release 11g will always encrypt it using the AES algorithm before transmission. To use encryption for the ongoing traffic between the user process and the server process requires the Advanced Security Option, but password encryption is standard. Any user can change their user account password at any time, or a highly privileged user (such as SYSTEM) can change any user account password. The syntax (whether you are changing your own password or another one) is ALTER USER username IDENTIFIED BY password ; External Authentication If a user account is created with external authentication, Oracle will delegate the authentication to an external service; it will not prompt for a password. If the Advanced Security Option has been licensed, then the external service can be a Kerberos server, a RADIUS server, or (in the Windows environment) the Windows native authentication service. When a user attempts to connect to the user account, rather than authenticating the user itself, the database instance will accept (or reject) the authentication according to whether the external authentication service has authenticated the user. For example, if using Kerberos, the database will check that the user does have a valid Kerberos token. Without the Advanced Security Option, the only form of external authentication that can be used is operating system authentication. This is a requirement for SYSDBA and SYSOPER accounts (as already discussed) but can also be used for normal users. The technique is to create an Oracle user account with the same name as the operating system user account but prefixed with a string specified by the instance parameter OS_ AUTHENT_PREFIX. This parameter defaults to the string OPS$. To check its value, use a query such as select value from v$parameter where name='os_authent_prefix'; OCA/OCP Oracle Database 11g All-in-One Exam Guide 212 On Linux or Unix, external operating system authentication is very simple. Assuming that the OS_AUTHENT_PREFIX is on default and that there is an operating system user called jwatson, then create an oracle user and grant the CREATE SESSION privilege as follows: create user ops$jwatson identified externally; grant create session to ops$jwatson; A user logged on to Unix as jwatson will be able to issue the command: sqlplus / from an operating system prompt, and will be connected to the database user account ops$jwatson. Under Windows, when Oracle queries the operating system to identify the user, Windows will usually (depending on details of Windows security configuration) return the username prefixed with the Windows domain. Assuming that the Windows logon ID is John Watson (including a space) and that the Windows domain is JWACER (which happens to be the machine name) and that the OS_AUTHENT_PREFIX is on default, the command will be create user "OPS$JWACER\JOHN WATSON" identified externally; Note that the username must be in uppercase, and because of the illegal characters (a backslash and a space) must be enclosed in double quotes. TIP Using external authentication can be very useful, but only if the users actually log on to the machine hosting the database. Users will rarely do this, so the technique is more likely to be of value for accounts used for running maintenance or batch jobs. Global Authentication An emerging standard for identity management makes use of LDAP servers. An LDAP- compliant directory server, the Oracle Internet Directory, is distributed by Oracle Corporation as part of Oracle Application Server. A global user is a user who is defined within the LDAP directory, and global authentication is a means of delegating user authentication to the directory. There are two techniques for global authentication: • The users can be defined in the directory, and also in the database. A user will be connected to a user account with the same name as the user’s common name in the directory. • The users can be defined only in the directory. The database will be aware of the users’ global names but connects all users to the same database user account. Neither of these techniques requires the user to present a password to the database. The connection will happen without any prompts if the directory accounts and the database user accounts are set up correctly. Chapter 6: Oracle Security 213 PART I Creating Accounts The CREATE USER command has only two mandatory arguments: a username and a method of authentication. Optionally, it can accept a clause to specify a default tablespace and a temporary tablespace, one or more quota clauses, a named profile, and commands to lock the account and expire the password. A typical example (with line numbers added) would be 1 create user scott identified by tiger 2 default tablespace users temporary tablespace temp 3 quota 100m on users, quota unlimited on example 4 profile developer_profile 5 password expire 6 account unlock; Only the first line is required; there are defaults for everything else. Taking the command line by line: 1. Provide the username, and a password for password authentication. 2. Provide the default and temporary tablespaces. 3. Set up quotas on the default and another tablespace. 4. Nominate a profile for password and resource management. 5. Force the user to change his password immediately. 6. Make the account available for use (which would have been the default). Every attribute of an account can be adjusted later with ALTER USER commands, with the exception of the name. To change the password: alter user scott identified by lion; To change the default and temporary tablespaces: alter user scott default tablespace store_data temporary tablespace temp; To change quotas: alter user scott quota unlimited on store_data, quota 0 on users; To change the profile: alter user scott profile prod_profile; To force a password change: alter user scott password expire; To lock the account: alter user scott account lock; Having created a user account, it may be necessary to drop it: drop user scott; OCA/OCP Oracle Database 11g All-in-One Exam Guide 214 This command will only succeed if the user does not own any objects: if the schema is empty. If you do not want to identify all the objects owned and drop them first, they can be dropped with the user by specifying CASCADE: drop user scott cascade; To manage accounts with Database Control, from the database home page take the Schema tab and then the Users link in the Security section. This will show all the user accounts in the database. Figure 6-3 shows these, sorted in reverse order of creation. To change the sort order, click the appropriate column header. The first “user” in the figure is PUBLIC. This is a notional user to whom privileges can be granted if you wish to grant them to every user. The CREATE button will present a window that prompts for all the user account attributes. The DELETE button will drop an account, with the CASCADE option if necessary—but it will give an “Are you sure?” prompt before proceeding. To adjust the attributes of an account, select it and click EDIT. This will take you to the Edit User window, shown in Figure 6-4. This interface can be used to change all Figure 6-3 Users shown by Database Control Chapter 6: Oracle Security 215 PART I aspects of the account except for tablespace quotas, which have their own tabs. It also has tabs for granting and revoking privileges and roles. Exercise 6-1: Create Users In this exercise, you will create some users to be used for the remaining exercises in this chapter. It is assumed that there is a permanent tablespace called STOREDATA and a temporary tablespace called TEMP. If these don’t exist, either create them or use any other suitable tablespaces. 1. Connect to your database with SQL*Plus as a highly privileged user, such as SYSTEM or SYS. 2. Create three users: create user sales identified by sales default tablespace storedata password expire; create user webapp identified by oracle default tablespace storedata quota unlimited on storedata; create user accounts identified by oracle; Figure 6-4 The Edit User Database Control window . default tablespace is not specified when creating the user. The default can be set when creating the database and changed later with: ALTER DATABASE DEFAULT TABLESPACE tablespace_name ; If a default. such as select value from v$parameter where name='os_authent_prefix'; OCA/ OCP Oracle Database 11g All-in-One Exam Guide 212 On Linux or Unix, external operating system authentication. Operations that need temporary space (in memory Figure 6-2 Managing user quotas OCA/ OCP Oracle Database 11g All-in-One Exam Guide 208 if possible, in a temporary tablespace if necessary) include