第40章 認証および相互運用性

bind-dyndb-ldap システムプラグインの最新バージョンでは、以前のバージョンに対して大幅に改善されていますが、現在いくつかの制限があります。制限の 1 つは LDAP 名前変更(MODRDN)操作のサポートがありません。そのため、LDAP で名前が変更された DNS レコードが正しく提供されません。この問題を回避するには、named デーモンを再起動して、MODRDN 操作ごとにデータを再同期します。Identity Management (IdM)クラスターで、すべての IdM レプリカで named デーモンを再起動します。

userRoot.ldif ファイルおよび ipaca.ldif ファイル(Identity Management (IdM)がバックアップからの復元時にバックエンドを再インポート)は、IdM バックアップを含む tar アーカイブに存在していても、完全なサーバー復元中に開くことができません。そのため、これらのファイルはサーバーのフル復元時にスキップされます。サーバーのフルバックアップから復元すると、復元されたバックエンドはバックアップの作成後に一部の更新を受け取ることができます。バックアップが作成された時間と復元が実行される時間の間に受信されたすべての更新が失われるため、これは想定されていません。サーバーが正常に復元されましたが、無効なデータが含まれる可能性があります。レプリカの初期化に無効なデータを含む復元されたサーバーを使用すると、レプリカの再初期化は成功しますが、レプリカのデータは無効になります。

現在利用できる回避策はありません。完全なサーバー IdM バックアップから復元されたサーバーを使用してレプリカを再初期化することが推奨されます。これにより、復元および再初期化プロセスの最後に予期しない更新が存在しないことを確認することが推奨されます。

この既知の問題は、データのみの IdM 復元ではなく、完全なサーバー IdM 復元にのみ関連します。

Identity Management (IdM)と AD へのフォレスト間の信頼を使用して Active Directory (AD)ユーザーがレガシークライアントにアクセスできるように Schema Compatibility プラグインが設定されている場合、AD ユーザーの複雑なグループメンバーシップを解決する要求を受信すると、389 Directory Server は特定の条件下で CPU 消費を増やすことができます。

Identity Management (IdM)サーバーをバックアップから復元し、復元したデータを他のレプリカに再初期化しても、スキーマ互換性プラグインは復元および再初期化を実行する前に古いデータのキャッシュを維持できます。その結果、レプリカが予期せず動作する可能性があります。たとえば、バックアップの実行後に最初に追加されたユーザーの追加を試み、復元および再初期化の手順で削除された場合、スキーマ互換性キャッシュには競合するユーザーエントリーが含まれるため、操作はエラーで失敗する可能性があります。この問題を回避するには、マスターサーバーから再利用した後に IdM レプリカを再起動します。これにより、スキーマ互換性キャッシュがクリアされ、上記の状況でレプリカが期待どおりに動作するようになります。

匿名ユーザーと認証されたユーザーは、Red Hat Enterprise Linux 7.1 バージョンの Identity Management (IdM)にアップグレードした後に facsimiletelephonenumber ユーザー属性を読み取るデフォルトのパーミッションを失います。新しいデフォルト設定を手動で変更し、属性を再度読み取りできるようにするには、以下のコマンドを実行します。

ipa permission-mod 'System: Read User Addressbook Attributes' --includedattrs facsimiletelephonenumber

ホストの DNS ゾーンが完全修飾されていない場合、ipa host-del --updatedns コマンドはホストの DNS レコードを更新しません。Red Hat Enterprise Linux 7.0 および 6 では、修飾されていないゾーンを作成できました。修飾されていない DNS ゾーンで ipa host-del --updatedns を実行すると（例：完全修飾 example.test. ではなく、ドット(.)）、コマンドは内部エラーで失敗し、DNS レコードではなくホストが削除されます。この問題を回避するには、Red Hat Enterprise Linux 7.0 または 6 を実行している IdM サーバーで ipa host-del --updatedns コマンドを実行します。ここで、ホスト DNS レコードの更新が期待どおりに機能するか、Red Hat Enterprise Linux 7.1 でコマンドを実行してからホスト DNS レコードを手動で更新します。

Identity Management (IdM)クライアントの Kerberos ライブラリーは、デフォルトで User Datagram Protocol (UDP)で通信します。ワンタイムパスワード(OTP)を使用すると、Kerberos タイムアウトの遅延や違反が発生する可能性があります。これにより、kinit コマンドおよびその他の Kerberos 操作は通信エラーを報告でき、ユーザーはロックアウトできます。この問題を回避するには、/etc/krb5.conf ファイルで udp_preference_limit オプションを 0 に設定して、TCP （若干遅い Transmission Control Protocol）を使用して通信を行います。

IdM に登録したホストは、AD フォレストに属する DNS ドメインと同じ DNS ドメインに属することはできません。Active Directory (AD)フォレストの DNS ドメインのいずれかが Identity Management (IdM)レルムに属すると、信頼ステータスが success と報告されても、AD を使用したフォレスト間の信頼は機能しません。この問題を回避するには、既存の AD フォレストとは別の DNS ドメインを使用して IdM をデプロイします。

AD と IdM の両方で同じ DNS ドメインを使用している場合は、最初に ipa realmdomains-show コマンドを実行して、IdM レルムドメインの一覧を表示します。次に、ipa realmdomains-mod --del-domain=wrong.domainコマンドを実行して、一覧から AD に属する DNS ドメイン を削除します。IdM から AD フォレスト DNS ドメインからホストの登録を解除し、これらのホストの AD フォレスト DNS ドメインと競合しない DNS 名を選択します。最後に、ipa trust-add コマンドで信頼を再確立して、フォレスト間の信頼のステータスを AD フォレストに更新します。

Active Directory (AD)との信頼を表す Lightweight Directory Access Protocol (LDAP)オブジェクトへのアクセス制御は、Identity Management (IdM)の Trusted Admins グループに渡されます。信頼を確立するには、IdM 管理者は Trusted Admins グループのメンバーであるグループに所属し、このグループには相対識別子(RID) 512 が割り当てられている必要があります。これを確認するには、ipa-adtrust-install コマンドを実行してから、ipa group-show admins --all コマンドを実行して、ipantsecurityidentifier フィールドに - 512 文字列で終わる値が含まれていることを確認します。フィールドが - 512 で終わらない場合は、ipa group-mod admins --setattr=ipantsecurityidentifier=SID コマンドを使用します。SID は、ipa group-show admins --all コマンド出力の フィールドの値で、最後のコンポーネント値(-XXXX)が - 512 文字列に置き換えられます。

OpenLDAP サーバーおよび 389 Directory Server (389 DS)は、猶予ログインを異なる方法で処理します。389 DS はそれらを の まま の猶予ログイン数として扱い、OpenLDAP は 使用 した猶予ログインの数として扱います。現在、SSSD は 389 DS が使用するセマンティクスのみを処理します。その結果、OpenLDAP を使用する場合、猶予パスワードの警告が正しくない可能性があります。

アカウントの有効期限が切れたかどうかを確認するために SSSD が使用する accountExpires 属性は、デフォルトでグローバルカタログに複製されません。その結果、GSSAPI 認証を使用する場合に、期限切れのアカウントを持つユーザーがログインできます。この問題を回避するには、sssd.conf ファイルで ad_enable_gc=False を指定してグローバルカタログサポートを無効にすることができます。この設定では、GSSAPI 認証を使用する場合に、期限切れのアカウントを持つユーザーはアクセスが拒否されます。SSSD は、このシナリオにおいて各 LDAP サーバーに個別に接続するため、接続数を増やすことができることに注意してください。

特定の状況では、SSSD サービスの特権属性証明書(PAC)レスポンダーコンポーネントのアルゴリズムは、多数のグループのメンバーであるユーザーを効果的に処理しません。そのため、Kerberos シングルサインオン(SSO)を使用して Windows クライアントから Red Hat Enterprise Linux クライアントにログインすると、かなり遅くなる可能性があります。現在、利用可能な既知の回避策はありません。

SSSD サービスは initgroup 検索にグローバルカタログ(GC)を使用しますが、ユーザーのホームディレクトリーやシェルなどの POSIX 属性は、デフォルトで設定された GC に複製されません。したがって、SSSD が SSSD ルックアップ時に POSIX 属性を要求すると、SSSD は GC に存在しないため、サーバーから削除する属性を誤って考慮し、SSSD キャッシュからも削除します。

この問題を回避するには、sssd-ad.conf ファイルで ad_enable_gc=False パラメーターを設定するか、POSIX 属性を GC に複製して GC サポートを無効にします。GC サポートの無効化は簡単ですが、クライアントがドメイン間のグループメンバーシップを解決できなくなります。POSIX 属性を GC にレプリケートすることは、より多くのシステムソリューションですが、Active Directory (AD)スキーマを変更する必要があります。上記の回避策のいずれかの結果、getent passwd user コマンドを実行すると、POSIX 属性が表示されます。id user コマンドを実行すると、適切に設定されている場合でも POSIX 属性が表示されない場合があることに注意してください。

samba-common.x86_64 パッケージおよび samba-common.i686 パッケージのバイナリーには同じファイルパスが含まれますが、その内容が異なります。そのため、RPM データベースがこのシナリオを禁止するため、パッケージを一緒にインストールすることはできません。

この問題を回避するには、主に samba-common. x86_64 が必要な場合は samba-common.i686 をインストールしないでください。 キックスタートファイルにも既にインストールされているシステムにもありません。samba-common.i686 が必要な場合は、samba-common.x86_64 は使用しないでください。その結果、システムはインストール可能ですが、一度に samba-common パッケージのアーキテクチャーは 1 つだけとなります。