1. システムを最新の RHEL 7 バージョンへアップグレードしている。
2. ドメインのドメインレベルが 1 に設定されていることを確認します。詳細は、RHEL 7 の Linux ドメイン ID、認証、およびポリシーガイド の ドメインレベルの表示と引き上げ を参照してください。

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

   [root@rhel7 ~]# yum update ipa-*

   警告

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

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

1. 最新バージョンの Red Hat Enterprise Linux がシステムにインストールされている。詳細は 標準的な RHEL 8 インストールの実行 を参照してください。

2. 時刻サーバー rhel7.example.com が以下と同期していることを確認します。

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

   重要

   RHEL 8 では IdM は独自の時刻サーバーを提供しません。つまり、rhel8.example.com に IdM をインストールしても、ホストに NTP サーバーはインストールされません。したがって、ntp.example.com などの別の NTP サーバーを使用する必要があります。詳細は Migrating to chrony および IdM のタイムサービス要件 を参照してください。

   rhel7.example.com は NTP サーバーロールで使用できますが、移行プロセスの一環としてサーバーの使用を停止します。したがって、rhel8.example.com は、代わりに ntp.example.com と直接同期する必要があります。これは、クライアントのインストールプロセス中に指定できます。

3. システムが、rhel7.example.com IdM サーバーが権威のあるドメインに登録されている IdM クライアントであることを確認します。詳細は、IdM クライアントのインストール を参照してください。

   重要

   クライアントをインストールするときに、--ntp-server オプションを使用して、前の手順のタイムサーバーを指定します。NTP サーバーのプールを使用している場合は、--ntp-pool オプションを使用します。

   NTP サーバーを手動で指定しない場合は、DNS レコードから自動的に設定されます。これにより、rhel8.example.com が rhel7.example.com と同期することになります。これにより、RHEL 7 サーバーが使用できなくなると問題が発生します。

   RHEL8 システムがすでに NTP クライアントとして適切に設定されている場合は、IdM クライアントのインストールを実行するときに --no-ntp オプションを使用できます。

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

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

   [root@rhel7 ~]# yum update ipa-*

検証

1. IdM サービスが rhel8.example.com で稼働していることを確認します。

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

2. NTP サーバーロールを除き、rhel8.example.com のサーバーロールが、rhel7.example.com と同じであることを確認します。

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

3. 必要に応じて、rhel7.example.com と rhel8.example.com 間のレプリカ合意の詳細を表示します。

   [root@rhel8 ~]# ipa-csreplica-manage list --verbose rhel8.example.com
   Directory Manager password:
   
   rhel7.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. rhel8.example.com で AD ユーザーの解決を試みます。

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

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

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

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

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

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

2. rhel8.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@rhel8 ~]$ ipactl restart

3. rhel7.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@rhel7 ~]$ ipactl restart

手順

1. 必要に応じて、rhel7.example.com が CRL を生成しているかどうかを確認します。

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

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

   [root@rhel7 ~]# 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. 必要に応じて、rhel7.example.com サーバーが CRL の生成を停止しているかどうかを確認します。

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

手順

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

   [root@rhel8 ~]# 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

2. CRL 生成が有効になっているかどうかを確認するには、ipa-crlgen-manage status コマンドを使用します。

   [root@rhel8 ~]# ipa-crlgen-manage status
   CRL generation: enabled
   Last CRL update: 2019-10-31 12:10:00
   Last CRL Number: 7
   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 回コピーされていないこと、およびそれらが正しい値を持っていることを確認してください。