承認のためのLDAPの使用

ファイル・ストレージでLDAPを使用して認可する方法について学習します。

Lightweight Directory Access Protocol (LDAP)をネットワーク情報サービスとして使用して、ファイル・ストレージ・サービスに認可情報を提供できます。LDAPを使用して承認情報を提供すると、次の利点があります。

UNIXユーザーおよびグループの一元管理。
最大256個のUNIXグループをサポートします。NFSリクエストのRPCヘッダー内で提供されるグループリストを使用するのではなく、セカンダリUNIXグループに対してLDAPを有効にした場合、16個のグループの AUTH_SYS制限の対象にはなりません。
LDAPインフラストラクチャーは、Kerberosを使用する際のユーザー認証ごとの要件です。すべての Kerberosシナリオ(エクスポートがすべて強制終了される場合など)には、LDAPは必要ありません。

セカンダリ・グループ参照

ファイル・ストレージ・ファイル・システムは、NFS操作のUID/GIDおよびセカンダリUNIXグループのリストを使用してアクセスを承認します。デフォルトでは、AUTH_SYSはNFSリクエストのRPCヘッダー内に指定されたグループ・リストを使用します。

LDAP認可が有効な場合、ファイル・ストレージはNFSリクエストのRPCヘッダーのUNIX UIDを使用して、AUTH_SYSアクセスのためにLDAPサーバーからセカンダリUNIXグループのリストを取得します。RPCヘッダーの既存のGIDLISTは、LDAPサーバーからのGIDLISTで上書きされます。LDAPサーバーからセカンダリUNIXグループを取得すると、承認要求で最大256グループを使用できます。

IDマッピングを使用したセカンダリ・グループ参照が有効になっているが、構成されていない、正しく構成されていない、またはLDAPサービスが使用できない場合、ファイル・ストレージはリクエストで使用されているセカンダリ・グループ・リストを更新できません。その結果、権限エラーが発生する場合があります。

AUTH_SYSのNFSリクエスト・シナリオ
グループ・リストのLDAPは使用可能ですか?	LDAPレスポンス	スカッシュのエクスポートが有効ですか?	NFSリクエスト
任意	任意	はい(すべて)	すべてをスカッシュする場合は、エクスポートのオプションに設定された「Squash UID」および「Squash GID」に進みます。セカンダリ・グループ・リストがありません。
任意	任意	はい(ルート)	ルートをスカッシュする場合は、UIDが0の場合のみ、エクスポートのオプションに設定された「Squash UID」および「Squash GID」に進みます。セカンダリ・グループ・リストがありません。
いいえ	適用なし	いいえ	RPCヘッダーのUID/GIDを続行します。
はい	UID一致	いいえ	LDAPサーバーから取得したセカンダリグループリストを使用します。
はい	UIDが一致しないか、LDAPエラー	いいえ	RPCヘッダーのUID/GIDを続行します。セカンダリ・グループ・リストがありません。

重要

LDAPを認可に使用するには、マウント・ターゲットおよびエクスポートでLDAPを有効化する必要があります。

LDAPとともに Kerberos認証を使用する場合の動作は少し異なります。詳細は、LDAP Lookups and Anonymous Accessを参照してください。

キャッシュ

ファイル・ストレージでは、インメモリーのみのオンデマンド・キャッシュ・モデルを使用して認可情報を格納し、パフォーマンスを向上させ、LDAPサーバーの負荷を軽減します。

NFSリクエストが発生すると、ファイル・ストレージはLDAPサーバーに接続して認可情報を取得します。ファイル・ストレージは、後続のNFS操作で使用するために認可情報をキャッシュします(正または負)。

次のオプションを使用して、LDAPのマウント・ターゲットを構成するときにファイル・ストレージがこの情報をキャッシュする期間を構成できます:

キャッシュ・リフレッシュ間隔(秒): エントリのリフレッシュを試行する前に、マウント・ターゲットがエントリをキャッシュに保持できるようにする時間。LDAPサーバーでのセキュリティーへの影響と許容される負荷のバランスをとる値を選択します。
キャッシュ存続期間(秒): マウント・ターゲットがキャッシュされたエントリを使用できる最大時間。顧客インフラストラクチャの負荷または障害のためにキャッシュ・エントリを適時にリフレッシュできない場合は、接続がリストアされるまで古いエントリを使用することをお薦めします。値を、なんらかの理由でLDAPサーバーを使用できないケースなど、LDAPキャッシュに失効したエントリを保持する最長期間に設定します。
マイナスのキャッシュ存続期間(秒): ユーザーがIDマッピング構成で見つからないという情報をマウント・ターゲットが保持する時間。LDAPデータベースにユーザーが見つからない場合、マウント・ターゲットは、ユーザーが存在しないことを示すエントリをキャッシュに配置します。セキュリティーへの影響とLDAPサーバーの許容可能な負荷のバランスを取る値を選択します。

前提条件

要件:

RFC2307 posixスキーマをサポートするLDAPサーバーを含む、顧客管理のLDAPインフラストラクチャ。LDAPサーバーは、OpenLDAPまたはMicrosoft Active Directoryに基づくことができます。LDAPディレクトリのファイル・ストレージ・サポートには、カスタマイズされた構成が必要な場合があります。
ファイル・ストレージ・マウント・ターゲットがRFC2307-compliantユーザーおよびグループ情報の参照に使用できるLDAPサーバーへのログイン・アカウント。
- LDAPサーバーには次のユーザー属性が必要です。
  - ObjectClass: posixAccount - このオブジェクト・クラスは、ユーザーに次の属性を提供します。
  - uidNumber - UNIXユーザーID。
  - gidNumber - ユーザーのプライマリ・グループのUNIXグループID。
  - uid - ユーザーのユーザー名
- LDAPサーバーには次のグループ属性が必要です。
  - ObjectClass: posixGroup - このオブジェクト・クラスは、グループに対して次の属性を提供します。
  - gidNumber - グループのUNIXグループID
  - memberUid - このグループのメンバーであるユーザーのuid属性。この属性を複数回追加して、グループに複数のユーザーを含めることができます。
ヒント

LDAPスキーマ・サポートをテストできます。
マウント・ターゲットがLDAPサーバーを含むホスト名を検索できるようにするDNSサーバー。

この図は、LDAP認可に必要な顧客管理インフラストラクチャおよびOCI管理インフラストラクチャを示しています。

TCP/UDPポート53を介したDNSサービスとの通信。
アウトバウンド・コネクタで構成されたTCPポートを介した顧客管理LDAPサービスとの通信。デフォルト値は、TCPポート636です。
ファイル・ストレージでの保存データの暗号化。

LDAPインフラストラクチャ

ファイル・ストレージには、マウント・ターゲットがLDAPSポート上のLDAPサーバーと通信できるように、アウトバウンド・コネクタが必要です。アウトバウンド・コネクタでは、LDAPサーバーの完全修飾ドメイン名(FQDN)、LDAPサーバーへのバインド・ユーザー名とパスワード、およびユーザーおよびグループの検索ベースを指定する必要があります。

ファイル・ストレージがLDAPサーバーにアクセスできるようにするには、次のことを確認します:

LDAPサーバーのファイアウォールでは、TCP 636を使用したファイル・ストレージ・マウント・ターゲットからのインバウンド・トラフィックを許可する必要があります(デフォルト)。
使用中のセキュリティ・リストおよびNSGでは、マウント・ターゲットおよびLDAPサーバー・トラフィックを許可する必要があります。
DNSは、マウント・ターゲットおよびクライアントがホスト名を解決するために構成されます。DNS構成オプションは次のとおりです:
- VCNでのデフォルトの解決およびホスト名でのOCI DNSの使用 - このオプションは、カスタムDNS名の柔軟性を提供しません。ホスト名はoraclevcn.comで終わり、VCNおよびサブネットのサブドメインがあります。詳細は、仮想クラウド・ネットワークのDNSを参照してください。
- プライベート・ゾーンでのOCIプライベートDNSの使用 - カスタム・ドメインのDNSゾーンは、OCIDNSでホストされます。このオプションを使用すると、OCIはDNSを完全に管理するため、独自のDNSサーバーを管理する必要はありません。ゾーンおよびレコードを管理する必要があります。詳細は、プライベートDNSを参照してください。
- 顧客管理DNSサーバーの使用 - VCNを作成するときは、「このVCNでDNSホスト名を使用」を選択しないでください。かわりに、次のいずれかの方法を使用して、独自のDNSサーバーを使用するようにVCNを構成します:
  1. 顧客管理DNSサーバーを使用するようにサブネットのDHCPオプションを構成します。
  2. VCN内のDNS問合せが顧客管理DNSサーバーに転送されるように、転送エンドポイントおよび転送ルールとともにVCNリゾルバを使用します。

ファイル・ストレージでは、LDAPS認可のSSLv2、SSLv3、TLSv1またはTLSv1.1はサポートされていません。ファイル・ストレージでは、LDAPS認可用の次のOpenSSL暗号スイートがサポートされています:

DHE-DSS-AES128-GCM-SHA256
DHE-DSS-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
TLS_AES_128_CCM_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384

LDAPスキーマ・サポートのテスト

次の問合せ例を使用すると、ファイル・ストレージが、サポートされている構成を持つLDAPサーバーからRFC2307-compliantユーザーおよびグループ情報を検索できます。

ldapsearch -b <user_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixAccount)(uid=<username>))' uidNumber gidNumber

$ ldapsearch -b 'ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixAccount)(uid=root))' uidNumber gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uid=root))
# requesting: uidNumber gidNumber
#

# root, Users, nfs_kerberos.fss_test.com
dn: uid=root,ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
uidNumber: 0

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

ldapsearch -b <user_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixAccount)(uidNumber=<user_uid>))' uid gidNumber

$ ldapsearch -b 'ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixAccount)(uidNumber=0))' uid gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uidNumber=0))
# requesting: uid gidNumber
#
# root, Users, nfs_kerberos.fss_test.com
dn: uid=root,ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
uid: root
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1

ldapsearch -b <group_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixGroup)(memberuid=<username>))' gidNumber

$ ldapsearch -b 'ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixGroup)(memberuid=root))' gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixGroup)(memberuid=root))
# requesting: gidNumber
#
# root, Groups, nfs_kerberos.fss_test.com
dn: cn=root,ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1

ヒント

ファイル・システム・メトリックに基づいてアラームを作成できます。これは、LDAP接続の問題を迅速に検出および診断するのに役立ちます。

モニタリングとアラーム

LDAPを使用する際には、問題を迅速に認識することが重要です。LDAPインフラストラクチャが正しく機能していない場合、NFSクライアントは、エクスポートを介して使用可能なファイル・ストレージ・ファイル・システムへのアクセスを失う可能性があります。このような問題を検出するには、マウント・ターゲットのメトリックにアラームを設定することをお薦めします。アラームは、数分以内にインフラストラクチャの問題を警告できます。

LDAP接続エラーおよびLDAPリクエスト・エラーから構築されたアラームは、マウント・ターゲット、アウトバウンド・コネクタおよび顧客管理LDAPインフラストラクチャ間の接続の問題を検出します。

次のクエリー例を使用すると、LDAP接続用のアラームを作成できます。

LdapConnectionErrors[1m]{resourceType = "outboundconnector", mtResourceName = "<mount_target_name>", errorType != "success"}.max() >= 1

メトリックのモニタリングおよびアラームの使用の詳細は、モニタリングの概要を参照してください。アラームの通知の詳細は、通知の概要を参照してください。

必須IAMポリシー

ファイル・ストレージは、LDAPサーバー・パスワードのVaultシークレットにアクセスする必要があります。マウント・ターゲットを構成するユーザーとマウント・ターゲット自体の両方に読取りアクセスが必要です。

重要

認可にLDAPを使用するようにマウント・ターゲットを構成する前に、これらのポリシーを作成する必要があります。

Vaultシークレットを管理するためのポリシー

Vaultシークレット権限を作成するユーザーまたはグループに付与します。詳細は、Vaultシークレットの管理を参照してください。

マウント・ターゲット構成を有効にするポリシー

次のようなポリシーを使用して、マウント・ターゲットに対するLDAPを構成するユーザーまたはグループに権限を付与します:

allow <user|group> to read secret-family in compartment <Compartment_ID> where any { target.secret.id = <LDAP_Password_Secret_ID> }

これにより、ユーザーはVaultシークレットを読み取り、構成中に検証するためにシークレットの一部を表示するファイル・ストレージ・コマンドを発行できます。

マウント・ターゲットにシークレットの取得を許可するポリシー

ファイル・ストレージ・サービスには、シークレットを読み取る機能が必要です。ファイル・ストレージでは、リソース・プリンシパルを使用して、特定のマウント・ターゲットのセットにVaultシークレットへのアクセス権を付与します。これは2ステップのプロセスです。まずアクセスが必要なマウント・ターゲットを動的グループに配置し、次に動的グループにシークレットを読み取るためのアクセス権が付与されます。

次のようなポリシーを使用して、マウント・ターゲットの動的グループを作成します:
```
ALL { resource.type='mounttarget', resource.compartment.id = '<mount_target_compartment_id>' }
```
ノート

動的グループに複数のルールがある場合、必ずMatch any rules defined belowオプションを使用してください。
マウント・ターゲットの動的グループにVaultシークレットへの読取りアクセス権を付与するIAMポリシーを作成します:
```
 allow dynamic-group <dynamic_group_name> to read secret-family in compartment <secret_compartment_name>
```

次のステップ

次の手順については、Setting Up LDAP for Authorizationを参照してください。

Oracle Cloud Infrastructureドキュメント