第1章 Active Directory との統合

この設定により、単一の Active Directory Domain Controller に依存するようになるため、Identity サービスがその AD Domain Controller に対して認証できない場合には、プロジェクトユーザーが影響を受けることになります。このリスクを管理するオプションは複数あります。たとえば、Identity サービスが 個別の AD Domain Controller ではなくDNS エイリアスやロードバランシングアプライアンスにクエリーを実行するように設定することが可能です。また、Domain Controller の 1 つが利用できない場合には、keystone が異なる Domain Controller にクエリーを実行するように設定することもできます。詳しくは、「高可用性の設定」を参照してください。

コマンドラインから Identity サービスドメインを管理するには、keystone v3 にアクセス可能である必要があります。

keystone サービスを実行しているコントローラーから以下の手順を実行します。

1. 既存の環境変数ファイルのコピーを作成します。director ベースのデプロイメントでは、overcloudrc と呼ばれます。

$ cp overcloudrc overcloudrc-v3

2. 新しい overcloudrc-v3 ファイルを編集します。

export OS_AUTH_URL=https://controllerIP:5000/v3/

export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default

3. source コマンドでこの設定ファイルを読み込み、現在のコマンドラインセッションでこれらのオプションを有効にします。

$ source overcloudrc-v3

keystone サービスを実行中のコントローラーから以下の手順を実行します。複数のコントローラーがある HA 環境を実行している場合には、各コントローラーでこれらの手順を実行する必要があります。

1. SELinux を設定します。

# setsebool -P authlogin_nsswitch_use_ldap=on

出力には、以下のようなメッセージが含まれている場合がありますが、これは無視できます。

Full path required for exclude: net:[4026532245].

2. domains ディレクトリーを作成します。

# mkdir /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/
# chown keystone /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/

3. Identity サービスが複数のバックエンドを使用するように設定します。

# crudini --set /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
# crudini --set /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf identity domain_config_dir /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains
# crudini --set /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf assignment driver sql

4. Dashboard で複数のドメインを有効にします。以下の行を /etc/openstack-dashboard/local_settings に追加します。

OPENSTACK_API_VERSIONS = {
    "identity": 3
}
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'Default'

httpd を再起動して、設定を適用します。

# systemctl restart httpd

5. 追加のバックエンドを設定します。

以下の例では、LAB は、Identity サービスドメインとして使用する NetBIOS の名前に置き換えます。

a. AD DS を統合するための keystone ドメインを作成します。

上記のステップで取得した NetBIOS 名の値をドメイン名として使用します。このアプローチでは、ログインプロセス中に、一貫したドメイン名をユーザーに提示することができます。たとえば、NetBIOS 名が LAB の場合には、以下のコマンドを実行します。

# openstack domain create LAB

b. 設定ファイルを作成します。

AD DA バックエンドを追加するには、/var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/keystone.LAB.conf (LAB は、前のステップで作成したドメイン名に置き換えます) という名前の新規ファイルに LDAP 設定を入力します。以下の設定例は、実際に使用する LDAP デプロイメントに合わせて編集する必要があります。

[ldap]
url                  = ldaps://addc.lab.local:636
user                  = CN=svc-ldap,OU=labUsers,DC=lab,DC=local
password                 = RedactedComplexPassword
suffix                   = DC=lab,DC=local
user_tree_dn             = OU=labUsers,DC=lab,DC=local
user_objectclass         = person
user_filter                  = (|(memberOf=cn=grp-openstack,OU=labUsers,DC=lab,DC=local)(memberOf=cn=grp-openstack-admin,OU=labUsers,DC=lab,DC=local)(memberOf=memberOf=cn=grp-openstack-demo,OU=labUsers,DC=lab,DC=local))
user_id_attribute        = sAMAccountName
user_name_attribute      = sAMAccountName
user_mail_attribute      = mail
user_pass_attribute      =
user_enabled_attribute   = userAccountControl
user_enabled_mask        = 2
user_enabled_default     = 512
user_attribute_ignore    = password,tenant_id,tenants
user_allow_create        = False
user_allow_update        = False
user_allow_delete        = False
group_objectclass        = group
group_tree_dn            = OU=labUsers,DC=lab,DC=local
group_filter             = (CN=grp-openstack*)
group_id_attribute       = cn
group_name_attribute     = name
group_allow_create       = False
group_allow_update       = False
group_allow_delete       = False
use_tls                  = False
tls_cacertfile                  = /etc/ssl/certs/addc.lab.local.crt
query_scope                  = sub
chase_referrals                  = false

[identity]
driver = keystone.identity.backends.ldap.Identity

各設定項目について説明します。

6. 設定ファイルの所有権を keystone ユーザーに変更します。

# chown keystone /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/keystone.LAB.conf

7. keystone サービスを再起動して、変更を適用します。

# sudo docker exec -it keystone pkill -HUP -f keystone

8. admin ユーザーにドメインへのアクセス権を付与します。

a. LAB ドメインの ID を取得します。

# openstack domain show LAB
+---------+----------------------------------+
| Field   | Value                            |
+---------+----------------------------------+
| enabled | True                             |
| id      | 6800b0496429431ab1c4efbb3fe810d4 |
| name    | LAB                              |
+---------+----------------------------------+

b. admin ユーザーの ID の値を取得します。

# openstack user list --domain default | grep admin
| 3d75388d351846c6a880e53b2508172a | admin      |

c. admin ロールの ID の値を取得します。

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+

d. 返されたドメインおよび管理 ID を使用して、keystone LAB ドメインの admin ロールに admin ユーザーを追加するコマンドを構築します。

# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf

9. コマンドで NetBIOS 名を指定して、AD DS ドメイン内のユーザー一覧を確認します。

# openstack user list --domain LAB

10. ローカルの Identity サービスデータベース内のサービスアカウントを確認します。

# openstack user list --domain default

Compute はデフォルトで keystone v2.0 を使用するように設定されているので、マルチドメイン機能を使用するためには、keystone v3 を使用するように設定する必要があります。

1. 各コンピュートノードとコントローラーで keystone_authtoken 値を変更します。

# crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3

2. コントローラーでサービスを再起動して、変更を適用します。

# systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service
# sudo docker exec -it keystone pkill -HUP -f keystone

3. 各コンピュートノードでサービスを再起動して、変更を適用します。

# systemctl restart openstack-nova-compute.service

keystone v3 に対して認証を実行するには、Block Storage (cinder) を設定する必要もあります。

認証されたユーザーが OpenStack リソースにアクセスするのを許可するための推奨される方法は、特定の Active Directory グループを承認してプロジェクトへのアクセス権を付与することです。これにより、OpenStack の管理者は、プロジェクト内で各ユーザーをロールに割り当てる必要がなくなり、代わりに Active Directory グループにプロジェクト内のロールが付与されます。その結果、それらの Active Directory グループのメンバーである Active Directory ユーザーは事前定義済みのプロジェクトにアクセスできるようになります。

本項は、Active Directory の管理者が以下のステップをすでに完了していることを前提としています。

以下のステップでは、AD グループにロールを割り当てます。これで、グループのメンバーに OpenStack リソースへのアクセス権が付与されます。

1. AD グループの一覧を取得します。

# openstack group list --domain LAB
+------------------------------------------------------------------+---------------------+
| ID                                                               | Name                |
+------------------------------------------------------------------+---------------------+
| 185277be62ae17e498a69f98a59b66934fb1d6b7f745f14f5f68953a665b8851 | grp-openstack       |
| a8d17f19f464c4548c18b97e4aa331820f9d3be52654aa8094e698a9182cbb88 | grp-openstack-admin |
| d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 | grp-openstack-demo  |
+------------------------------------------------------------------+---------------------+

2. ロールの一覧を取得します。

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 0969957bce5e4f678ca6cef00e1abf8a | ResellerAdmin |
| 1fcb3c9b50aa46ee8196aaaecc2b76b7 | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
| d3570730eb4b4780a7fed97eba197e1b | SwiftOperator |
+----------------------------------+---------------+

3. Active Directory グループに上記のロールを 1 つまたは複数追加して、プロジェクトへのアクセス権を付与します。たとえば、grp-openstack-demo グループ内のユーザーを demo プロジェクトの一般ユーザーにするには、そのグループを member ロールに追加する必要があります。

# openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8  _member_

その結果、grp-openstack-demo のメンバーは、AD DS のユーザー名とパスワードを入力して Dashboard にログインすることができます。また、ドメインフィールドに LAB と入力してログインすることも可能です。

grp-openstack AD グループのメンバーである AD DS ユーザーには、Dashboard 内のプロジェクトにログインするパーミッションを付与することができます。

1. AD ユーザーの一覧を取得します。

# openstack user list --domain LAB
 +------------------------------------------------------------------+----------------+
| ID                                                               | Name           |
+------------------------------------------------------------------+----------------+
| 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e | user1          |
| 12c062faddc5f8b065434d9ff6fce03eb9259537c93b411224588686e9a38bf1 | user2          |
| afaf48031eb54c3e44e4cb0353f5b612084033ff70f63c22873d181fdae2e73c | user3          |
| e47fc21dcf0d9716d2663766023e2d8dc15a6d9b01453854a898cabb2396826e | user4          |
+------------------------------------------------------------------+----------------+

2. ロールの一覧を取得します。

# openstack role list
+----------------------------------+---------------+
| ID                               | Name          |
+----------------------------------+---------------+
| 544d48aaffde48f1b3c31a52c35f01f9 | SwiftOperator |
| 6d005d783bf0436e882c55c62457d33d | ResellerAdmin |
| 785c70b150ee4c778fe4de088070b4cf | admin         |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_      |
+----------------------------------+---------------+

3. 一覧表示されたロールの中から 1 つまたは複数のロールをユーザーに追加して、プロジェクトへのアクセス権を付与します。たとえば、user1 を demo プロジェクトの一般ユーザーにするには、member ロールに追加します。

# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_

また、user1 を demo プロジェクトの管理ユーザーにするには、admin ロールに追加します。

# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin

その結果、user1 は AD DS のユーザー名とパスワードを入力してから、ドメインのフィールドにも LAB と入力すると Dashboard にログインすることができます。

Active Directory Domain Controller に対してテストクエリーをリモートで実行するには、ldapsearch を使用します。クエリーが成功した場合には、ネットワーク接続が機能しており、AD DS サービスが稼働中であることを確認できます。以下の例では、テストクエリーはサーバー addc.lab.local のポート636 に対して実行されます。

# ldapsearch -Z -x -H ldaps://addc.lab.local:636 -D "svc-ldap@lab.local" -W -b "OU=labUsers,DC=lab,DC=local" -s sub "(cn=*)" cn

ldapsearch のテストの際に Peer's Certificate issuer is not recognized. というエラーを受け取った場合には、TLS_CACERTDIR パスが正しく設定されていることを確認してください。以下に例を示します。

TLS_CACERTDIR /etc/openldap/certs

TLS_REQCERT allow

nc を使用して、LDAPS ポート (636) がリモートでアクセス可能であることを確認します。この例では、サーバー addc.lab.local に対してプローブを実行します。ctrl-c を押してプロンプトを終了します。

# nc -v addc.lab.local 636
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.200.10:636.
^C

接続を確立できなかった場合には、ファイアウォールの設定に問題がある可能性があります。