33 認証の管理
33.1 認証の概要
認証は、ディレクトリ・サーバーが、そのディレクトリに接続しているユーザーの本当のアイデンティティを確定するプロセスです。
LDAPセッションがバインド操作によって確立されたときに行われます。このようにして、すべてのセッションにユーザー・アイデンティティが関連付けられます。
ユーザー、ホストおよびクライアントのアイデンティティを検証するために、Oracle Internet Directoryでは、3種類の一般的な認証を使用できます。それらについて、次の項目で説明します。
33.1.1 直接認証
この項では、Oracle Internet Directory内で使用可能な3種類の直接認証と、SASL対応クライアントがディレクトリ・サーバーに対して認証を行う方法について説明します。
直接認証オプションには、次の3種類があります。
表33-1 直接認証オプション
認証オプション | 説明 |
---|---|
匿名認証 |
匿名で認証する場合、ユーザーは、ユーザー名とパスワードのフィールドを空白のままにしてログインします。各匿名ユーザーは、匿名ユーザーに付与されている権限すべてを使用できます。 |
簡易認証 |
簡易認証を使用する場合、クライアントは、ネットワーク上を暗号化されずに送信される識別名とパスワードによって、サーバーに対して自己認証を行います。 |
Simple Authentication and Security Layer (SASL)を使用した認証 |
これは接続ベースのプロトコルに認証サポートを追加する方法です。SASLを使用するために、プロトコルには、ユーザーを識別してサーバーに対して認証を行い、オプションで、以降のプロトコル対話の保護を規定するコマンドが含まれます。SASLを使用して、ネゴシエーションに成功すると、セキュリティ・レイヤーがプロトコルおよび接続の間に挿入されます。 |
-
Oracle Internet Directoryは、SASLを使用する2種類の認証メカニズムをサポートします。
-
ダイジェストMD5: LDAPバージョン3内では必須の認証メカニズムです(RFC 2829)。MD5ハッシュ関数を使用して、任意の長さのメッセージを、クライアント/サーバー認証のベリファイアとして使用できる128ビットのメッセージ・ダイジェストに変換します。
-
外部認証: SSL相互認証を使用するメカニズム。この場合、クライアントは、ユーザー名とパスワードを使用するかわりに、証明書、トークンまたは他のデバイスによって、サーバーに対して認証します。証明書による認証には、次の形式があります。
-
完全一致: クライアント証明書内のサブジェクトDNが、ディレクトリ内のユーザーDNと比較されます。この2つの値が一致すると、バインドが行われます。
-
証明書ハッシュ: クライアント証明書がハッシュ処理され、ディレクトリ内に保管されている証明書のハッシュ値と比較されます。この2つの値が一致し、かつこのペアに関連付けられているDNが1つのみの場合は、バインドが行われます。複数のDNが関連付けられている場合は、証明書ハッシュとユーザーDNの関係はn対1の対応であり1対nの対応ではないので、エラーが返されます。つまり、1つのDNには複数の証明書を関連付けることができますが、1つの証明書には1つのDNしか関連付けられません。
-
完全一致/証明書ハッシュ: まず、完全一致検索が行われます。一致するものがない場合は、証明書ハッシュが実行されます。
これらの方法のいずれかを選択するには、『Oracle Identity Managementリファレンス』のOracle Identity ManagementのLDAP属性リファレンスに関する項で指示されているDSA構成属性
orclpkimatchingrule
を編集します。(認証の場合、orclpkimatchingrule
の値3または4が値2に等しくなります)。 -
-
ノート:
-
10g(10.1.4.0.1)に証明書のハッシュ値を導入する場合は、ユーザー証明書を旧リリースからアップグレードする必要があります。証明書をアップグレードする方法を学習するには、『Oracle Identity Managementリファレンス』の
upgradecert.pl
コマンド行ツールのリファレンスを参照してください。 -
バイナリ属性
usercertificate
を検索できます。検索方法を学習するには、「ディレクトリでのユーザー証明書の検索」を参照してください。 -
usercertificate
属性は、DER書式の証明書の格納のみを目的としています。
関連項目:
-
http://www.ietf.org
にあるInternet Engineering Task Force (IETF)のWebサイトで、RFC 2829 (LDAPバージョン3サーバーで必要な認証メカニズムとしてのSASL MD5ダイジェストを指定)、RFC 2831 (MD5ダイジェストメカニズムの説明)、RFC 2617 (SASL MD5ダイジェストがベースとしているHTTP Digest認証メカニズムの説明)の各RFCを参照してください
33.1.2 間接認証について
間接認証は、ディレクトリに資格証明を保持するエンティティ(Oracle Internet Directoryセルフサービス・コンソールのようなアプリケーション、ファイアウォールやRADIUSサーバーのような中間層など)を介して行われます。アプリケーションや中間層は、プロキシ・ユーザーとなります。プロキシ・ユーザーは、エンド・ユーザーの代理となる権限を持ち、そのユーザーが権限を持つ操作をユーザーにかわって実行します。
図33-1および図に続く説明は、間接認証がどのように実行されるかを示しています。
図33-1 間接認証
![この図については本文で説明しています。 この図については本文で説明しています。](img/oidag048.gif)
間接認証は、次の手順で行われます。
-
エンド・ユーザーが、Oracle Internet Directoryへの問合せを含むリクエストをアプリケーションまたは中間層に送信します。アプリケーションまたは中間層がエンド・ユーザーを認証します。
-
アプリケーションまたは中間層がディレクトリにバインドします。
-
アプリケーションまたは中間層は、エンド・ユーザーの識別名を使用して、2回目のバインドを実行します。この場合、エンド・ユーザーのパスワードは入力しません。
-
ディレクトリ・サーバーは、アプリケーションまたは中間層がエンド・ユーザーのアイデンティティに切り替えようとしているものとして、この2回目のバインドを認識します。アプリケーションまたは中間層によってエンド・ユーザーに付与された認証を受け入れます。ただし、アプリケーションまたは中間層に、このユーザーのプロキシとなる権限があるかどうかを検証する必要があります。エンド・ユーザーのエントリを管理するACPによって、このエンド・ユーザーに対するプロキシ権限がこのアプリケーションまたは中間層に付与されているかどうかをチェックします。
-
エンド・ユーザーのエントリにより、アプリケーションまたは中間層に必要なプロキシ権限が提供された場合、ディレクトリ・サーバーは、認可アイデンティティをエンド・ユーザーのものに変更します。後続するすべての操作は、そのエンド・ユーザーがサーバーに直接接続して直接認証された場合と同様に行われます。
-
エンド・ユーザーのエントリが、アプリケーションまたは中間層に必要なプロキシ権限を提供しない場合、ディレクトリ・サーバーは、「アクセス権限が不十分です。」というエラー・メッセージを返します。
関連項目:
-
ディレクトリ・サーバーは同一セッションで、その他のエンド・ユーザーを認証および許可できます。また、セッションをエンド・ユーザーから、そのセッションをオープンしたアプリケーションまたは中間層に切り替えることもできます。
セッションをクローズするには、アプリケーションまたは中間層がバインド解除リクエストをディレクトリ・サーバーに送信します。
たとえば、次の場所に次のパートナがあるものとします。
-
cn=User1
でディレクトリにバインドする中間層には、ディレクトリ全体に対するプロキシ・アクセス権限があります。 -
cn=User2
でディレクトリにバインドできるエンド・ユーザーがいます。
このエンド・ユーザーが、ディレクトリに対する問合せが含まれているリクエストをアプリケーションまたは中間層に送信すると、アプリケーションまたは中間層がエンド・ユーザーを認証します。その後、中間層サービスは、そのサービスのアイデンティティであるcn=User1
を使用してディレクトリにバインドし、次に、エンド・ユーザーの識別名cn=User2
のみを使用して2回目のバインドを実行します。この2回目のバインドは、Oracleディレクトリ・サーバーでは、プロキシ・ユーザーがエンド・ユーザーの代理になろうとしているものと認識されます。ディレクトリ・サーバーは、cn=user1
にプロキシ・アクセス権限があることを確認した後、この2回目のバインドの実行を許可します。パスワードなど、エンド・ユーザー識別名の妥当性をさらに要求することはありません。このセッションでは、これ以降すべてのLDAP操作は、cn=User2
が実行しているかのようにアクセス制御されます。
あるユーザーがアプリケーションからサービスを受け、続いて別のユーザーが同じアプリケーションのサービスをリクエストした場合、アプリケーションは、先行ユーザーのセッションを中断せずに、新規接続を確立して前述のとおりに処理を進めることができます。ただし、まだサービスを受けている先行ユーザーがいない場合は、新しい接続を確立することなく、既存の確立済接続を何度も使用できます。
33.1.3 外部認証について
多くの企業では、ユーザー・セキュリティ資格証明をOracle Internet Directory以外のリポジトリ(データベースや他のLDAPディレクトリなど)に格納しています。
Oracle Internet Directoryの外部認証プラグインとパスワード変更プラグインにより、ユーザー認証用のこれらの資格証明をOracleコンポーネントに対して使用できます。資格証明をOracle Internet Directoryに格納する必要はなく、常に同期化させる必要はありません。
関連項目:
33.1.4 Simple Authentication and Security Layer(SASL)
この項では、SASLの動作について詳細に説明します。
「直接認証」の項では、Oracle Internet Directory環境でのSASLの使用について説明しました。この項では、SASLの動作について詳細に説明します。この項の内容は、次のとおりです。
33.1.4.1 MD5ダイジェストを使用した、ディレクトリ・サーバーに対するSASL対応クライアントの認証
ノート:
SASL MD5ダイジェストをレルムとともに使用するには、SASLで動的ユーザー検証機能を作成する必要があります。可逆的なパスワード生成を有効にする必要があります。詳細は、『Oracle Identity Managementアプリケーション開発者ガイド』のMD5ダイジェストを使用したSASL認証の使用に関する項を参照してください。
SASL対応クライアントがサーバーに対してMD5ダイジェスト認証を求める場合、その認証プロセスは次のとおりです。
- ディレクトリ・サーバーは、サポートする各種MD5ダイジェスト認証オプションと特別なトークンを含むダイジェスト・チャレンジをLDAPクライアントに送信します。
- クライアントは、認証オプションを選択し、選択したオプションを示すダイジェスト・レスポンスをサーバーに送信します。このレスポンスには、セキュアなトークンとクライアント資格証明が暗号化されて含まれます。このようして、サーバーに対するクライアントの認証を実行できます。
- ディレクトリ・サーバーは、レスポンスのクライアント資格証明を復号化し、検証します。
33.1.4.2 外部認証を使用した、ディレクトリ・サーバーに対するSASL対応クライアントの認証
Oracle Internet Directoryでは、クライアントおよびサーバーの両方が相互に証明書を提供して認証するSSL接続を介してSASL外部認証を提供します。識別名は、SSLネットワーク・ネゴシエーションで使用されたクライアント証明書から作成されます。
クライアントが、SSLのような外部認証メカニズムを使用してディレクトリ・サーバーに認証を求める場合、その認証プロセスは次のとおりです。
- クライアントは、認可アイデンティティの入った初期メッセージを送信します。
- ディレクトリ・サーバーは、SASLの外部にある情報を使用して、クライアントが認可アイデンティティとして正当に認証できるかどうかを判断します。クライアントを確実に認証できた場合、ディレクトリ・サーバーは認証情報の交換が無事完了したことを示します。そうでない場合、ディレクトリ・サーバーは失敗を示します。
外部情報は、IPsecやSSL/TLSなどのシステムにより提供されます。認可アイデンティティは、次のようにして得られます。
-
完全一致の場合は、外部認証を提供するシステムのクライアント認証資格証明(クライアントSSL証明書など)から認可アイデンティティが作成されます。
-
クライアントが認可アイデンティティとして空の文字列を送信した場合、認可アイデンティティは外部認証を提供するシステムのクライアント認証資格証明(SSL証明書など)から作成されます。
33.2 Fusion Middleware Controlを使用した証明書認証方式について
この項では、Oracle Fusion Middleware Controlを使用した証明書認証方式について説明します。
証明書認証に使用される方式を決定するDSA構成属性orclPKIMatchingRule
の値を構成するには、Oracle Enterprise Manager Fusion Middleware ControlのOracle Internet Directoryの「共有プロパティ」ページを使用します。「Oracle Internet Directory」メニューから「管理」を選択し、「共有プロパティ」を選択します。「PKI一致ルール」のリストから目的の一致方式を選択します。
33.3 Oracle Enterprise Manager Fusion Middleware Controlを使用したSASL認証の構成
この項では、Oracle Enterprise Manager Fusion Middleware Controlを使用してSASL認証を構成する手順について説明します。
Oracle Enterprise Manager Fusion Middleware Controlを使用してSASL認証を構成するには:
33.4 コマンド行ツールを使用した証明書認証方式の構成
証明書認証に使用される方式を決定するDSA構成属性orclPKIMatchingRule
の値を構成するには、ldapmodify
を使用します。
コマンドラインで、次のコマンドを入力します。
ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile
これとあわせて、次のようなLDIFファイルを使用します。
dn: cn=dsaconfig, cn=configsets, cn=oracle internet directory changetype: modify replace: orclPKIMatchingRule orclPKIMatchingRule: 1
値は次のとおりです。
-
0 - 完全一致。PKI証明書の識別名が、ユーザーが入力した識別名と一致する必要があります。
-
1 - 証明書検索。ユーザーがOracle Internet DirectoryにプロビジョニングされているPKI証明書を持っているかどうかをチェックします。
-
2 - 完全一致と証明書検索の組合せ。完全一致しなかった場合、証明書検索が実行されます。
-
3 - マッピング・ルールのみ。マッピング・ルールを使用して、ユーザーのPKI証明書識別名をOracle Internet Directoryの証明書識別名にマップします。
-
4: 1(マッピング・ルール)、2(証明書検索)、3(完全一致)の順に試行します。
33.5 コマンド行を使用したSASL認証
この項では、SASL認証属性とその説明を示します。
表33-3に、SASL認証属性を示します。これらは、インスタンス固有の構成エントリにあります。
表33-3 SASL認証属性
属性 | 説明 | デフォルト | 使用可能な値 |
---|---|---|---|
|
SASL認証モード |
1 |
auth、auth-int、auth-conf。 |
|
SASL暗号選択 |
Rc4-56、rc4-40、rc4、des、3des |
Rc4-56、des、3des、rc4、rc4-40の任意の組合せ |
|
SASLメカニズム |
DIGEST-MD5、EXTERNAL |
DIGEST-MD5、EXTERNAL |
「MD5 SASL認証モード」は、orclsaslauthenticationmode
属性によって制御されます。表33-4に、使用可能なモードを示します。3つの値すべて、あるいは値のサブセットをカンマ区切りの文字列で指定します。
表33-4 SASL認証モード
orclsaslauthenticationmodeの値 | モード | 説明 |
---|---|---|
|
auth |
認証のみ。 |
|
auth-int |
完全性保護での認証。チャネルでチェックサムが実行されます。 |
|
auth-conf |
完全性保護での認証と暗号化。チャネルは暗号化されます。 |
orclsaslauthenticationmode
を3
(auth-conf
)に設定した場合は、orclsaslcipherchoice
の値も選択する必要があります。選択肢は、rc4-56
、des
、3des
、rc4
およびrc4-40
です。デフォルトでは、5つがすべて有効になっています。少なくともdes
および3des
を構成する必要があります。これを行わないと、SASL認証が失敗します。
変数orclsaslmechanism
は、SASLでサポートされる認証メカニズムを制御します。値DIGEST-MD5
およびEXTERNAL
は、デフォルトで設定されています。MD5ダイジェスト認証は、無効にしないでください。これは、LDAPバージョン3サーバーで必須の認証メカニズムです。外部認証は、ldapmodify
を使用して無効にできます。SSLクライアントおよびサーバー認証を実行するようにOracle Internet Directoryを構成しない場合は、外部認証を無効にしてください。
SASL属性を変更した後、サーバーを再起動します。
33.6 匿名ユーザーによるバインド
匿名ユーザーによるバインドは、パスワードを使用せずに簡易認証を使用する方法です。デフォルトでは、ディレクトリ・サーバーは匿名バインドを許可しますが、匿名ユーザーのルートDSEエントリでの検索操作のみ許可します。
すべての匿名バインドを許可するよう、あるいは匿名バインドを許可しないようサーバーを構成できます。この動作は、サーバー・インスタンス固有の構成エントリのorclanonymousbindsflag
属性で制御します。表33-5に、orclanonymousbindsflag
に指定可能な値と、ディレクトリ・サーバーの動作を示します。
表33-5 orclanonymousbindsflagの値とディレクトリ・サーバーの動作
orclAnonymousBindsFlagの値 | ディレクトリ・サーバーの動作 |
---|---|
0 |
匿名ユーザーによるバインドを禁止 |
1 |
匿名ユーザーによるバインドを許可 |
2 |
匿名ユーザーによるバインドを許可。ただし、許可されるのは、匿名ユーザーのルートDSEエントリでの検索操作のみ(デフォルト) |
33.7 匿名ユーザーによるバインドの管理
Oracle Internet Directory 11gリリース1 (11.1.1.0.0)以降では匿名バインドがデフォルトで許可されますが、匿名ユーザーはルートDSEエントリでの検索操作のみ実行できます。
Fusion Middleware Controlまたはコマンド行を使用して、匿名バインドに関するサーバーの動作を変更できます。この項では、次の項目について説明します。
33.7.1 Fusion Middleware Controlを使用した匿名ユーザーによるバインドの管理
この項では、Oracle Enterprise Manager Fusion Middleware Controlを使用して匿名ユーザーによるバインドを管理する手順について説明します。
次のステップを実行します。
-
「Oracle Internet Directory」メニューから、「管理」→「サーバー・プロパティ」→「一般」タブを選択します。
-
「匿名バインド」リストから「許可」を選択して、匿名ユーザーによるバインドを有効にします。ルートDSEエントリに対する匿名ユーザーの検索操作のみを許可するには、「ルートDSEでの読取りアクセスを除いて使用できません」を選択します。
匿名ユーザーによるバインドを無効にするには:
- 「Oracle Internet Directory」メニューから、「管理」→「サーバー・プロパティ」→「一般」タブを選択します。
- 「匿名バインド」リストから「拒否」を選択します。
33.7.2 コマンド行を使用した匿名ユーザーによるバインドの管理
ldapmodify
を使用して、コンポーネント名がoid1
のOracle Internet Directoryインスタンスですべての匿名バインドを有効にできます。
コマンドラインで、次のコマンドを入力します。
ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile
この場合、次のようなLDIFファイルを使用します。
dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry changetype: modify replace: orclAnonymousBindsFlag orclAnonymousBindsFlag: 1
すべての匿名バインドを無効にするには同様のLDIFファイルを使用しますが、最後の行を次のように変更します。
orclAnonymousBindsFlag: 0
関連項目:
33.8 Oracle Internet Directoryサーバーに対するユーザーのバインドの制限
Oracle Internet Directory 11gリリース1 (11.1.1.9.0)以降では、bindAuthPriv
属性によって、Oracle Internet Directoryサーバーにバインド可能なユーザーを指定できます。
サーバーにバインド可能なユーザーを指定するには:
- サーバーに対するバインドを許可するユーザーのみを含むディレクトリ・グループを作成します。
- ステップ1で作成したグループを指し示すように
bindAuthPriv
属性を設定します。 - サーバーに対するバインドを許可する各ユーザー(ステップ1のグループのメンバーであるユーザー)のユーザー・エントリに
bindAuthPriv
属性を追加します。
ユーザーがこのグループのメンバーではない場合、サーバーは、そのユーザーからの後続のバインド・リクエストを拒否します。
その他の考慮事項は、次のとおりです。
-
bindAuthPriv
属性には、特定のユーザーが属性を継承できる集合属性を指定できます。 -
ディレクトリ・グループには、ネストされたグループを指定できます。
-
唯一の管理者のみが
bindAuthPriv
属性をユーザー・エントリに追加できるように、その適切なアクセス制御(ACL)を設定する必要があります。
関連項目:
Oracle Directory Services Manager (ODSM)またはLDAPコマンド行ツールを使用してユーザーとグループを作成および管理する方法の詳細は、次の項目を参照してください。
33.9 未認証バインドの管理
Oracle Internet Directoryでは、識別名の値(ユーザー識別名)を含み、パスワードを含まないバインド・リクエストを送信する未認証の認証メカニズムがサポートされます。
未認証バインドが許可される場合、バインド試行は、匿名バインドとして処理されます。この項では、次の項目について説明します。
33.9.1 未認証バインドの構成
orclunauthenticatedbindsflag
属性によって、未認証バインドが成功するように設定できます。
orclunauthenticatedbindsflag
属性によって、未認証バインドが成功するように設定できます。この属性を1
に設定すると、未認証バインドが成功します。デフォルトでは、このパラメータは0
に設定されています。
未認証バインドを構成するには、「コマンド行を使用した未認証バインドの管理」を参照してください。
33.9.2 コマンド行を使用した未認証バインドの管理
ldapmodify
を使用して、コンポーネント名がoid1
のOracle Internet Directoryインスタンスで未認証バインドを有効にできます。
コマンドラインで、次のコマンドを入力します。
ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile
この場合、次のようなLDIFファイルを使用します。
dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry changetype: modify replace: orclunauthenticatedbindsflag orclunauthenticatedbindsflag: 1
未認証バインドを無効にするには同様のLDIFファイルを使用しますが、最後の行を次のように変更します。
orclunauthenticatedbindsflag: 0