Active Directory統合の前提条件

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

ハードウェア

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

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

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

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

  • ホストサーバーには、Windows Server 2012、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ドメイン/フォレストの機能レベル：Oktaは、2003以降のADドメイン/フォレストの機能レベルをサポートしています。ADドメインの機能レベルの詳細については、次を参照してください：https://docs.microsoft.com/ja-jp/windows-server/identity/ad-ds/plan/security-best-practices/understanding-active-directory-domain-services--ad-ds--functional-levels
    • 2003のADドメインの機能レベルを使用する場合、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パスワード履歴ポリシー）：ADパスワード履歴ポリシーを適用するには、バージョン3.4.1以降のOkta ADエージェントを使用する必要があり、ADドメインの機能レベルはWindows Server 2012 R2以降である必要があります。
  • High availability（高可用性）：高可用性と冗長性を確保するには、エージェントを2台以上のコンピューターにインストールします。
  • Number of agents（エージェントの数）：3万人以上のユーザーがいる場合は、最低3つのADエージェントをデプロイします。

以下も決める必要があります。

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

必要なアカウント

  • Oktaカスタム管理者アカウント：ADエージェントがOktaに接続できるように、ADエージェントをインストールする場合に使用します。このアカウントは、ADソースではなくOktaソースである必要があります。
  • ドメイン管理者権限を持つADユーザーアカウント：Okta ADエージェントのインストーラーを実行するために必要です。同じADサービスアカウントを使用してすべてのOkta ADエージェントをインストールすることをお勧めします。インストール中に、Oktaサービスアカウントを作成するかどうか尋ねられます。
  • Okta AD Agentサービスを実行するためのOktaサービスアカウント：これはADドメインサービスまたはユーザーアカウントです。インストーラーで（デフォルトでOktaServiceと呼ばれます）で作成することも、既存のアカウントを選択することもできます。Oktaサービスアカウントは、エージェントが接続するすべてのドメインでユーザーデータの読み取りとアクセスを行うために、そのフォレスト内のすべてのドメインで権限を持っていることが重要になります。

カスタム管理者アカウントを作成する

カスタム管理者は、エージェントを表示、登録、管理できます。インストールでは、ADエージェントをOktaに接続するために、Active Directory（AD）アカウントではなくOktaカスタム管理者アカウントが必要です。「カスタム管理者ロール」を参照してください。

ADエージェント専用のカスタム管理者アカウントを使用することをお勧めします。個人のスーパー管理者アカウントを使用してADエージェントをインストールおよび実行し、その個人の管理者権限が後で低下したり取り消されたり、非アクティブ化された場合、Okta AD統合が機能しなくなります。このような場合、OktaをADに再接続するには、既存のADエージェントをアンインストールし、新しいスーパー管理者アカウントでADエージェントを再インストールする必要があります。

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

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

同じADサービスアカウントを使用してすべてのエージェントをインストールすることをお勧めします。エージェントのインストール中に、インストーラーでOktaサービスアカウントを作成するかどうか尋ねられます。選択に応じて、次のいずれかが必要です。

  • インストーラーにOktaサービスアカウントの作成を許可する場合は、ADドメインの管理者アカウント。
  • 既存のドメインユーザーアカウントをOktaサービスアカウントとして使用する場合は、ホストサーバーのローカル管理者権限を持つADユーザーアカウント。

  • セットアップで［Use an alternate account that I specify（指定した代替アカウントを使用）］を選択した場合、ADユーザーアカウントには、OktaServiceアカウントを含むOUへの読み取りアクセス権が必要です。

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

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

インストール中に、インストーラーでOktaサービスアカウントを作成するかどうか尋ねられます。これを行うには、次の権限が必要です。

  • ドメイン管理者グループのメンバーであること。ADエージェントサービスアカウントとして機能する新しい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サーバーで、必要に応じてADドメインでOktaサービスアカウントへの委任を構成する必要があります。

  1. ADドメインコントローラーで、［Active Directory Users and Computers（Active Directoryユーザーとコンピューター）］スナップインを開きます。
  2. OUまたはdomain name（ドメイン名）を右クリックし、［Delegate Control（制御の委任）］を選択します。
  3. ［Delegation of Control（オブジェクト制御の委任）］ウィザードで、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（グループのメンバーシップを変更する）］：グループプッシュ用。