1. システムを最新の RHEL 8 バージョンにアップグレードします。

   重要

   RHEL 9.0 に移行する場合は、RHEL 8.6 よりも新しいバージョンに更新しないでください。RHEL 8.7 からの移行は、RHEL 9.1 でのみサポートされています。

2. ipa-* パッケージを最新バージョンへ更新している。

   [root@rhel8 ~]# dnf update ipa-*

   警告

   複数の Identity Management (IdM) サーバーをアップグレードする場合は、各アップグレードの間隔は少なくとも 10 分あけてください。

   複数のサーバーで同時または間隔をあまりあけないでアップグレードを行うと、トポロジー全体でアップグレード後のデータ変更を複製する時間が足りず、複製イベントが競合する可能性があります。

1. 最新バージョンの Red Hat Enterprise Linux がシステムにインストールされている。詳細は、標準的な RHEL 9 インストールの実行を参照してください。
2. システムが、rhel8.example.com IdM サーバーが権威ドメインに登録されている IdM クライアントであることを確認します。詳細は、IdM クライアントのインストール: 基本的なシナリオ を参照してください。
3. システムが IdM サーバーのインストール要件を満たしていることを確認します。Preparing the system for IdM server installation を参照してください。

4. 時刻サーバー rhel8.example.com が同期されていることを確認している。

   [root@rhel8 ~]# ntpstat
   synchronised to NTP server (ntp.example.com) at stratum 3
      time correct to within 42 ms
      polling server every 1024 s

5. システムで IdM レプリカのインストールが許可されていることを確認します。Authorizing the installation of a replica on an IdM client を参照してください。

6. ipa-* パッケージを最新バージョンへ更新している。

   [root@rhel8 ~]# dnf update ipa-*

検証

1. IdM サービスが rhel9.example.com で実行されていることを確認します。

   [root@rhel9 ~]# ipactl status
   Directory Service: RUNNING
   [... output truncated ...]
   ipa: INFO: The ipactl command was successful

2. rhel9.example.com のサーバーロールが rhel8.example.com の場合と同じであることを確認します。

   [root@rhel9 ~]# kinit admin
   [root@rhel9 ~]# ipa server-role-find --status enabled --server rhel9.example.com
   ----------------------
   2 server roles matched
   ----------------------
     Server name: rhel9.example.com
     Role name: CA server
     Role status: enabled
   
     Server name: rhel9.example.com
     Role name: DNS server
     Role status: enabled

3. (オプション)rhel8.example.com と rhel9.example.com 間のレプリカ合意の詳細を表示します。

   [root@rhel9 ~]# ipa-csreplica-manage list --verbose rhel9.example.com
   Directory Manager password:
   
   rhel8.example.com
   last init status: None
   last init ended: 1970-01-01 00:00:00+00:00
   last update status: Error (0) Replica acquired successfully: Incremental update succeeded
   last update ended: 2019-02-13 13:55:13+00:00

4. (オプション)IdM デプロイメントが AD と信頼関係にある場合は、そのデプロイメントが機能していることを確認します。

   1. Kerberos 設定を確認します

   2. rhel9.example.com で AD ユーザーの解決を試みます。

      [root@rhel9 ~]# id aduser@ad.domain

5. rhel9.example.com が NTP サーバーと同期していることを確認します。

   [root@rhel8 ~]# chronyc tracking
   Reference ID    : CB00710F (ntp.example.com)
   Stratum         : 3
   Ref time (UTC)  : Wed Feb 16 09:49:17 2022
   [... output truncated ...]

1. CA サブシステム証明書の更新を処理するように rhel9.example.com を設定します。

   [root@rhel9 ~]# ipa config-mod --ca-renewal-master-server rhel9.example.com
     ...
     IPA masters: rhel8.example.com, rhel9.example.com
     IPA CA servers: rhel8.example.com, rhel9.example.com
     IPA CA renewal master: rhel9.example.com

   出力で更新が成功したことを確認します。

2. rhel9.example.com で、証明書更新タスクを有効にします。

   1. /etc/pki/pki-tomcat/ca/CS.cfg 設定ファイルを開いて編集します。
   2. ca.certStatusUpdateInterval エントリーを削除するか、適切な間隔 (秒単位) に設定します。デフォルト値は 600 です。
   3. /etc/pki/pki-tomcat/ca/CS.cfg 設定ファイルを保存して閉じます。

   4. IdM サービスを再起動します。

      [user@rhel9 ~]$ ipactl restart

3. rhel8.example.com で、証明書更新タスクを無効にします。

   1. /etc/pki/pki-tomcat/ca/CS.cfg 設定ファイルを開いて編集します。

   2. ca.certStatusUpdateInterval を 0 に変更するか、以下のエントリーを追加します (存在しない場合)。

      ca.certStatusUpdateInterval=0

   3. /etc/pki/pki-tomcat/ca/CS.cfg 設定ファイルを保存して閉じます。

   4. IdM サービスを再起動します。

      [user@rhel8 ~]$ ipactl restart

手順

1. (オプション)rhel8.example.com が CRL を生成していることを確認します。

   [root@rhel8 ~]# ipa-crlgen-manage status
   CRL generation: enabled
   Last CRL update: 2021-10-31 12:00:00
   Last CRL Number: 6
   The ipa-crlgen-manage command was successful

2. rhel8.example.com サーバーで CRL の生成を停止します。

   [root@rhel8 ~]# ipa-crlgen-manage disable
   Stopping pki-tomcatd
   Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
   Starting pki-tomcatd
   Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
   Restarting httpd
   CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable.
   The ipa-crlgen-manage command was successful

3. 必要に応じて、rhel8.example.com サーバーが CRL の生成を停止しているかどうかを確認します。

   [root@rhel7 ~]# ipa-crlgen-manage status

手順

1. rhel9.example.com で CRL の生成を開始するには、ipa-crlgen-manage enable コマンドを使用します。

   [root@rhel9 ~]# ipa-crlgen-manage enable
   Stopping pki-tomcatd
   Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
   Starting pki-tomcatd
   Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
   Restarting httpd
   Forcing CRL update
   CRL generation enabled on the local host. Please make sure to have only a single CRL generation master.
   The ipa-crlgen-manage command was successful

手順

1. IdM がインストールされていない場合: 既存の LDAP ディレクトリーがインストールされているマシンとは別のマシンに、IdM サーバー (カスタム LDAP ディレクトリースキーマを含む) をインストールします。詳細は、Installing Identity Management を参照してください。

   注記

   カスタムユーザースキーマまたはカスタムグループスキーマの IdM でのサポートは限られています。互換性のないオブジェクト定義があると、移行中に問題が発生する可能性があります。

2. パフォーマンスの理由から、互換性プラグインを無効にします。

   # ipa-compat-manage disable

   スキーマ互換性機能の詳細と、移行時にスキーマ互換性機能を無効にする利点は、The schema to use when migrating from LDAP to IdM and the schema compat feature を参照してください。

3. IdM Directory Server インスタンスを再起動します。

   # systemctl restart dirsrv.target

4. IdM サーバーが移行を許可できるように設定します。

   # ipa config-mod --enable-migration=TRUE

   --enable-migration を TRUE に設定すると、以下のようになります。

   • LDAP の追加操作時に、ハッシュ前のパスワードを許可します。
   • 初期 Kerberos 認証に失敗した場合に、パスワードの移行シーケンスを試行するように SSSD を設定します。詳細は、Using SSSD when migrating passwords from LDAP to IdM の Workflow セクションを参照してください。

5. ユースケースに応じたオプションを指定して、IdM 移行スクリプト ipa migrate-ds を実行します。詳細は、Customizing the migration from LDAP to IdM を参照してください。

   # ipa migrate-ds --your-options ldap://ldap.example.com:389

   注記

   上記のいずれかの手順で compat プラグインを無効にしなかった場合は、--with-compat オプションを ipa migrate-ds に追加します。

   # ipa migrate-ds --your-options --with-compat ldap://ldap.example.com:389

6. 互換性プラグインを再度有効にします。

   # ipa-compat-manage enable

7. IdM Directory Server を再起動します。

   # systemctl restart dirsrv.target

8. すべてのユーザーのパスワードが移行したら、移行モードを無効にします。

   # ipa config-mod --enable-migration=FALSE

9. [オプション] すべてのユーザーが移行されたら、非 SSSD クライアントを再設定して、LDAP 認証 (pam_ldap) ではなく Kerberos 認証 (pam_krb5) を使用します。詳細は、RHEL 7 System-level Authentication Guide の Configuring a Kerberos Client を参照してください。

10. ユーザーにハッシュされた Kerberos パスワードを生成させます。Planning password migration when migrating from LDAP to IdM で説明されている方法のいずれかを選択します。

    • SSSD メソッド を決定した場合は、以下を行います。

      • SSSD がインストールされているクライアントを、LDAP ディレクトリーから IdM ディレクトリーに移動し、IdM でクライアントとして登録します。これにより必要なキーと証明書がダウンロードされます。

        Red Hat Enterprise Linux クライアントでは、この ipa-client-install コマンドを使用して実行できます。以下に例を示します。

        # ipa-client-install --enable-dns-update

    • IdM 移行 Web ページ メソッドを決定した場合は、以下を行います。

      • 移行 Web ページを使用して IdM にログインするようにユーザーに指示します。

        https://ipaserver.example.com/ipa/migration

11. ユーザーの移行プロセスを監視するには、パスワードは持っているが Kerberos プリンシパルキーはまだないユーザーアカウントを表示するよう既存の LDAP ディレクトリーに問い合わせます。

    $ ldapsearch -LL -x -D 'cn=Directory Manager' -w secret -b 'cn=users,cn=accounts,dc=example,dc=com' '(&(!(krbprincipalkey=))(userpassword=))' uid

    注記

    フィルターの前後に一重引用符を付けてシェルで解釈されないようにします。

12. クライアントとユーザーすべての移行が完了したら LDAP ディレクトリーを廃止します。

検証

1. ipa user-add を使用して、IdM にテストユーザーを作成します。移行したユーザーの出力を、テストユーザーの出力と比較します。移行したユーザーに、テストユーザーに存在する属性およびオブジェクトクラスの最小セットが含まれていることを確認します。以下に例を示します。

   $ ipa user-show --all testing_user
   dn: uid=testing_user,cn=users,cn=accounts,dc=idm,dc=example,dc=com
   User login: testing_user
   First name: testing
   Last name: user
   Full name: testing user
   Display name: testing user
   Initials: tu
   Home directory: /home/testing_user
   GECOS: testing user
   Login shell: /bin/sh
   Principal name: testing_user@IDM.EXAMPLE.COM
   Principal alias: testing_user@IDM.EXAMPLE.COM
   Email address: testing_user@idm.example.com
   UID: 1689700012
   GID: 1689700012
   Account disabled: False
   Preserved user: False
   Password: False
   Member of groups: ipausers
   Kerberos keys available: False
   ipauniqueid: 843b1ac8-6e38-11ec-8dfe-5254005aad3e
   mepmanagedentry: cn=testing_user,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
   objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject,
                ipasshuser, ipaSshGroupOfPubKeys, mepOriginEntry

2. IdM にあるように、移行したユーザーの出力を、元の LDAP サーバーにあるように、ソースユーザーと比較します。インポートされた属性が 2 回コピーされていないこと、およびそれらが正しい値を持っていることを確認してください。

手順

1. リモート LDAP サーバー証明書を発行した CA の証明書を、今後使用する IdM サーバーのファイルに保存します。たとえば、/tmp/remote.crt です。

2. Migrating an LDAP server to IdM に記載されている手順に従います。ただし、移行時に暗号化された LDAP 接続の場合、URL で ldaps プロトコルを使用し、ipa migrate-ds コマンドに --ca-cert-file オプションを渡します。以下に例を示します。

   # ipa migrate-ds --ca-cert-file=/tmp/remote.crt --your-other-options ldaps://ldap.example.com:636

検証

1. ipa user-add を使用して、IdM にテストユーザーを作成します。移行したユーザーの出力を、テストユーザーの出力と比較します。移行したユーザーに、テストユーザーに存在する属性およびオブジェクトクラスの最小セットが含まれていることを確認します。以下に例を示します。

   $ ipa user-show --all testing_user
   dn: uid=testing_user,cn=users,cn=accounts,dc=idm,dc=example,dc=com
   User login: testing_user
   First name: testing
   Last name: user
   Full name: testing user
   Display name: testing user
   Initials: tu
   Home directory: /home/testing_user
   GECOS: testing user
   Login shell: /bin/sh
   Principal name: testing_user@IDM.EXAMPLE.COM
   Principal alias: testing_user@IDM.EXAMPLE.COM
   Email address: testing_user@idm.example.com
   UID: 1689700012
   GID: 1689700012
   Account disabled: False
   Preserved user: False
   Password: False
   Member of groups: ipausers
   Kerberos keys available: False
   ipauniqueid: 843b1ac8-6e38-11ec-8dfe-5254005aad3e
   mepmanagedentry: cn=testing_user,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
   objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject,
                ipasshuser, ipaSshGroupOfPubKeys, mepOriginEntry

2. IdM にあるように、移行したユーザーの出力を、元の LDAP サーバーにあるように、ソースユーザーと比較します。インポートされた属性が 2 回コピーされていないこと、およびそれらが正しい値を持っていることを確認してください。