パスワード移行を実行する
早期アクセスリリース
パスワード移行プロセスは、エンドユーザーに対して透過的です。移行進行時にユーザーがパスワードを使用してOktaにサインインする際に、パスワードが安全に取得され、移行されます。Oktaは、そのユーザーの認証を即座に引き継ぎます。移行全体が完了すると、ADを介した委任認証は行われなくなり、移行された全ユーザーのユーザー認証はOktaがすべて処理します。
パスワード移行には、移行の開始、監視、終了という3つの主要なフェーズがあります。移行完了後に、エンドユーザーがパスワードリセットを適切に実行できようにする必要があり、また新規ユーザーの処理方法を理解する必要もあります。
orgごとに最大10件のアクティブなパスワード移行を含めることができ、各移行には最大100個の移行グループを含めることができます。
開始する前に
次の権限を持つ管理者としてサインインします。
- ディレクトリの管理
- グループの表示
パスワード移行を開始する
-
Admin Consoleでに移動します。
- ユーザーパスワードを移行するADインスタンスを選択します。
- ［Provisioning（プロビジョニング）］タブをクリックします。
- ［Settings（設定）］の下にある［Password migration（パスワード移行）］をクリックします。
- 任意。［Enable password sync（パスワード同期を有効にする）］を選択します。このオプションを選択すると、移行時または移行後にOktaで行われたパスワードの変更がADに同期されます。これは、ADパスワードを使用するレガシーアプリで役立ちます。このオプションを有効にすることを推奨します。「移行後のパスワードリセットを処理する」を参照してください。
- ［Start campaign（キャンペーンを開始）］をクリックします。
- 移行するユーザーのグループを検索して選択します。［Migrate（移行する）］をクリックして、選択したグループからパスワード移行を開始します。
パスワード移行を監視する
パスワード移行の実行時に、［Password migration（パスワード移行）］ページの［Migrated groups（移行済みグループ）］タブをクリックして、進行状況を監視できます。このタブには、移行の進捗状況（各グループで正常に移行されたパスワード数など）が表示されます。グループ移行数が不一致になる場合があります。これは以下のいずれかの理由で発生する可能性があります。
- 移行グループに他のADインスタンスのメンバーが含まれている場合、そのメンバーのパスワードは移行されません。ただし、それらのグループのメンバー数には含まれます。
- 移行グループにパスワードがすでにOktaにあるメンバーが含まれている場合、そのメンバーのパスワードは移行済みパスワードとしてカウントされませんが、メンバーはグループメンバーの合計数には含まれます。
- 移行グループのメンバーが他の移行グループに属している場合、そのメンバーが属する最初のグループで成功したパスワード移行のみがカウントされます。メンバーの他の移行グループでは、移行パスワード数は増えません。
必要なパスワードが移行されたことを確認後、または移行をキャンセルする場合は、次のセクションに進みます。
パスワード移行を終了する
パスワード移行を終了させるには2つの方法のいずれかを行います。移行を完了させてADインスタンス全体のADへの委任認証を無効にするか、または移行をキャンセルして変更を元に戻すかです。
パスワード移行を終了する
移行中は、定期的に［Migrated groups（移行済みグループ）］ページを確認する必要があります。必要なパスワードが移行されたことを確認したら、［Finish campaign（キャンペーンを終了）］をクリックします。これにより、次のアクションが実行されて移行が終了します。
- 委任認証を無効にする：ADインスタンスに対して委任認証が無効になります。
- ジャストインタイム（JIT）プロビジョニングとユニバーサルセキュリティーグループのサポートを無効にする：ADインスタンスに対するJITプロビジョニングとプロファイルの再読み込みが両方とも無効になります。これは、JITがADインスタンスで無効にされた委任認証を使用しており、ユーザーをプロビジョニングする機能が終了するためです。
- パスワードリセットメールを送信する：任意。移行が終了したら、［Create Okta password option（Oktaパスワードを作成オプション）］を選択し、移行時にパスワードが取得されなかったユーザーにパスワードリセットメールを送信します。これにより、ユーザーは移行完了後もサインインできるようになります。［Don't create Okta password（Oktaパスワードを作成しない）］を選択すると、移行時にパスワードが取得されなかったユーザーがサインインするには、サポートに問い合わせる必要があります。
パスワードが正常に移行されなかったユーザーは、パスワードをリセットする前に仕事用のメールにアクセス場合があります。ユーザーがパスワードリセットメールにアクセスできるようにするには、次のいずれかの方法でアクセスを確保します。
- パスワードリセットメールを各ユーザーのセカンダリメールアドレスに送信します。セカンダリメールアドレスは、ユーザーがアクセスできる個人用アカウントにする必要があります。
- ユーザーがパスワード以外の要素を使用してOktaに認証できるようにします。
パスワード移行をキャンセルする
すでに進行中のパスワード移行を放棄することができます。これを行うには、［Passwords migration（パスワード移行）］ページに移動し、［Cancel campaign（キャンペーンをキャンセル）］をクリックします。これにより、パスワードの取得プロセスが停止し、ADインスタンスが移行開始前の状態に戻ります。
移行をキャンセルすると、選択したグループ内の移行済みユーザーがすべてリセットされ、ログインタイプが委任認証に戻ります。
移行後のパスワードリセットを処理する
ユーザーは、移行成功後にOktaでパスワード変更が必要であることを把握していなければなりません。
移行後に、Oktaでパスワードを変更する必要があることをユーザーに伝えます。ADのWindowsセキュリティ画面（Ctrl+Alt+Delを押してアクセス）または類似の方法で行われたパスワード変更はOktaに同期されないため、ユーザーのOktaパスワードとADパスワードの不一致による認証の問題が発生します。
移行後にOktaでのパスワード変更をADに同期する場合は、移行開始時に［Enable password sync（パスワード同期を有効にする）］を選択してください。これにより、ユーザーが移行中と移行後に開始したすべてのパスワードリセットイベントが、パスワード移行後にADに同期されるようになります。
移行後に新規ユーザーを処理する
移行が完了すると、JITプロビジョニングが無効になります。これは、JITがADインスタンスで無効にされた委任認証を使用しており、ユーザーをプロビジョニングする機能が終了するためです。移行後にユーザーを作成するときは、次の点に留意してください。
- ユーザーは、サインインできるOktaに存在している必要があります。
- 移行後にOktaにインポートされた新規ユーザーは、初回サインイン時にパスワードを設定する必要があります。