Oktaと楽しいディレクトリ統合~前提編~

Oktaと楽しいディレクトリ統合~前提編~

ブログ書いてないし、なんかみんな書いてるみたいなのでブームに乗っからないと思ってる、ちゃんみおです。

今回は、弊社はZeroTrust!と言っていたりADのない構成!と言っていたりしていますが!真逆をいくOktaのディレクトリ統合の1つのADとOktaの連携の前提条件を書きます。 前提条件だけです!すぐにハイ導入!なんて大変なのだ! なので導入編はまた今度

ちなみに、公式ドキュメントはこちら! Integrate with Active Directory | Okta

必要な権限・アカウントとか環境

ここに書くこと以外にも、たくさんあるので要Oktaのドキュメント参照です!

アカウントとロール

  • Oktaの管理者アカウント(super admin)
  • ADDSのAdminアカウント
    • インストールするホストの管理者、Domain AdminがあればOK
  • Okta Agent用アカウント
    • サービスアカウントを作成するときに、次の情報の入力が必要、(これの詳しい話は導入編で書くよ!)

環境

  • Windows Server 2008 R2以降
  • ADDSはインターネットと接続が可能な状況であること
    • それができない場合は、インストーラーを転送して行うことも可能
  • ADドメイン/フォレスト機能レベルは、2003以降
    • 機能レベルが2003の場合は、ユーザーはuserPrincipalNameを持っている必要がある
    • ADパスワード履歴ポリシーを有効にする場合は、2008 R2以降が必要
  • ドメインコントローラーではなく、メンバーサーバーを推奨
    • フォレストに参加している必要
  • Okta AD Agentは、複数ホストにインストーにして冗長構成にすることを推奨

決めておくこと

実際にAD – Oktaを連携したときに決めておかなければいけないことがあります! AD Agentを入れる前に、決めておきましょう

  • usernameのフォーマット
    • SSOするときに利用するデフォルト値です!
    • email, sAMAccountName, userPrincipalNameのいずれかから選択してね
    • 後から変更も可能だし、SaaSごとに今回は、〇〇で〜って変更は可能ではあるけど、デフォルトを何にするかは大切です
    • Okta的にはuserPrincipalNameを推奨してます
  • ユーザーとグループをインポートする対象のOU
    • あとで変更することも可能だけど、その後のSaaSとのSSO作業の時にOU毎にアサインしていくこともできるので、OUはちゃんと整備が必要です
  • OktaユーザープロファイルにインポートするADの属性
    • ADDSでカスタム値使っている場合は、Oktaでもその受け入れ先を作る必要があるよ
    • デフォルトのマッピングや、カスタム値の追加はドキュメント見よう!
    • AD user profiles and attributes | Okta

前提編はこれにて終了! 導入編では、ADにサービスアカウントの作成や、アカウントに対しての権限、AD Agentのインストーラーの手順なんかを書いていきます!