Menu Close

RHEL 9 の Identity Management への移行

Red Hat Enterprise Linux 9

RHEL 9 で実行するための IdM サーバーの移行および IdM クライアントのアップグレードに関するガイド

概要

本書は、Red Hat Enterprise Linux 8 インストール、他の LDAP ソリューション、または他の Linux ディストリビューションから、Identity Management 環境の Red Hat Enterprise Linux 9 (RHEL) サーバーへ移行する方法を説明します。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。

Identity Management では、以下のような用語の置き換えが含まれます。

  • ブラックリストからブロックリスト
  • ホワイトリストから許可リスト
  • スレーブからセカンダリー
  • 単語 マスター は、コンテキストに応じて、より正確な言語に置き換えられます。

    • マスターからIdM サーバー
    • CA 更新マスターからCA 更新サーバー
    • CRL マスターからCRL パブリッシャーサーバー
    • マルチマスターからマルチサプライヤー

Red Hat ドキュメントへのフィードバック (英語のみ)

ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。

  • 特定の部分についての簡単なコメントをお寄せいただく場合は、以下をご確認ください。

    1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上隅に Feedback ボタンがあることを確認してください。
    2. マウスカーソルで、コメントを追加する部分を強調表示します。
    3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。
    4. 表示される手順に従ってください。
  • Bugzilla を介してフィードバックを送信するには、新しいチケットを作成します。

    1. Bugzilla の Web サイトに移動します。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

パート I. RHEL 8 から RHEL 9 への IdM の移行

第1章 RHEL 8 サーバーから RHEL 9 サーバーへの IdM 環境の移行

RHEL 8 IdM 環境を RHEL 9 にアップグレードするには、最初に新しい RHEL 9 IdM レプリカを RHEL 8 IdM 環境に追加し、RHEL 8 サーバーを廃止する必要があります。

警告

RHEL 9 への RHEL 8 IdM サーバーのインプレースアップグレードはサポートされていません。

本セクションでは、すべての Identity Management (IdM) データおよび設定を、Red Hat Enterprise Linux (RHEL) 8 サーバーから RHEL 9 サーバーに 移行 する方法を説明します。

移行手順には、以下が含まれます。

  1. RHEL 9 IdM サーバーを設定し、現在の RHEL 8 IdM 環境にレプリカとして追加します。詳細は、Installing the RHEL 9 Replica を参照してください。
  2. RHEL 9 サーバーを認証局 (CA) 更新サーバーにする。詳細は「RHEL 9 IdM サーバーへの CA 更新サーバーロールの割り当て」を参照してください。
  3. RHEL 8 サーバーで証明書失効リスト(CRL)の生成を停止し、CRL 要求を RHEL 9 レプリカにリダイレクトします。詳細は、Stopping CRL generation on a RHEL 8 IdM CA server を参照してください。
  4. RHEL 9 サーバーで CRL の生成を開始する。詳細は、Starting CRL generation on the new RHEL 9 IdM CA server を参照してください。
  5. 元の RHEL 8 CA 更新サーバーを停止して廃止する。詳細は、Stopping and decommissioning the RHEL 8 server を参照してください。

手順では、以下を前提としています。

  • rhel9.example.com は、新しい CA 更新サーバーとなる RHEL 9 システムです。
  • rhel8.example.com は、元の RHEL 8 CA 更新サーバーです。CA 更新サーバーである Red Hat Enterprise Linux 8 サーバーを特定するには、任意の IdM サーバーで次のコマンドを実行します。

    [root@rhel8 ~]# ipa config-show | grep "CA renewal"
    IPA CA renewal master: rhel8.example.com

    IdM デプロイメントで IdM CA を使用しない場合、RHEL 8 で実行されている IdM サーバーは rhel8.example.com になります。

注記

IdM デプロイメントで組み込み認証局 (CA) しか使用する場合に限り、以下のセクションの手順を実行します。

1.1. IdM を RHEL 8 から 9 に移行するための前提条件

rhel8.example.com で、以下を行います。

  1. システムを最新の RHEL 8 バージョンにアップグレードします。
  2. ipa-* パッケージを最新バージョンへ更新している。

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

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

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

rhel9.example.com で以下を行います。

  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-*

関連情報

  • 新しい IdM プライマリーサーバー rhel9.example.com にインストールするサーバーロールを決定するには、以下のリンクを参照してください。

  • RHEL 9 に IdM 用の特定のサーバーロールをインストールするには、特定の IdM リポジトリーからパッケージをダウンロードする必要があります (Installing packages required for an IdM server 参照)。
  • RHEL 8 から RHEL 9 へシステムをアップグレードする場合は、『RHEL 8 から RHEL 9 へ のアップグレード』を参照してください。

1.2. RHEL 9 レプリカのインストール

  1. RHEL 8 環境に存在するサーバーの一覧を表示します。

    [root@rhel8 ~]# ipa server-role-find --status enabled --server rhel8.example.com
    ----------------------
    3 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
    [... output truncated ...]
  2. (必要に応じて)rhel9.example.comrhel8.example.com が使用しているものと同じサーバーごとのフォワーダーを使用する場合は、rhel8.example.com のサーバーごとのフォワーダーを確認します。

    [root@rhel8 ~]# ipa dnsserver-show rhel8.example.com
    -----------------------------
    1 DNS server matched
    -----------------------------
      Server name: rhel8.example.com
      SOA mname: rhel8.example.com.
      Forwarders: 192.0.2.20
      Forward policy: only
    --------------------------------------------------
    Number of entries returned 1
    --------------------------------------------------
  3. IdM サーバーソフトウェアを rhel9.example.com にインストールして、RHEL 8 IdM サーバーのレプリカとして設定します (rhel8.example.com にあるすべてのサーバーロールを含む)。上記の例からロールをインストールするには、ipa-replica-install コマンドで以下のオプションを使用します。

    • --setup-ca: Certificate System コンポーネントを設定する
    • --setup-dns および --forwarder:統合 DNS サーバーを設定し、IdM ドメインの外に出る DNS クエリーを処理するようにサーバーごとのフォワーダーを設定する

      注記

      また、IdM デプロイメントが Active Directory (AD) と信頼関係にある場合は、--setup-adtrust オプションを ipa-replica-install コマンドに追加し、rhel9.example.com に AD 信頼機能を設定します。

    • --ntp-server: NTP サーバーを指定する、または --ntp-pool: NTP サーバーのプールを指定する

      IP アドレスが 192.0.2.20 のサーバーごとのフォワーダーを使用し ntp.example.com NTP サーバーと同期する、IP アドレスが 192.0.2.1 の IdM サーバーを設定するには、次のコマンドを実行します。

      [root@rhel9 ~]# ipa-replica-install --setup-ca --ip-address 192.0.2.1 --setup-dns --forwarder 192.0.2.20 --ntp-server ntp.example.com

      DNS が正常に動作している場合は、rhel9.example.com が DNS 自動検出を使用してそれを見つけるため、RHEL 8 IdM サーバー自体を指定する必要はありません。

  4. (オプション)外部 NTP 時刻サーバーの _ntp._udp サービス(SRV)レコードを、新たにインストールした IdM サーバーの DNS( rhel9.example.com )に追加します。IdM DNS に時刻サーバーの SRV レコードが存在すると、今後 RHEL 9 のレプリカとクライアントインストールが rhel9.example.com で使用される時刻サーバーと同期するように自動的に設定されます。これは、--ntp-server または --ntp-pool オプションがインストールコマンドラインインターフェース(CLI)で指定されていない限り、ipa-client-install_ntp._udp DNS エントリーを検索するためです。

検証

  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.comrhel9.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.comNTP サーバーと同期していることを確認します。

    [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.3. RHEL 9 IdM サーバーへの CA 更新サーバーロールの割り当て

注記

IdM デプロイメントで組み込み認証局 (CA) を使用する場合にのみ、本セクションの手順を行います。

rhel9.example.com で、新しい CA 更新サーバーとして rhel9.example.com を設定します。

  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.certStatusUpdateInterval0 に変更するか、または以下のエントリーを追加します(存在しない場合)。

      ca.certStatusUpdateInterval=0
    3. /etc/pki/pki-tomcat/ca/CS.cfg 設定ファイルを保存して閉じます。
    4. IdM サービスを再起動します。

      [user@rhel8 ~]$ ipactl restart

1.4. RHEL 8 IdM CA サーバーでの CRL 生成の停止

注記

IdM デプロイメントで組み込み認証局 (CA) を使用する場合にのみ、本セクションの手順を行います。

本セクションでは、ipa-crlgen-manage コマンドを使用して、rhel8.example.com CA サーバーで証明書失効リスト(CRL)の生成を停止する方法を説明します。

前提条件

  • root としてログインしている。

手順

  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

rhel8.example.com サーバーが CRL の生成を停止しました。次の手順では、rhel9.example.com で CRL の生成を有効にします。

1.5. 新しい RHEL 9 IdM CA サーバーでの CRL 生成の開始

注記

IdM デプロイメントで組み込み認証局 (CA) を使用する場合にのみ、本セクションの手順を行います。

前提条件

  • rhel9.example.com マシンに root としてログインしている必要があります。

手順

  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

検証手順

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

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

1.6. RHEL 8 サーバーの停止および使用停止

  1. 最新の変更を含むすべてのデータが rhel8.example.com から rhel9.example.com に正しく移行されていることを確認します。以下は例になります。

    1. rhel8.example.com で新規ユーザを追加します。

      [root@rhel8 ~]# ipa user-add random_user
      First name: random
      Last name: user
    2. ユーザが rhel9.example.com に複製されていることを確認します。

      [root@rhel9 ~]# ipa user-find random_user
      --------------
      1 user matched
      --------------
        User login: random_user
        First name: random
        Last name: user
  2. rhel8.example.com 上のすべての IdM サービスを停止して、新しい rhel9.example.com サーバーへのドメイン検索を実施します。

    [root@rhel7 ~]# ipactl stop
    Stopping CA Service
    Stopping pki-ca:                                           [  OK  ]
    Stopping HTTP Service
    Stopping httpd:                                            [  OK  ]
    Stopping MEMCACHE Service
    Stopping ipa_memcached:                                    [  OK  ]
    Stopping DNS Service
    Stopping named:                                            [  OK  ]
    Stopping KPASSWD Service
    Stopping Kerberos 5 Admin Server:                          [  OK  ]
    Stopping KDC Service
    Stopping Kerberos 5 KDC:                                   [  OK  ]
    Stopping Directory Service
    Shutting down dirsrv:
        EXAMPLE-COM...                                         [  OK  ]
        PKI-IPA...                                             [  OK  ]

    この後に、ipa ユーティリティーを使用すると、Remote Procedure Call (RPC) で新規サーバーに接続します。

  3. RHEL 9 サーバーで削除コマンドを実行して、トポロジーから RHEL 8 サーバーを削除します。詳細は「IdM サーバーのアンインストール」を参照してください。

第2章 RHEL 8 から RHEL 9 への IdM クライアントのアップグレード

IdM サーバーとは異なり、IdM クライアントの RHEL 8 から RHEL 9 へのインプレースアップグレードは、サポートされています。Leapp インプレースアップグレードユーティリティーは、必要な設定をすべて変更します。

パート II. 外部ソースから IdM への移行

第3章 LDAP ディレクトリーから IdM への移行

ID および認証ルックアップ用に LDAP サーバーをデプロイしている場合は、ルックアップサービスを Identity Management (IdM) に移行できます。IdM では、以下のタスクに役立つ移行ツールを利用できます。

  • データを失うことなく、パスワードやグループメンバーシップなどのユーザーアカウントを転送するタスク。
  • クライアントで高価な設定更新を回避するタスク。

ここで説明する移行プロセスは、LDAP に 1 つ、IdM に 1 つの名前空間がある単純な導入シナリオを想定しています。複数の名前空間やカスタムスキーマがある場合など、より複雑な環境については、Red Hat サポートサービスにお問い合わせください。

3.1. LDAP から IdM への移行に関する考慮事項

LDAP サーバーから Identity Management (IdM) に移行するプロセスには、以下の段階があります。

  • クライアントの移行このステージは慎重に計画してください。現在のインフラストラクチャーの各クライアントが使用するサービスを判断します。これには、Kerberos や Systems Security Services Daemon (SSSD) などが含まれます。次に、最終的な IdM デプロイメントで使用できるサービスを決定します。詳細は、Planning the client configuration when migrating from LDAP to IdM を参照してください。
  • データ の移行
  • パスワード の移行このステージは慎重に計画してください。IdM では、パスワードのほかに、すべてのユーザーアカウントに Kerberos ハッシュが必要です。パスワードに関する考慮事項と移行パスの一部は、Planning password migration when migrating from LDAP to IdM で説明しています。

最初にサーバー部分を移行してからクライアントを移行するか、または最初にクライアントを移行してからサーバーを移行することができます。2 つのタイプの移行の詳細は、LDAP to IdM migration sequence を参照してください。

重要

実際に LDAP 環境の移行に入る前に、LDAP のテスト環境を設定して移行プロセスを検証することを強く推奨します。環境をテストする場合は、以下を行います。

  1. IdM でテストユーザーを作成し、移行したユーザーの出力を、テストユーザーの出力と比較します。移行したユーザーに、テストユーザーに存在する属性およびオブジェクトクラスの最小セットが含まれていることを確認します。
  2. IdM にあるように、移行したユーザーの出力を、元の LDAP サーバーにあるように、ソースユーザーと比較します。インポートされた属性が2回コピーされていないこと、およびそれらが正しい値を持っていることを確認してください。

3.2. LDAP から IdM への移行時のクライアント設定の計画

Identity Management は、さまざまなレベルの機能性、柔軟性、安全性で多数の異なるクライアント設定に対応することができます。オペレーティングシステムと、IT メンテナンスの優先度に基づいて、各クライアントに最適な設定を決定します。クライアントの機能領域も考慮してください。開発マシンは通常、実稼働サーバーやユーザーラップトップとは異なる設定を必要とします。

重要

ほとんどの環境では、クライアントが IdM ドメインに接続する方法が混在しています。管理者は各クライアント別に最適となるシナリオを決定しなければなりません。

3.2.1. 初期の移行前のクライアント設定

Identity Management (IdM) でクライアント設定の詳細を決定する前に、現在の移行前設定の詳細を確立します。

移行予定の LDAP デプロイメントの初期の状態の場合、ほとんど全てに ID および認証サービスを提供している LDAP サービスがあります。

図3.1 基本的な LDAP ディレクトリーとクライアント設定

IPA 移行の初期状態

Linux および Unix のクライアントは PAM_LDAP と NSS_LDAP ライブラリーを使って、LDAP サービスに直接接続します。これらのライブラリーにより、クライアントは、/etc/passwd または /etc/shadow にデータが格納されているかのように LDAP ディレクトリーからユーザー情報を取得できます。現実的には ID 検索に LDAP、認証に Kerberos や別の設定を使用している場合など、インフラストラクチャーはもう少し複雑になる場合があります。

LDAP ディレクトリーと Identity Management (IdM) サーバーの間には、特にスキーマサポートとディレクトリーツリーに構造的な違いがあります。これらの違いに関する背景は、「LDAP から IdM への移行時のクライアント設定の計画」の「標準 LDAP ディレクトリーを使用した IdM の比較 」を参照してください。このような相違は、特にディレクトリーツリーのデータに影響を及ぼし、エントリー名に影響を及ぼします。ただし、この相違はクライアントの設定、およびクライアントの IdM への移行にはほとんど影響を及ぼしません。

3.2.3. 推奨設定以外で対応している設定

Mac、Solaris、HP-UX、AIX、Scientific Linux などの Unix および Linux システムでは IdM で管理されるすべてのサービスに対応していますが SSSD は使用しません。同様に、古い Red Hat Enterprise Linux (RHEL) バージョン (特に 6.1 および 5.6) は SSSD に対応していますが、IdM を ID プロバイダーとしてサポートしていない古いバージョンがあります。

システムで最新バージョンの SSSD を使用できない場合は、以下の方法でクライアントを設定できます。

  • クライアントは、nss_ldap を使用して、ID 検索で LDAP ディレクトリーサーバーであるかのように IdM サーバーに接続します。
  • クライアントは、pam_krb5 を使用して、通常の Kerberos KDC であるかのように IdM サーバーに接続します。

IdM サーバーを ID プロバイダーおよび Kerberos 認証ドメインとして使用するように古いバージョンの SSSD を持つ RHEL クライアントを設定する方法は、RHEL 7 System-Level Authentication GuideConfiguring identity and authentication providers for SSSD セクションを参照してください。

図3.3 LDAP および Kerberos を使用するクライアントおよび IdM

migr ldap

一般的には、クライアントで可能な限り安全な設定を使用することがベストプラクティスとなります。これは、ID の SSSD または LDAP、および認証の Kerberos を意味します。ただし、メンテナンス状況や IT 構造によっては、最も単純な例 (クライアントで nss_ldap ライブラリーおよび pam_ldap ライブラリーを使用して ID と認証の両方を提供するように LDAP を設定) に頼る必要があります。

3.3. LDAP から IdM への移行時のパスワードの移行の計画

ユーザーを LDAP から Identity Management (IdM) に移行する前に決定すべき重大な問題は、ユーザーパスワードを移行するかどうかです。以下のタイプが使用できます。

パスワードを使用しないユーザーの移行

より迅速に実行できますが、管理者とユーザーによるより多くの手作業が必要です。特定の状況では、これが唯一の選択肢となります (元の LDAP 環境にクリアテキストのユーザーパスワードが保存されている 場合やパスワードが IdM で定義されているパスワードポリシーの要件を満たしていない 場合など)。

パスワードを使用せずにユーザーアカウントを移行する場合は、すべてのユーザーパスワードをリセットします。移行したユーザーには、最初のログイン時に変更する一時パスワードが割り当てられます。パスワードのリセット方法は、RHEL 7 IdM ドキュメント Changing and resetting user passwords を参照してください。

パスワードを使用したユーザーの移行

移行はよりスムーズになりますが、移行および移行プロセスで LDAP ディレクトリーと IdM を並列に管理することも必要になります。これは、IdM がデフォルトで認証に Kerberos を使用し、各ユーザーには、標準ユーザーパスワードのほかに、IdM Directory Server に保存されている Kerberos ハッシュが必要であるためです。このハッシュを生成するには、IdM サーバー側でユーザーのパスワードがクリアテキストで利用可能である必要があります。新しいユーザーパスワードを作成すると、パスワードはハッシュされて IdM に保存される前に、クリアテキストで利用できるようになります。ただし、ユーザーを LDAP ディレクトリーから移行する場合には関連するユーザーパスワードがすでにハッシュ化されているため該当する Kerberos キーは生成できません。

重要

デフォルトでは、ユーザーアカウントが存在しても、Kerberos ハッシュが発生するまで、ユーザーは IdM ドメインに認証したり、IdM リソースにアクセスしたりできません。回避策の 1 つが利用できます。Kerberos 認証の代わりに、IdM で LDAP 認証を使用します。この回避策では、ユーザーに Kerberos ハッシュは必要ありません。ただし、この回避策により IdM の機能が制限されるため、推奨できません。

次のセクションでは、ユーザーとそのパスワードを移行する方法を説明します。

3.3.1. Methods for migrating passwords when migrating LDAP to IdM

ユーザーにパスワードの変更を強制せずに、ユーザーアカウントを LDAP から Identity Management (IdM) に移行するには、以下の方法を使用できます。

方法 1: 移行 Web ページの使用

ユーザーに、IdM Web UI (https://ipaserver.example.com/ipa/migration) のスペシャルページに LDAP 認証情報を一度入力するように指示します。バックグラウンドで実行しているスクリプトが、クリアテキストパスワードをキャプチャーして、パスワードと適切な Kerberos ハッシュを使用してユーザーアカウントを適切に更新します。

方法 2 (推奨) - SSSD の使用

SSSD (System Security Services Daemon) を使用して必要なユーザーキーを生成することで、移行によるユーザーへの影響を軽減します。大量のユーザーを導入する場合やユーザーにパスワード変更の面倒をかけさせない場合に最適なシナリオです。

ワークフロー

  1. ユーザーが SSSD でマシンにログインします。
  2. SSSD は、IdM サーバーに対して Kerberos 認証の実行を試みます。
  3. ユーザーがシステムに存在していも Kerberos ハッシュがないため key type is not supported エラーで認証に失敗します。
  4. SSSD は、セキュアな接続でプレーンテキストの LDAP バインドを実行します。
  5. IdM はこのバインド要求をインターセプトします。ユーザーが Kerberos プリンシパルは持っているのに Kerberos ハッシュを持っていない場合、IdM ID プロバイダーはハッシュを生成してユーザーのエンティティーに格納します。
  6. 認証に成功すると SSSD は IdM との接続を切断し Kerberos 認証を再試行します。この場合、エンティティーにハッシュが存在しているため要求は成功します。

方法 2 では、ユーザーにはプロセス全体が表示されません。ユーザーは、パスワードが LDAP から IdM に移動したことに気が付かずにクライアントサービスにログインします。

3.3.2. Planning the migration of cleartext LDAP passwords

ほとんどのデプロイメントでは暗号化された LDAP パスワードが格納されますが、ユーザーまたは環境によってユーザーエンティティーにクリアテキストのパスワードが使用される場合があります。

ユーザーを LDAP サーバーから IdM サーバーに移行する場合、IdM ではクリアテキストパスワードが許可されていないため、クリアテキストパスワードは移行されません。代わりに、Kerberos プリンシパルがユーザーごとに作成され、キータブは true に設定されます。また、パスワードは期限が切れたときに設定されます。つまり、IdM では、次回のログイン時にユーザーがパスワードをリセットする必要があります。詳細は、Planning the migration of LDAP passwords that do not meet the IdM requirements を参照してください。

3.3.3. Planning the migration of LDAP passwords that do not meet the IdM requirements

元のディレクトリーのユーザーパスワードが、Identity Management (IdM) で定義されているパスワードポリシーに一致しない場合、そのパスワードは移行後に無効になります。

パスワードのリセットは、ユーザーが kinit と入力して IdM ドメイン内の Kerberos チケット付与チケット (TGT) を最初に取得しようとするときに自動的に行われます。ユーザーはパスワードの変更を強制されます。

[migrated_idm_user@idmclient ~]$ kinit
Password for migrated_idm_user@IDM.EXAMPLE.COM:
Password expired.  You must change it now.
Enter new password:
Enter it again:

3.4. 移行における考慮事項と要件

LDAP サーバーから Identity Management (IdM) への移行を計画している場合は、LDAP 環境が IdM の移行スクリプトで機能できることを確認してください。

3.4.1. 移行に対応している LDAP サーバー

LDAP サーバーから Identity Management への移行プロセスは、特別なスクリプト ipa migrate-ds を使用して移行を実行します。このスクリプトには、LDAP ディレクトリーと LDAP エントリーの構造に関する特定の要件があります。移行に対応しているのは複数の共通ディレクトリーを含む LDAPv3 準拠のディレクトリーサービスのみになります。

  • Sun ONE Directory Server
  • Apache Directory Server
  • OpenLDAP

LDAP サーバーから IdM への移行は、Red Hat Directory Server および OpenLDAP でテストされています。

注記

Microsoft Active Directory の場合、移行用スクリプトを使った移行には対応していません。これは、LDAPv3-コンプライアントディレクトリーではないためです。Active Directory からの移行については、Red Hat Professional Services にお問い合わせください。

3.4.2. 移行のための LDAP 環境要件

LDAP サーバーと Identity Management (IdM) にはさまざまな設定シナリオが存在し、これが移行プロセスの円滑さに影響します。本章で説明している移行例の場合、以下に示すような環境を想定しています。

  • 1 つの LDAP ディレクトリードメインが、1 つの IdM レルムに移行中です。統合はありません。
  • ユーザーパスワードは、LDAP ディレクトリーにハッシュ形式で保存されます。対応しているハッシュの一覧は、Red Hat Directory Server Documentation の Red Hat Directory Server 10 で利用可能な Configuration, Command, and File Reference タイトルの Password Storage Schemes セクションを参照してください。
  • LDAP ディレクトリーインスタンスは ID 格納および認証方法の両方になります。クライアントマシンは、pam_ldap または nss_ldap を使用して LDAP サーバーに接続するように設定されます。
  • エントリーは標準の LDAP スキーマのみを使用します。カスタムオブジェクトクラスまたはカスタム属性を含むエントリーは、IdM に移行されません。
  • migrate-ds は、以下のアカウントのみを移行します。

    • gidNumber 属性を含むもの。この属性は、posixAccount オブジェクトクラスに必要です。
    • sn 属性を含むもの。この属性は、person オブジェクトクラスに必要です。

3.4.3. 移行のための IdM システム要件

中程度のサイズのディレクトリー (約 10,000 ユーザー、および 10 グループ) では、移行を続行するのに十分な強力なターゲット IdM システムが必要です。移行の最小要件は以下のとおりです。

  • 4 コア
  • 4 GB のメモリー
  • 30GB のディスク領域
  • 2MB の SASL バッファサイズ。これは IdM サーバーのデフォルトです。

    移行エラーが発生した場合は、バッファーサイズを大きくします。

    [root@ipaserver ~]# ldapmodify -x -D 'cn=directory manager' -w password -h ipaserver.example.com -p 389
    
    dn: cn=config
    changetype: modify
    replace: nsslapd-sasl-max-buffer-size
    nsslapd-sasl-max-buffer-size: 4194304
    
    modifying entry "cn=config"

    nsslapd-sasl-max-buffer-size をバイト単位で設定します。

3.4.4. sudo ルールに関する考慮事項

LDAP で sudo を使用している場合は、LDAP に保存されているsudoルールを Identity Management (IdM) に手動で移行する必要があります。Red Hat では、IdM のネットグループをホストグループとして再作成することを推奨しています。IdM は、SSSD sudoプロバイダーを使用しないsudo設定で、従来のネットグループとしてホストグループを自動的に表示します。

3.4.5. LDAP から IdM への移行ツール

LDAP ディレクトリーのデータが正しくフォーマット化され、ldM サーバーに適切にインポートされるように、Identity Management (IdM) は特定の ipa migrate-ds コマンドを使って移行プロセスを進めます。ipa migrate-ds を使用する場合は、--bind-dn オプションで指定するリモートシステムユーザーに、userPassword 属性への読み取りアクセスが必要です。読み取りアクセスがないと、パスワードが移行されません。

Identity Management サーバーは移行モードで実行するように設定してから、移行スクリプトを使用することができます。詳しくは、Migrating an LDAP server to IdMを参照してください。

3.4.6. LDAP から IdM への移行パフォーマンスの改善

LDAP の移行は、基本的には、IdM サーバー内の 389 Directory Server (DS) インスタンスに対する特殊なインポート操作です。インポート操作のパフォーマンスを向上させるために、389 DS インスタンスをチューニングすると、移行パフォーマンス全体を改善できます。

インポートのパフォーマンスに直接影響を与えるパラメーターは、以下の 2 つです。

  • nsslapd-cachememsize 属性。エントリーキャッシュに使用できるサイズを定義します。これは、キャッシュメモリーの合計サイズの 80% に自動的に設定されるバッファーです。大規模なインポート操作の場合は、このパラメーターを増やし、メモリーキャッシュ自体も増やすことができます。これにより、多数のエントリーや、大きな属性を持つエントリーを処理する際に、ディレクトリーサービスの効率が向上します。

    dsconf コマンドを使用して属性を変更する方法の詳細は、Adjusting the entry cache size を参照してください。

  • システムulimit設定オプションは、システムユーザーに許可されるプロセスの最大数を設定します。大規模なデータベースの処理が制限を超える可能性があります。これが発生した場合は、値を上げます。

    [root@server ~]# ulimit -u 4096

3.4.7. LDAP から IdM への移行シーケンス

IdM に移行する場合は、主に 4 つの手順がありますが、順序は、サーバークライアント のどちらを最初に移行するかによって異なります。

重要

クライアントファーストおよびサーバーファーストの両方の移行では、一般的な移行手順が提供されますが、すべての環境で機能するとは限りません。実際の LDAP 環境を移行する前に、テスト用の LDAP 環境を設定して移行プロセスの検証を行ってください。

クライアントファースト移行

SSSD は、Identity Management (IdM) サーバーが設定される際に、クライアント設定を変更するために使用されます。

  1. SSSD をディプロイします。
  2. クライアントが現在の LDAP サーバーに接続し IdM にフェールオーバーするよう再設定を行います。
  3. IdM サーバーをインストールします。
  4. IdM ipa migrate-ds スクリプトを使用してユーザーデータを移行します。これによりデータが LDAP ディレクトリーからエクスポートされ、IdM スキーマ用にフォーマット化されて IdM にインポートされます。
  5. LDAP サーバーをオフラインにし、クライアントが IdM に透過的にフェイルオーバーできるようにします。
サーバーファースト移行

LDAP から IdM への移行が最初に行われます。

  1. IdM サーバーをインストールします。
  2. IdM ipa migrate-ds スクリプトを使用してユーザーデータを移行します。これによりデータが LDAP ディレクトリーからエクスポートされ、IdM スキーマ用にフォーマット化されて IdM にインポートされます。
  3. オプション:SSSD をディプロイします。
  4. クライアントが IdM に接続するよう再設定を行います。LDAP サーバーと単純に差し替えることはできません。IdM ディレクトリーツリー (およびユーザーエントリーの DN) は以前のディレクトリーツリーとは異なります。

    クライアントの再設定は必要ですが、直ちに再設定を行う必要はありません。更新したクライアントは IdM サーバーをポイントし、他のクライアントは旧 LDAP ディレクトリーをポイントするためデータ移植後に適度なテストと移行段階を持たせることができます。

    注記

    LDAP ディレクトリーと IdM サーバーを長期に渡っては並行稼動させないでください。2 つのサービス間でユーザーデータの整合性が失われる危険を招くことになります。

3.5. LDAP から IdM への移行のカスタマイズ

ipa migrate-ds コマンドを使用して、LDAP サーバーから Identity Management (IdM) に認証サービスと認可サービスを移行できます。一番単純な例では移行するディレクトリーの LDAP URL を取得し、共通デフォルト設定をもとにデータをエクスポートします。

別の ipa migrate-ds コマンドオプションを使用すると、移行プロセスをカスタマイズし、データの識別およびエクスポート方法をカスタマイズできます。LDAP ディレクトリーツリーに一意の構造がある場合、またはエントリー内の特定のエントリーまたは属性を除外する必要がある場合は、移行をカスタマイズします。

3.5.1. LDAP から IdM への移行時にバインド DN およびベース DN をカスタマイズする例

ipa migrate-ds コマンドを使用して、LDAP から Identity Management (IdM) に移行します。一番単純な例では移行するディレクトリーの LDAP URL を取得し、共通デフォルト設定をもとにデータをエクスポートします。このセクションでは、デフォルト設定の変更例を説明します。

# ipa migrate-ds ldap://ldap.example.com:389
バインド DN のカスタマイズ

デフォルトでは、DN "cn=Directory Manager" は、リモート LDAP ディレクトリーにバインドするために使用されます。--bind-dn オプションを使用して、カスタムバインド DN を指定します。

# ipa migrate-ds ldap://ldap.example.com:389 --bind-dn=cn=Manager,dc=example,dc=com
命名コンテキストのカスタマイズ

LDAP サーバーの命名コンテキストが IdM で使用されているものと異なる場合は、オブジェクトのベース DN が変換されます。たとえば、uid=user,ou=people,dc=ldap,dc=example,dc=com は、uid=user,ou=people,dc=idm,dc=example,dc=com に移行されます。--base-dn を使用して、コンテナーサブツリーのターゲットを変更し、移行にリモート LDAP サーバーで使用するベース DN を設定できます。

# ipa migrate-ds --base-dn="ou=people,dc=example,dc=com" ldap://ldap.example.com:389

関連情報

  • ipa migrate-ds --help

3.5.2. 特定のサブツリーの移行

デフォルトのディレクトリー構造の場合、人のエントリーは ou=People サブツリーに配置され、グループのエントリーは ou=Groups サブツリーに配置されます。こうしたサブツリーは異なるタイプのディレクトリーデータ用のコンテナーエントリーになります。migrate-ds コマンドでオプションが渡されていない場合、ユーティリティーは、指定の LDAP ディレクトリーが ou=People および ou=Groups 構造を使用していることを前提とします。

多くのデプロイメントは完全に異なるディレクトリー構造をしている場合があります。または、元のディレクトリーツリーの特定部分のみをエクスポートする場合もあります。管理者は、以下のオプションを使用して、ソース LDAP サーバーの別のユーザーまたはグループのサブツリーの RDN を指定できます。

  • --user-container
  • --group-container
注記

いずれの場合も、サブツリーは相対識別名 (RDN) でなければならず、ベース DN に相対的である必要があります。たとえば、--user-container=ou=Employees を使用して、>ou=Employees,dc=example,dc=com ディレクトリーツリーを移行できます。

以下に例を示します。

[ipaserver ~]# ipa migrate-ds --user-container=ou=employees \
--group-container="ou=employee groups" ldap://ldap.example.com:389

必要に応じて、--scope オプションを ipa migrate-ds コマンドに追加して、スコープを設定します。

  • onelevel: デフォルト。指定したコンテナーのエントリーのみが移行されます。
  • subtree: 指定したコンテナーおよびすべてのサブコンテナーのエントリーが移行されます。
  • base: 指定されたオブジェクト自体のみが移行されます。

3.5.3. エントリーの追加と除外

デフォルトでは、ipa migrate-ds スクリプトは、person オブジェクトクラスを持つすべてのユーザーエントリーと、groupOfUniqueNames オブジェクトクラスまたは groupOfNames オブジェクトクラスを持つすべてのグループエントリーをインポートします。

一部の移行パスでは、特定のタイプのユーザーとグループのみをエクスポートする必要がある場合や、あるいは特定のユーザーとグループを除外する必要がある場合があります。ユーザーまたはグループのエントリーを検索する際に、検索するオブジェクトクラスを設定することで、含めるユーザーとグループのタイプを選択できます。

このオプションは、さまざまなユーザータイプにカスタムオブジェクトクラスを使用する場合にとりわけ役立ちます。たとえば、次のコマンドは、カスタムfullTimeEmployee オブジェクトクラスを持つユーザーのみを移行します。

[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee ldap://ldap.example.com:389

グループの種類が異なるため、これは、ユーザーグループなどの特定の種類のグループのみを移行し、証明書グループなどの他の種類のグループを除外する場合にも非常に役立ちます。以下に例を示します。

[root@ipaserver ~]# ipa migrate-ds --group-objectclass=groupOfNames --group-objectclass=groupOfUniqueNames ldap://ldap.example.com:389

オブジェクトクラスに基づいて移行するユーザーとグループのエントリを指定すると、他のすべてのユーザーとグループが移行から暗黙的に除外されます。

また、ごく少数のエントリー以外、すべてのユーザーとグループのエントリーを移行する場合にも便利です。そのタイプの他のすべてを移行するときに、特定のユーザーまたはグループアカウントを除外できます。たとえば、これは趣味のグループと 2 人のユーザーのみを除外します。

[root@ipaserver ~]# ipa migrate-ds --exclude-groups="Golfers Group" --exclude-users=idmuser101 --exclude-users=idmuser102 ldap://ldap.example.com:389

exclude ステートメントは、uid でパターンに一致するユーザーと、cn 属性でパターンに一致するグループに適用されます。

一般的なオブジェクトクラスを移行できますが、そのクラスの特定のエントリーは除外できます。たとえば、これには特に fullTimeEmployee オブジェクトクラスを持つユーザーが含まれますが、3 つのマネージャーは除外されます。

[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee --exclude-users=jsmith --exclude-users=bjensen --exclude-users=mreynolds ldap://ldap.example.com:389

3.5.4. エントリー属性の除外

デフォルトではユーザーやグループエントリーのすべての属性とオブジェクトクラスが移行されます。特定のシナリオでは、帯域幅とネットワークの制約のため、または属性データが関連しなくなったために、これは現実的ではない場合があります。たとえば、ユーザーが Identity Management (IdM) ドメインに参加する際に新しいユーザー証明書が割り当てられる場合は、userCertificate 属性を移行しても意味がありません。

migrate-ds コマンドで以下のオプションを使用すると、特定のオブジェクトクラスおよび属性を無視できます。

  • --user-ignore-objectclass
  • --user-ignore-attribute
  • --group-ignore-objectclass
  • --group-ignore-attribute

たとえば、ユーザーの userCertificate 属性および strongAuthenticationUser オブジェクトクラスとグループの groupOfCertificates オブジェクトクラスを除外するには、次のコマンドを実行します。

[root@ipaserver ~]# ipa migrate-ds --user-ignore-attribute=userCertificate --user-ignore-objectclass=strongAuthenticationUser --group-ignore-objectclass=groupOfCertificates ldap://ldap.example.com:389
注記

必要な属性が無視されていないか必ず確認します。また、オブジェクトクラスを除外する場合は、そのオブジェクトクラスのみがサポートする属性を必ず除外してください。

3.5.5. LDAP から IdM への移行時に使用するスキーマとスキーマ互換機能

Identity Management (IdM) は、RFC2307bis スキーマを使用して、ユーザー、ホスト、ホストグループ、およびその他のネットワーク ID を定義します。ただし、移行のソースとして使用する LDAP サーバーが、代わりに RFC2307 スキーマを使用する場合は、ipa migrate-ds コマンドで --schema オプションを指定します。

[root@ipaserver ~]# ipa migrate-ds --schema=RFC2307 ldap://ldap.example.com:389

また、IdM には組み込みのスキーマの互換機能 があるため、RFC2307bis に対応していないシステムのデータを IdM が再フォーマットできます。compat プラグインはデフォルトで有効になっています。つまり、ディレクトリーサーバーは、ユーザーとグループの代替ビューを計算し、cn=users,cn=compat,dc=example,dc=com コンテナーエントリーにこのビューを提供します。これは、システムの起動時にエントリーの内容を事前に計算して、必要に応じてエントリーを更新することで行われます。

システムのオーバーヘッドを低減するために、この機能は移行中に無効にすることが推奨されます。

3.6. LDAP サーバーの IdM への移行

ipa migrate-ds コマンドを使用して、LDAP サーバーから Identity Management (IdM) に認証サービスと認可サービスを移行できます。

警告

この例は一般的な移行手順のため、あらゆる環境に対応するわけではありません。

実際に LDAP 環境の移行に入る前に、LDAP のテスト環境を設定して移行プロセスを検証することを強く推奨します。環境をテストする場合は、以下を行います。

  1. IdM でテストユーザーを作成し、移行したユーザーの出力を、テストユーザーの出力と比較します。
  2. IdM にあるように、移行したユーザーの出力を、元の LDAP サーバーにあるように、ソースユーザーと比較します。

詳細なガイダンスは、以下の 検証 のセクションを参照してください。

前提条件

手順

  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 GuideConfiguring 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回コピーされていないこと、およびそれらが正しい値を持っていることを確認してください。

3.7. Migrating from LDAP to IdM over SSL

ipa migrate-ds コマンドを使用して、LDAP サーバーから Identity Management (IdM) に認証サービスと認可サービスを移行できます。本セクションでは、移行中に送信するデータを暗号化する方法を説明します。

警告

この例は一般的な移行手順のため、あらゆる環境に対応するわけではありません。

実際に LDAP 環境の移行に入る前に、LDAP のテスト環境を設定して移行プロセスを検証することを強く推奨します。環境をテストする場合は、以下を行います。

  1. IdM でテストユーザーを作成し、移行したユーザーの出力を、テストユーザーの出力と比較します。
  2. IdM にあるように、移行したユーザーの出力を、元の LDAP サーバーにあるように、ソースユーザーと比較します。

詳細なガイダンスは、以下の 検証 のセクションを参照してください。

前提条件

手順

  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回コピーされていないこと、およびそれらが正しい値を持っていることを確認してください。