ALTER USER
目的
ALTER
USER
を使用すると、次の操作を実行できます。
-
データベース・ユーザーの認証またはデータベース・リソースの特性を変更します。
-
プロキシ・サーバーが認証なしでクライアントとして接続することを許可します。
-
Oracle Automatic Storage Management (Oracle ASM)クラスタで、ユーザーのパスワードを現在のノードのOracle ASMインスタンスに対してローカルなパスワード・ファイルで変更します。
関連項目:
ユーザーの認証方式の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
前提条件
通常、ALTER
USER
システム権限が必要です。ただし、現行ユーザーはこの権限がない場合でも自分のパスワードは変更できます。
SYS
パスワードを変更するには、パスワード・ファイルが存在する必要があり、SYS
パスワードを変更できるようにするには、alter user権限を付与されたアカウントにSYSDBA
管理ロールが必要です。
Oracle ASMインスタンス・パスワード・ファイルで自分以外のユーザーのパスワードを変更するには、AS
SYSASM
として認証されている必要があります。
CONTAINER
句を指定する場合は、マルチテナント・コンテナ・データベース(CDB)に接続している必要があります。現在のコンテナがルートである場合は、CONTAINER
=
ALL
またはCONTAINER
=
CURRENT
を指定できます。現在のコンテナがプラガブル・データベース(PDB)である場合は、CONTAINER
=
CURRENT
のみ指定可能です。
container_data_clause
を使用してCONTAINER_DATA
属性を設定および変更する場合は、CDBに接続している必要があります。また、現在のコンテナがルートである必要があります。
構文
container_data_clause::=
db_user_proxy_clauses::=
セマンティクス
この項で説明するキーワード、パラメータおよび句は、ALTER
USER
独自か、または、CREATE
USER
での場合とセマンティクスが異なります。その他のキーワード、パラメータおよび句には、CREATE
USER
文と同じ意味があります。
ノート:
ユーザー名およびパスワードは、ご使用のプラットフォームに応じて、ASCIIまたはEBCDIC文字のみでエンコードすることをお薦めします。
関連項目:
キーワードおよびパラメータについては、「CREATE USER」を参照してください。ユーザーにデータベース・リソースへの制限を割り当てる方法については、「CREATE PROFILE」を参照してください。
IF EXISTS
IF EXISTS
は、既存の表を変更する場合に指定します。
ALTER VIEW
にIF NOT EXISTS
を指定すると、ORA-11544: Incorrect IF EXISTS clause for ALTER/DROP statement
が発生します。
IDENTIFIED句
BY password
BY
password
を指定すると、ユーザーの新しいパスワードを指定できます。パスワードは大/小文字が区別されます。この後に、ユーザーをデータベースに接続するために使用されるCONNECT
文字列は、このALTER
USER
文で使用されているものと同じ文字(大文字、小文字または混在)を使用してパスワードを指定する必要があります。パスワードには、データベース文字セットから、シングルバイト文字、マルチバイト文字または両方を含めることができます。
ノート:
異なるタイムスタンプで特定のパスワードを再設定する必要があります。1秒以内に1つのパスワードを複数回再設定した場合(たとえば、スクリプトを使用して一連のパスワードの設定を繰り返した場合)、データベースはパスワードが再利用できないというエラー・メッセージを戻すことがあります。このため、パスワードの再設定には、スクリプトを使用しないことをお薦めします。
自分のパスワードを設定する場合、またはALTER
USER
システム権限を持っていて、他のユーザーのパスワードを変更する場合は、REPLACE
句を省略できます。ただし、ALTER
USER
システム権限を持たないかぎり、複雑なパスワードの検証機能が使用可能な場合は、UTLPWDMG.SQL
スクリプトを実行するか、またはユーザーに割り当てられたプロファイルのPASSWORD_VERIFY_FUNCTION
パラメータに検証機能を指定して、常にREPLACE
句を指定する必要があります。
Oracle ASMクラスタで、この句を使用して、ユーザーのパスワードを、現行のノードのOracle ASMインスタンスに対してローカルなパスワード・ファイルで変更できます。REPLACE
old_password
句を使用せずにIDENTIFIED
BY
password
を指定するには、AS
SYSASM
として認証されている必要があります。AS
SYSASM
として認証されていない場合は、REPLACE
old_password
を指定して自分のパスワードのみを変更できます。
以前のパスワードをREPLACE
句に指定した場合でも、自分以外の既存のパスワードを変更している場合は、以前のパスワードはチェックされません。
段階的なデータベース・パスワード・ロールオーバー期間を開始するためのパスワードの変更
前提条件
CREATE PROFILE
またはALTER PROFILE
を使用してPASSWORD_ROLLOVER_TIME
ユーザー・プロファイル・パラメータにゼロ以外の値を設定し、段階的なデータベース・パスワード・ロールオーバー期間を有効にします。
PASSWORD_ROLLOVER_TIME
を設定して、ユーザーのプロファイルで段階的なパスワード・ロールオーバー期間を指定した後、ALTER USER
文を使用してユーザーのパスワードを変更でき、これにより、パスワード・ロールオーバー期間が期限切れになるまで、クライアントは古いパスワードと新しいパスワードの両方を使用してログインできるようになります。
パスワード・ロールオーバー期間中に、( PASSWORD_ROLLOVER_TIME
が終了する前に)新しいパスワードをすべてのクライアントに伝播する必要があります。新しいパスワードを早期に(パスワード・ロールオーバー期間の終了前に)すべてのクライアントに正常に伝播した場合は、EXPIRE PASSWORD ROLLOVER PERIOD
句を使用してパスワード・ロールオーバーを終了できます(新しいパスワードのみを使用できるように、パスワードの変更をファイナライズできます)。
段階的なデータベース・パスワード・ロールオーバー期間中のパスワードの変更
パスワード・ロールオーバー期間中に(ロールオーバー期間が期限切れになる前に)、REPLACE
句の有無にかかわらず、ALTER USER
を使用してパスワードを変更できます。
たとえば、ユーザーu1
が元のパスワードp1
を持ち、p2
がロールオーバー・プロセスを開始した新しいパスワードであるとします。ここで、p2
のかわりにp3
に切り替えます。次のいずれかの文を使用して、パスワードをp3
に変更できます。
ALTER USER u1 IDENTIFIED BY p3;
ALTER USER u1 IDENTIFIED BY p3 REPLACE p1;
ALTER USER u1 IDENTIFIED BY p3 REPLACE p2;
パスワードをp3
に変更した後、ユーザーはp1
またはp3
を使用してログインできます。p2
を使用してログインすると、エラーInvalid credential or not authorized; logon denied
が戻され、ログイン試行の失敗として記録されます。
ロールオーバーの開始時間は、パスワード変更のタイムスタンプ、つまり、ユーザーのパスワードが変更された時間に設定されたままとなります。ロールオーバーの開始時間とパスワードの変更時間は、パスワード・ロールオーバー期間中にさらにパスワードが変更されても影響を受けません。古いパスワードは、最大でPASSWORD_ROLLOVER_TIME
の日数の間使用できます。
関連項目:
-
パスワード作成のガイドラインに関しては『Oracle Databaseセキュリティ・ガイド』を参照してください
GLOBALLY
この句の詳細は、「CREATE USER」を参照してください。
ユーザー・アクセスの検証方法は、IDENTIFIED
GLOBALLY
からIDENTIFIED
BY
password
またはIDENTIFIED
EXTERNALLY
のいずれかに変更できます。ユーザーのアクセス検証方法を他のいずれかの検証方法からIDENTIFIED
GLOBALLY
に変更できるのは、ユーザーに明示的に付与されたすべての外部ロールが取り消された場合のみです。
EXTERNALLY
この句の詳細は、「CREATE USER」を参照してください。
関連項目:
グローバルまたは外部で識別されるユーザーの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。また、「ユーザー識別の変更: 例」および「ユーザー認証の変更: 例」も参照してください。
NO AUTHENTICATION句
この句を使用して、認証を使用する既存のユーザー・アカウントを認証を使用しないスキーマ・アカウントに変更して、アカウントにログインできないようにします。
DEFAULT COLLATION句
この句を使用すると、ユーザーが所有するスキーマのデフォルトの照合を変更できます。新しいデフォルトの照合は、それ以降にスキーマで作成される表、ビューおよびマテリアライズド・ビューに割り当てられます。これは、既存の表ビューおよびマテリアライズド・ビューのデフォルトの照合には影響を及ぼしません。この句のセマンティクスの詳細は、「CREATE
USER
」の「DEFAULT COLLATION句」を参照してください。
DEFAULT TABLESPACE句
この句を使用すると、ユーザーの永続セグメントの表領域の割当てまたは再割当てを行うことができます。この句は、データベース用に指定されているデフォルトの表領域を上書きします。
デフォルト表領域の制限事項
ローカル管理の一時表領域(UNDO表領域を含む)またはディクショナリ管理の一時表領域は、ユーザーのデフォルトの表領域として指定できません。
[LOCAL] TEMPORARY TABLESPACE句
この句を使用すると、ユーザーの一時セグメントの一時表領域または表領域グループの割当てまたは再割当てを行うことができます。
-
tablespace
に、ユーザーの一時セグメント表領域を指定します。共有一時表領域を指定するには、TEMPORARY
TABLESPACE
を指定します。ローカル一時表領域を指定するには、LOCAL
TEMPORARY
TABLESPACE
を指定します。CDBに接続しているときに、CDB$DEFAULT
を指定すると、CDB全体のデフォルト一時表領域を使用できます。 -
tablespace_group_name
を指定すると、ユーザーは、tablespace_group_name
で指定された表領域グループ内の任意の表領域に一時セグメントを保存できるようになります。ローカル一時表領域を表領域グループに含めることはできません。
ユーザーの一時表領域の制限事項
ユーザーの一時表領域として割り当てる表領域、または再度割り当てる表領域は、標準的なブロック・サイズの一時表領域である必要があります。
関連項目:
DEFAULT ROLE句
ログオン時に、ユーザーに対してデフォルトで有効になるロールを指定します。この句では、GRANT
文を使用してユーザーに直接付与されているロール、またはCREATE
ROLE
権限を持つユーザーが作成したロールのみ指定できます。DEFAULT
ROLE
句を使用して次のロールを指定することはできません。
-
ユーザーに付与されていないロール
-
他のロールを介して付与されているロール
-
外部サービス(オペレーティング・システムなど)またはOracle Internet Directoryによって管理されるロール
-
パスワード認証されるロールや保護アプリケーション・ロールなど、
SET
ROLE
文によって使用可能になるロール
関連項目:
CDBの共通ユーザーへのデフォルト・ロールの割当て
現在のコンテナや、CDB内のすべてのコンテナの共通ユーザーに割り当てられたデフォルト・ロールを変更できます。
すべてのコンテナの共通ユーザーにデフォルト・ロールを割り当てているときには、role
は、共通ユーザーに共通に付与された共通ロールにする必要があります。
現在のコンテナの共通ユーザーにデフォルト・ロールを割り当てているときには、role
は、次のいずれかのロールにする必要があります。
-
現在のコンテナの共通ユーザーに付与されたローカル・ロール
-
共通ユーザーに付与された共通ロール(共通に付与されたものか、現在のコンテナでローカルに付与されたもののいずれか)
EXPIRE PASSWORD ROLLOVER PERIOD句
EXPIRE PASSWORD ROLLOVER PERIOD
を使用して、パスワード・ロールオーバー期間を手動で期限切れにすることができます。
ENABLE EDITIONS
この句は元に戻すことができません。ENABLE
EDITIONS
を指定すると、ユーザーは、エディションを使用しているスキーマ内で、エディション化可能なオブジェクトの複数のバージョンを作成できるようになります。エディションが有効でないスキーマ内のエディション化可能なオブジェクトは、エディション化できません。
FOR
句を使用すると、ユーザーが作成できるエディション化可能オブジェクトについて、1つ以上のオブジェクト・タイプを指定できます。object_type
の有効な値のリストを表示するには、V$EDITIONABLE_TYPES
動的パフォーマンス・ビューを問い合せます。
FOR
句を省略した場合、スキーマでエディション化可能になる型は、VIEW
、SYNONYM
、PROCEDURE
、FUNCTION
、PACKAGE
、PACKAGE BODY
、TRIGGER
、TYPE
、TYPE BODY
およびLIBRARY
です。
デフォルトで有効になっていない他のオブジェクト・タイプのエディションを有効にするには、FOR
句でオブジェクト・タイプを明示的に指定する必要があります。
例: デフォルトで有効になっていないオブジェクト・タイプのエディションの有効化
ALTER USER username ENABLE EDITIONS FOR SQL TRANSLATION PROFILE;
関連項目:
-
ENABLE EDITIONS句のセマンティクスの詳細は、CREATE USERの対応する項を参照してください。
-
V$EDITIONABLE_TYPES
動的パフォーマンス・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
エディションを有効にするスキーマ内にエディション化が可能でないオブジェクトが含まれており、そのオブジェクトがスキーマ内のエディション化可能なオブジェクトに依存している場合は、FORCE
を指定して、このスキーマのエディションを有効にする必要があります。この場合、エディションを有効にするスキーマ内にある、エディション化可能なタイプのオブジェクトに依存するオブジェクトのうち、エディション化が可能でないオブジェクトは、すべて無効になります。
[HTTP] DIGEST句
この句を使用すると、ユーザーのHTTP Digestアクセス認証を有効または無効にできます。
-
HTTP Digestアクセス認証を有効にする場合は、
ENABLE
を指定します。この句を指定した後、ユーザーのパスワードを変更する必要があります。これにより、データベースで新しいパスワードのHTTP Digest検証が生成されます。このようにすることによってのみ、HTTP Digestアクセス認証が有効になります。この句を発行した後でユーザーのパスワードが確実に変更されるようにする1つの方法は、HTTP
DIGEST
ENABLE
句と同じ文内で、次のようにPASSWORD
EXPIRE
句を指定することです。ALTER USER user PASSWORD EXPIRE HTTP DIGEST ENABLE;
これにより、ユーザーが次回データベースにログインしようとすると、新しいパスワードを要求されます。その後、ユーザーのHTTP Digestアクセス認証が有効になります。
-
ユーザーのHTTP Digestアクセス認証を無効にする場合は、
DISABLE
を指定します。この句を有効にするために、ユーザーのパスワードを変更する必要はありません。DISABLE
句を指定すると、ディクショナリ表からHTTPダイジェストが削除されます。ALTER USER user PASSWORD EXPIRE HTTP DIGEST DISABLE;
この句の詳細は、CREATE
USER
のドキュメントの「[HTTP] DIGEST句」を参照してください。
CONTAINER句
現在のコンテナがPDBである場合、CONTAINER
=
CURRENT
を指定すると、現在のコンテナ内で、ローカル・ユーザーの属性、または共通ユーザーのコンテナ固有の属性(デフォルト表領域など)を変更できます。現在のコンテナがルートである場合は、CONTAINER
=
ALL
を指定することによって、CDB全体の共通ユーザーの属性を変更できます。現在のコンテナがPDBであるときにこの句を省略した場合、デフォルトはCONTAINER
=
CURRENT
です。現在のコンテナがルートであるときにこの句を省略した場合、デフォルトはCONTAINER
=
ALL
です。
CDBの共通ユーザーの変更の制限事項
共通ユーザーの特定の属性は、CDB内の一部のコンテナに限定するのではなく、すべてのコンテナに対して変更する必要があります。そのため、次のいずれかの句を使用して共通ユーザーを変更にするときには、ルートに接続し、CONTAINER=ALL
を指定することによって、すべてのコンテナを変更するようにしてください。
-
IDENTIFIED
句 -
PASSWORD
句 -
[HTTP]
DIGEST
句
ENABLEまたはDISABLE DICTIONARY PROTECTION
この句を使用して、作成したユーザーに対してディクショナリ保護を有効または無効にします。スキーマがディクショナリ保護されている場合、スキーマに対するシステム権限が付与されている場合でも、他のユーザーはスキーマに対してシステム権限(ANY
権限を含む)を使用できません。ディクショナリ保護されたスキーマに対して使用できるのは、SELECT ANY DICTIONARY
およびANALYZE ANY DICTIONARY
システム権限のみです。ユーザーは、スキーマに対するオブジェクト権限が付与されている場合、引き続きスキーマに対してオブジェクト権限を使用できます。オブジェクトに対するオブジェクト権限がないが、対応するシステム権限を持つユーザーは、権限不足エラーでオブジェクトへのアクセスを拒否されます。
デフォルトでは、Oracle管理スキーマはディクショナリ保護を受けていますが、この保護は必要に応じて一時的に削除できます。顧客(Oracle以外の管理)スキーマでディクショナリ保護を有効にすることはできません。ディクショナリ保護を有効にしたカスタム・スキーマも作成できません。
Oracle管理スキーマのディクショナリ保護を管理するには、SYSDBA
管理権限を持つユーザーSYS
としてログインする必要があります。
関連項目:
-
『Oracle Databaseセキュリティ・ガイド』の「権限とロール認可の構成」
READ ONLY | READ WRITE
ローカルPDBユーザーへの読取り専用アクセスを設定するには、READ ONLY
を指定します。
読取り専用アクセスの場合、ローカルPDBユーザーは、接続先のPDBに対する書込み操作を実行できません。セッションは、データベースが読取り専用モードで開いているかのように動作します。
ローカル・ユーザーに対するREAD ONLY
アクセスを取り消すには、READ WRITE
を指定します。
この文を実行するには、ALTER USER
権限が必要です。
ローカル・ユーザーの状態は、*_USERS
ビューで表示できます。
container_data_clause
container_data_clause
を使用すると、共通ユーザーのCONTAINER_DATA
属性を設定および変更できます。FOR
句を使用すると、デフォルトのCONTAINER_DATA
属性を設定または変更するのか、オブジェクト固有のCONTAINER_DATA
属性を設定または変更するのかを指定できます。これらの属性によって決定されるコンテナ・セット(このセットからのルートの除外は不可)のデータが、現在のセッションがルートであるときに、CONTAINER_DATA
オブジェクトを介して、指定した共通ユーザーに表示されます。
container_data_clause
を指定するには、現在のセッションがルートである必要があります。また、CONTAINER
=
CURRENT
を指定する必要があります。
SET CONTAINER_DATA
この句を使用すると、デフォルトのCONTAINER_DATA
属性、または共通ユーザーのオブジェクト固有のCONTAINER_DATA
属性を設定できます。この句を使用すると、CONTAINER_DATA
属性に既存の値がある場合は、その値が置換されます。
container_name
を使用すると、ユーザーがアクセスできるようになる1つ以上のコンテナを指定できます。
ALL
を使用すると、ユーザーは、CDBに含まれる現在または将来のすべてのコンテナにアクセスできるようになります。
DEFAULT
を使用すると、次に示すデフォルトの動作を指定できます。
-
デフォルトの
CONTAINER_DATA
属性の場合、ユーザーは、現在のコンテナ(つまり、ルート)と、CDB全体にアクセスできるようになります。 -
オブジェクト固有の
CONTAINER_DATA
属性の場合、データベースはユーザーのデフォルトのCONTAINER_DATA
属性を使用します。
ノート:
CONTAINER_DATA
属性はDEFAULT
に設定されていると、DBA_CONTAINER_DATA
ビューに表示されません。
ADD CONTAINER_DATA
この句を使用すると、デフォルトのCONTAINER_DATA
属性、または共通ユーザーのオブジェクト固有のCONTAINER_DATA
属性にコンテナを追加できます。container_name
を使用すると、追加するコンテナを1つ以上指定できます。
この句は、デフォルトのCONTAINER_DATA
属性にALL
を設定しているときには指定できません。デフォルトのCONTAINER_DATA
属性にDEFAULT
を設定しているときに、この句を使用すると、コンテナのセットにCDB$ROOT
が自動的に追加されます(このセットにCDB$ROOT
がすでに含まれていない場合)。
この句は、オブジェクト固有のCONTAINER_DATA
属性をALL
またはDEFAULT
に設定されているときには使用できません。
REMOVE CONTAINER_DATA
この句を使用すると、デフォルトのCONTAINER_DATA
属性、または共通ユーザーのオブジェクト固有のCONTAINER_DATA
属性からコンテナを削除できます。container_name
を使用すると、削除するコンテナを1つ以上指定できます。
この句は、デフォルトのCONTAINER_DATA
属性またはオブジェクト固有のCONTAINER_DATA
属性をALL
またはDEFAULT
に設定しているときには使用できません。
FOR container_data_object
FOR
句を指定すると、共通ユーザーのcontainer_data_object
のオブジェクト固有のCONTAINER_DATA
属性を設定および変更できます。container_data_object
は、CONTAINER_DATA
表またはビューであることが必要です。schema
を省略すると、そのcontainer_data_object
は自分のスキーマ内にあるとみなされます。
FOR
句を省略すると、共通ユーザーのデフォルトのCONTAINER_DATA
属性を設定および変更できるようになります。
関連項目:
PDBオブジェクトに関する情報が共通ユーザーに表示されるようにする方法の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
proxy_clause
proxy_clause
を使用すると、エンタープライズ・ユーザー(データベースの外側のユーザー)またはデータベース・プロキシ(別のデータベース・ユーザー)が、変更対象のデータベース・ユーザーとして、どのように接続できるようにするかを制御できます。
GRANT CONNECT THROUGH
GRANT
CONNECT
THROUGH
を指定すると、接続を許可できます。
REVOKE CONNECT THROUGH
REVOKE
CONNECT
THROUGH
を指定すると、接続を禁止できます。
ENTERPRISE USER
この句を使用すると、user
を、エンタープライズ・ユーザーがプロキシ使用できるように公開できます。Oracle Internet Directoryを担当する管理者は、user
の代理として作業するエンタープライズ・ユーザーに権限を適切に付与する必要があります。
db_user_proxy
この句を使用すると、user
を、データベース・ユーザーdb_user_proxy
(プロキシ)がプロキシ使用できるように公開できます。
-
プロキシは、userに直接付与されたすべての権限を持ちます。
-
db_user_proxy_clauses
のWITH
句を指定してプロキシをuserの一部のロールまたはロールなしに制限した場合を除き、プロキシはuserに関連付けられているすべてのロールを持ちます。プロキシに関連付けられている各ロールについて、デフォルトでログイン時にuser
に対してロールが有効化される場合、プロキシに対してもデフォルトでログイン時にそのロールが有効化されます。
db_user_proxy_clauses
プロキシ・セッションで、パスワード保護されたロールを有効にできます。セキュア・アプリケーション・ロールでも、パスワード保護されたロールでも、セッションでロールを有効にする安全な方法があります。安全でないチャネルでパスワードを管理、転送しなければならない場合には、または複数の担当者がパスワードを知る必要がある場合には、パスワード保護されたロールではなく、セキュア・パスワード・ロールを使用することをお薦めします。プロキシ・セッションの場合、パスワード保護されたロールは、自動化処理を利用してロールを設定する状況に適しています。
プロキシ・ユーザーはパスワード保護されたロールにアクセスできます。WITH
句を指定して、プロキシをuser
に関連付けられている一部のロールまたはロールなしに制限し、AUTHENTICATION
REQUIRED
句を使用して、認証が必要かどうかを指定します。
WITH ROLE
WITH
ROLE
role_name
を使用すると、プロキシは指定したユーザーとして接続でき、role_name
で指定されたロールのみをアクティブにできますこの句には、user
に関連付けられているロールのみを含めることができます。プロキシ・ユーザーをセキュアなロールとして使用する必要がある場合、パスワード保護されたロールと、セキュア・アプリケーション・ロールは、WITH
ROLE
句で使われている必要があります。 こうしたセキュアなロールを、WITH ROLE ALL
句に追加します(WITH ROLE
を指定しない場合はデフォルト)。 WITH ROLE
にセキュアなロールを指定しない場合は、正しいパスワードを使っても有効にできません。
WITH ROLE ALL EXCEPT
WITH
ROLE
ALL
EXCEPT
role_name
を使用すると、プロキシは指定したユーザーとして接続でき、role_name
で指定されたロール以外の、このユーザーに対応付けられたすべてのロールをアクティブにできます。この句には、user
に関連付けられているロールのみを含めることができます。
WITH NO ROLES
WITH
NO
ROLES
を使用すると、プロキシは指定したユーザーとして接続できますが、パスワード保護されたロールなどのセキュア・ロールとセキュア・アプリケーション・ロールであっても、接続後にそのユーザーのロールを1つでもアクティブにすることは禁止されます。
AUTHENTICATION
REQUIRED
句を指定しない場合、Oracle Databaseは、ユーザーの認証にプロキシを想定しません。この句は、ユーザーが指定されたプロキシを介して認証される場合に、ユーザーの認証資格証明が提示される必要があることを示しています。資格証明は、パスワードです。
以前のリリースの構文に出現したAUTHENTICATED
USING
句は非推奨になり、必要でなくなりました。AUTHENTICATED
USING
PASSWORD
句を指定した場合、AUTHENTICATION
REQUIRED
句に変換されます。AUTHENTICATED
USING
CERTIFICATE
句またはAUTHENTICATED
USING
DISTINGUISHED
NAME
句を指定することは、AUTHENTICATION
REQUIRED
句を省略することと同じです。
関連項目:
-
データベース・セキュリティの概要および中間層システムおよびプロキシ認証の詳細は、『Oracleセキュリティ概要』を参照してください。
-
プロキシおよびデータベースの使用方法の詳細は、『Oracle Databaseセキュリティ・ガイド』および「プロキシ・ユーザー: 例」を参照してください。
例
ユーザー識別の変更: 例
次の文は、ユーザーsidney
(「データベース・ユーザーの作成: 例」で作成)のパスワードをsecond_2nd_pwd
に、デフォルト表領域を表領域example
に変更します。
ALTER USER sidney IDENTIFIED BY second_2nd_pwd DEFAULT TABLESPACE example;
次の文は、new_profile
プロファイル(「プロファイルの作成: 例」で作成)をサンプル・ユーザーsh
に割り当てます。
ALTER USER sh PROFILE new_profile;
後続のセッションでは、sh
はnew_profile
プロファイルの制限に従います。
次の文は、sh
に直接付与されているすべてのロール(dw_manager
ロールを除く)をデフォルト・ロールに設定します。
ALTER USER sh DEFAULT ROLE ALL EXCEPT dw_manager;
sh
の次のセッションの開始時には、dw_manager
以外でsh
に直接付与されているすべてのロールが使用可能になります。
ユーザー認証の変更: 例
次の文は、ユーザーapp_user1
(「データベース・ユーザーの作成: 例」で作成)の認証メカニズムを変更します。
ALTER USER app_user1 IDENTIFIED GLOBALLY AS 'CN=tom,O=oracle,C=US';
次の文は、ユーザーsidney
のパスワードを期限切れにします。
ALTER USER sidney PASSWORD EXPIRE;
PASSWORD
EXPIRE
を使用してデータベース・ユーザーのパスワードを期限切れにした場合、そのユーザー(またはDBA)は、期限切れの後でデータベースにログインする際、パスワードを変更する必要があります。ただし、SQL*Plusなどのツール製品を使用した場合、期限切れの後の最初のログイン時に、パスワードを変更できます。
表領域グループの割当て: 例
次の文は、tbs_grp_01
(「表領域グループへの一時表領域の追加: 例」で作成)を表領域グループとしてユーザーsh
に割り当てます。
ALTER USER sh TEMPORARY TABLESPACE tbs_grp_01;
プロキシ・ユーザー: 例
次の文は、ユーザーapp_user1
を変更します。例では、app_user1
がプロキシ・ユーザーsh
を使用して接続できます。また、プロキシsh
を使用して接続したときに、app_user1
がwarehouse_user
ロール(「ロールの作成: 例」で作成)を有効にできます。
ALTER USER app_user1 GRANT CONNECT THROUGH sh WITH ROLE warehouse_user;
基本的な構文を示すため、サンプル・データベースSales Historyのユーザー(sh
)をプロキシとして使用します。通常、プロキシ・ユーザーは、アプリケーション・サーバーまたは中間層のエンティティに存在します。アプリケーション・サーバーを経由して、アプリケーション・ユーザーとデータベースの間のインタフェースを作成する場合の詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。
関連項目:
-
app_user
ユーザーの作成方法の詳細は、「外部データベース・ユーザーの作成: 例」を参照してください。 -
dw_user
ロールの作成方法の詳細は、「ロールの作成: 例」を参照してください。
次の文は、ユーザーapp_user1
がプロキシ・ユーザーsh
を使用して接続する権限を取り消します。
ALTER USER app_user1 REVOKE CONNECT THROUGH sh;
次の仮想例は、プロキシ認証の他の方法を示します。
ALTER USER sully GRANT CONNECT THROUGH OAS1 AUTHENTICATED USING PASSWORD;
次の例では、ユーザーapp_user1
をエンタープライズ・ユーザーがプロキシ使用できるように公開します。エンタープライズ・ユーザーは、Oracle Internet Directory管理者が適切な権限を付与するまでは、app_user1
の代理として作業することができません。
ALTER USER app_user1 GRANT CONNECT THROUGH ENTERPRISE USERS;