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

管理者として認証およびアイデンティティールックアップ用の LDAP サーバーをデプロイしたので、次に Identity Management にバックエンドを移行します。IdM 移行ツールを使用して、パスワードやグループなどユーザーアカウントをデータを損失することなく転送します。また、クライアント上での大規模なコストのかかる設定更新を回避することができます。
ここに記載の移行プロセスは、LDAP に名前空間が 1 つ、IdM に 1 つという単純なデプロイメントシナリオが想定さrています。複数の名前空間やカスタムのスキーマなど、より複雑な環境については、Red Hat サポートサービスにお問い合わせください。

37.1. LDAP から IdM への移行に関する概要

LDAP サーバーから Identity Management に移動する実際の移行部分はかなり単純です (1 つのサーバーから別のサーバーにデータを移動させるプロセス)。データ、パスワード、クライアントの順で移動する単純なプロセスです。
最もコストのかかる移行プロセスは、Identity Management を使用するようにクライアントをどのように設定するかを決定する部分です。インフラストラクチャーのクライアントごとに、どのサービス (Kerberos、SSSD など) を使用して最終的なIdM デプロイメントで使用可能なサービスがどれかを決定する必要があります。
2 番目に重要な考慮事項はパスワードの移行方法の計画です。Identity Management ではパスワードに加え各ユーザーアカウントすべてに Kerberos ハッシュが必要になります。パスワードの移行パスおよび考慮すべき点については、いくつか 「パスワード移行のプランニング」 で説明しています。

37.1.1. クライアント設定のプランニング

Identity Management はさまざまなレベルの機能性、柔軟性、安全性で多数の異なるクライアント設定に対応することができます。クライアントのオペレーティングシステム、機能領域 (開発用マシン、実稼動サーバー、ユーザーのラップトップ)、IT メンテナンスの優先性などに応じて クライアントごと個別に 最適となる設定を選択してください。

重要

異なるクライアント設定は 相互に排他的とはなりません。 ほとんどの環境でクライアントが IdM ドメインへの接続に使用する方法はクライアントによって異なっています。管理者は各クライアント別に最適となるシナリオを決定しなければなりません。

37.1.1.1. クライアント初期設定 (移行前)

Identity Management でのクライアント設定を決定する前にまず移行前の状態を確認します。
移行予定の LDAP デプロイメントの初期の状態の場合、ほとんど全てに ID および認証サービスを提供している LDAP サービスがあります。
基本的な LDAP ディレクトリーとクライアント設定

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

Linux および Unix のクライアントは PAM_LDAP と NSS_LDAP ライブラリーを使って LDAP サービスに直接接続を行います。このライブラリーを使ってクライアントはユーザー情報を LDAP ディレクトリーから取得します。まるでデータが /etc/passwd/etc/shadow に格納されていたかのように見えます。(現実的には ID 検索に LDAP、認証に Kerberos や別の設定を使用している場合などインフラストラクチャーはもう少し複雑になる場合があります。)
LDAP ディレクトリーと IdM サーバーの間には特にスキーマサポートとディレクトリーツリーに構造的な違いがあります (構造的な違いの背景については「Identity Management と標準 LDAP ディレクトリーの比較」を参照してください)。こうした違いはデータ (特にエントリー名に影響するディレクトリーツリー) には影響する可能性がありますが クライアントの設定 にはほとんど影響しないため、Identity Management にクライアントを移行させる上では実際にはほとんど影響がありません。

37.1.1.2. Red Hat Enterprise Linux クライアント向けの推奨設定

Red Hat Enterprise Linux には System Security Services Daemon (SSSD) と呼ばれるサービスがあります。SSSD は特殊な PAM と NSS ライブラリー (pam_sssnss_sss) を使用します。このライブラリーによって SSSD と Identity Management の緊密な統合が行われ、Identity Management の認証機能および ID 機能をフル活用することができるようになります。中央サーバーとの接続が失われた場合でもユーザーがログインできるよう ID 情報をキャッシングできる機能など、SSSD には便利な機能が多数搭載されています。こうした便利な機能については 『システムレベルの認証ガイド』 で詳しく説明しています。
汎用の LDAP ディレクトリーサービス (pam_ldapnss_ldap を使用する) とは異なり、SSSD は ドメイン 定義によって ID 情報と認証情報間の関係を確立します。SSSD のドメインは認証、ID 検索、アクセス、パスワード変更の 4 つのバックエンド機能を定義します。この SSSD ドメインを 4 つの機能のうちの 1 つの機能 (またはすべて) の情報を提供する プロバイダー を使用するよう設定します。ID プロバイダーはドメイン設定に必ず必要になります。他の 3 つのプロバイダーはオプションです。認証、アクセス、またはパスワードプロバイダーが定義されていない場合は ID プロバイダーがその機能に使用されます。
SSSD ではそのすべてのバックエンド機能に Identity Management を使用できるため理想的な設定になります。LDAP ID の汎用プロバイダーや Kerberos 認証とは異なり、多岐に渡る Identity Management の機能性をすべて利用することができます。たとえば、SSSD では 日常的な運用時に、Identity Management でセキュリティー機能やホストベースのアクセス制御ルールを有効化させることができます。

注記

LDAP ディレクトリーから Identity Management への移行プロセスではユーザーによる介入を必要とすることなくユーザーのパスワード移行が SSSD によりシームレスに行われます。
IdM バックエンドによるクライアントおよび SSSD

図37.2 IdM バックエンドによるクライアントおよび SSSD

ipa-client-install スクリプトにより自動的に SSSD がバックエンドの全 4 サービスに IdM を使用するよう設定されるため、Red Hat Enterprise Linux クライアントはデフォルトで推奨設定にセットアップされます。

注記

このクライアント設定に対応するのは最新の SSSD と ipa-client のバージョンに対応する Red Hat Enterprise Linux 6.1 以降および Red Hat Enterprise Linux 5.7 以降のみになります。これより旧式の Red Hat Enterprise Linux については 「推奨設定以外で対応している設定」 の説明に従って設定を行ってください。

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

Mac、Solaris、HP-UX、AIX、Scientific Linux などの Unix および Linux システムでは IdM で管理されるすべてのサービスに対応していますが SSSD は使用しません。同様に旧式の Red Hat Enterprise Linux バージョン (6.1 および 5.6) は SSSD には対応しますが、ID プロバイダーの IdM には対応していない旧バージョンが搭載されています。
最近の SSSD バージョンを使用できない場合は、IdM サーバーへの接続は ID 検索用 LDAP ディレクトリーサービスへの接続のようにクライアントを設定します (nss_ldap を使用) 。また IdM への接続は通常の Kerberos KDC への接続のように設定を行います (pam_krb5 を使用)。
LDAP と Kerberos を使用したクライアントと IdM

図37.3 LDAP と Kerberos を使用したクライアントと IdM

Red Hat Enterprise Linux クライアントで旧式の SSSD バージョンを使用している場合、IdM サーバーを ID プロバイダーおよびその Kerberos 認証ドメインとして使用するよう SSSD を設定することができます。詳細については 『システムレベルの認証ガイド』 の SSSD 設定セクションで説明しています。
IdM ドメインクライアントはいずれも、nss_ldappam_krb5 を使用して IdM サーバーに接続するよう設定することができます。共通する構成要素が最低限となるようなメンテナンス環境や IT インフラストラクチャーなどの場合には LDAP を ID と認証の両方に使用する必要があるかもしれません (nss_ldappam_ldap)。ただし、クライアントにはできる限り安全な設定を使用するのが一般的にはベストプラクティスです (つまり SSSD と Kerberos または LDAP と Kerberos)。

37.1.2. パスワード移行のプランニング

LDAP から Identity Management への移行に影響する可能性がある問題としてもっともよく知られているのが恐らくユーザーのパスワード移行でしょう。
Identity Management では認証に Kerberos を使用し (デフォルト)、各ユーザーには標準のユーザーパスワード以外にも Identity Management Directory Server に格納する Kerberos ハッシュが必要になります。このハッシュを生成するため、IdM サーバー側でユーザーのパスワードがクリアテキストで使用できなければなりません。ユーザーの作成時は、パスワードがハッシュ化されて、Identity Management に保存される前に、パスワードをクリアテキストの状態で入手できる状態です。ただし、ユーザーを LDAP ディレクトリーから移行する場合には関連するユーザーパスワードがすでにハッシュ化されているため該当する Kerberos キーは生成できません。

重要

ユーザーに Kerberos ハッシュを持たせるまでユーザーによる IdM ドメインへの認証や IdM リソースへのアクセスは行えません。
ユーザーに Kerberos ハッシュがない場合[6]、そのユーザーはユーザーアカウントがあっても IdM ドメインにログインすることができません。パスワード移行にはパスワード変更の実施、web ページの使用、SSSD の使用の 3 通りの方法があります。
既存システムからユーザーを移行すると遷移プロセスはスムースですが、移行と遷移期間を通じて LDAP ディレクトリーおよび IdM を平行管理する必要があります。パスワードを維持しない場合は、移行はより迅速に行うことができますが管理者およびユーザーによる手作業が多く必要になります。

37.1.2.1. 方法 1: 一時的なパスワードの使用とパスワード変更の強制

Identity Management でパスワードを変更すると、適切な Kerberos ハッシュも作成されます。このため方法 の 1 つとしてユーザーアカウントの移行時にすべてのユーザーパスワードをリセットしてユーザーにパスワードの変更を強制する方法があります。新規ユーザーには一時的なパスワードが割り当てられ、初回のログインで変更することになります。パスワードの移行はありません。
詳細情報は「ユーザーパスワードの変更およびリセット」を参照してください。

37.1.2.2. 方法 2: 移行用 Web ページの使用

移行モードで実行している場合は Identity Management の web UI 内に特殊な web ページが用意されています。このページを使用するとクリアテキストのパスワードのキャプチャと適切な Kerberos ハッシュの作成が行われます。
https://ipaserver.example.com/ipa/migration
管理者はユーザーに対して上記の web ページで一度だけ認証を行うよう通知します。これによりユーザーのアカウントがユーザーのパスワードと Kerberos ハッシュで正しく更新されます。パスワードの変更は必要ありません。

37.1.2.3. 方法 3: SSSD の使用 (推奨)

SSSD は IdM と連携し必要なユーザーキーを生成することで移行の際にユーザーに与える影響を軽減することができます。大量のユーザーを導入する場合やユーザーにパスワード変更の面倒をかけさせない場合に最適なシナリオです。
  1. ユーザーが SSSD でマシンにログインします。
  2. SSSD は Kerberos 認証を IdM サーバーに対して試行します。
  3. ユーザーがシステムに存在していも Kerberos ハッシュがないため key type is not supported エラーで認証に失敗します。
  4. SSSD は次に安全な接続でプレーンテキストの LDAP バインドを行います。
  5. IdM によってこのバインド要求が遮断されます。ユーザーが Kerberos プリンシパルは持っているのに Kerberos ハッシュを持っていない場合、IdM ID プロバイダーはハッシュを生成してユーザーのエンティティーに格納します。
  6. 認証に成功すると SSSD は IdM との接続を切断し Kerberos 認証を再試行します。この場合、エンティティーにハッシュが存在しているため要求は成功します。
プロセス全体がユーザーに対しては透過的に行われるので、ユーザーは単純にクライアントサービスにログインし、通常通りに動作したということしかわかりません。

37.1.2.4. クリアテキスト LDAP パスワードの移行

ほとんどのデプロイメントでは暗号化された LDAP パスワードが格納されますが、ユーザーまたは環境によってユーザーエンティティーにクリアテキストのパスワードが使用される場合があります。
ユーザーを LDAP サーバーから IdM サーバーに移行する場合にはクリアテキストのパスワードは移行されません。Identity Management はクリアテキストのパスワードを許可していません。代わりにユーザーには Kerberos プリンシパルが作成され、keytab が true に設定されるためパスワードは有効期限切れとして設定されます。つまり、次回のログインでユーザーによるパスワードのリセットが必要になります。

注記

パスワードがハッシュ化されると「方法 2: 移行用 Web ページの使用」「方法 3: SSSD の使用 (推奨)」と同様に SSSD および移行用 web ページからの移行に成功します。

37.1.2.5. 要件を満たしていないパスワードの自動リセット

オリジナルのディレクトリーにあるユーザーパスワードが Identity Management で定義されているパスワードポリシーに合わない場合は移行後にパスワードのリセットが必要になります。
パスワードのリセットはユーザーが kinit をはじめて IdM ドメインで発行したときに自動的に行われます。
[jsmith@server ~]$ kinit 
Password for jsmith@EXAMPLE.COM: 
Password expired.  You must change it now.
Enter new password: 
Enter it again:

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

LDAP から Identity Management に移行を計画している場合には、使用する LDAP 環境が Identity Management の移行スクリプトで正しく動作できることを確認してください。

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

LDAP から Identity Management への移行プロセスで移行を行う際に特殊なスクリプト ipa migrate-ds が使用されます。このスクリプトは正しく動作するため LDAP ディレクトリーおよび LDAP エントリーに一定の構造を期待します。移行に対応しているのは複数の共通ディレクトリーを含む LDAPv3 準拠のディレクトリーサービスのみになります。
  • Sun ONE Directory Server
  • Apache Directory Server
  • OpenLDAP
LDAP サーバーから Identity Management への移行は Red Hat Directory Server および OpenLDAP でテストが行われています。

注記

Microsoft Active Directory の場合、移行用スクリプトを使った移行には対応していません。Microsoft Active Directory は LDAPv3 準拠のディレクトリーではありません。Active Directory からの移行については Red Hat プロフェッショナルサービスにご連絡ください。

37.1.3.2. 移行環境に関する要件

Red Hat Directory Server と Identity Management はいずれもさまざまに異なる設定状況が考えられ、それぞれに移行プロセスに影響を与える可能性があります。本章で説明している移行例の場合、以下に示すような環境を想定しています。
  • 1 つの LDAP ディレクトリードメインを 1 つの IdM レルムに移行します。統合はありません。
  • ユーザーのパスワードは LDAP ディレクトリー内にハッシュで格納されています。サポートされているハッシュの一覧は、『Red Hat Directory Server 10 Administration Guide』の「Password Policy Attributes」の表 に含まれる passwordStorageScheme 属性を参照してください。
  • LDAP ディレクトリーインスタンスは ID 格納および認証方法の両方になります。クライアントのマシンは LDAP サーバーへの接続に pam_ldap または nss_ldap を使用するよう設定します。
  • エントリーに使用するのは標準の LDAP スキーマのみです。カスタムオブジェクトクラスまたは属性に含まれるエントリーは Identity Management には移行されません。

37.1.3.3. 移行 — IdM システムの要件

中規模サイズのディレクトリーの場合 (ユーザー数 10,000、グループ数 10 程度)、移行を進めるには移行先のシステム (IdM システム) に十分な性能を必要とします。移行に最小限必要となる要件を以下に示します。
  • 4 コア
  • 4GB の RAM
  • 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 の値をバイト単位で設定します。

37.1.3.4. 移行ツール

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

37.1.3.5. 移行のパフォーマンス改善

LDAP 移行とは基本的に IdM サーバー内の 389 Directory Server インスタンスに対する特殊なインポート動作になります。インポート動作のパフォーマンスがよくなるよう 389 Directory Server インスタンスをチューニングすると移行の全体的なパフォーマンスが向上します。
インポートのパフォーマンスに直接影響するパラメーターが 2 種類あります。
  • nsslapd-cachememsize 属性、エントリーキャッシュに許可するサイズを定義します。キャッシュの合計メモリーサイズの 80% に自動的に設定されるバッファです。大規模なインポート動作の場合にはこのパラメーター (およびメモリーキャッシュ自体) を増やして多数のエントリーまたは大きい属性を持つエントリーをより効率的に処理できるようにします。
    ldapmodify を使用して属性を変更する方法は、『Red Hat Directory Server Performance Tuning Guide』の該当のセクション を参照してください。
  • システムの ulimit 設定オプションでは、システムユーザーに対して許可するプロセス数の最大値を設定します。大規模なデータベースを処理すると上限を超える可能性があります。このような場合には、値を増やしてください。
    [root@server ~]# ulimit -u 4096
詳しい情報は、Red Hat Directory Server 『Performance Tuning Guide』のhttps://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html-single/Performance_Tuning_Guide/index.htmlを参照してください。

37.1.3.6. 移行順序

Identity Management への移行は大きく分けて 4 ステップになります。ただし、サーバーを先に移行するのかクライアントを先に移行するのかによってこの順序は若干異なります。
クライアントを先に移行する場合は SSSD を使ってクライアント設定を変更し、IdM サーバーを設定します。
  1. SSSD を導入します。
  2. クライアントが現在の LDAP サーバーに接続し IdM にフェールオーバーするよう再設定を行います。
  3. IdM サーバーをインストールします。
  4. IdM の ipa migrate-ds スクリプトを使ってユーザーデータの移行を行います。これによりデータが LDAP ディレクトリーからエクスポートされ、IdM スキーマ用にフォーマット化されて IdM にインポートされます。
  5. LDAP サーバーをオフラインにしてクライアントを透過的に Identity Management にフェールオーバーさせます。
サーバーを先に移行する場合は、LDAP から Identity Management への移行を最初に行います。
  1. IdM サーバーをインストールします。
  2. IdM の ipa migrate-ds スクリプトを使ってユーザーデータの移行を行います。これによりデータが LDAP ディレクトリーからエクスポートされ、IdM スキーマ用にフォーマット化されて IdM にインポートされます。
  3. オプションです。SSSD を導入します。
  4. クライアントが IdM に接続するよう再設定を行います。LDAP サーバーと単純に差し替えることはできません。IdM ディレクトリーツリー — およびユーザーエントリーの DN — は以前のディレクトリーツリーとは異なります。
    クライアントの再設定は必要ですが、直ちに再設定を行う必要はありません。更新したクライアントは IdM サーバーをポイントし、他のクライアントは旧 LDAP ディレクトリーをポイントするためデータ移植後に適度なテストと移行段階を持たせることができます。

    注記

    LDAP ディレクトリーと IdM サーバーを長期に渡っては並行稼動させないでください。2 つのサービス間でユーザーデータの整合性が失われる危険を招くことになります。
どちらも一般的な移行手順になりますが、すべての環境では動作しない場合があります。実際の LDAP 環境を移行する前に、テスト用の LDAP 環境を設定して移行プロセスの検証を行ってください。


[6] Kerberos 認証の代わりに Identity Management では LDAP を使用することができます。この場合ユーザーに Kerberos ハッシュは必要ありません。ただし、これを行うと Identity Management の機能性が制限されるため推奨していません。