Active Directory統合の前提条件
このトピックでは、Active Directory(AD)統合の前提条件について説明します。
ハードウェア
Okta ADエージェントをインストールするには、1つ以上のWindowsサーバーが必要です。このサーバーはホストサーバーと呼ばれます。このホストサーバーは、Oktaと通信できるように常に稼働していて、インターネットに常時接続している必要があります。
- ホストサーバーは、物理サーバーまたは仮想サーバーのどちらでもかまいません。
- サーバーには、2つ以上のCPUと8GB以上のRAMが必要です。
オペレーティングシステムとソフトウェア
ホストサーバーに最新バージョンのOkta ADエージェントをダウンロードしてインストールし、最新の機能を利用可能にして最適なパフォーマンスが得られるようにします。複数のOkta ADエージェントを実行している場合は、それらがすべて同じバージョンであることを確認してください。ドメイン内で異なるバージョンを実行すると、そのドメイン内のすべてのエージェントが、最も古いエージェントのレベルで機能することになる可能性があります。これは、ほかのドメインには影響しません。
- ホストサーバーには、Windows Server 2012、Windows server 2012 R2、Windows Server 2016、Windows Server 2019、Windows server 2022をインストールすることをお勧めします:Okta ADエージェントをインストールするには、Windowsサーバーにアクセスする必要があります。ドメインコントローラーにエージェントをインストールする必要はありません。エージェントのインストール時に作成されるADサービスアカウント用に、システムに20MBのメモリが必要です。
注:Windows ServerでIE 10以降を実行している必要があります。 -
.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を持つ必要があるということです。
- メンバーサーバー:ホストサーバーは、ADドメインのメンバーサーバーまたはドメインコントローラーのどちらでもかまいません。メンバーサーバーの使用を推奨します。
-
ホストサーバーからセットアップウィザードを実行します:エージェントをインストールするホストサーバー上で、Webブラウザーを使ってエージェントセットアップウィザードを実行します。この推奨方法を用いない場合は、エージェントインストーラーをホストサーバーに転送して実行する必要があります。
- Active Directoryフォレスト内のメンバーサーバーである必要があります:ホストサーバーは、ユーザーが存在するドメインとは異なるドメインに存在できますが、同じADフォレスト内に存在している必要があります。エージェントを別のドメインに配置すると、パフォーマンスの問題が発生する可能性があります。
- ADパスワード履歴ポリシー:ADパスワード履歴ポリシーを適用するには、バージョン3.4.1以降のOkta ADエージェントを使用する必要があり、ADドメインの機能レベルはWindows Server 2012 R2以降である必要があります。
- 高可用性:高可用性と冗長性を確保するには、エージェントを2台以上のコンピューターにインストールします。
- エージェントの数:3万人以上のユーザーがいる場合は、最低3つのADエージェントをデプロイします。
以下も決める必要があります。
- ADユーザーをOktaにインポートするときに使用するユーザー名の形式(メールアドレス、samAccountName、UPN、またはカスタム)。
- ユーザーとグループのインポート元のOU。
- OktaユーザープロファイルにインポートするAD属性。
必要なアカウント
- Okta管理者アカウント:ADエージェントをインストールして、ADエージェントがOktaに接続できるようにするときに使用します。このアカウントは、ADソースではなくOktaソースである必要があります。このアカウントタイプにはスーパー管理者権限が必要です。
- ドメイン管理者権限を持つADユーザーアカウント:Okta ADエージェントのインストーラーを実行するために必要です。同じADサービスアカウントを使用してすべてのOkta ADエージェントをインストールすることをお勧めします。インストール中に、Oktaサービスアカウントを作成するかどうか尋ねられます。
- Okta AD Agentサービスを実行するためのOktaサービスアカウント:これはADドメインサービスまたはユーザーアカウントです。インストーラー(デフォルトでOktaServiceと呼ばれます)で作成することも、既存のアカウントを選択することもできます。Oktaサービスアカウントは、エージェントが接続するすべてのドメインでユーザーデータの読み取りとアクセスを行うために、そのフォレスト内のすべてのドメインで権限を持っていることが重要になります。
Okta管理者アカウントを作成する
インストール時には、ADエージェントをOktaに接続するため、ADアカウントではなくOktaアカウントが必要です。このアカウントを作成するには、スーパー管理者である必要があります。
ADエージェント専用のOkta管理者アカウントを使用することをお勧めします。個人のスーパー管理者アカウントを使用してADエージェントをインストールおよび実行し、その個人の管理者権限が後で低下したり取り消されたり、非アクティブ化された場合、Okta AD統合が機能しなくなります。このような場合、OktaをADに再接続するには、既存のADエージェントをアンインストールし、新しいスーパー管理者アカウントでADエージェントを再インストールする必要があります。
- Oktaスーパー管理者アカウントにサインインします。
- [Admin(管理者)]をクリックして、Okta Admin Consoleを開きます。
- [Directory(ディレクトリ)]>[People(ユーザー)]>[Add Person(ユーザーを追加)]をクリックします。
- フィールドに入力して、[保存]をクリックします。
- [Security(セキュリティ)]>[Administrators(管理者)]>[Add Administrator(管理者を追加)]をクリックします。
- [Grant Administrator role to field(管理者ロールを以下に付与):]フィールドで、手順3で追加したユーザーの名前の入力を開始し、リストからユーザーを選択します。
- [Super Administrator(スーパー管理者)]を選択します。管理者権限の詳細については、「管理者」を参照してください。
Okta ADエージェントの管理者アカウントは、ADソースではなくOktaソースにすることをお勧めします。これは、既存のADソースの管理者には影響しません。また、管理者をADから切断することをお勧めします([Directory(ディレクトリ)]>[People(ユーザー)]>[More Actions(その他のアクション)]>[Disconnect from AD(ADから切断)]を選択し、切断する管理者ユーザーを選択して、[Disconnect Selected(選択したものを切断)]をクリックします)。
Okta ADエージェントインストーラーを実行するためのADサービスアカウント
同じADサービスアカウントを使用してすべてのエージェントをインストールすることをお勧めします。エージェントのインストール中に、インストーラーでOktaサービスアカウントを作成するかどうか尋ねられます。選択に応じて、次のいずれかが必要です。
- インストーラーにOktaサービスアカウントの作成を許可する場合は、ADドメインの管理者アカウント。
- 既存のドメインユーザーアカウントをOktaサービスアカウントとして使用する場合は、ホストサーバーのローカル管理者権限を持つADユーザーアカウント。
-
セットアップで[Use an alternate account that I specify(指定した代替アカウントを使用)]を選択した場合、ADユーザーアカウントには、OktaServiceアカウントを含むOUへの読み取りアクセス権が必要です。
Okta ADエージェントサービスを実行するためのOktaサービスアカウント
Oktaサービスアカウントは、インストーラーで作成できます。デフォルトのアカウント名はOktaServiceです。既存のドメインユーザーアカウントを使用する場合は、アカウントのパスワードが有効期限なしになるように設定してください。管理対象のサービスアカウントは、バージョン3.6.0以降のOkta ADエージェントでサポートされています。
インストール中に、インストーラーでOktaサービスアカウントを作成するかどうか尋ねられます。これを行うには、次の権限が必要です。
- ドメイン管理者グループのメンバーであること。ADエージェントサービスアカウントとして機能する新しいADユーザーをADで作成できるようになっている必要があるため、この権限が必要になります。
- ローカル管理者権限があること。ADエージェントをインストールしているものの、既存のユーザーアカウントを使用してサービスアカウントとして実行する場合は、ローカル管理者権限のみ必要になります。
どちらのオプションを使用しても、インストーラーは、選択したドメインユーザーに対してサービスとしてログオンの権利を与えます。
Oktaサービスアカウントの権限
ADエージェントは、指定したOktaアカウント(インストーラーが作成するOktaserviceアカウント、またはエージェントのインストール時に選択したドメインユーザー)で実行されます。統合の構成に応じて、エージェントは次のアクションを実行します。
- ユーザー、OU、グループを読み取る:アクセスするオブジェクトに対する読み取りアクセス権が必要です。ドメインユーザーには、これを行うのに十分な権限がデフォルトで付与されています。ドメイン全体に対する読み取りアクセス権を推奨しますが、必須ではありません。
- ユーザーを認証する:特別な権限は必要ありません。
- (現在のパスワードを入力して)ユーザーパスワードを変更する:特別な権限は必要ありません。
- (管理上、現在のパスワードなしで)ユーザーパスワードを設定する:ユーザーのパスワードを設定する権限が必要です。
- Oktaからプッシュされた値を使用して、ADでユーザー・属性・メンバーシップを作成・更新する:更新する属性の読み取りおよび書き込みを行うための権限が必要です。
Oktaサービスアカウントの委任を構成する
Windowsサーバーで、必要に応じてADドメインでOktaサービスアカウントへの委任を構成する必要があります。
- ADドメインコントローラーで、[Active Directory Users and Computers(Active Directoryユーザーとコンピューター)]スナップインを開きます。
- OUまたはドメイン名を右クリックし、[Delegate Control(制御の委任)]を選択します。
- [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(グループのメンバーシップを変更する)]:グループプッシュ用。