みなさんこんにちは。ネットワールドの金沢と申します。
Okta Privileged Accessを用いてAD管理を行いました。全3編、ADアカウント管理、ADサーバー管理、応用編としてブログを作成する予定です。
【本記事でわかること】
- Okta Privileged AccessでActive Directoryの特権アカウントを管理するときの画面遷移
- 基本的なOkta Privileged Accessアプリの設定方法
【略称・呼称に関して】
本記事では、以下の略称が用いられます。
Okta Privileged Access：OPA
Active Directory：AD
操作前に
まずはアカウント管理の完成形のイメージを掴んでいただきます。
OPAでは、OPAアプリにアカウントやサーバーなどを同期または登録することを「リソースを保護する」という表現をします。
本例では、作成したOPAOU内にある以下のADアカウントを保護します。
完成図としては以下のイメージです。
Active Directory内のアカウントがOPAで一元管理できています。
これだけだとディレクトリ統合したOkta UDとの違いはわかりづらいですが、パスワード管理が行えることも特徴です。「show credential」というボタンが有効化されているアカウントは、Oktaにて完全なパスワード管理が行われています。このパスワードは決められた期間を過ぎるとOPAによってローテーションされます。期間は自由に設定でき、最短1時間、最長400日でローテーションされます。以下はパスワードローテーションの期間を1時間と設定した際のあるアカウントのパスワードの様子です。
※本画像は2026/7/23のものであり、既にこのアカウントは存在しません
このパスワードはADのパスワードと一致します。たとえば、サーバーにアクセスする際はOPAでローテーションされたパスワードでログオンします。以下は、ADに参加しているクライアントマシンにOPAで管理しているパスワードを用いてログオンするときの映像です。画面が小さくてわかりづらいですが、Oktaから取得したパスワードがそのままADアカウントのパスワードになっています。
では実際に、ADアカウントをOPAで保護してみましょう。ここからはOkta UDとActive Directoryが統合されていることが前提となります。詳しい手順に関しましては、Okta公式が出している以下ドキュメントをご参考ください。
help.okta.com
「OPAでアカウント管理をする」というと、OPAとADが直接連携していると思う方がいらっしゃるのですが、ユーザー基盤であるOkta UDを本丸とし、そちらから保護対象のアカウントを選択し同期するというイメージを持つのが正しいです。あくまでOPAはOktaのアプリのひとつであることを考えると、理解しやすいかもしれません。
またOPAでは、一般的に「ユーザー」と一般的に呼称されるものを3種類使い分ける必要があります。本記事では以下のように呼び分け、記載することといたします。
| 呼び方 | 説明 |
|---|---|
| ADアカウント | Active Directoryからインポートされる、OPA管理対象のアカウント |
| ○○ユーザー | Okta内でサービスを利用する、利用に特別な権限を要求しないユーザー （例：OPAユーザー・Access Requestsユーザー） |
| ○○管理者 | Okta内で特定の権限を持ってサービスの設定を行うOktaユーザー （例：OPAスーパー管理者、Access Requests管理者） |
作業準備
OPAでAD管理をする前に、4つの設定が必要になります。
- ADエージェントの同期
- Okta Privileged Accessアプリのインストール
- OPAユーザーの作成・権限整備
- リソースを管理する階層の整備
ADエージェントの同期方法に関しては、前述したリンクをご参照ください。ここでは、OPAアプリ内に絞った設定準備を行っていきます。
OPAアプリのインストール
デフォルト状態ではOPAアプリはインストールされていません。Okta Admin Consoleから「Application」タブに遷移し、インストールします。
「Okta Privileged Access」で検索し、出てきたアプリを追加します。
Team Nameを記入します。このTeam NameというのはOPAアプリ内でのテナント名のイメージです。全世界で一意である必要があることに注意してください。今回は「Administrator_teams」を記入しました。
Teamの概念に関しては以下リンクが非常に参考になります。
iamse.blog
OPAユーザー作成
OPA構築前に、OPAアプリ内で操作するユーザーを整えます。OPAアプリでユーザーを作成するには、Okta UDからユーザーに対してアプリを割り当てることが必要です。
もちろんグループで割り当てることも可能ですが、その場合はグループは同期されません。同期するためにはプッシュグループが必要です。
OPAユーザー 権限整備
ユーザー権限の整備も必要です。
OPAアプリではOkta本体とは独立した権限が存在し、これらを整備しないとOPAアプリ内の設定ができません。権限は設定すればするほど表示される画面が変わってきます。
OPAに存在する権限の詳しい説明は以下リンクをご参考ください。本記事では、「リソース管理者権限」「セキュリティ管理者権限」を持ったOPAユーザーにて設定しています。
help.okta.com
リソースグループ・プロジェクト整備
管理対象のADアカウントとサーバーを登録するための枠組みを作成していきます。OPAでは、リソースグループを最上位階層とし、プロジェクトに分けてリソースを管理します。今回はADアカウント及びADサーバーを管理するので、リソースグループ「ActiveDirectory」を作成し、プロジェクト「ADAccount」「Server」をそれぞれ作成しました。
※設定後の画面を撮影しているため、リソース数が加算されています。
アカウント管理
準備が整えば、ようやくアカウント管理が可能です。
アカウントルールをOPAアプリ内で作成しOkta UDから保護したいADアカウントを選択し、OPAアプリに同期する作業を行います。この設定にはリソース管理者権限が必要です。
ADドメインをOPAアプリに同期する
Resource Administration > Connection と遷移すると、Okta UDに統合されているADドメインが一覧となって表示されています。OPAで管理したいドメインをアクティブにすることで、そのドメインをOPA管理下に置くことが可能です。
アカウントルールの作成
「Resource assignment」タブから「Active Directory」タブに遷移すると、先ほど設定したドメインが表示されています。
同期したいアカウントが入っているドメイン名を押下し「Account Rules」を開きます。「∨」を開くとアカウントルールの種類が検索できます。今回は「share」ルールにします。
アカウントルール作成例
以下例は「[vSphereAD.com]ドメイン内[OPAOU]に入っているアカウントを[ActiveDirectory]リソースグループ内[ADAccount]プロジェクト」に入れるアカウントルールです。
特筆すべきは以下ルールでしょうか。
| 番号 | ルール名 | ルール内容 |
|---|---|---|
| 1 | Keep accounts for Okta-managed access | インポートしたアカウントをOktaのユーザーとしても扱う →パスワード管理の基盤がOktaに移動する |
| 2 | Initial password rotation | チェックボックスをON →検出し即座にパスワードローテーションを行う |
それぞれぱっと見では大変わかりづらいですが、設定の意味を考えると理解が簡単です。
1は、アカウントの基盤を設定しています。繰り返すようですが、OPAはアカウントの本丸をOkta UDに置いています。これをONにするとアカウントをOkta UD内ユーザーとして扱うことになります。つまり、パスワードもOkta管理にでき、同時にパスワードローテーションの対象になるということです。
パスワードローテーションはOPA管理とした場合自動で行われるものであり、パスワードローテーションをオフにするかつOkta管理とする構成は不可能となります。もしオフにした場合、OPA上ではパスワード管理外となりOkta上では参照できなくなります。
2はシンプルです。対象OPAユーザーのパスワードローテーションのタイミングを設定します。
オフにしていると、OPAアプリに取り込んでから最初のローテーションのタイミングが来るまではADで設定したパスワードが有効になります。
今回は両方ともオンにして設定しました。
アカウントルール設定確認
正しく設定されると、作成したプロジェクトに保護対象ADアカウントが表示されます。
Resource Administration > Resource managementに遷移し、設定したプロジェクトに移動すると、設定したリソースが保護されていることが確認できます。
※検証では反映には1時間がかかることを確認しています。おそらくOktaで設定しているADエージェントの同期タイミングと一致しているかと思われます。
セキュリティポリシー設定
ADアカウントをOPAアプリ内に取り込み、保護することに成功しました。セキュリティポリシーの設定によって、どのユーザーが保護対象リソースを使用できるのかを設定することが可能です。
今回は「NormalUser-Group」内ユーザーに割り当て、そのグループ内にいるOPAユーザーがパスワードを確認できるのかを確認していきます。この設定にはセキュリティ管理者権限が必要です。
セキュリティポリシーの作成
Security Administrationタブに遷移し、Create Policyボタンから「デフォルト」を押下します。
ポリシーとルールの作成を行います。ポリシーを作り割り当てるには、ルールを最低一つ必要です。ポリシーとルールの棲み分けは以下をイメージしてください。
ポリシー：アクセス権を与える対象を定義する
ルール：ポリシー内で定義される、リソースのスコープと、これらリソースへの特権アクセスの付与方法を定義したもの。
勝手としてはOktaで設定するサインオンポリシーと似ている。
作成した後は「Save Policy」を押下してポリシーを保存し、「Publish Policy」をオンにすることを忘れないようにしましょう。セキュリティポリシー一覧においてStatusが「Active」になっていればそのポリシーは有効です。
セキュリティポリシー作成例
以下は保護対象ADアカウントのパスワードのパスワード閲覧と手動のパスワードローテーションを許可するポリシーとルールです。「Principal」に「Normal User-Group」を割り当て、「Password」ルールを設定しました。
「Password」ルールは以下のように設定しました。Principalに設定したグループのOPAユーザーはパスワード閲覧とローテーションができ、MFA等の追加設定は不要にしました。またここで、取り込んだ保護リソースのうちプリンシパル対象にどれを閲覧させるのかを設定しています。
設定後
セキュリティポリシーの設定が完了しました。実際にどういった画面になるのか、「NormalUser-Group」のユーザーである「AR-approve」から確認してみましょう。
My Privileged Access > Active Directoryタブに移動すると、Active Directoryルールで決めた管理対象ドメインが表示されます。押下すると、セキュリティポリシーで設定した保護リソースが確認できます。
[show credential]ボタンを押すとパスワードが閲覧できます。
また右側の縦三点を押すと、パスワードローテーションを手動で行うことも可能です。
ADアカウントをOPAで保護する手順は上記で終了です。次はADサーバーが取り込まれたドメインコントローラーを管理していきます。
▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼
ネットワールドが開催する 年に一度の大イベント
【 Networld Wiz 2026 】お申込み受付中！！
本ブログでご紹介したメーカーもイベントへ出展します！
セッション & ブース出展情報 随時更新中
▼ぜひチェックしてください▼
networldwiz.jp
