Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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

管理者として、認証および ID 検索用に LDAP サーバーをデプロイしてあるので、次にバックエンドを Identity Management に移行する必要があります。IdM 移行ツールを使用して、データを失うことなく、パスワードやグループなどのユーザーアカウントを転送します。また、クライアントでの高価な設定更新を回避する場合もあります。
ここで説明する移行プロセスは、LDAP に 1 つ、IdM に 1 つの名前空間がある単純な導入シナリオを想定しています。複数の名前空間やカスタムスキーマなど、より複雑な環境では、Red Hat サポートサービスにお問い合わせください。

39.1. LDAP から IdM への移行の概要

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

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

Identity Management はさまざまなレベルの機能性、柔軟性、安全性で多数の異なるクライアント設定に対応することができます。クライアントのオペレーティングシステム、機能領域 (開発用マシン、実稼動サーバー、ユーザーのラップトップ)、IT メンテナンスの優先性などに応じて クライアントごと個別に 最適となる設定を選択してください。
重要
異なるクライアント設定は 相互に排他的とはなりません。ほとんどの環境でクライアントが IdM ドメインへの接続に使用する方法はクライアントによって異なっています。管理者は各クライアント別に最適となるシナリオを決定しなければなりません。

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

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

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

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

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

Red Hat Enterprise Linux には、SSSD (System Security Services Daemon) と呼ばれるサービスがあります。SSSD は、特別な PAM ライブラリーおよび NSS ライブラリー (pam_sss および nss_ss) を使用して、SSSD を Identity Management と密接に統合し、Identity Management の完全な認証およびアイデンティティー機能を利用できます。このライブラリーによって SSSD と ∏ の緊密な統合が行われ、∏ の認証機能および ID 機能をフル活用することができるようになります。中央サーバーとの接続が失われた場合でもユーザーがログインできるよう ID 情報をキャッシングできる機能など、SSSD には便利な機能が多数搭載されています。こうした便利な機能については 『System-Level Authentication Guide』 で詳しく説明しています。
汎用の 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 によりシームレスに行われます。

図39.2 IdM バックエンドのあるクライアントおよび SSSD

IdM バックエンドのあるクライアントおよび SSSD
ipa-client-install スクリプトは、その 4 つのバックエンドサービスすべてに IdM を使用するよう SSSD を自動的に設定するため、Red Hat Enterprise Linux クライアントはデフォルトで推奨される設定で設定されます。
注記
このクライアント設定は、最新バージョンの SSSD と ipa-client に対応している Red Hat Enterprise Linux 6.1 以降および Red Hat Enterprise Linux 5.7 以降でのみサポートされています。「推奨設定以外で対応している設定」 の説明に従って、Red Hat Enterprise Linux の古いバージョンを設定できます。

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

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

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

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

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

LDAP から Identity Management への移行に影響を及ぼす可能性がある最も注目すべき問題は、ユーザーパスワードの移行です。
Identity Management (デフォルトでは) は認証に Kerberos を使用し、各ユーザーには、標準のユーザーパスワードに加えて、Identity Management Directory Server に保存されている Kerberos ハッシュが必要です。このハッシュを生成するため、IdM サーバー側でユーザーのパスワードがクリアテキストで使用できなければなりません。ユーザーを作成すると、パスワードがハッシュされ、Identity Management に保存される前に、平文で利用できるようになります。ただし、ユーザーを LDAP ディレクトリーから移行する場合には関連するユーザーパスワードがすでにハッシュ化されているため該当する Kerberos キーは生成できません。
重要
ユーザーは、IdM ドメインに対して認証したり、IdM リソースにアクセスしたり、Kerberos ハッシュがなくなるまでできません。
ユーザーが Kerberos ハッシュを持たない場合[6]ユーザーアカウントがある場合でも、そのユーザーは IdM ドメインにログインできません。パスワード移行にはパスワード変更の実施、web ページの使用、SSSD の使用の 3 通りの方法があります。
既存システムからユーザーを移行すると遷移プロセスはスムースですが、移行と遷移期間を通じて LDAP ディレクトリーおよび IdM を平行管理する必要があります。パスワードを維持しない場合は、移行はより迅速に行うことができますが管理者およびユーザーによる手作業が多く必要になります。

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

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

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

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

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

SSSD は IdM と連携し必要なユーザーキーを生成することで移行の際にユーザーに与える影響を軽減することができます。大量のユーザーを導入する場合やユーザーにパスワード変更の面倒をかけさせない場合に最適なシナリオです。
  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 認証を再試行します。この場合、エンティティーにハッシュが存在しているため要求は成功します。
プロセス全体がユーザーに対しては透過的に行われるため、ユーザーは単純にクライアントサービスにログインし、通常通りに動作したということしかわかりません。

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

ほとんどのデプロイメントでは暗号化された LDAP パスワードが格納されますが、ユーザーまたは環境によってユーザーエンティティーにクリアテキストのパスワードが使用される場合があります。
ユーザーが LDAP サーバーから IdM サーバーに接続すると、クリアテキストのパスワードは移行されません。ID 管理では、クリアテキストのパスワードは許可されません。Kerberos プリンシパルはユーザーに作成され、キータブは true に設定されます。また、パスワードは期限が切れたときに設定されます。つまり、Identity Management では、次回ログイン時にパスワードをリセットする必要があります。
注記
パスワードがハッシュ化されると、「方法 2: 移行用 Web ページの使用」および「方法 3: SSSD の使用 (推奨)」と同様に SSSD および移行用 web ページからの移行に成功します。

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

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

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

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

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

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

Red Hat Directory Server と Identity Management には多くの異なる設定シナリオがあり、これらのシナリオのいずれかが移行プロセスに影響を及ぼす可能性があります。本章で説明している移行例の場合、以下に示すような環境を想定しています。
  • 1 つの LDAP ディレクトリードメインが、1 つの IdM レルムに移行中です。統合はありません。
  • ユーザーパスワードは、LDAP ディレクトリーにハッシュ形式で保存されます。サポートされるハッシュのリストは、passwordStorageScheme 属性 (表 19.2パスワードポリシー関連の属性、『Red Hat Directory Server 10 管理ガイド』) を参照してください。
  • LDAP ディレクトリーインスタンスは ID 格納および認証方法の両方になります。クライアントマシンは、pam_ldap または nss_ldap を使用して LDAP サーバーに接続するように設定されます。
  • エントリーは標準の LDAP スキーマのみを使用します。カスタムオブジェクトクラスまたはカスタム属性を含むエントリーは、Identity Managment に移行されません。

39.1.3.3. 移行 - IdM のシステム要件

中程度のサイズのディレクトリー (約 10,000 ユーザー、および 10 グループ) では、移行を続行するのに十分な強力なターゲットシステム (IdM システム) が必要です。移行の最小要件は以下のとおりです。
  • 4 コア
  • 4 GB のメモリー
  • 30GB のディスク領域
  • SASL バッファーサイズの 2MB (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 をバイト単位で設定します。

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

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

39.1.3.5. 移行ツール

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

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

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

39.1.3.7. 移行順序

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 の機能が制限されるため、推奨されません。