Active Directory統合の前提条件

このトピックでは、Active Directory（AD）統合の前提条件について説明します。

ハードウェア

Okta AD Agentをインストールするには、少なくとも1つのWindowsサーバーが必要です。このサーバーはホストサーバーと呼ばれます。このホストサーバーは、Oktaと通信できるように常に稼働し、インターネットに常時接続している必要があります。

  • ホストサーバーは、物理サーバーと仮想サーバーのどちらでもかまいません。
  • サーバーには、2つ以上のCPUと8GB以上のRAMが必要です。

オペレーティングシステムとソフトウェア

ホストサーバーに最新バージョンのOkta AD Agentをダウンロードしてインストールします。これにより、最新の機能を確実に利用でき、最適なパフォーマンスが得られます。複数のOkta AD Agentを実行しているときは、すべてを同一バージョンにします。ドメイン内で異なるバージョンを実行すると、そのドメイン内のすべてのエージェントが、最も古いエージェントのレベルで動作する可能性があります。その他のドメインは影響を受けません。

  • Windows Server 2016、Windows Server 2019、Windows Server 2022、またはWindows Server 2025を実行しているホストサーバー（Host server running Windows Server 2016, Windows Server 2019, Windows Server 2022, or Windows Server 2025）：Okta AD Agentをインストールするには、Windowsサーバーへのアクセス権が必要です。ドメインコントローラーにエージェントをインストールする必要はありません。エージェントのインストール時に作成されるADサービスアカウント用に、システムに20MBのメモリが必要です。

  • .NET 4.6.2以降。以前のバージョンの.NETを使用しているときは、4.6.2以降にアップグレードしてください。

  • AD統合のセキュリティ向上のために、.NET Framework 4.5以降を実行しているorgのデフォルトのセキュリティプロトコルはTLS 1.2です。
  • ADドメイン/フォレストの機能レベル（AD domain/forest functional level）：Oktaは、ADドメイン/フォレストの2003以降の機能レベルをサポートします。「フォレスト/ドメインの機能レベル」を参照してください。

    ADドメインの2003の機能レベルを使用する場合、ADユーザー名はドメイン名の形式である必要があります。つまり、ユーザーは、@domain.nameという形式が含まれるUPNを持つ必要がります。

  • メンバーサーバー（Member server）：ホストサーバーは、ADドメインのメンバーサーバーとドメインコントローラーのどちらでもかまいません。メンバーサーバーを使用することをお勧めします。Okta

  • ホストサーバーからセットアップウィザードを実行（Run the setup wizard from the host server）：エージェントをインストールするホストサーバー上で、Webブラウザーを使ってエージェントセットアップウィザードを実行します。この推奨事項に従わないときは、エージェントインストーラーをホストサーバーに転送して実行する必要があります。

  • Active Directoryフォレスト内のメンバーサーバーである必要がある（Must be a member server within your active directory forest）：ホストサーバーは、ユーザーが存在するドメインとは異なるドメインに存在できますが、同じADフォレスト内に存在する必要があります。エージェントを別のドメインに配置すると、パフォーマンスの問題が生じる可能性があります。
  • ADパスワード履歴ポリシー（AD password history policy）：このポリシーを適用するには、バージョン3.4.1以降のOkta AD Agentを使用する必要があり、ADドメインの機能レベルがWindows Server 2016以降である必要があります。
  • 高可用性（High availability）：高可用性と冗長性を確保するには、2台以上のコンピューターにエージェントをインストールします。
  • エージェント数（Number of agents）：3万人以上のユーザーがいるときは、少なくとも3つのAD Agentをデプロイします。

次の事項を決める必要もあります。

  • ADユーザーをOktaにインポートする際に使用するユーザー名の形式（メールアドレス、samAccountName、UPN、またはカスタム）。
  • ユーザーとグループのインポート元のOU。
  • OktaユーザープロファイルにインポートするAD属性。

必要なアカウント

  • 必要な権限を備えたOktaアカウント：AD Agentをインストールするために必要な権限と、AD AgentにOktaとの接続を許可するために必要な権限を備えたアカウントでOktaにサインインします。このアカウントは、ADではなくOktaをソースとする必要があります。
  • Okta AD Agentインストーラーを実行するためのAD管理者アカウント：Okta AD Agentインストーラーの実行に必要です。エージェントが接続するドメイン内のユーザーデータの読み取りとアクセスのために、このアカウントにはフォレスト内のすべてのドメインの権限が必要です。
  • Okta AD Agentサービスを実行するためのOktaサービスアカウント：これはADドメインサービスまたはユーザーアカウントです。インストール時に、このアカウント（デフォルトではOktaService）をインストーラーに作成させるか、既存のアカウントを自分で選択するかを選択できます。エージェントが接続するドメイン内のユーザーデータの読み取りとアクセスのために、Oktaサービスアカウントにはフォレスト内のすべてのドメインの権限が必要です。すべてのOkta AD Agentのインストールに同じADサービスアカウントを使用することをお勧めします。

必要な権限を持つOktaアカウント

エージェントをインストールするには、ディレクトリの管理、エージェントの管理、エージェントの登録の権限を持つアカウントを使用する必要があります。ベストプラクティスは、これらの権限を持つカスタム管理者ロールを作成することです。ロールをOktaアカウントに割り当てて、エージェントをOktaに接続します。ロールを作成（Create a role）とエージェント権限を参照してください。

バージョン3.18.0以降のAD Agentは、どのOktaアカウントからも独立して動作します。これにより、Okta AD統合は、エージェントの登録に使われたアカウントのステータスに関係なく想定どおりに機能し続けます。たとえば、バージョン3.17.0以前では、エージェントの登録には専用アカウントがよく使用されました。そのアカウントの権限が変更される（低下、失効など）、またはアカウントが非アクティブ化されると、AD Agentは動作を停止します。

Okta AD Agentインストーラーを実行するためのAD管理者アカウント

エージェントのインストール時に、Oktaサービスアカウントをインストーラーに作成させるかどうかの確認が求められます。選択に応じて、次のいずれかが必要になります。

  • Oktaサービスアカウントをインストーラーに作成させる場合は、ADドメインの管理者アカウント。
  • 既存のドメインユーザーアカウントをOktaサービスアカウントとして使用する場合は、ホストサーバーのローカル管理者権限を持つADユーザーアカウント。
  • インストール時に指定した代替アカウントを使用（Use an alternate account that I specify）オプションを選択したときは、ADユーザーアカウントにOUへの読み取りアクセス権が必要です。この要件は、OktaServiceアカウントにも適用されます。

Okta AD Agentサービスを実行するためのADドメインユーザーアカウント

インストール時にOktaサービスアカウントをインストーラーに作成させることを選択できます。デフォルトでは、これはOktaServiceと呼ばれます。既存のドメインユーザーアカウントを使用するときは、アカウントのパスワードが期限切れにならないように、有効期限なしに設定してください。Okta AD Agentは、バージョン3.6.0以降の管理対象サービスアカウントをサポートします。

インストール時にOktaサービスアカウントをインストーラーに作成させるには、次の要件を満たす必要があります。

  • ドメイン管理者グループのメンバーであること。AD Agentサービスアカウントとして機能するADユーザーを作成できる必要があるため、この権限が必要になります。
  • ローカル管理者権限があること。AD Agentをインストールしているが、既存のユーザーアカウントを使ってサービスアカウントとして実行している場合に必要なのは、ローカル管理者権限のみです。

いずれのオプションでも、選択したドメインユーザーに対してインストーラーはサービスとしてログオン（logon as a service）権限を付与します。

Oktaサービスアカウントの権限

AD Agentは、指定したOktaアカウント（インストーラーが作成するOktaサービス（OktaService）アカウント、またはエージェントのインストール時に選択したドメインユーザー）で実行されます。

統合の構成に応じて、エージェントは次のアクションを実行します。

  • ユーザー、OU、グループを読み取る（Read users, OUs, and groups）：アクセスするオブジェクトに対する読み取りアクセス権が必要です。ドメインユーザーには、そのための十分な権限がデフォルトで付与されます。ドメイン全体に対する読み取りアクセス権が推奨されますが、必須ではありません。
  • ユーザーを認証（Authenticate users）：特別な権限は必要ありません。
  • Change user passwords (by supplying the current password（（現在のパスワードを指定して）ユーザーパスワードを変更）（Change user passwords (by supplying the current password)）：特別な権限は必要ありません。
  • Set user passwords (administratively, without the current password)（（管理上、現在のパスワードレスで）ユーザーパスワードを設定）：ユーザーのパスワードを設定する権限が必要です。
  • Oktaからプッシュされた値を使ってADでユーザー、属性、メンバーシップを作成、更新（Create and update users, attributes, and memberships in AD with values pushed from Okta）：更新する属性の読み取りおよび書き込み権限が必要です。

Oktaサービスアカウントの委任を構成する

Windowsサーバーで、必要に応じてOktaサービスアカウントへの委任をADドメインに構成する必要があります。

  1. ADドメインコントローラーで、Active Directoryのユーザーとコンピューター（Active Directory Users and Computers）スナップインを開きます。
  2. OUまたはドメイン名（domain name）を右クリックし、制御の委任（Delegate Control）を選択します。
  3. 制御の委任ウィザードでOktaサービスアカウントを追加し、委任するタスクを選択します。

    • ユーザーアカウントを作成、削除、管理（Create, delete, and manage user accounts）：ユーザーフローの作成と更新向け。

    • ユーザーパスワードをリセットし、次回ログオン時にパスワードの変更を強制（Reset user passwords and force password change at next logon）：パスワードの同期向け。

    • すべてのユーザー情報の読み取り（Read all user information）：ユーザーフローのインポート、作成向け。

    • グループのメンバーシップを変更（Modify the membership of a group）：グループプッシュ向け。

関連項目

Okta Active Directory Agentをインストールする

Oktaサービスアカウントの権限