みなさんこんにちは。ネットワールドの金沢と申します。
前回はADからアカウントを管理することに関してブログを書かせていただきました。今回はその続き、サーバー管理についてお話しさせていただきます。
本記事でできるようになること
【画面】
特権ADアカウントでクライアント端末にサインインし、RDP時にOPAアプリを経由したアクセスを可能にします。以下は「DomainServer」というサーバーに対してRDPする画面遷移を撮影したものです。またRDPの際にはMFAを要件としています。
【本記事でわかること】
- OPAにおけるドメインコントローラー・メンバーサーバー管理方法
- ドメインコントローラー用設定の違い
※本記事は以下記事の続編となっております。OPAアプリの設定方法やADアカウントの取り込み方法は割愛いたしますので、ご了承ください。
前提
本記事においては表記ゆれがいくつかございます。それぞれ以下のように定義させていただきます。
| 名称 | 定義 |
|---|---|
| ドメインコントローラー | Active Directoryを管理しているサーバー。一般的にActive Directoryで定義されるものと同じ。 |
| メンバーサーバー | ADに参加しているサーバー。一般的にActive Directoryで定義されるものと同じ。 |
| ドメインサーバー | 「ドメインコントローラー」の表記ゆれとし、「ドメインコントローラー」で示すものと同意義。 |
また本記事でAdmin Consoleを操作するとき、そのユーザーは、スーパー管理者権限を持っている状態です。
特権ADアカウントをOPAアプリに割り当てる
特権ADアカウントがアプリを経由してRDPできるように、アプリの割り当てを行う必要があります。Admin ConsoleからApplication > Okta Privileged Access > Assignmentesタブへと遷移し、割り当てを行います。グループ・ユーザーどちらの単位でもかまいません。
サーバーを登録する
OPAアプリに保護対象サーバーを登録します。保護イメージ及びシナリオとしては、前記事にて作成したリソースグループ「ActiveDirectory」内のプロジェクト「Server」に登録します。
※設定後の画面を撮影しているため、リソース数が加算されています。
サーバーエージェントをインストールする
OPAでサーバーを管理するためには、対象リソースにサーバーエージェントをインストールし、トークンファイルを作成することが必要です。まずはサーバーエージェントをインストールします。以下手順書に従ってインストールすれば完了です。
help.okta.com
対象OSはLinux系OS(Linux、AlmaLinu、CentOS、Ubuntu、Deblan、Suse Linux)、WindowsOSです。インストールしたいサーバーのOSに合わせて以下リンクを参照しインストールしてください。
help.okta.com
今回はWindows Serverにインストールしています。インストールが完了すると、以下のようなアプリがインストールされていることが確認できるはずです。
トークンファイルを作成する
プロジェクトに登録するためには、サーバーエージェントをインストールするだけでなく、トークンファイルを作成する必要があります。
プロジェクト「Server」を開き、リソースタイプを「Server」に選択した状態でCreate Enrollment Token」を押下します。※画像はプロジェクト名にマスクをかけています。
登録トークンの作成を行います。以下のように登録トークンが作成されるので、これをコピーします。
保護対象サーバーに戻ります。エクスプローラーで以下ディレクトリに移動します。
C:\windows\system32\config\systemprofile\AppData\Local\scaleft
enrollment.tokenファイルを作成します。先ほどコピーしてきたトークンをメモ帳等にペーストし、拡張子を「token」としたファイルを当該ディレクトリに作成します。
登録確認
正しく設定ができていれば、しばらくするとOPAアプリの該当プロジェクトにてサーバーが登録されます。検証の範囲内では少なくとも5分以内に登録されました。また作成したトークンファイルはOPAの登録が完了するとエクスプローラーに表示されなくなるため、正しい登録の指標としてください。
カスタムYAMLファイルの設定
この項目は、ドメインコントローラーをOPAでコントロールする場合に必要となる設定です。デフォルトのサーバーエージェントの設定だと、ドメインコントローラーへの変更があらかじめ制限されています。Oktaでドメインコントローラーをスキャンしてドメインアカウントのパスワードを識別または管理することはそのままの設定だと不可です。従って、その設定を上書きするためのYAMLファイルを作成する必要があります。詳しくは以下ドキュメントを参考にしてください。
help.okta.com
help.okta.com
カスタムYAMLファイルを設定するためには、まず保護対象のサーバーにAdministrator権限を持ったADアカウントでサインインし、以下ディレクトリに移動します。
C:\Windows\System32\config\systemprofile\AppData\Local\scaleft
「sftd.yaml」ファイルを作成し、ドキュメント及びYAMLの記法に従ってファイルを作成してください。以下にて例を記載します。
LogLevel: debug DomainController: AccountManagement: allow AccountManagement: PersistentAccount: auto JITAccount: auto JITGroupMembership: allow Labels: customlabel: domaincontroller
設定の意味は以下となります。
- LogLevel：ログ詳細度を設定 debugモード
- DomainController：ドメインコントローラーの設定。インデントを下げ以下設定
- AccountManagement設定をAllowにし、エージェントの決定したデフォルトを上書きする
- AccountManagement:アカウント管理機能の詳細を決定。インデントを下げ以下設定
- JITGroupMembership設定をAllowに。これにより、対象のOktaユーザーがADのローカルグループであるAdministratorグループもしくはRemote Desktopユーザーグループに割り当てる許可をサーバーエージェントに付与。
- Labels：カスタムラベルを追加。デフォルトでは3つ作成されるものに追加して設定
設定を反映させるにはサーバーエージェントを再起動する必要があります。以下コマンドで自分は再起動しました。※マシンによって異なる可能性があります。
Restart-Service “ScaleFT Server Tools”
設定が正しく反映されているかどうかは、以下ディレクトリにてサーバー内に出力されるログを確認すると参考になります。
C:\Windows\System32\config\systemprofile\AppData\Local\scaleft\Logs\sftd
たとえば以下はログファイルが読み取れていないときのログです。（Failed to Load Configurationの記載）
また、”Using Configuration”以下を確認するとyamlファイルにて属性がどう読み取られているのかを確認することができるため、デフォルトから設定を変更している場合は反映がされているかを確認してみるとよいでしょう。
Okta Active Directoryエージェントにパスワード管理権限を付与する
この項目は、ドメインコントローラーをOPAでコントロールする場合に必要となる設定です。
ADサーバーを登録する場合に実行します。AD自体はOkta本体で管理されているため、ADエージェントに対して設定を追加する必要があります。ADエージェント同期時に作成したOkta ServiceアカウントがAD内特権持ちアカウントに対してパスワードの変更を行うことを許可します。また、保護されたアカウントをOPAで管理する場合は、さらにOkta Serviceアカウントに別途パスワードリセット権限を与える必要があります。
「保護されたアカウント」に関しては以下リンクを参照ください。
learn.microsoft.com
ADエージェントインストール時に作成されるOkta Serviceというサービスアカウントに対して、[OPAOU]の編集権限を付与する流れを記載します。
ADエージェントにパスワード管理権限を付与する
まずはADエージェント自体にパスワードリセット権限を付与します。ADエージェントのサービスアカウント名はADエージェントインストール時に決定したものです。事前にADエージェントが存在するOUを以下コマンドで把握しておきます。
Get-ADUser -Identity [AD Agent名] -Properties DistinguishedName | Select-Object DistinguishedName
※既定値であれば[OktaService]がアカウント名です。
サービスアカウントが存在するOUを右クリックし「制御の委任」を押下します。手順に関して詳しくはOkta公式ガイドをご参照ください。
help.okta.com
表示された手順に従ってパスワードリセット権限を付与します。
手順が終了し、許可が付与されていることはコマンドで確認できます。以下コマンドを実行します。先ほどOUを探したときに「DistinguishedName」として出力した値を入れればOKです。
dsacls “CN=[ユーザー名],CN=[CN名],DC=[OU名],DC=[TLD]
実行し、ACL内に「Change password」が出現していることを確認できればOKです。
保護されたアカウントに対するパスワードリセット権限を付与する
「保護されたアカウント」であるActive DirectoryのアカウントのうちDomain Admins、Enterprise Admins、Administratorsは、アクセスリストが通常ADアカウントと異なり、AdminSDHolderコンテナーのACL値がテンプレートとして使用されます。そのため、上記に加え、別途こちらに対してもパスワードリセット権限を付与する操作が必要です。手順に関して詳しくはOkta公式ガイドをご参照ください。
help.okta.com
リセット権限の付与コマンドは以下です。
dsacls “ CN=AdminSDHolder,CN=System,DC=[ドメイン名],DC=[TLD] ” /G “[アカウント名@[ドメイン名].[TLD]]:CA;Reset Password”
正しく実行されると、「Reset Password」がOktaServiceアカウントに対して追加されます。
クライアントPCを登録する
OPAで管理しているサーバーにRDPもしくはSSH接続を行うためには、接続したい端末をOPAアプリ上に登録しておく必要があります。OPAクライアントをインストールしたあと、ユーザーごとに登録する処理が必要です。インストールは端末に対して一挙でできますが、登録はユーザーごとに都度行う必要があります。
また、この手順ではOPA・Oktaともに特別な権限は必要ありません。
OPAクライアントをインストールする
クライアント端末にOktaに同期かつOPAで保護するADアカウントでサインインします。このときのアカウントは特権ADアカウントをOPAアプリに割り当てる項目で割り当てたアカウントを使用してください。
対応するクライアントOSはLinux・Windowsです。OSに対応するクライアントは以下リンクより取得・ダウンロードできます。
help.okta.com
今回はWindowsOSにインストールします。こちらも指示通りにインストールを行えばOKです。インストールが完了すると以下のようなアプリがインストールされます。
OPAに端末を登録する
クライアントをインストールすることで、専用のコマンドラインが使えるようになりました。これを用いて端末をOPAに登録します。公式ドキュメントではPowerShellを開き、以下コマンドを実行し
sft enroll
Team Nameを入れて登録する手順の記載がありました。しかしこの手順だと「An unknown error」が起き、失敗してしまう事態が多数起き先に進めませんでした....
違う手段で今回は登録してみます。OPAに一度接続したいADアカウント及びOktaユーザーでログインします。Directoryタブ>「client」に遷移すると登録コマンドが表示されるので、それを管理者権限で実行します。
実行すると以下のような画面が表示されます。登録名をカスタムしたい場合はここでやっておきましょう。
クライアント端末が登録されます。
セキュリティポリシーを設定する
前記事に引き続きセキュリティポリシーを設定します。今回はOPAユーザーである特権ADアカウントに対して保護サーバーへのRDP権限を設定します。
画面イメージとしては以下です。My Privileged Accessタブから「Server」を押下すると、RDP可能なサーバーが表示されている状態です。
サーバー名を押下すると、RDPに使用できる保護アカウントが一覧になって表示されています。
今記事ではポリシーの作成方法は省略し、ルールの作成から行います。以下ドキュメントも参考にしてください。
help.okta.com
セキュリティルールを作成する
プリンシパル対象のユーザーに、サーバーに対しRDP可能なADアカウントを表示させます。「Connect」ボタンを押すと実際にそのユーザー情報でRDPが可能になります。
作成したセキュリティポリシーから「Active Directory Account」ルールを選択します。前のルールに追加する形でもよいかもしれませんが、管理の面から分けることをおすすめいたします。
ルール作成例
今回は以下のように作成しました。
Permissions for accountsでRDP Sessionを定義しました。これにより、このルールでは保護されたADアカウント情報を使用したRDP接続を制御します。
その他の設定意図は以下をご参照ください。
| 設定項目名 | 設定意図 |
|---|---|
| Select shared accounts by specific account names | このルールで保護するアカウントを指定。今回はアカウント名を明示的に指定。 |
| Multifactor authentication | このルールで保護したアカウントの情報を使用する際にMFAを要求するように設定。 MFAの要求要素は2要素、また次回MFA要求までに1時間の猶予を指定。 |
今回、サーバールールでのRDP制御ではなくActive Directory アカウントルールでのRDP制御を行いました。サーバールールでの制御とActive Directoryアカウントルールでの制御の違いは、対象とするアカウントの違いにあります。
サーバールールで対象とする保護リソースはActive Directoryではなくサーバーローカルのアカウントのため、ここでセキュリティポリシーを定義しても利用可能なアカウントとして表示されません。
今回はADアカウントを使ったRDPセッションを定義するため、Active Directory アカウントルールで対象サーバーとアカウントを同時にセットアップしました。
終わりに
OPAにサーバーを登録してからRDP行うための一連のやり取りを記載させていただきました。いかがだったでしょうか。
次ブログでは、Access Requestsなど別機能も組み合わせ、Entra IDでいう「PIM」に近しい実装をご紹介できればと思います。現在の設定は恒常的にOkta Privileged Accessに特権アカウントが割り当たっている状態で、言い換えればパスワード閲覧ができればいつでもドメインコントローラーにRDPできてしまいます。これを時間式にし、セルフアクセスをによってアクセスを管理できるように設定するやり方をご紹介します。
▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼
ネットワールドが開催する 年に一度の大イベント
【 Networld Wiz 2026 】お申込み受付中！！
本ブログでご紹介したメーカーもイベントへ出展します！
セッション & ブース出展情報 随時更新中
▼ぜひチェックしてください▼
おまけ トラブルシューティング
ドメインコントローラーで管理しているADアカウントが一部同期されない
→ADアカウントに姓と名を与える、もしくはUDでのマッピングルールを変更する。
Oktaではデフォルトの基本必須属性が姓・名・メールアドレス・ログイン(Okta内一意のID)ですが、ADアカウントの必須属性に姓と名はありません。姓・名が存在しないアカウントがインポートされた場合でも対応できるように設定が必要です。Okta UDにおいては姓と名を必須属性としない設定が可能ですが、OPA及びこの後使用するAccess Requestでは姓と名が必須のため、「N/A」という文字列を記入するという対応をとります。
まずはOkta UDにて姓と名を必須属性でないようにする設定を追加します。以下ドキュメントを参考にしてください。
help.okta.com
設定終了後、マッピングルールの設定を行います。引き続きAdmin Consoleからディレクトリ > Profile Editorへと遷移し、「Okta Access Requests User」「Okta Privileged Access User」の「マッピング」を押下します。。※どちらにも同じ動作を行うため、優先度に変更はありません。
上タブを「Okta Userから[アプリ名]」に変更したことを確認してください。
givenName、firstNameをそれぞれ以下のように変更します。
【givenName】
String.len(user.firstName) > 0 ? user.firstName : "N/A"
【firstName】
String.len(user.lastName) > 0 ? user.lastName : "N/A"
この拡張言語の意味は「入力された値が空欄なら「N/Aを入力する」です。実際に姓と名が空欄のユーザーで試すと、姓・名に「N/A」という入力が自動でされるようになります。
初期設定[Administrator]アカウントがインポートできない
→isCriticalSystemObject」属性がTrueとなっている可能性がある
確認可能コマンドは以下となります。
Get-ADUser Administrator -Properties isCriticalSystemObject | Select-Object Name,isCriticalSystemObject
この属性がTrueの場合、Oktaはこのアカウントをインポートすることができず、したがってOPAでのパスワード管理は不可となります。
属性が「False」になっているユーザーを管理対象として設計しなおす必要があります。
詳しくは以下ドキュメントをご参照ください。
support.okta.com
ローテーションするパスワードをもう少し短くしたい
→プロジェクトにて文字数・使用文字種類を設定可能。
前記事にてご紹介が漏れていた設定となります。
リソース管理者権限を持ったユーザーでログインします。
Resource Administration > Resource Management と遷移し、ADアカウントを管理しているプロジェクトを開きます。
「Setting」を押下すると、パスワードの複雑さや長さ、ローテーションのタイミングを調整することができます。
