Red Hat Training

A Red Hat training course is available for Red Hat Directory Server

9.9. SASL Identity マッピングの設定

Red Hat Directory Server は、一部のアプリケーションが情報を安全に共有できるように、TLS の代替手段である Simple Authentication and Security Layer(SASL)による LDAP クライアント認証をサポートします。
Simple Authentication and Security Layer (SASL) は、LDAP などのプロトコルと GSS-API などの認証方法との間の抽象化レイヤーであり、SASL と対話できるプロトコルが SASL と連携できる認証メカニズムを利用できるようにします。簡単に言えば、SASL は、異なるメカニズムを使用して、アプリケーションに対して認証できるようにする仲介者です。SASL は、クライアントとサーバーとの間で暗号化されたセッションを確立するためにも使用できます。
SASL フレームワークでは、クライアントアプリケーションとサーバーアプリケーションの両方で有効になっているメカニズムに応じて、サーバーに対してユーザーを認証するためにさまざまなメカニズムを使用できます。SASL は、暗号化された (セキュアな) セッションのレイヤーも作成します。GSS-API を使用すると、Directory Server は Kerberos チケットを使用してセッションを認証し、データを暗号化します。

9.9.1. SASL Identity マッピングの概要

SASL バインド要求の処理時に、サーバーは、サーバー内に格納されている LDAP エントリーで Directory Server に対して認証するために使用される SASL 認証 ID を照合またはマップします。Kerberos を使用する場合、通常 SASL ユーザー ID の形式は userid@REALM になります (例: scarter@EXAMPLE.COM)。この ID は、uid=scarter,ou=people,dc=example,dc=com など、ユーザーの Directory Server エントリーの DN に変換する必要があります。
認証 ID が個人の LDAP エントリーに明確に対応する場合は、Directory Server が認証 ID を自動的にエントリー DN にマッピングするように設定できます。Directory Server には、最も一般的な構成を処理する事前構成済みのデフォルトマッピングがいくつかあり、カスタマイズされたマップを作成できます。デフォルトでは、バインド試行時に SASL マッピングフォールバックが有効ではない場合は、最初に一致するマッピングルールのみが適用されます。SASL マッピングフォールバックの詳細は、「SASL マッピングフォールバックの有効化」を参照してください。
1 つのマッピングルールのみが認証文字列と一致するように、SASL マップを設定するようにしてください。
SASL マッピングは、コンテナーエントリー下のエントリーによって設定されます。
dn: cn=sasl,cn=config
objectClass: top
objectClass: nsContainer
cn: sasl
SASL アイデンティティーマッピングエントリーは、以下のエントリーの子です。
dn: cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsContainer
cn: mapping
マッピングエントリーは以下の属性で定義されます。
  • nsSaslMapRegexString: 指定した authid の要素をマップするために使用される正規表現。
  • nsSaslMapFilterTemplate: DN を作成する nsSaslMapRegexString の要素を適用するテンプレート。
  • nsSaslMapBaseDNTemplate: 構築した DN と照合する検索ベースまたは特定のエントリー DN を指定します。
  • オプション: nsSaslMapPriority: この SASL マッピングの優先度を設定します。nsslapd-sasl-mapping-fallbackcn=config で有効になっている場合は、優先度値が使用されます。詳細は「SASL マッピングの優先度の設定」を参照してください。
以下に例を示します。
dn: cn=mymap,cn=mapping,cn=sasl,cn=config
objectclass:top
objectclass:nsSaslMapping
cn: mymap
nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
nsSaslMapFilterTemplate: (objectclass=inetOrgPerson)
nsSaslMapBaseDNTemplate: uid=\1,ou=people,dc=\2,dc=\3
nsSaslMapRegexString 属性は、検索中にテンプレート属性に埋め込まれたバインド ID に対し、\1\2\3 形式の変数を設定します。この例では、inetOrgPerson オブジェクトクラスに属する ou=People,dc=example,dc=com サブツリーに含まれるユーザーに対して SASL アイデンティティーマッピングを設定します。
Directory Server が、mconnors@EXAMPLE.COM をユーザー ID (authid) として使用する SASL バインド要求を受け取ると、正規表現は uid=mconnors,ou=people,dc=EXAMPLE,dc=COM をユーザー ID として使用するベース DN テンプレートに入力し、認証がそこから続行します。
注記
dc の値は大文字と小文字を区別しないため、dc=EXAMPLEdc=example は同じです。
Directory Server では、以下のようなより包含されたマッピングスキームも使用できます。
dn: cn=example map,cn=mapping,cn=sasl,cn=config
objectclass: top
objectclass: nsSaslMapping
cn: example map
nsSaslMapRegexString: \(.*\)
nsSaslMapBaseDNTemplate: ou=People,dc=example,dc=com
nsSaslMapFilterTemplate: (cn=\1)
これは任意のユーザー ID に一致し、フィルター cn=userId を満たす ou=People,dc=example,dc=com サブツリー下でエントリーをマップします。
nsSaslMapRegexString 属性にレルムを指定すると、マッピングを 1 つのレルムに制限することができます。以下に例を示します。
dn: cn=example map,cn=mapping,cn=sasl,cn=config
objectclass: top
objectclass: nsSaslMapping
cn: example map
nsSaslMapRegexString: \(.*\)@US.EXAMPLE.COM   
nsSaslMapBaseDNTemplate: ou=People,dc=example,dc=com
nsSaslMapFilterTemplate: (cn=\1)
このマッピングは以前のマッピングと同じですが、US.EXAMPLE.COM レルムから認証されるユーザーにのみ適用されます。(レルムは「プリンシパルおよびレルムについて」で説明されています。)
レプリケーション時やチェーンでなど、別のサーバーに接続する場合、デフォルトのマッピングはアイデンティティーを適切にマッピングしません。これは、あるサーバーのプリンシパル (SASL ID) が、認証が実行するサーバー上のプリンシパルと一致しないため、マッピングエントリーに一致しないためです。
サーバーが SASL を使用したサーバー認証を使用できるようにするには、特定のサーバープリンシパルの特定ユーザーエントリーへのマッピングを作成します。たとえば、このマッピングは ldap1.example.com サーバーを cn=replication manager,cn=config エントリーに一致します。マッピングエントリー自体は 2 番目のサーバーに作成されます (例: ldap2.example.com)。
dn: cn=z,cn=mapping,cn=sasl,cn=config
objectclass: top
objectclass: nsSaslMapping
cn: z
nsSaslMapRegexString: ldap/ldap1.example.com@EXAMPLE.COM
nsSaslMapBaseDNTemplate: cn=replication manager,cn=config
nsSaslMapFilterTemplate: (objectclass=*)
レルム名は、SASL GSS-API 設定のプリンシパル名に含まれていないことがあります。2 つ目のマッピングは、プリンシパル名にレルムを指定せずに、最初のマッピングと同じ 2 番目のマッピングを作成できます。以下に例を示します。
dn: cn=y,cn=mapping,cn=sasl,cn=config
objectclass: top
objectclass: nsSaslMapping
cn: y
nsSaslMapRegexString: ldap/ldap1.example.com
nsSaslMapBaseDNTemplate: cn=replication manager,cn=config
nsSaslMapFilterTemplate: (objectclass=*)
レルムが指定されていないため、2 番目のマッピングはより一般的です (つまり、最初のマッピングよりも多くのエントリーと一致する可能性があります)。ベストプラクティスは、より具体的なマッピングを最初に処理し、より一般的なマッピングに徐々に進めていく方法です。
nsSaslMapPriority パラメーターを使用して SASL マッピングに優先度が設定されていない場合は、マッピングが処理される順序を指定する方法はありません。ただし、SASL マッピングの処理方法 (名前) を制御する方法もあります。Directory Server は、ASCII の逆順で SASL マッピングを処理します。過去 2 つの例では、cn=z マッピング (最初の例) が最初に処理されます。一致する場合、サーバーは cn=y マッピングを処理します (2 番目の例)。
注記
LDIF ファイルでマッピングを指定し、ConfigFile ディレクティブで LDIF ファイルを追加すると、サイレントインストール中にインスタンスが作成される時に SASL マッピングを追加できます。サイレントインストールの使用方法は、『インストールガイド』 で説明しています。