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

コンテナー内の SSSD を完全サポート

System Security Services Daemon (SSSD) を提供する rhel7/sssd コンテナーイメージがテクノロジープレビューではなく、完全サポートとなりました。rhel7/ipa-server コンテナーイメージはテクノロジープレビューのままであることに留意してください。
詳細は Using Containerized Identity Management Services を参照してください。(BZ#1467260)

Identity Management が FIPS をサポート

今回の機能拡張では、Identity Management (IdM) が連邦情報処理標準 (FIPS: Federal Information Processing Standard) をサポートするようになりました。これにより、FIPS に合致する必要のある環境での IdM の稼働が可能になっています。FIPS モードを有効にして IdM を稼働するには、FIPS モードを有効にした Red Hat Enterprise Linux 7.4 を使用して IdM 環境内の全サーバーを設定する必要があります。
以下の点に注意してください。
  • FIPS モードを無効にしてインストールした既存の IdM サーバーで FIPS モードを有効にすることはできません。
  • FIPS モードが無効になっている既存の IdM サーバーに FIPS サポートを有効にした新規レプリカをインストールすることはできません。
詳細は Linux ドメイン ID、認証、およびポリシーガイド を参照してください。(BZ#1125174)

スマートカード認証の際に、SSSD が Kerberos チケットの取得をサポート

System Security Services Daemon (SSSD) が Kerberos PKINIT 事前承認メカニズムをサポートするようになりました。Identity Management (IdM) ドメインに登録済みのデスクトップクライアントシステムにスマートカードで認証する際に、認証が成功するとユーザーは有効な Kerberos チケット保証チケット (TGT) を受け取ります。ユーザーはこの TGT を使って、クライアントシステムからさらにシングルサインオン (SSO) 認証をすることができます。
詳細は https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/sc-pkinit-auth.html を参照してください。(BZ#1200767, BZ#1405075)

SSSD で同一のスマートカード証明書を使って別のユーザーアカウントにログイン可能

これまでは System Security Services Daemon (SSSD) では、各証明書が単一ユーザーに一意にマッピングされている必要がありました。スマートカード認証を使用すると、複数のアカウントがあるユーザーは同一のスマートカード証明書ではすべてのアカウントにログインできませんでした。例えば、個人のアカウントと機能アカウント (データベース管理者アカウントなど) を持つユーザーは個人アカウントにしかログインできませんでした。
今回の更新により、SSSD で証明書が一意に単一ユーザーにマッピングされる必要性がなくなりました。このため、ユーザーは単一のスマートカード証明書を使って異なるアカウントにログインできます。
詳細は https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/smart-cards.html を参照してください。(BZ#1340711, BZ#1402959)

IdM ウェブ UI でスマートカードを使用したログインが可能

Identity Management ウェブ UI を使用してユーザーがスマートカードを使用したログインをできるようになりました。
詳細は https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/sc-web-ui-auth.html を参照してください。(BZ#1366572)

新パッケージ: keycloak-httpd-client-install

keycloak-httpd-client-install パッケージは、Red Hat シングルサインオン (RH-SSO、Keycloak とも呼ぶ) でフェデレーションを行った Identity Provider (IdP) クライアントとして登録する際に、Apache httpd 認証モジュールを自動化および簡素化する各種のライブラリーとツールを提供します。
RH-SSO に関する詳細情報は、https://access.redhat.com/products/red-hat-single-sign-on を参照してください。
今回の更新の一部として、以下の新規依存関係が Red Hat Enterprise Linux に追加されました。
  • python-requests-oauthlib パッケージ: python-requests パッケージ向けの OAuth ライブラリーサポートを提供します。これにより python-requests は認証に OAuth を使用できるようになります。
  • python-oauthlib パッケージ: これは Python ライブラリーで、OAuth 認証メッセージ作成および消費を提供します。メッセージを転送するツールと併せて使用するものです。(BZ#1401781, BZ#1401783, BZ#1401784)

新 Kerberos 認証情報キャッシュタイプ: KCM

今回の更新では、kcm と呼ばれる新たな SSSD サービスが追加されました。このサービスは sssd-kcm サブパッケージに格納されています。
kcm サービスをインストールする際には、KCM と呼ばれる新しいタイプの認証情報キャッシュを使用するように Kerberos ライブラリーを設定できます。KCM 認証情報キャッシュタイプが設定されると、sssd-kcm サービスが認証情報を管理します。
KCM 認証情報キャッシュタイプは、コンテナー化された環境に適しています。
  • KCM を使用すると、kcm サービスがリッスンする UNIX ソケットのマウントを基に、コンテナー間で認証情報キャッシュがオンデマンドで共有できます。
  • RHEL がデフォルトで使用する KEYRING 認証情報キャッシュタイプとは異なり、kcm サービスは kernel の外のユーザースペースで稼働します。KCM の場合、kcm サービスを実行できるのは、選択したコンテナーのみになります。KEYRING の場合は、全コンテナーが kernel を共有するので、認証情報キャッシュも共有することになります。
また、KCM 認証情報キャッシュタイプは、FILE キャッシュタイプとは異なり、キャッシュコレクションをサポートします。
詳細は、sssd-kcm(8) man ページを参照してください。(BZ#1396012)

AD ユーザーがウェブ UI にログインしてセルフサービスページにアクセス可能

これまでは Active Directory (AD) ユーザーはコマンドラインから kinit ユーティリティーを使ってしか認証できませんでした。今回の更新により、AD ユーザーは Identity Management (IdM) ウェブ UI にもログインできるようになりました。AD ユーザーがログイン可能となるには、IdM 管理者がそのユーザーの ID 上書きを作成する必要があることに留意してください。
これにより、AD ユーザーは IdM ウェブ UI からセルフサービスにアクセスできます。セルフサービスページには、AD ユーザーの ID 上書きから情報が表示されます。
詳細は https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/smart-cards-advanced.html#ad-users-idm-web-ui を参照してください。(BZ#872671)

SSSD で SSSD サーバーモードによる AD サブドメインの設定が可能

これまでは System Security Services Daemon (SSSD) は自動的に信頼される Active Directory (AD) ドメインを設定していました。今回の更新により SSSD では、登録済みドメインと同じ方法で信頼される AD ドメインの特定パラメーターを設定できるようになりました。
これにより、SSSD が通信するドメインコントローラーといった、信頼されるドメインの個別設定が可能になっています。これを実行するには、/etc/sssd/sssd.conf ファイル内に以下の形式に従った名前のセクションを作成します。 
[domain/main_domain/trusted_domain]
例えば、メインの IdM ドメイン名が ipa.com で信頼される AD ドメイン名が ad.com の場合、セクション名は以下のようになります。 
[domain/ipa.com/ad.com]
(BZ#1214491)

SSSD が AD 環境でユーザーおよびグループ検索と短い名前での認証に対応

これまでは System Security Services Daemon (SSSD) は、デーモンがスタンドアロンドメインに参加した場合にのみ、ユーザーおよびグループの解決でドメイン要素のないユーザー名 (短い名前とも呼ぶ) に対応していました。今回の更新により、以下の環境で全 SSSD ドメインにおいてこの目的で短い名前を使用することができます。
  • Active Directory (AD) に参加しているクライアント
  • AD フォレストとの信頼関係がある Identity Management (IdM) デプロイメント
短い名前を使用する場合でも、全コマンドの出力形式は常に完全修飾になります。この機能は、以下のいずれか方法で (上から望ましい順) ドメインの解決順序を設定した後、デフォルトで有効になります。
  • ローカルで /etc/sssd/sssd.conf ファイルの [sssd] セクションにある domain_resolution_order オプションを使用してリストを設定する。
  • ID ビューを使用する。
  • グローバルで IdM 設定を使用する。
この機能を無効にするには、/etc/sssd/sssd.conf ファイルの [domain/example.com] セクションで use_fully_qualified_names オプションを True に設定します。(BZ#1330196)

SSSD が UID や SID の設定なしで、ユーザーおよびグループ解決、認証、承認をサポート

通常の System Security Services Daemon (SSSD) デプロイメントでは、ユーザーとグループには POSIX 属性セットがあるか、Windows セキュリティー識別子 (SID) に基づいて SSSD がユーザーとグループを解決できるようになっています。
今回の更新により、LDAP を ID プロバイダーとして使用する設定では、UID や SID が LDAP ディレクトリーにない場合でも、SSSD は以下の機能に対応するようになっています。
  • D-Bus インターフェースによるユーザーおよびグループの解決。
  • プラグ可能な認証モジュール (PAM) インターフェースを使った認証および承認。(BZ#1425891)

SSSD で sssctl user-checks コマンドが導入され、単一操作内での基本的 SSSD 機能を確認

sssctl ユーティリティーに新規コマンド user-checks が含まれるようになりました。sssctl user-checks コマンドは、System Security Services Daemon (SSSD) をユーザー検索、認証、および承認のためのバックエンドとして使用するアプリケーションにおけるデバッグ問題に役立ちます。
  • sssctl user-checks [USER_NAME] コマンドは、Name Service Switch (NSS) と D-Bus インターフェースの InfoPipe レスポンダーから利用可能なユーザーデータを表示します。このデータは、ユーザーが system-auth のプラグ可能な認証モジュール (PAM) サービスを使用してログインする権限があるかどうかを表示します。
  • sssctl user-checks が受け付ける追加オプションは、認証もしくは別の PAM サービスをチェックします。
sssctl user-checks に関する詳細は、sssctl user-checks --help コマンドを使用してください。(BZ#1414023)

secrets をサービスとしてサポート

今回の更新では、レスポンダー secrets が System Security Services Daemon (SSSD) に追加されました。このレスポンダーを使用すると、アプリケーションは Custodia API を使用して UNIX ソケット経由で SSSD と通信できるようになります。これにより SSSD は、ローカルデータベースに秘密を保存するか、Custodia サーバーに転送することが可能になりました (BZ#1311056)。

Directory Server が SSHA_512 パスワード保存スキームをデフォルトで使用

これまでは Directory Server は、160-bit のソルトを使用した弱いセキュアハッシュアルゴリズム (SSHA) を cn=config エントリーの passwordStorageScheme と nsslapd-rootpwstoragescheme パラメーターで設定するデフォルトのパスワード保存アルゴリズムとして使用していました。セキュリティーを強化するため、これら両方のパラメーターのデフォルトがより強力な 512-bit SSHA スキーム (SSHA_512) に変更されています。
新たなデフォルトは以下の場合に使用されます。
  • Directory Server の新規インストール時
  • passwordStorageScheme パラメーターが設定されておらず、userPassword 属性に保存されているパスワードを更新する際
  • nsslapd-rootpwstoragescheme パラメーターが設定されておらず、nsslapd-rootpw 属性で設定されている Directory Server のパスワードを更新する際 (BZ#1425907)

Directory Server が tcmalloc メモリーアロケーターを使用

Red Hat Directory Server が tcmalloc メモリーアロケーターを使用するようになりました。これまで使用していた標準の glibc アロケーターはより多くのメモリーを必要とし、状況によってはサーバーでメモリー不足となる場合がありました。tcmalloc メモリーアロケーターを使用することで、Directory Server で必要となるメモリーが抑えられ、パフォーマンスが向上します。(BZ#1426275)

Directory Server が nunc-stans フレームワークを使用

nunc-stans イベントベースフレームワークが Directory Server に統合されました。これまでは、Directory Server への同時着信接続が多くなると動作が遅くなっていましたが、今回の更新でパフォーマンスにマイナス影響を出さずに多数の接続を処理できるようになっています。(BZ#1426278, BZ#1206301, BZ#1425906)

Directory Server memberOf プラグインのパフォーマンス向上

これまでは、大きいグループや入れ子型のグループの作業を実行する際に、プラグインの操作に時間がかかる場合がありました。今回の更新により、Red Hat Directory Server memberOf プラグインが改善され、memberOf プラグインによるグループへのユーザー追加およびグループからのユーザー削除が迅速になりました。(BZ#1426283)

Directory Server がエラーログファイルに重大度レベルを記録

Directory Server が重大度レベルを /var/log/dirsrv/slapd-instance_name/errors ログファイルに記録するようになりました。これまでは、エラーログファイルでエントリーの重大度を判別することが困難でした。今回の機能拡張で、管理者は重大度レベルを使用してエラーログをフィルターすることができます。
詳細情報については、Red Hat Directory Server Configuration, Command, and File Reference の対応セクションを参照してください (https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/error-logs.html#error-logs-content) (BZ#1426289)

Directory Server が PBKDF2_SHA256 パスワード保存スキームに対応

セキュリティー向上のために今回の更新では 256-bit パスワードベースのキー派生関数 2 (PBKDF2_SHA256) が Directory Server の対応パスワード保存スキーム一覧に追加されました。このスキームは、30,000 の反復を使用して 256-bit セキュアハッシュアルゴリズム (SHA256) を適用します。
Red Hat Enterprise Linux 7.4 より前のネットワークセキュリティーサービス (NSS) データベースは、PBKDF2 に対応していません。このため、以前の Directory Server バージョンではレプリケーショントポロジーでこのパスワードスキームが使用できないことに注意してください。(BZ#1436973)

Directory Server での自動チューニングサポートの改善

これまでは、パフォーマンスを改善するにはデータベースを監視して、手動で設定をチューニングする必要がありました。今回の更新で Directory Server は以下の自動チューニングの最適化に対応するようになっています。
  • データベースおよびエントリーキャッシュ
  • 作成されたスレッド数
Directory Server は、サーバーのハードドライブリソースをベースにこれらの設定をチューニングします。
新規 Directory Server インスタンスをインストールすると、自動チューニングはデフォルトで自動的に有効になるようになっています。以前のバージョンからのインスタンスアップグレードでは、自動チューニングを有効にすることを Red Hat では推奨しています。詳細については、以下を参照してください。

外部 DNS サーバー上の IdM DNS レコードの半自動アップグレードが IdM で可能

外部 DNS サーバー上の Identity Management (IdM) DNS レコードの更新を簡素化するために、IdM に ipa dns-upgrade-system-records --dry-run --out [file] コマンドが導入されました。このコマンドは、nsupdate ユーティリティーで受け付ける形式でレコード一覧が生成されます。
Transaction Signature (TSIG) プロトコルまたは GSS algorithm for TSIG (GSS-TSIG) でセキュア化された標準の動的 DNS 更新を使用することで、生成されたファイルを使って外部 DNS サーバー上のレコードを更新できます。
詳細は https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/dns-updates-external.html を参照してください。(BZ#1409628)

IdM が SHA-256 証明書と公開キーフィンガープリントを生成

これまでは Identity Management (IdM) は、証明書および公開キーのフィンガープリント生成に MD5 ハッシュアルゴリズムを使用してきました。セキュリティー強化のために、IdM はこのシナリオにおいて SHA-256 アルゴリズムを使用するようになりました。(BZ#1444937)

IdM がスマートカード証明書とユーザーアカウントのリンクのための柔軟性のあるマッピングメカニズムをサポート

これまでは、Identity Management (IdM) 内の特定のスマートカードに対応するユーザーアカウントを見つける唯一の方法は、Base64 でエンコード化された DER 文字列としてスマートカード証明書全体を提供することでした。今回の更新により、証明書の文字列自体ではなく、スマートカード証明書の属性を指定することでもユーザーアカウントをみつけることができるようになっています。例えば、管理者は特定の証明機関 (CA) が発行したスマートカード証明書と IdM 内のユーザーアカウントをリンクさせる、マッチングルールとマッピングルールを定義することができます。
詳細は https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/smart-cards.html#sc-one-card-multiple-accounts-links を参照してください。(BZ#1402959)

新たなユーザースペースツールでより便利な LMDB デバッグが可能

今回の更新では、/usr/libexec/openldap/ ディレクトリーに mdb_copy、mdb_dump、mdb_load、および mdb_stat のツールが導入されています。また、関連の man ページも man/man1 サブディレクトリーに追加されています。これらの新ツールは、Lightning Memory-Mapped Database (LMDB) バックエンドに関連する問題のデバッグにのみ使用してください。(BZ#1428740)

openldap がバージョン 2.4.44 にリベース

openldap パッケージがアップストリームバージョン 2.4.44 にアップグレードされ、以前のバージョンに対するバグ修正および拡張機能が数多く加えられています。特に、このバージョンでは多くのレプリケーションと Lightning Memory-Mapped Database (LMDB) のバグ修正がなされています。(BZ#1386365)

DNS lookups のセキュリティー改善および Identity Management におけるサービスプリンシパル検索の信頼性

Kerberos クライアントライブラリーは、チケット保証チケットサーバー (TGS) リクエストを発行する際にホスト名の正規化を試みなくなりました。この機能により、以下が改善されます。
  • これまでは正規化の間に必要とされていた DNS 検索が実行されないので、セキュリティーが改善します。
  • クラウドやコンテナー化されたアプリケーションなどのより複数な DNS 環境におけるサービスプリンシパル検索の信頼性の改善。
ホストおよびサービスプリンシパルで正確な完全修飾ドメイン名 (FQDN) を指定してください。この変更により、Kerberos は短い名前などの他の形式のプリンシパルの解決を試みません。(BZ#1404750)

samba が 4.6.2 リリースシリーズにリベース

samba パッケージはアップストリームのリリースシリーズ 4.6.2 にアップグレードされて、旧バージョンに対して多くのバグ修正および機能拡張が加えられています。
  • Samba は、winbindd サービスの起動前に ID マッピング設定を検証するようになりました。設定が無効な場合は、winbindd は起動に失敗します。testparm ユーティリティーを使って /etc/samba/smb.conf ファイルを検証してください。詳細は、smb.conf man ページの IDENTITY MAPPING CONSIDERATIONS セクションを参照してください。
  • Windows 10 からのプリンタードライバーのアップロードが正常に機能します。
  • これまでは、rpc server dynamic port range パラメーターのデフォルト値は 1024-1300 でした。今回の更新により、デフォルト値が 49152-65535 に変更され、Windows Server 2008 およびそれ以降で使用される範囲に一致するようになっています。必要に応じてファイアウォールルールを更新してください。
  • ドメインを離れる際に、net ads unregister コマンドが Active Directory DNS ゾーンからホストの DNS エントリーを削除できるようになりました。
  • SMB 2.1 リースが smb2 leases パラメーターでデフォルトで有効になっています。SMB リースにより、クライアントが積極的にファイルをキャッシュできます。
  • セキュリティー強化のために、NT LAN マネージャーバージョン 1 (NTLMv1) プロトコルがデフォルトで無効になっています。安全でない NTLMv1 プロトコルが必要な場合は、/etc/samba/smb.conf ファイル内の ntlm auth パラメーターを yes に設定します。
  • イベントスクリプトとの対話のために event サブコマンドが ctdb ユーティリティーに追加されました。
  • idmap_hash ID マッピングバックエンドが非推奨とマークされ、今後の Samba バージョンからは削除される予定です。
  • 非推奨となっていた only user と username のパラメーターが削除されました。
smbd、nmbd または winbind デーモンの起動時に、Samba により tbd データベースファイルが自動的に更新されるようになりました。Samba の起動前にデータベースをバックアップするようにしてください。Red Hat では tbd データベースファイルのダウングレードはサポートしていないので注意してください。
主な変更点に関する詳細情報は、更新前にアップストリームのリリースノートを参照してください。

SSSD がスマートカードによるユーザー認証をする設定が authconfig で可能

この新機能では、authconfig コマンドで System Security Services Daemon (SSSD) がスマートカードを使ったユーザー認証をする設定が可能になりました。例を示します。 
# authconfig --enablesssd --enablesssdauth --enablesmartcard --smartcardmodule=sssd --smartcardaction=0 --updateall
今回の更新により、pam_pkcs11 がインストールされていないシステムでスマートカード認証が可能になっています。ただし、pam_pkcs11 がインストールされている場合は、--smartcardmodule=sssd オプションは無視されます。/etc/pam_pkcs11/pam_pkcs11.conf で最初に定義されている pkcs11_module がデフォルトとして使用されます。
詳細は https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/auth-idm-client-sc.html を参照してください。(BZ#1378943)

authconfig でアカウントロックが可能

今回の更新で --enablefaillock オプションが authconfig コマンドに追加されました。このオプションを有効にすると、設定アカウントで 15 分以内にログインに 4 回連続で失敗した場合、アカウントがロックされます。(BZ#1334449)

IdM サーバーのパフォーマンス改善

Identity Management (IdM) サーバーは、全般的な多くのワークフローおよび設定にわたり高レベルのパフォーマンスを発揮します。主に以下の改善点があります。
  • IdM サーバー管理フレームワーク内のラウンドトリップを減らすことで認証情報コンテナーのパフォーマンスを改善。
  • 内部のコミュニケーションと認証にかかる時間を減らすように IdM サーバー管理フレームワークをチューニング。
  • nunc-stans フレームワークの使用により、Directory Server 接続管理がより拡張可能。
  • 新規インストールでは、Directory Server がサーバーのハードウェアリソースに基づいてデータベースエントリーキャッシュとスレッド数を自動的にチューニング。
  • 大型または入れ子型のグループでの作業で、memberOf プラグインのパフォーマンスが改善。(BZ#1395940, BZ#1425906, BZ#1400653)

IdM ウェブ UI のデフォルトセッションの有効期間の変更

これまでは、ユーザー名とパスワードを使用して Identity Management (IdM) ウェブ UI にログインした場合、20 分間なにも操作がないとユーザーはウェブ UI から自動的にログアウトされました。今回の更新により、このデフォルトセッションの長さはログイン操作中に取得された Kerberos チケットの有効期間と同じ長さになっています。デフォルトセッションの長さを変更するには、/etc/ipa/default.conf ファイルの kinit_lifetime オプションを使用してから httpd サービスを再起動します。(BZ#1459153)

dbmon.sh スクリプトがインスタンス名を使用して Directory Server インスタンスに接続

dbmon.sh シェルスクリプトでは、Directory Server のデータベースとエントリーキャッシュの使用量を監視することができます。今回の更新により、このスクリプトは HOST と PORT の環境変数を使用しなくなりました。安全なバインドをサポートするために、サーバーが安全な接続を必要とする場合は、スクリプトが Directory Server インスタンス名を SERVID 環境変数から読み取り、これを使ってホスト名、ポート、および情報を取得するようになっています。例えば、slapd-localhost インスタンスを監視する場合は、以下を入力します。 
SERVID=slapd-localhost INCR=1 BINDDN="cn=Directory Manager" BINDPW="password" dbmon.sh
(BZ#1394000)