3.9. 新規プロジェクトの作成
上記の統合ステップが完了した後に新規プロジェクトを作成する場合には、Default ドメインと、自分で作成した keystone ドメインのどちらに作成するかを決定する必要があります。これは、ワークフローとユーザーアカウントの管理方法を考慮して決定することができます。Default ドメインは、サービスアカウントと admin プロジェクトに使用する内部ドメインとして考えることができるので、AD でバッキングされているユーザーを異なる keystone ドメインに内に配置することは理にかなっています。これは、LDAP ユーザーが管理されているのと全く同じ keystone ドメインである必要はありません。また、分離の目的で複数の keystone ドメインを使用することも可能です。
3.9.1. Dashboard へのログインプロセスの変更 リンクのコピーリンクがクリップボードにコピーされました!
Identity サービスに複数のドメインを設定すると、Dashboard のログインメージに新しい ドメイン フィールドが有効になります。
ユーザーは、ログイン認証情報にマッチするドメインを入力する必要があります。このフィールドには、keystone で提示されるドメインの 1 つを手動で入力する必要があります。利用可能なエントリーを表示するには、openstack コマンドを使用します。
以下の例では、LDAP アカウントには LAB ドメインを指定する必要があります。admin のような組み込みの keystone アカウントには、ドメインに Default を指定する必要があります。
3.9.2. コマンドラインへの変更 リンクのコピーリンクがクリップボードにコピーされました!
特定のコマンドでは、対象のドメインを指定する必要がある場合があります。たとえば、以下のコマンドに --domain LAB を追加すると、LAB ドメイン内のユーザー (grp-openstack グループのメンバー) が返されます。
openstack user list --domain LAB
# openstack user list --domain LAB
--domain Default を追加すると、組み込みの keystone アカウントが返されます。
openstack user list --domain Default
# openstack user list --domain Default
3.9.3. LDAP 統合のテスト リンクのコピーリンクがクリップボードにコピーされました!
以下の手順では、Dashboard の機能へのユーザーアクセスをテストして、LDAP の統合を検証します。
1. LDAP にテストユーザーを作成し、そのユーザーを grp-openstack LDAP グループに追加します。
2. テストユーザーを demo テナントの _member_ ロールに追加します。
3. LDAP テストユーザーの認証情報を使用して Dashboard にログインします。
4. 各タブをクリックし、エラーメッセージなしに正常に表示されているかどうかを確認します。
5. Dashboard を使用してテストインスタンスをビルドします。
上記の手順で問題が発生した場合には、組み込みの admin アカウントでステップ 3 から 5 までを実行してください。正常に実行できた場合には、OpenStack が想定通りに機能していることが実証されるので、問題は LDAP と Identity の統合設定の間のどこかにあることになります。「トラブルシューティング」を参照してください。