midPoint by OpenStandia Advent Calendar 2024 の16日目は、15日目の記事で構築したActive Directory（以下、AD）互換環境であるSamba4に対して、ユーザーをプロビジョニングします。
基本的な設定の流れは、11日目の記事「midPoint からCSVにプロビジョニングする」で解説したものと同じです。リソースの作成を行い、アウトバウンドマッピングや同期、Correlationの設定を行います。今回異なる部分としては、連携先がADということで、アカウントステータスとパスワードのプロビジョニング設定も行います。とはいえ大部分の設定はCSVプロビジョニングのケースと同じですので、具体的な操作は過去の記事も参考にしてください。
15日目までの環境を前提としています。
リソース設定
新規リソース作成のウィザードを開始してセットアップしていきます。
リソースの新規作成
最初に選択するリソースカタログでは、今回はADに接続するために「AdLdapConnector」を選択します。
リソースの基本情報は以下のとおりです。
-
名前：
AD -
ライフサイクル状態：
Active (production)
コネクターの設定画面では以下のように入力し、「次へ：ディスカバリー」をクリックします。
-
Host：
ad1 -
Port number：
389 - Connection security：空のまま
-
Bind DN：
cn=Administrator,cn=Users,dc=ad,dc=example,dc=com -
Bind password：
p@ssw0rd2
実際のADに接続する場合は、LDAPSで接続するためPort numberは636にし、Connection securityをsslに設定します。今回の開発/検証用のSamba4では、LDAP接続も許可しているため、ここでは一旦LDAP接続で先に進みます。というのも、次の画面に進む際にはADに実際に接続確認が行われるため、LDAPS接続のためのサーバー証明書のセットアップを行っていないこの環境では、以下のようなエラーとなるためです。
ディスカバリーの画面では、以下を設定します。また、「空項目を表示する」ボタンをクリックしてその他の項目も表示します。
Base context：DC=ad,DC=example,DC=com
コネクターの設定項目が多数表示されますが、以下を設定しておきます。今回、パスワードの連携もしますが、その場合、AD（Samba4）はパスワードの更新時にはLDAPSが必須となります。しかし今回の環境では、LDAPS接続のためのサーバー証明書のセットアップは省いているため、Samba4が生成したデフォルトのサーバー証明書をそのまま受け入れる形にしておきます。
Allow untrusted SSL/TLS：True
実際のADに接続する場合はこのオプションを設定せず、midPointに信頼するサーバー証明書のセットアップをするなどして正しくLDAPS接続を行います。以下のドキュメントに、コネクターなどによる外部へのTLS接続時におけるサーバー証明書のセットアップについて記載されています。
画面最下部の「次へ：スキーマ」ボタンをクリックして先に進みます。
少々待たされた後に、ADのスキーマ一覧が表示されます（ADからスキーマ情報を取得するため、時間がかかります）。
今回はユーザーをプロビジョニング対象としたいので、上部の検索ボックスにuserと入力して「検索」ボタンをクリックします。すると、以下の様にフィルタされた結果が表示されます。
「user」の左隣のチェックボックスをクリックします。すると「選択された項目」に追加された状態になります。
今後の記事で、グループもプロビジョニングしますので、次はgroupと入力して「検索」ボタンをクリックします。表示された「group」を同様にチェックし、「選択された項目」に追加します。
画面最下部にある「リソースの作成」ボタンをクリックして、一旦この内容でリソースを作成します。
作成完了の画面で、「リソースの詳細へ」をクリックして、一旦リソースの詳細画面を開きます。
LDAPS接続に変更
リソースの作成時に、ADへの接続はLDAP接続で設定しているため、このままではユーザーにパスワードの設定ができません。よって、LDAPS接続に変更しておきます。
「AD」リソースの詳細画面より、「コネクター設定」メニューを開きます。
「Port number」を636に変更します。
また、「空項目を表示する」をクリックして、「Connection security」項目を表示させます。ここにsslを設定し、これで「保存」ボタンをクリックして保存します。
再度「AD」リソースの詳細画面を開き、「コネクター設定」メニューを開きます。更新後の設定になっていることを確認します。
「接続テスト」ボタンをクリックしてテスト接続が成功するか確認しておきます。
以下のように全てグリーンとなれば成功です。
オブジェクトタイプの追加
「AD」リソースの詳細画面より、「スキーマ処理」メニューを開き、ユーザープロビジョニングのためのオブジェクトタイプの追加を行います。
基本情報の設定画面では、以下を設定します。
-
表示名：
User -
種類：
アカウント
リソース・データの設定画面では、以下を設定します。
-
オブジェクトクラス：
user
MidPointデータの設定画面では、以下を設定します。これで「設定を保存」ボタンをクリックして保存します。
-
タイプ：
ユーザー
マッピングの設定
「マッピング」をクリックしてマッピング設定画面を開きます。
今回はADがプロビジョニング先となるため、「アウトバウンドマッピング」を設定します。マッピング内容は下表を参考に設定します。
| ソース | 式 | ターゲット |
|---|---|---|
| name | スクリプト | dn |
| name | 現状 | userPrincipalName |
| name | 現状 | sAMAccountName |
| familyName | 現状 | sn |
| givenName | 現状 | givenName |
| emailAddress | 現状 |
ターゲットdnのスクリプト設定は以下のようにnameのオリジナル値よりcnでRDNを構成するようにしておきます。
-
コード：
basic.composeDnWithSuffix("cn", name.orig, "ou=Users,ou=IDM,dc=ad,dc=example,dc=com")
最終的に以下のような設定となります。これで「マッピングを保存」ボタンをクリックして保存します。
同期の設定
11日目の記事「midPoint からCSVにプロビジョニングする」と同様に、同期の設定をしておきます。
ただし、今回は以下の表の内容で設定します。「Unmatched」に対する設定はしないでおきます（安全のため、AD側にだけ存在するユーザーを削除しないように）。
| 状況 | アクション | 設定意図 |
|---|---|---|
| Linked | 同期 | 既にLinked状態のユーザーに対して、リコンシリエーションタスクの実行時に差分があれば反映する |
| Unlinked | 紐づけ | 名寄せ処理にて、ADのユーザーと一致するmidPoint側のデータを発見した場合に、紐づけを行う |
| Deleted | 同期 | リコンシリエーションタスク実行時にAD側でユーザーが削除されたことを検知した場合は、再びADにユーザーをプロビジョニングする |
Correlationの設定
11日目の記事「midPoint からCSVにプロビジョニングする」と同様に、名寄せの設定をしておきます。
名寄せ用のインバウンドマッピングの追加
再度マッピングの設定画面を開き、以下の内容でインバウンドマッピングを追加します。
今回は簡易のためcnを使っていますが、異なるOUにもプロビジョニングを行う場合は、cnでは一意に名寄せできないケースも想定されるため注意してください。
-
ソース：
cn -
式：
現状 -
To resource attribute：
name
追加したインバウンドマッピングの詳細画面で、以下の設定を行い名寄せ専用とします。
-
Use for：
相関
Correlationの設定
Correlationの設定画面を開き、ルールを追加します。
ルールの詳細設定画面を開き、「アイテム」に先ほど追加した名寄せ用のインバウンドマッピングのアイテムであるnameを選択します。
アクティベーションの設定
ADのユーザーはアカウントステータスを持っていますので、それもmidPointからプロビジョニングするように設定しておきます。
アカウントステータスは専用マッピング設定となっており、「オブジェクト・タイプのウィザード」画面より「アクティベーション」をクリックして設定を開始します。
アクティベーション設定画面が開くので、「アウトバウンド」をクリックしてアウトバウンドの設定に切り替えます。ここで「アウトバウンドの追加」ボタンをクリックします。
アクティベーション・ルールの選択ダイアログが表示されますので、管理ステータスをクリックして選択します。
以下のように追加された状態になります。今回はデフォルトの設定（通常（normal）かつ現状（As is）マッピング）を利用します。「設定を保存する」ボタンをクリックして保存します。
クレデンシャルの設定
ADのユーザーはパスワード持っていますので、それもmidPointからプロビジョニングするように設定しておきます。
パスワード（クレデンシャル）は専用マッピング設定となっており、「オブジェクト・タイプのウィザード」画面より「クレデンシャル」をクリックして設定を開始します。
クレデンシャル設定画面が開くので、「アウトバウンド」をクリックしてアウトバウンドの設定に切り替えます。ここで「アウトバウンドの追加」ボタンをクリックします。
すると、以下のように追加された状態になります。今回はデフォルトの設定（通常（normal）かつ現状（As is）マッピング）を利用します。「設定を保存する」ボタンをクリックして保存します。
プロビジョニングの確認
リソースの設定が完了したので、いよいよプロビジョニングさせてみます。
リソースアサイン追加によるプロビジョニング
11日目の記事「midPoint からCSVにプロビジョニングする」と同様に、まずは簡易的な確認方法として、リソースを直接アサインして動作確認をします。
プロビジョニングを行うユーザーの詳細画面を開き、「アサイン ＞ リソース」メニューを開き、アサインの追加操作を行い「オブジェクトの選択」ダイアログを表示します。「AD」リソースにチェックを入れて、「種類」ではアカウント、「用途」ではdefaultを選択して、「追加」ボタンをクリックします。
その後、「変更のプレビュー」ボタンをクリックしてみましょう。リソースの設定が正しければ、ADへのプロビジョニング処理のプレビューが表示されます。「保存」ボタンをクリックして保存します。
該当ユーザーのプロジェクションを確認しておきます。「AD」リソースのプロジェクションが追加されていることが分かります。
DN箇所をクリックしてプロジェクションの詳細画面も確認しておきます（この時、裏でコネクターを通じてLDAP検索が行われます）。以下のように、プロビジョニングされたADユーザーの属性を確認することができます。
アカウントステータスのプロビジョニング
アカウントステータスのプロビジョニング確認もしておきます。ユーザーの詳細画面から「アクティベーション」メニューを開きます。「空項目を表示する」をクリックします。
アクティベーションの各種項目が表示されます。
「管理ステータス」を無効とします。これは、midPointの管理者側から該当ユーザーを強制的にアカウント停止するような際に利用します。
これで「変更のプレビュー」ボタンをクリックすると、以下のようにADの管理ステータスを無効とする変更差分が表示されます。「保存」ボタンをクリックして保存します。
midPointのユーザーを無効化すると、ユーザー一覧ではこのように無効を示すアイコン表示に変わります。
該当のユーザーの詳細画面より「プロジェクション」メニューを再度開き、ADのプロジェクション詳細を開くと、AD側でも「管理ステータス」が無効となっていることが分かります。
パスワードのプロビジョニング
パスワードのプロビジョニング確認もしておきます。ユーザーの詳細画面から「パスワード」メニューを開きます。「空項目を表示する」をクリックします。
パスワードの各種項目が表示されます。
「値」にパスワードを設定します。
これで「変更のプレビュー」ボタンをクリックすると、以下のようにADユーザーにパスワードを設定する変更差分が表示されます。「保存」ボタンをクリックして保存します。
パスワードの値をADから取得することはできませんので、プロジェクションの詳細を開いても設定されたかどうか確認することができません。ただし、「pwdLastSet」属性でパスワードの最終更新日時を確認することはできます。
ADでは17桁のLDAPタイムスタンプとして参照可能です。以下のサイトなどで変換できます。例えば、133787066117915000は2024年12月15日 日曜日 12:23:31 GMT+09:00です。ちょうどこの記事を書いている時間にパスワードが設定されたことが分かります。
midPointからADのユーザーには初期パスワードのみをプロビジョニングし、利用者がADにそのパスワードで初回ログインした際には、パスワード強制変更をさせるような運用をするケースがあります。その場合は、下記のMicrosoftのドキュメントに記載されているように、このpwdLastSetに0を設定することで、ADログイン時にパスワード変更を強制させることができます。
https://docs.microsoft.com/en-us/windows/win32/adschema/a-pwdlastset
今回はアウトバウンドマッピングでpwdLastSetに対して設定していませんが、要件に応じて設定し、このようなユースケースにも対応することができます。
ロールアサインによるプロビジョニング
12日目の記事「midPoint におけるロールベースプロビジョニング」で紹介したように、ロールにリソースをインデュースメントで設定し、ユーザーにはそのロールをアサインすることでプロビジョニングさせることができます。ADでも同様の方法でのプロビジョニングを確認しておきます。
ロールの作成
今回は「AD User」ロールを作成します。
「インデュースメント ＞ リソース」メニューをクリックして、リソースへのインデュースメント設定画面を開き、ADリソースへのインデュースを設定します。
「種類：アカウント、用途：default」を選択します。
そのまま「次へ：マッピング」ボタンをクリックして進みます。
そのまま「設定を保存」ボタンをクリックして保存します。
ロールアサインによるプロビジョニング確認
プロビジョニングさせたいユーザーの「アサイン ＞ ロール」メニューを開き、アサイン追加アイコンをクリックしてオブジェクトの選択ダイアログを表示し、「AD User」ロールにチェックを付けて「追加」ボタンをクリックします。
これで「変更のプレビュー」ボタンをクリックすると、リソース直接アサインと同様に、プロビジョニング予定の更新差分が表示されます。「保存」ボタンをクリックし、同様にプロビジョニングされることを確認します。
アーキタイプ経由の自動プロビジョニング
13日目の記事「midPoint のアーキタイプを使用した自動プロビジョニング（Birthright）」で紹介したように、アーキタイプにリソースをインデュースメントで設定し、ユーザーがHRシステムよりmidPointに取り込まれたタイミングでプロビジョニングさせることができます。AddressbookのCSVだけでなく、ADにも自動プロビジョニングするようにします。
アーキタイプとリソースの関連付け設定
13日目の記事「midPoint のアーキタイプを使用した自動プロビジョニング（Birthright）」で作成した「Employee」アーキタイプの詳細画面から「インデュースメント ＞ リソース」メニューを開きます。
アイコンをクリックしてアプリケーション・リソースの追加のウィザードを開始します。
「AD」リソースを選択して「次へ：リソース・オブジェクトタイプ」ボタンをクリックして進みます。
そのまま「次へ：マッピング」ボタンをクリックして進みます。
そのまま「設定を保存」ボタンをクリックして保存します。
自動プロビジョニングの確認
まだADにプロビジョニングしていないユーザーの詳細画面を開き、1件リコンサイルプレビューを表示して確認します（「オプション」より「リコンサイル」にチェックを付けて、「変更のプレビュー」をクリックします）。
リソースの直接アサイン、ロールアサインによるプロビジョニングと同様に、プレビュー表示されることを確認します。「保存」ボタンをクリックし、ADにユーザーがプロビジョニングされることを確認します。
インポートタスクによる一括プロビジョニング
最後に、「HR import users」タスクの詳細画面を開き、「今すぐ実行」ボタンをクリックして残りのユーザーもまとめてADにプロビジョニングさせてみます。しばらく待ち、タスクが「正常」で「終了」となれば成功です。
実際に、ADにLDAP検索してユーザーがプロビジョニングされているか確認してみましょう。
docker compose exec ad bash -c "ldapsearch -D cn=Administrator,cn=Users,dc=ad,dc=example,dc=com -w p@ssw0rd -b ou=Users,ou=IDM,dc=ad,dc=example,dc=com dn"とコンソールより実行すれば、AD（Samba4）に対してldapsearchコマンドで検索ができます。
以下のようにCN=1001〜CN=1010のユーザーが登録されていることが分かります。
$ docker compose exec ad bash -c "ldapsearch -D cn=Administrator,cn=Users,dc=ad,dc=example,dc=com -w p@ssw0rd -b ou=Users,ou=IDM,dc=ad,dc=example,dc=com dn"
# extended LDIF
#
# LDAPv3
# base <ou=Users,ou=IDM,dc=ad,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: dn
#
# 1004, Users, IDM, ad.example.com
dn: CN=1004,OU=Users,OU=IDM,DC=ad,DC=example,DC=com
# 1008, Users, IDM, ad.example.com
dn: CN=1008,OU=Users,OU=IDM,DC=ad,DC=example,DC=com
# 1009, Users, IDM, ad.example.com
dn: CN=1009,OU=Users,OU=IDM,DC=ad,DC=example,DC=com
# 1001, Users, IDM, ad.example.com
dn: CN=1001,OU=Users,OU=IDM,DC=ad,DC=example,DC=com
# 1007, Users, IDM, ad.example.com
dn: CN=1007,OU=Users,OU=IDM,DC=ad,DC=example,DC=com
# 1010, Users, IDM, ad.example.com
dn: CN=1010,OU=Users,OU=IDM,DC=ad,DC=example,DC=com
# 1003, Users, IDM, ad.example.com
dn: CN=1003,OU=Users,OU=IDM,DC=ad,DC=example,DC=com
# 1005, Users, IDM, ad.example.com
dn: CN=1005,OU=Users,OU=IDM,DC=ad,DC=example,DC=com
# 1002, Users, IDM, ad.example.com
dn: CN=1002,OU=Users,OU=IDM,DC=ad,DC=example,DC=com
# Users, IDM, ad.example.com
dn: OU=Users,OU=IDM,DC=ad,DC=example,DC=com
# 1006, Users, IDM, ad.example.com
dn: CN=1006,OU=Users,OU=IDM,DC=ad,DC=example,DC=com
# search result
search: 2
result: 0 Success
# numResponses: 12
# numEntries: 11
まとめ
16日目では、midPointからADへのユーザープロビジョニングの設定ついて解説しました。設定の流れは、11日目の記事「midPoint からCSVにプロビジョニングする」で解説したものと同じあり、midPointではリソースの種類に依存せず、汎用的な方法で設定可能であることが分かったかと思います。
次回は、ADユーザーに続いてADグループ（セキュリティグループ）のプロビジョニング設定を追加する予定です。お楽しみに！