Windowsドメインコントローラー
Okta Privileged AccessサーバーエージェントをWindowsドメインコントローラーにインストールできます。そうすると、サーバーはActive Directory（AD）環境に接続して特権アカウントを検出し、管理者はOkta Privileged Accessポリシーを使用してこれらのアカウントへのアクセスを管理できるようになります。
Okta Privileged AccessとADの統合
ADアカウント管理とドメインコントローラーへのアクセスには、Okta Privileged AccessのADアカウントルール内で特定の構成が必要です。Okta Privileged Accessを介したドメインコントローラーへのRDPアクセスを有効にするには、Okta Privileged Access ADアカウントルール内で次の構成が必要です。
-
ADアカウントはOkta Privileged Accessで管理されている必要があります。
-
必要なADアカウントとターゲットドメインコントローラーサーバーの両方を、ルール内で明示的に構成する必要があります。
RDPでサインインするには、グループポリシーまたはその他の仕組みによって、ADアカウントにRDP権限が付与されている必要があります。
ADにおけるOkta Privileged Accessサーバーエージェントのスコープ
AD環境が中断する可能性を最小限に抑えるため、OktaではドメインコントローラーやADグループ（管理者など）がサーバーエージェントによって変更されるのを防ぎます。
-
ドメインコントローラーへのアクセスは、既存のドメインアカウントと権限を通じてのみ管理されます。個々のOktaユーザーアカウントは、サーバー上で作成も削除もされません。たとえば、トラブルシューティングのためにユーザーに一時的なサーバーアクセスを付与するポリシーをorgに用意することができます。ただし、このポリシーはドメインコントローラーに適用することはできません。この場合に、サーバーエージェントは個々のOktaユーザーアカウントを作成しないためです。
-
Okta Privileged Accessサーバーエージェントは、ドメインコントローラーをスキャンしてドメインアカウントのパスワードを識別または管理することはありません。
-
ドメインローカルグループ管理者とリモートデスクトップユーザーは変更できず、他のグループは影響を受けません。
Okta Privileged AccessがWindowsサーバーで永続アカウントをプロビジョニングする際に、ユーザーのOUにWindowsユーザー名が一致するActive Directory（AD）ユーザーがいるかを確認します。一致がある場合、Okta Privileged Accessは直ちにADオブジェクトを制御し、パスワードを変更して、ADからの直接サインイン試行をブロックします。その時点から、ユーザーはOkta Privileged Accessを介して環境にアクセスする必要があります。ドメインコントローラーでADユーザーとして、またメンバーサーバーでローカルユーザーとしてサインインできます。
この変更された動作により、Okta Privileged Accessサーバーエージェントは、ローカルグループ管理者などのドメインコントローラーやADグループを変更できなくなります。ただし、これらのデフォルト設定は、sftd.yaml構成ファイルを使って上書きできます。「Okta Privileged Accessサーバーエージェントを構成する」を参照してください。