ブログ書いてないし、なんかみんな書いてるみたいなのでブームに乗っからないと思ってる、ちゃんみおです。
今回は、弊社は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のインストーラーの手順なんかを書いていきます！
