Active Directory統合の前提条件

この項目では、Active Directory(AD)統合の前提条件について説明します。

ハードウェア

Okta ADエージェントをインストールするには、1台以上のWindows Serverが必要です。このサーバーはホストサーバーと呼ばれます。ホストサーバーは、Okta と通信できるように、常に電源が入っていてインターネットに接続された状態である必要があります。

  • ホストサーバーは物理サーバーでも仮想サーバーでもかまいません。
  • このサーバーには、少なくとも2基のCPU、8GBのRAMが必要です。

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

Okta ADエージェント の最新バージョンをホストサーバーにダウンロードしてインストールすることで、 最新の機能を活用し、最適なパフォーマンスを発揮できるようにします。複数のOkta ADエージェントを実行している場合は、そのすべてが同じバージョンになるようにしてください。同じドメイン内で異なるバージョンが実行されると、そのドメイン内のすべてのエージェントの機能が、最も古いバージョンと同程度に制限される可能性があります。別のドメインにその影響が及ぶことはありません。

  • Oktaは、Windows Server 2012 R2、Windows Server 2016、Windows Server 2019以降のいずれかをホストサーバーにインストールすることを推奨しています — Okta ADエージェントをインストールするには、Windows Serverへのアクセス権が必要です。ドメインコントローラーにエージェントをインストールする必要はありません。システムには、エージェントのインストール時に作成されるADサービスアカウント用のメモリが少なくとも 20MB必要です。
    注: Windows ServerでIE 10以降を実行している必要があります。
  • .NET 4.5.2 以降。 .NETのバージョンがそれよりも古い場合は、4.5.2以降にアップグレードします。

  • .NET Framework 4.5 以降を実行している環境ではデフォルトのセキュリティプロトコルに TLS 1.2 を使用し、AD 統合のセキュリティを向上させています。Windows 2008 R2では、TLS 1.2がデフォルトで無効にされているため、レジストリを介してこれを有効にする必要があります。
  • ADドメイン/フォレストの機能レベル — Oktaは、ADドメイン/フォレストの2003以上の機能レベルをサポートしています。ADドメインの機能レベルの詳細については、以下をご覧ください: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/understanding-active-directory-domain-services--ad-ds--functional-levels
    • 使用しているADドメインの機能レベルが2003の場合は、ADユーザー名をドメイン名の形式にする必要があります。つまり、ユーザーに@domain.nameの形式を持つUPN が付与されている必要があります。
  • メンバーサーバー — ホストサーバーを、ADドメインのメンバーサーバーやドメインコントローラーにできます。メンバーサーバーの使用を推奨します。
  • ホストサーバーでのセットアップウィザードの実行 – エージェントをインストールするホストサーバーのウェブブラウザで、エージェントセットアップウィザードを実行します。この推奨手順に従わない場合は、エージェントインストーラーをホストサーバーに転送して、そこでインストーラーを実行する必要があります。

  • 必ず同じActive Directoryフォレスト内のメンバーサーバーにすること — ホストサーバーは、ユーザーが属するドメインとは異なるドメインにも配置できますが、同じADフォレスト内に属している必要があります。エージェントを別のドメインに配置すると、性能面に影響が及ぶおそれがあります。
  • AD のパスワード履歴に関するポリシー — ADのパスワード履歴に関するポリシーを適用するには、Okta ADエージェントのバージョン3.4.1以降を使用し、ADドメインの機能レベルをWindows Server 2012 R2以上に設定する必要があります。
  • 高可用性 — 高可用性と冗長性を確保するには、2台以上のコンピューターにエージェントをインストールします。
  • エージェントの数 — ユーザーの数が30,000以上の場合は、少なくとも3つのADエージェントをデプロイします。

その他、以下の事項を決定する必要があります。

  • AD ユーザーを Okta にインポートする際に使用するユーザー名の形式(メールアドレス形式、samAccountName 形式、UPN 形式、または任意のカスタマイズした形式)
  • ユーザーおよびグループのインポート元となる組織単位(OU)
  • Okta のユーザープロファイルにインポートする AD 属性

必須アカウント

  • Okta管理者アカウント — ADエージェントをインストールする際に、そのADエージェントがOktaに接続できるようにするために使用します。このアカウントのソースはADではなく、Oktaである必要があります。このアカウントには、少なくともスーパー管理者の権限が必要です。
  • ドメイン管理者の権限を持つADユーザーアカウント — Okta ADエージェントインストーラーの実行に必要です。Oktaは、同じADサービスアカウントを使用してすべてのOkta ADエージェントをインストールすることを推奨しています。インストールの実行中に、Oktaサービスアカウントを作成するかどうかの確認が表示されます。
  • Okta ADエージェントサービスを実行するOktaサービスアカウント — これは、ADドメインサービスかユーザーアカウントです。インストーラーで作成(デフォルト名がOktaService)することも、 既存のアカウントを選択することもできます。重要なのは、Oktaサービスアカウントの権限が対象フォレスト内の全ドメインに及ぶもので、エージェントの接続先である全ドメインのユーザーデータに対するアクセスと読み取りが可能であるという点です。

Okta管理者アカウントの作成

インストール時にADエージェントをOktaに接続するために必要なアカウントは、ADアカウントではなくOktaアカウントです。このアカウントを作成するには、スーパー管理者の権限が必要です。

Oktaは、ADエージェントに専用のOkta管理者アカウントを使用することを推奨しています。個人のスーパー管理者アカウントでADエージェントをインストール、実行している場合で、その個人の管理者権限が降格されたり、取り消されたり、ディアクティベートされた場合、Okta AD統合は機能しなくなります。これが発生した場合、既存のADエージェントをアンインストールして、新しいスーパー管理者アカウントでADエージェントを再インストールしてOktaをADに再接続する必要があります。

  1. Oktaスーパー管理者アカウントにサインインします。
  2. [Admin(管理者)]をクリックしてOkta管理コンソールを開きます。
  3. [Directory(ディレクトリ)]>[People(ユーザー)]>[Add Person(ユーザーを追加)]の順にクリックします。
  4. フィールドに入力して[Save(保存)]をクリックします。
  5. [Security(セキュリティ)]> [Administrators(管理者)]>[Add Administrator(管理者を追加)]の順にクリックします。
    1. Grant Administrator role toフィールドに、手順3で追加したユーザーの名前を入力して、そのユーザーをリストから選択します。
    2. ユーザーに付与する管理者ロールを選択します。エージェントのインストールには、少なくともスーパー管理者のロールが必要です。管理者権限について詳しくは、管理者をご覧ください。

Oktaは、ADではなくOktaをソースとして使用するOkta ADエージェント管理者アカウントを推奨しています。これは、ADをソースとする既存の管理者に影響しません。管理者をADから切断することをおすすめします( [Directory(ディレクトリ)]> [People(ユーザー)] >[More Actions(その他のアクション)]> [Disconnect from AD(ADから切断)]を選択して、切断する管理者ユーザーを選択して、[Disconnect Selected(選択したユーザーを切断)]をクリックします)。

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

Oktaは、同じADサービスアカウントを使用してすべてのエージェントをインストールすることを推奨しています。エージェントのインストール時、Oktaサービスアカウントをインストーラーで作成するかどうかの確認が表示されます。選択に応じて、以下のいずれかが必要になります:

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

Okta ADエージェントサービスを実行するOktaサービスアカウント

Oktaサービスアカウントはインストーラーで作成できます。デフォルトで、このアカウントはOktaServiceという名前になります。既存のドメインユーザーアカウントを使用するように選択した場合は、アカウントパスワードを期限なしに設定するようにします。マネージドサービスアカウントは、Okta ADエージェントバージョン3.6.0以降でサポートされます。

インストール時、Oktaサービスアカウントをインストーラーで作成するかどうかの確認が表示されます。これを行うには、次の権限を持っている必要があります:

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

いずれのオプションでも、インストーラーは選択したドメインユーザーにサービスとしてのログオンを許可します。

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

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

  • ユーザー、OU、グループの読み取り — アクセス対象のオブジェクトに対する読み取りアクセス権が必要です。デフォルトで、ドメインユーザーはこれを行うための十分な権限を持っています。ドメイン全体に対する読み取りアクセス権を推奨しますが、必須ではありません。
  • ユーザーの認証 — 特別な権限は必要ありません。
  • 現在のパスワードを提供してユーザーパスワードを変更する — 特別な権限は必要ありません。
  • 管理者として、現在のパスワードを提供せずにユーザーパスワードを設定する — ユーザーのパスワードを設定する権限が必要です。
  • Oktaからプッシュされた値で、ADのユーザー、属性、メンバーシップの作成、アップデートを行う — アップデートする属性の読み取りと書き込みを行う権限が必要です。

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

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

  1. ADドメインコントローラーで、[Active Directory Users and Computers(Active Directoryユーザーとコンピューター)]スナップインを開きます。
  2. [OU]または[domain name(ドメイン名)]を右クリックして、[Delegate Control(管理の委任)]を選択して[Delegation of Control(管理の委任)]ウィザードを開きます。
  3. Oktaサービスアカウントを追加して、委任する適切なタスクを選択します:
    • ユーザーアカウントの作成、削除、管理 — ユーザーフローの作成とアップデート用。

    • ユーザーパスワードのリセットと、次回ログイン時のパスワード変更の強制 — パスワードの同期用。

    • すべてのユーザー情報の読み取り — ユーザーフローのインポート、作成用。

    • グループのメンバーシップの変更 — グループプッシュ用。