13.3.7. LDAP 認証
単純なバインド認証を使用してユーザー名とパスワードを LDAPv3 サーバーに対して検証するには、identityProviders
スタンザに LDAPPasswordIdentityProvider
を設定します。
これらの手順に従うのではなく、LDAP サーバーのフェイルオーバーを要求する場合には、SSSD で LDAP フェイルオーバーを設定 して Basic 認証の方法を拡張します。
認証時に、指定されたユーザー名に一致するエントリーが LDAP ディレクトリーで検索されます。単一の一意の一致が見つかった場合、エントリーの識別名 (DN) と指定されたパスワードを使用した単純なバインドが試みられます。
以下の手順が実行されます。
-
設定された
url
の属性およびフィルターとユーザーが指定したユーザー名を組み合わせて検索フィルターを生成します。 - 生成されたフィルターを使用してディレクトリーを検索します。検索によって 1 つもエントリーが返されない場合は、アクセスを拒否します。
- 検索で取得したエントリーの DN とユーザー指定のパスワードを使用して LDAP サーバーへのバインドを試みます。
- バインドが失敗した場合は、アクセスを拒否します。
- バインドが成功した場合は、アイデンティティー、電子メールアドレス、表示名、および推奨ユーザー名として設定された属性を使用してアイデンティティーを作成します。
設定される url
は、LDAP ホストと使用する検索パラメーターを指定する RFC 2255 URL です。URL の構文は以下のようになります。
ldap://host:port/basedn?attribute?scope?filter
上記の例は、以下のコンポーネントで設定されています。
URL コンポーネント | 説明 |
---|---|
|
通常の LDAP の場合は、文字列 |
|
LDAP サーバーの名前とポートです。デフォルトは、ldap の場合は |
| すべての検索が開始されるディレクトリーのブランチの DN です。これは少なくともディレクトリーツリーの最上位になければなりませんが、ディレクトリーのサブツリーを指定することもできます。 |
|
検索対象の属性です。RFC 2255 はコンマ区切りの属性の一覧を許可しますが、属性をどれだけ指定しても最初の属性のみが使用されます。属性を指定しない場合は、デフォルトで |
|
検索の範囲です。 |
|
有効な LDAP 検索フィルターです。指定しない場合、デフォルトは |
検索の実行時に属性、フィルター、指定したユーザー名が組み合わされて以下のような検索フィルターが作成されます。
(&(<filter>)(<attribute>=<username>))
たとえば、以下の URL について見てみましょう。
ldap://ldap.example.com/o=Acme?cn?sub?(enabled=true)
クライアントが bob
というユーザー名を使用して接続を試みる場合、生成される検索フィルターは (&(enabled=true)(cn=bob))
になります。
LDAP ディレクトリーの検索に認証が必要な場合は、エントリー検索の実行に使用する bindDN
と bindPassword
を指定します。
LDAPPasswordIdentityProvider
を使用したマスター設定
oauthConfig: ... identityProviders: - name: "my_ldap_provider" 1 challenge: true 2 login: true 3 mappingMethod: claim 4 provider: apiVersion: v1 kind: LDAPPasswordIdentityProvider attributes: id: 5 - dn email: 6 - mail name: 7 - cn preferredUsername: 8 - uid bindDN: "" 9 bindPassword: "" 10 ca: my-ldap-ca-bundle.crt 11 insecure: false 12 url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid" 13
- 1
- このプロバイダー名は返されるユーザー名に接頭辞として付加され、アイデンティティー名が作成されます。
- 2
true
の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーのWWW-Authenticate
challenge ヘッダーと共に送信されます。- 3
true
の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。- 4
- このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記 を参照してください)。
- 5
- アイデンティティーとして使用する属性の一覧です。最初の空でない属性が使用されます。少なくとも 1 つの属性が必要です。一覧表示される属性のいずれにも値がない場合、認証は失敗します。
- 6
- メールアドレスとして使用する属性の一覧です。最初の空でない属性が使用されます。
- 7
- 表示名として使用する属性の一覧です。最初の空でない属性が使用されます。
- 8
- このアイデンティティーのユーザーをプロビジョニングする際に推奨ユーザー名として使用する属性の一覧です。最初の空でない属性が使用されます。
- 9
- 検索フェーズでバインドするために使用するオプションの DN です。
- 10
- 検索フェーズでバインドするために使用するオプションのパスワードです。この値は 環境変数、外部ファイル、または暗号化されたファイル でも指定できます。
- 11
- 設定された URL のサーバー証明書を検証するために使用する証明書バンドルです。このファイルのコンテンツは、/etc/origin/master/<identity_provider_name>_ldap_ca.crt ファイルにコピーされます。アイデンティティープロバイダー名は
openshift_master_identity_providers
パラメーターの値です。CA テキストまたはローカル CA ファイルのパスを指定しない場合は、CA 証明書を/etc/origin/master/
ディレクトリーに配置する必要があります。複数のアイデンティティープロバイダーを指定する場合は、各プロバイダーの CA 証明書を/etc/origin/master/
ディレクトリーに手動で配置する必要があります。この位置を変更することはできません。証明書バンドルの定義は、insecure: false
がインベントリーファイルに設定されている場合にのみ適用されます。 - 12
true
の場合、サーバーへの TLS 接続は行われません。false
の場合、ldaps://
URL は TLS を使用して接続し、ldap://
URL は TLS にアップグレードされます。- 13
- LDAP ホストと使用する検索パラメーターを指定する RFC 2255 URL です (上記 を参照してください)。
LDAP 統合のためのユーザーのホワイトリストを作成するには、lookup
マッピング方法を使用します。LDAP からのログインが許可される前に、クラスター管理者は各 LDAP ユーザーのアイデンティティーとユーザーオブジェクトを作成する必要があります。