Active Directory統合の前提条件

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

ハードウェア

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

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

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

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

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

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

  • AD統合のセキュリティ向上のために、.NET Framework 4.5以降を実行しているorgのデフォルトのセキュリティプロトコルはTLS 1.2です。
  • ［AD domain/forest functional level（ADドメイン/フォレストの機能レベル）］：Oktaは、ADドメイン/フォレストの2003以降の機能レベルをサポートします。「フォレスト/ドメインの機能レベル」を参照してください。
    • ADドメインの2003の機能レベルを使用する場合、ADユーザー名はドメイン名の形式である必要があります。つまり、ユーザーは、@domain.nameという形式が含まれるUPNを持つ必要がります。
  • ［Member server（メンバーサーバー）］：ホストサーバーは、ADドメインのメンバーサーバーとドメインコントローラーのどちらでもかまいません。メンバーサーバーを使用することをお勧めします。

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

  • ［Must be a member server within your active directory forest（Active Directoryフォレスト内のメンバーサーバーである必要がある）］：ホストサーバーは、ユーザーが存在するドメインとは異なるドメインに存在できますが、同じADフォレスト内に存在する必要があります。エージェントを別のドメインに配置すると、パフォーマンスの問題が生じる可能性があります。
  • ［AD password history policy（ADパスワード履歴ポリシー）］：このポリシーを適用するには、バージョン3.4.1以降のOkta AD３エージェントを使用する必要があり、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エージェントのインストールに同じADサービスアカウントを使用することをお勧めします。

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

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

ADエージェントを使ってアプリインスタンスを作成するには、ディレクトリ権限が必要です。「ロールの権限」を参照してください。

セキュリティ向上のために、Admin Consoleにアクセスする管理者にMFAの使用を義務づけてください。「Admin ConsoleへのアクセスにMFAを強制適用する」を参照してください。

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

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

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

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

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

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

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

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

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

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

ADエージェントは、指定したOktaアカウント（インストーラーが作成する［OktaService］アカウント、またはエージェントのインストール時に選択したドメインユーザー）で実行されます。統合の構成に応じて、エージェントは次のアクションを実行します。

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

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

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

  1. ADドメインコントローラーで、［Active Directory Users and Computers（Active Directoryのユーザーとコンピューター）］スナップインを開きます。
  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（グループのメンバーシップを変更）］：グループプッシュ向け。