RHEL での認証と認可の設定
SSSD、authselect、および sssctl を使用した認証および承認の設定
概要
authselect
や sssctl
などのユーティリティーは、SSSD、Pluggable Authentication Modules (PAM)、および Name Service Switch (NSS)の設定に対応します。
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社の CTO である Chris Wright のメッセージ を参照してください。
Identity Management では、以下のような用語の置き換えが含まれます。
- ブラックリストからブロックリスト
- ホワイトリストから許可リスト
- スレーブからセカンダリー
単語 マスター は、コンテキストに応じて、より正確な言語に置き換えられます。
- マスターからIdM サーバー
- CA 更新マスター から CA 更新サーバー
- CRL マスターからCRL パブリッシャーサーバー
- マルチマスターからマルチサプライヤー
Red Hat ドキュメントへのフィードバック (英語のみ)
Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。
特定の文章に関するコメントの送信
- Multi-page HTML 形式でドキュメントを表示し、ページが完全にロードされてから右上隅に Feedback ボタンが表示されていることを確認します。
- カーソルを使用して、コメントを追加するテキスト部分を強調表示します。
- 強調表示されたテキストの近くに表示される Add Feedback ボタンをクリックします。
- フィードバックを追加し、Submit をクリックします。
Bugzilla からのフィードバック送信 (アカウントが必要)
- Bugzilla の Web サイトにログインします。
- Version メニューから正しいバージョンを選択します。
- Summary フィールドにわかりやすいタイトルを入力します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
- Submit Bug をクリックします。
第1章 authselect でユーザー認証の設定
authselect
は、特定のプロファイルを選択して、システム ID および認証ソースを設定できるようにするユーティリティーです。profile は、作成される PAM (Pluggable Authentication Modules) および Network Security Services (NSS) の設定を記述するファイルのセットです。デフォルトのプロファイル設定を選択するか、またはカスタムプロファイルを作成できます。
1.1. authselect の使用方法
authselect
ユーティリティーを使用して、Red Hat Enterprise Linux 8 ホストでユーザー認証を設定できます。
既製のプロファイルのいずれかを選択して、ID 情報および認証ソースおよびプロバイダーを設定できます。
-
デフォルトの
sssd
プロファイルでは、LDAP 認証を使用するシステムの System Security Services Daemon (SSSD) が有効になります。 -
winbind
プロファイルは、Microsoft Active Directory と直接統合したシステムの Winbind ユーティリティーを有効にします。 -
nis
プロファイルにより、従来のネットワーク情報サービス (NIS) システムとの互換性が確保されます。 -
minimal
プロファイルは、システムファイルから直接ローカルユーザーおよびグループのみを提供します。これにより、管理者は不要になったネットワーク認証サービスを削除できます。
authselect
プロファイルを特定のホストに対して選択すると、そのプロファイルは、そのホストにログインしているすべてのユーザーに適用されます。
Red Hat は、たとえば、ドメイン内でサービスを使用するために、データベースの LDAP、winbind、または NIS を使用してユーザーを認証している場合など、半集中型の ID 管理環境での authselect
の使用を推奨しています。
次の場合は、authselect
を使用する必要はありません。
-
ホストは Red Hat Enterprise Linux Identity Management (IdM) の一部です。ホストを IdM ドメインに参加させると、
ipa-client-install
コマンドは、ホストで SSSD 認証を自動的に設定します。 -
ホストは SSSD 経由で Active Directory の一部です。
realm join
コマンドを呼び出して、ホストを Active Directory ドメインに参加させると、ホストで SSSD 認証が自動的に設定されます。
Red Hat は、ipa-client-install
または realmjoin
によって設定された authselect
プロファイルを変更しないことをお勧めします。それらを変更する必要がある場合は、変更を加える前に現在の設定を表示して、必要に応じて元に戻すことができるようにします。
$ authselect current
Profile ID: sssd
Enabled features:
- with-sudo
- with-mkhomedir
- with-smartcard
1.1.1. ファイルおよびディレクトリーの authselect の変更
authconfig
ユーティリティーは、以前の Red Hat Enterprise Linux バージョンで、さまざまな設定ファイルの作成および変更するために使用されていたため、トラブルシューティングが困難になりました。authselect
は、次のファイルおよびディレクトリーのみを変更するため、テストとトラブルシューティングが容易になります。
| GNC C ライブラリーおよびその他アプリケーションはこの NSS (Name Service Switch) を使用して、さまざまなカテゴリーの名前サービス情報を、どのソースから、どの順番で取得するかを決定します。情報の各カテゴリーは、データベース名で識別されます。 |
| Linux-PAM (Pluggable Authentication Modules) は、システムのアプリケーション (サービス) の認証タスクを処理するモジュールのシステムです。認証の性質は動的に設定できます。システム管理者は、個々のサービス提供アプリケーションがユーザーを認証する方法を選択できます。
たとえば、これらのファイルには以下の情報が含まれています。
|
|
このディレクトリーは、 |
1.1.2. /etc/nsswitch.conf
のデータプロバイダー
デフォルトの sssd
プロファイルは、/etc/nsswitch.conf
に sss
エントリーを作成することで、SSSD を情報ソースとして確立します。
passwd: sss files group: sss files netgroup: sss files automount: sss files services: sss files ...
これは、これらの項目のいずれかに関する情報が要求されると、システムが最初に SSSD を調べることを意味します。
-
ユーザー情報の
passwd
-
ユーザー
グループ
情報のグループ -
NIS
netgroup
情報のnetgroup
-
NFS 自動マウント情報の
automount
-
サービスに関する情報に関する
services
sssd
キャッシュ、および認証を提供するサーバーで、要求された情報が見つからない、または sssd
を実行していないと、システムはローカルファイル (/etc/*
) を調べます。
たとえば、ユーザー ID に関する情報が要求されると、そのユーザー ID は、最初に sssd
キャッシュで検索されます。そこで見つからない場合は、/etc/passwd
ファイルが参照されます。同様に、ユーザーのグループ所属が要求されると、最初に sssd
キャッシュで検索され、そこに見つからない場合に限り、/etc/group
ファイルが参照されます。
実際には、ローカルの files
データベースは参照されません。最も重要な例外は、root
ユーザーの場合です。これは、sssd
で処理されることはありませんが、files
で処理されます。
1.2. authselect プロファイルの選択
システム管理者は、特定のホストの authselect
ユーティリティーにプロファイルを選択できます。そのプロファイルはそのホストにログインしているすべてのユーザーに適用されます。
前提条件
-
authselect
コマンドを実行するにはroot
認証情報が必要です。
手順
認証プロバイダーに適した
authselect
プロファイルを選択します。たとえば、LDAP を使用している企業のネットワークにログインするには、sssd
を選択します。# authselect select
sssd
authselect select sssd
コマンドまたはauthselect select winbind
コマンドに次のオプションを追加して、デフォルトのプロファイル設定を変更できます。-
with-faillock
-
with-smartcard
-
with-fingerprint
-
使用可能なオプションの完全なリストを表示するには、スクリプトを authconfig から authselect に変換する を参照してください。
または authselect-migration(7)
man ページ。
authselect select
手順を完了する前に、プロファイルに関連する設定ファイルが正しく設定されていることを確認してください。たとえば、sssd
デーモンが正しく設定されておらずアクティブではない場合に authselect select
を実行すると、ローカルユーザーのみが、pam_unix
を使用して認証できるようになります。
検証手順
SSSD の
sss
エントリーが/etc/nsswitch.conf
にあることを確認します。passwd: sss files group: sss files netgroup: sss files automount: sss files services: sss files ...
pam_sss.so
エントリーの/etc/pam.d/system-auth
ファイルの内容を確認します。# Generated by authselect on Tue Sep 11 22:59:06 2018 # Do not modify this file manually. auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet auth [default=1 ignore=ignore success=ok] pam_localuser.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so forward_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so ...
1.3. 既製の authselect プロファイルの変更
システム管理者は、ニーズに合わせてデフォルトプロファイルのいずれかを変更することができます。
以下の項目を除き、/etc/authselect/user-nsswitch.conf
ファイルを変更できます。
-
passwd
-
group
-
netgroup
-
automount
-
services
その後 authselect select
profile_name
を実行すると、/etc/authselect/user-nsswitch.conf
から /etc/nsswitch.conf
ファイルに許容可能な変更が転送されます。受け入れられない変更は、デフォルトのプロファイル設定によって上書きされます。
/etc/nsswitch.conf
ファイルを直接編集しないでください。
手順
authselect
プロファイルを選択します。以下に例を示します。#
authselect select
sssd
-
必要な変更で
/etc/authselect/user-nsswitch.conf
ファイルを編集します。 /etc/authselect/user-nsswitch.conf
ファイルから変更を適用します。#
authselect apply-changes
検証手順
-
/etc/nsswitch.conf
ファイルで、/etc/authselect/user-nsswitch.conf
からの変更が伝播されているのを確認してください。
関連情報
1.4. 独自の authselect プロファイルの作成とデプロイメント
システム管理者は、デフォルトプロファイルのいずれかのカスタムコピーを作成して、カスタムプロファイルを作成およびデプロイできます。
これは、同梱の authselect プロファイル を変更するのに特に便利です。カスタムプロファイルをデプロイすると、そのプロファイルは指定したホストにログインしているすべてのユーザーに適用されます。
手順
authselect create-profile
コマンドを使用してカスタムプロファイルを作成します。たとえば、既製のsssd
プロファイルに基づくuser-profile
というカスタムプロファイルを作成し、/etc/nsswitch.conf
ファイルで項目を設定するには、以下のコマンドを実行します。#
authselect create-profile
user-profile
-bsssd
--symlink-meta
--symlink-pam
New profile was created at /etc/authselect/custom/user-profileコマンドで
--symlink-pam
オプションを使用すると、PAM テンプレートが、コピーではなく元のプロファイルファイルへのシンボリックリンクになります。--symlink-meta
オプションを使用すると、README、REQUIREMENTS などのメタファイルが、コピーではなく元のプロファイルファイルへのシンボリックリンクになります。これにより、元のプロファイルの PAM テンプレートおよびメタファイルへの今後の更新が、カスタムプロファイルにも反映されます。このコマンドにより、
/etc/authselect/custom/user-profile/
ディレクトリーの/etc/nsswitch.conf
ファイルのコピーが作成されます。-
/etc/authselect/custom/user-profile/nsswitch.conf
ファイルを設定します。 authselect select
コマンドを実行してカスタムプロファイルを選択し、custom/name_of_the_profile
パラメーターを追加します。たとえば、user-profile
プロファイルを選択するには、以下のコマンドを実行します。#
authselect select
custom/user-profile
お使いのマシンで
user-profile
プロファイルを選択すると、その後 Red Hat がsssd
プロファイルを更新した場合に、/etc/nsswitch.conf
ファイルに行った更新以外のすべての更新を利用できるようになります。例1.1 プロファイルの作成
次の手順は、
sssd
プロファイルに基づいてプロファイルを作成する方法を示しています。ここでは、ホスト名に対するローカルの静的テーブルルックアップを、/etc/hosts
ファイルでのみ参照し、dns
データベースまたはmyhostname
データベースは参照しません。/etc/nsswitch.conf
ファイルで、次の行を編集します。hosts: files
sssd
に基づいてカスタムプロファイルを作成します。/etc/nsswitch.conf
に対する変更は除外します。#
authselect create-profile
user-profile
-bsssd
--symlink-meta --symlink-pamプロファイルを選択します。
#
authselect select
custom/user-profile
必要に応じて、カスタムプロファイルで、次の点を確認します。
-
選択した
sssd
プロファイルに応じて/etc/pam.d/system-auth
ファイルが作成されている。 /etc/nsswitch.conf
の設定は変更されていない。hosts: files
注記反対に
authselect select
sssd
を実行すると、hosts: files dns myhostname
のようになります。
-
選択した
関連情報
1.5. authconfig
から authselect
へのスクリプトの変換
ipa-client-install
または realm join
を使用してドメインに参加する場合は、スクリプトの authconfig
呼び出しを削除しても問題はありません。これができない場合は、各 authconfig
コールを、同等の authselect
コールに置き換えてください。その場合は、正しいプロファイルと適切なオプションを選択します。さらに、必要な設定ファイルを編集します。
-
/etc/krb5.conf
-
/etc/sssd/sssd.conf
(sssd
プロファイルの場合) または/etc/samba/smb.conf
(winbind
プロファイルの場合)
authconfig オプションと同等の authselect プロファイルオプション と authconfig オプションと authselect プロファイルの関係 では、authconfig
オプションと同等の authselect
を示しています。
表1.1 authconfig オプションと authselect プロファイルの関係
authconfig オプション | authselect プロファイル |
---|---|
|
|
|
|
|
|
|
|
|
|
表1.2 authconfig オプションと同等の authselect プロファイルオプション
authconfig オプション | authselect プロファイル機能 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
authconfig コマンドと同等の authselect コマンドの例 では、authconfig
へのキックスタートの呼び出しを authselect
へのキックスタートの呼び出しに変換する事例を紹介します。
表1.3 authconfig コマンドと同等の authselect コマンドの例
authconfig コマンド | 同等の authselect コマンド |
---|---|
|
|
|
|
|
|
|
|
1.6. 関連情報
第2章 SSSD とその利点について
システムセキュリティーサービスデーモン (System Security Services Daemon: SSSD) は、リモートディレクトリーと認証メカニズムにアクセスするシステムサービスです。本章では、SSSD の仕組み、SSSD の使用時の利点、設定ファイルの処理方法、設定可能な ID および認証プロバイダーの概要を説明します。
2.1. SSSD の仕組み
システムセキュリティーサービスデーモン (System Security Services Daemon: SSSD) は、リモートディレクトリーと認証メカニズムにアクセスするシステムサービスです。SSSD クライアント であるローカルシステムを、外部のバックエンドシステム (プロバイダー) に接続できます。
以下に例を示します。
- LDAP ディレクトリー
- IdM (Identity Management) ドメイン
- AD (Active Directory) ドメイン
- Kerberos レルム
SSSD は、以下の 2 段階で機能します。
- クライアントをリモートプロバイダーに接続し、ID 情報および認証情報を取得します。
- 取得した認証情報を使用して、クライアントにユーザーと認証情報のローカルキャッシュを作成します。
ローカルシステムのユーザーは、リモートプロバイダーに保存されているユーザーアカウントを使用して認証できます。
SSSD は、ローカルシステムでユーザーアカウントを作成しません。ただし、SSSD は、IdM ユーザーのホームディレクトリーを作成するように設定できます。作成が完了すると、IdM ユーザーのホームディレクトリーと、クライアント上のコンテンツは、ユーザーがログアウトしても削除されません。
図2.1 SSSD の仕組み

SSSD は、NSS (Name Service Switch) や PAM (Pluggable Authentication Modules) などの複数のシステムサービスのキャッシュを提供することもできます。
2.2. SSSD を使用する利点
SSSD (System Security Services Daemon) を使用すると、ユーザー ID の取得とユーザー認証に複数の利点があります。
- オフライン認証
- SSSD は、必要に応じて、リモートプロバイダーから取得したユーザー ID および認証情報のキャッシュを保持します。この設定では、セッションの開始時にすでにリモートプロバイダーに対して一度認証されている場合は、リモートプロバイダーまたはクライアントがオフラインであってもリソースに対して正常に認証できます。
- 単一のユーザーアカウント: 認証プロセスの一貫性の向上
SSSD では、オフライン認証用に中央アカウントとローカルユーザーアカウントの両方を維持する必要はありません。条件は次のとおりです。
- 特定のセッションでは、ユーザーが最低でも一度ログインしている必要があります。ユーザーが初めてログインしたときに、クライアントはリモートプロバイダーに接続する必要があります。
SSSD でキャッシュを有効にする必要があります。
SSSD を使用しないと、リモートユーザーには、多くの場合、複数のユーザーアカウントが存在します。たとえば、仮想プライベートネットワーク (VPN) に接続するには、リモートユーザーが、ローカルシステム用のアカウントのほかに、VPN システム用の別のアカウントが必要になります。このシナリオでは、最初にプライベートネットワーク上で認証して、リモートサーバーからユーザーを取得し、ユーザー認証情報をローカルでキャッシュする必要があります。
SSSD では、キャッシュおよびオフライン認証により、リモートユーザーはローカルマシンに認証することで、ネットワークリソースに接続できます。SSSD は次にネットワークの認証情報を維持します。
- ID プロバイダーおよび認証プロバイダーへの負荷の軽減
- 情報をリクエストすると、クライアントはまずローカルの SSSD キャッシュを確認します。SSSD は、キャッシュで情報が利用できない場合に限り、リモートプロバイダーに問い合わせます。
2.3. クライアントごとに複数の SSSD 設定ファイル
SSSD のデフォルト設定ファイルは /etc/sssd/sssd.conf
です。このファイルとは別に、SSSD は、/etc/sssd/conf.d/
ディレクトリーが *.conf
ファイルのすべてからその設定を読み取ることができます。
この組み合わせにより、すべてのクライアントでデフォルトの /etc/sssd/sssd.conf
ファイルを使用し、追加の設定ファイルに追加設定を追加して、クライアントごとに機能を個別に拡張できます。
SSSD が設定ファイルを処理する方法
SSSD は、以下の順番で設定ファイルを読み取ります。
-
プライマリー
/etc/sssd/sssd.conf
ファイル -
/etc/sssd/conf.d/
の他の*.conf
ファイル (アルファベット順)
同じパラメーターが複数の設定ファイルに表示されると、SSSD は最後に読み取るパラメーターを使用します。
SSSD は、conf.d
ディレクトリー内の隠しファイル (.
で始まるファイル) を読み込みません。
2.4. SSSD の ID プロバイダーおよび認証プロバイダー
SSSD クライアントは、外部 ID および認証プロバイダー (LDAP ディレクトリー、Identity Management (IdM)、Active Directory (AD) ドメイン、Kerberos レルムなど) に接続できます。次に、SSSD クライアントは SSSD プロバイダーを使用して ID および認証リモートサービスにアクセスします。SSSD が、異なる ID プロバイダーおよび認証プロバイダー、またはそれらの組み合わせを使用するように設定できます。
SSSD ドメインとしての ID および認証プロバイダー
ID および認証プロバイダーは、SSSD 設定ファイル /etc/sssd/sssd.conf
で ドメイン として設定されます。プロバイダーは、ファイル [domain/name of the domain]
セクションまたは [domain/default]
セクションに登録されます。
1 つのドメインを、以下のプロバイダーのいずれかとして設定できます。
UID や GID などのユーザー情報を提供する ID プロバイダー
-
/etc/sssd/sssd.conf
ファイルの[domain/name of the domain]
セクションのid_provider
オプションを使用して、ドメインを ID プロバイダー として指定します。
-
認証要求を処理する 認証プロバイダー
-
/etc/sssd/sssd.conf
の[domain/name of the domain]
セクションのauth_provider
オプションを使用して、ドメインを 認証プロバイダー として指定します。
-
認可要求を処理する アクセス制御プロバイダー
-
/etc/sssd/sssd.conf
の[domain/name of the domain]
セクションのaccess_provider
オプションを使用して、ドメインを アクセス制御プロバイダー として指定します。デフォルトでは、オプションはpermit
に設定されており、常にすべてのアクセスを許可します。詳細は sssd.conf(5) man ページを参照してください。
-
対応するすべての操作が 1 台のサーバー内で実行される場合など、これらのプロバイダーの組み合わせ
-
この場合、
id_provider
オプション、auth_provider
オプション、およびaccess_provider
オプションはすべて、/etc/sssd/sssd.conf
の[domain/name of the domain]
または[domain/default]
セクションに登録されます。
-
この場合、
SSSD に複数のドメインを設定できます。少なくともいずれかのドメインを設定する必要があります。設定しないと、SSSD は起動しません。
プロキシープロバイダー
プロキシープロバイダーは、SSSD と、SSSD が使用できないリソースとの間の中間リレーとして機能します。プロキシープロバイダーを使用する場合、SSSD はプロキシーサービスに接続し、プロキシーは指定されたライブラリーを読み込みます。
SSSD がプロキシープロバイダーを使用して以下を有効にするように設定できます。
- 指紋スキャナーなどの別の認証方法
- NIS などのレガシーシステム
-
/etc/passwd
ファイルで ID プロバイダーとして定義されるローカルシステムアカウントと、Kerberos などのリモート認証プロバイダー
ID プロバイダーおよび認証プロバイダーの利用可能な組み合わせ
SSSD が、以下の ID プロバイダーと認証プロバイダーの組み合わせを使用するように設定できます。
表2.1 ID プロバイダーおよび認証プロバイダーの利用可能な組み合わせ
sssctl
ユーティリティーを使用してドメインのステータスを一覧表示して確認するには、Active Directory (AD) フォレストとの信頼関係にある Identity Management (IdM) にホストを登録する必要があります。
第3章 LDAP を使用し、TLS 認証を必要とする SSSD の設定
SSSD (System Security Services Daemon)は、Red Hat Enterprise Linux ホストで ID データの取得と認証を管理するデーモンです。システム管理者は、スタンドアロンの LDAP サーバーをユーザーアカウントデータベースとして使用するようにホストを設定できます。管理者は、LDAP サーバーとの接続を TLS 証明書で暗号化する必要があるという要件も指定できます。
現在、TLS を強制する SSSD 設定オプション ldap_id_use_start_tls
は、デフォルトで false
に設定されています。ID 検索に TLS なしで ldap://
を使用すると、攻撃ベクトル、つまり中間者(MITM)攻撃のリスクが発生します。これにより、LDAP 検索で返されるオブジェクトの UID または GID を変更することでユーザーの権限を借用できます。
セットアップが信頼できる環境で動作していることを確認し、id_provider = ldap
に暗号化されていない通信を使用しても安全かどうかを判断してください。注記: id_provider = ad
および id_provider = ipa
は、SASL および GSSAPI によって保護された暗号化接続を使用するため、影響を受けません。
暗号化されていない通信を使用することが安全ではない場合は、/etc/sssd/sssd.conf
ファイルで ldap_id_use_start_tls
オプションを true
に設定して TLS を強制します。
3.1. SSSD を使用して、暗号化された方法で LDAP からデータを取得する OpenLDAP クライアント
LDAP オブジェクトの認証方法は、Kerberos パスワードまたは LDAP パスワードのいずれかになります。LDAP オブジェクトの認証および認可に関する質問は、本章では扱いません。
LDAP で SSSD を設定するのは、SSSD および LDAP で高度な専門知識を必要とする複雑な手順です。代わりに、Active Directory や Red Hat Identity Management (IdM) などの統合型の自動ソリューションを使用することを検討してください。IdM の詳細は Identity Management の計画 を参照してください。
3.2. LDAP を使用し、TLS 認証を必要とする SSSD の設定
以下の手順に従って、Red Hat Enterprise Linux (RHEL) システムを OpenLDAP クライアントとして設定します。
以下のクライアント設定を使用します。
- RHEL システムが OpenLDAP ユーザーアカウントデータベースに保存されているユーザーを認証する。
- RHEL システムが SSSD (System Security Services Daemon) サービスを使用してユーザーデータを取得する。
- RHEL システムが TLS で暗号化された接続で OpenLDAP サーバーと通信する。
または、この手順に従って、RHEL システムを Red Hat Directory Server のクライアントとして設定することもできます。
前提条件
- OpenLDAP サーバーがインストールされ、ユーザー情報を含めて設定されている。
- LDAP クライアントとして設定するホストの root 権限がある。
-
LDAP クライアントとして設定するホストで、
/etc/sssd/sssd.conf
ファイルが作成され、ldap
をautofs_provider
およびid_provider
として指定するように設定されている。 -
OpenLDAP サーバー証明書を発行した認証局からの PEM 形式の証明書チェーンがあり、
core-dirsrv.ca.pem
という名前のローカルファイルに保存されている。
手順
必要なパッケージをインストールします。
# dnf -y install openldap-clients sssd sssd-ldap oddjob-mkhomedir
認証プロバイダーを
sssd
に切り替えます。# authselect select sssd with-mkhomedir
OpenLDAP サーバーの SSL/TLS 証明書を発行した認証局からのルート CA 署名証明書チェーンを含む
core-dirsrv.ca.pem
ファイルを/etc/openldap/certs
フォルダーにコピーします。# cp core-dirsrv.ca.pem /etc/openldap/certs
LDAP サーバーの URL と接尾辞を
/etc/openldap/ldap.conf
ファイルに追加します。URI ldap://ldap-server.example.com/ BASE dc=example,dc=com
/etc/openldap/ldap.conf
ファイルで、/etc/openldap/certs/core-dirsrv.ca.pem
を参照する TLS_CACERT パラメーターの行を追加します。# When no CA certificates are specified the Shared System Certificates # are in use. In order to have these available along with the ones specified # by TLS_CACERTDIR one has to include them explicitly: TLS_CACERT /etc/openldap/certs/core-dirsrv.ca.pem
/etc/sssd/sssd.conf
ファイルで、環境の値をldap_uri
パラメーターおよびldap_search_base
パラメーターに追加し、ldap_id_use_start_tls
をTrue
に設定します。[domain/default] id_provider = ldap autofs_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://ldap-server.example.com/ ldap_search_base = dc=example,dc=com ldap_id_use_start_tls = True cache_credentials = True ldap_tls_cacertdir = /etc/openldap/certs ldap_tls_reqcert = allow [sssd] services = nss, pam, autofs domains = default [nss] homedir_substring = /home …
/etc/sssd/sssd.conf
で、[domain]
セクションのldap_tls_cacert
およびldap_tls_reqcert
の値を変更して TLS 認証要件を指定します。… cache_credentials = True ldap_tls_cacert = /etc/openldap/certs/core-dirsrv.ca.pem ldap_tls_reqcert = hard …
/etc/sssd/sssd.conf
ファイルの権限を変更します。# chmod 600 /etc/sssd/sssd.conf
SSSD サービスおよび
oddjobd
デーモンを再起動して有効にします。# systemctl restart sssd oddjobd # systemctl enable sssd oddjobd
(必要に応じて) LDAP サーバーが非推奨の TLS 1.0 プロトコルまたは TLS 1.1 プロトコルを使用している場合は、クライアントシステムでシステム全体の暗号化ポリシーを LEGACY レベルに切り替えて、RHEL がこのプロトコルを使用して通信できるようにします。
# update-crypto-policies --set LEGACY
詳細は、Red Hat カスタマーポータルのナレッジベースStrong crypto defaults in RHEL 8 and deprecation of weak crypto algorithmsおよび man ページの
update-crypto-policies(8)
を参照してください。
検証手順
id
コマンドを使用し、LDAP ユーザーを指定して、LDAP サーバーからユーザーデータを取得できることを確認します。# id ldap_user uid=17388(ldap_user) gid=45367(sysadmins) groups=45367(sysadmins),25395(engineers),10(wheel),1202200000(admins)
システム管理者は、id
コマンドを使用して LDAP からユーザーをクエリーできるようになりました。このコマンドは、正しいユーザー ID とグループメンバーシップを返します。
第4章 ID プロバイダーおよび認証プロバイダーの追加設定
システムセキュリティーサービスデーモン (System Security Services Daemon: SSSD) は、リモートディレクトリーと認証メカニズムにアクセスするシステムサービスです。SSSD の主な設定ファイルは /etc/sssd/sssd.conf
です。本章では、/etc/sssd/sssd.conf
ファイルを次のように変更して、SSSD サービスおよびドメインを設定する方法を概説します。
- オフライン認証を有効にするため、SSSD による完全なユーザー名の解釈と出力方法を調整します。
- DNS サービスディスカバリー、シンプルアクセスプロバイダールール、および SSSD が LDAP アクセスフィルターを適用するように設定します。
4.1. SSSD が完全なユーザー名を解釈する方法の調整
SSSD は、完全なユーザー名の文字列を解析して、ユーザー名とドメインコンポーネントにします。デフォルトでは、SSSD は、Python 構文の以下の正規表現に基づいて、user_name@domain_name
形式の完全なユーザー名を解釈します。
(?P<name>[^@]+)@?(?P<domain>[^@]*$)
Identity Management プロバイダーおよび Active Directory プロバイダーは、デフォルトのユーザー名の形式は user_name@domain_name
または NetBIOS_name\user_name
です。
SSSD による完全なユーザー名の解釈方法は、re_expression
オプションを /etc/sssd/sssd.conf
ファイルに追加し、カスタム正規表現を定義することで調整できます。
-
正規表現をグローバルに定義するには、正規表現のグローバル例の定義 の例で示されているように
sssd.conf
ファイルの[sssd]
セクションに正規表現を追加します。 -
特定のドメインに正規表現を定義するには、特定のドメインで正規表現の定義 の例にあるように、
sssd.conf
ファイルの対応するドメインセクション ([domain/LDAP]
など) に正規表現を追加します。
前提条件
-
root
アクセス
手順
-
/etc/sssd/sssd.conf
ファイルを開きます。 re_expression
オプションを使用して、カスタムの正規表現を定義します。例4.1 正規表現のグローバルでの定義
すべてのドメインに対してグローバルに正規表現を定義するには、
sssd.conf
ファイルの[sssd]
セクションにre_expression
を追加します。以下の glob 表現を使用して、
domain\\username
またはdomain@username
の形式でユーザー名を定義できます。[sssd] [... file truncated ...] re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)
例4.2 特定のドメインへの正規表現の定義
特定のドメインに個別に正規表現を定義するには、
sssd.conf
ファイルの対応するドメインセクションにre_expression
を追加します。以下の glob 表現を使用して、LDAP ドメインの
domain\\username
またはdomain@username
の形式でユーザー名を定義できます。[domain/LDAP] [... file truncated ...] re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)
詳細は、sssd.conf(5)
man ページの SPECIAL SECTIONS
and DOMAIN SECTIONS
部分の re_expression
を参照してください。
4.2. SSSD が完全なユーザー名を出力する方法の調整
/etc/sssd/sssd.conf
ファイルで use_fully_qualified_names
オプションが有効になっている場合、SSSD は、デフォルトで以下の拡張を基にした @domain
形式で、完全なユーザー名を出力します。
%1$s@%2$s
use_fully_qualified_names
が設定されていない場合や、信頼されるドメインに対して明示的に false
に設定されている場合に、ドメインコンポーネントのないユーザー名のみを出力します。
full_name_format
オプションを /etc/sssd/sssd.conf
ファイルに追加してカスタム拡張を定義することで、SSSD による完全なユーザー名の出力形式を調整できます。
前提条件
-
root
アクセス
手順
-
root
として/etc/sssd/sssd.conf
ファイルを開きます。 すべてのドメインに対してグローバルに拡張を定義するには、
sssd.conf
の[sssd]
セクションにfull_name_format
を追加します。[sssd] [... file truncated ...] full_name_format = %1$s@%2$s
この場合、ユーザー名は
user@domain.test
と表示されます。特定のドメインにユーザー名出力形式を定義するには、
sssd.conf
の対応するドメインセクションにfull_name_format
を追加します。%2$s\%1$s
を使用して Active Directory (AD)ドメインの拡張を設定するには、以下を実行します。[domain/ad.domain] [... file truncated ...] full_name_format = %2$s\%1$s
この場合、ユーザー名は
ad.domain\user
と表示されます。%3$s\%1$s
を使用して Active Directory (AD)ドメインの拡張を設定するには、以下を実行します。[domain/ad.domain] [... file truncated ...] full_name_format = %3$s\%1$s
この場合、Active Directory ドメインのフラットドメイン名が
AD
に設定されている場合、ユーザー名はAD\user
として表示されます。
詳細は、sssd.conf(5)
man ページの SPECIAL SECTIONS
と DOMAIN SECTIONS
部分にある full_name_format
の説明を参照してください。
SSSD は、名前の設定で名前のドメインコンポーネントを削除できるため、認証エラーが発生する可能性があります。full_name_format
を標準以外の値に設定すると、これを標準形式に変更するように要求する警告が表示されます。
4.3. オフライン認証の有効化
SSSD は、デフォルトでは、ユーザーの認証情報をキャッシュしません。認証要求の処理時に、SSSD は常にアイデンティティープロバイダーに問い合わせします。プロバイダーが利用できない場合は、ユーザー認証に失敗します。
アイデンティティープロバイダーが利用できない場合にユーザーが認証できるようにするには、/etc/sssd/sssd.conf
ファイルで cache_credentials
を true
に設定して認証情報キャッシュを有効にできます。
SSSD は、パスワードをプレーンテキストでキャッシュしません。パスワードのハッシュのみを保存します。
認証情報はソルト付きの SHA-512 ハッシュとして保存されますが、攻撃者がブルートフォース攻撃を使用してキャッシュファイルにアクセスし、パスワードを解読できた場合、セキュリティーリスクが生じる可能性があります。キャッシュファイルにアクセスするには、RHEL のデフォルトである特権アクセスが必要です。
前提条件
-
root
アクセス
手順
-
/etc/sssd/sssd.conf
ファイルを開きます。 ドメインセクションで、
cache_credentials = true
設定を追加します。[domain/your-domain-name] cache_credentials = true
推奨 (任意): アイデンティティープロバイダーが利用できない場合に SSSD がオフライン認証の許可期間に制限を設定します。
SSSD と連携するように PAM サービスを設定します。
詳細は authselect でユーザー認証の設定 を参照してください。
offline_credentials_expiration
オプションを使用して、時間制限を指定します。制限は日単位で設定されることに注意してください。
たとえば、最終ログインに成功してから 3 日間、オフライン認証を可能にするには、以下を使用します。
[pam] offline_credentials_expiration = 3
関連情報
-
sssd.conf(5)
の man ページ
4.4. DNS サービスディスカバリーの設定
DNS サービス検出を使用すると、アプリケーションが特定タイプの特定サービスに対して指定のドメインの SRV レコードを確認し、必要なタイプのサーバーを返すことができます。ID または認証サーバーが /etc/sssd/sssd.conf
ファイルで明示的に定義されていない場合は、SSSD は DNS サービス検出を使用してサーバーを動的に検出できます。
たとえば、sssd.conf
に id_provider = ldap
設定が含まれているものの、ldap_uri
オプションでホスト名または IP アドレスが指定されていない場合に、SSSD は DNS サービス検出を使用してサーバーを動的に検出します。
SSSD が検出するのは、プライマリーサーバーのみで、バックアップサーバーを動的には検出できません。
前提条件
-
root
アクセス
手順
-
/etc/sssd/sssd.conf
ファイルを開きます。 プライマリーサーバーの値を
_srv_
に設定します。LDAP プロバイダーの場合、プライマリーサーバーは
ldap_uri
オプションを使用して設定されます。[domain/your-domain-name] id_provider = ldap ldap_uri = _srv_
パスワード変更プロバイダーでサービス検出を有効にするには、サービスタイプを設定します。
[domain/your-domain-name] id_provider = ldap ldap_uri = _srv_ chpass_provider = ldap ldap_chpass_dns_service_name = ldap
-
必要に応じて、サービス検出は、システムホスト名のドメイン部分をドメイン名として使用します。別の DNS ドメインを使用するには、
dns_discovery_domain
オプションを使用してドメイン名を指定します。 -
オプション: デフォルトでは、サービス検出は LDAP サービスタイプをスキャンします。別のサービスタイプを使用するには、
ldap_dns_service_name
オプションを使用してタイプを指定します。 -
オプション: デフォルトでは、SSSD は IPv4 アドレスの検索を試行します。試行に失敗すると、SSSD は IPv6 アドレスの検索を試行します。この動作をカスタマイズするには、
lookup_family_order
オプションを使用します。 サービス検出を使用するすべてのサービスについて、DNS レコードを DNS サーバーに追加します。
_service._protocol._domain TTL priority weight port host_name
関連情報
- DNS サービス検出に関する RFC 2782
-
sssd.conf(5)
の man ページ
4.5. Simple アクセスプロバイダーのルール設定
simple
アクセスプロバイダーは、ユーザー名またはグループの一覧に基づいてアクセスを許可または拒否します。これにより、特定のマシンへのアクセスを制限できます。
たとえば、Simple
アクセスプロバイダーを使用して、特定のユーザーまたはグループへのアクセスを制限できます。他のユーザーまたはグループは、設定済みの認証プロバイダーに対して正常に認証されている場合でもログインできません。
前提条件
-
root
アクセス
手順
-
/etc/sssd/sssd.conf
ファイルを開きます。 access_provider
オプションをsimple
に設定します。[domain/your-domain-name] access_provider = simple
ユーザーのアクセス制御ルールを定義します。
-
ユーザーへのアクセスを許可するには、
simple_allow_users
オプションを使用します。 ユーザーへのアクセスを拒否するには、
simple_deny_users
オプションを使用します。重要特定のユーザーへのアクセスを拒否する場合には、他のユーザーすべてにアクセスを自動的に許可します。特定ユーザーにアクセスを許可する方が拒否するよりも安全であると考えられます。
-
ユーザーへのアクセスを許可するには、
グループのアクセス制御ルールを定義します。以下のいずれかを選択します。
-
グループへのアクセスを許可するには、
simple_allow_groups
オプションを使用します。 グループへのアクセスを拒否するには、
simple_deny_groups
オプションを使用します。重要特定のグループへのアクセスを拒否する場合には、他のグループすべてに、アクセスを自動的に許可します。特定グループにアクセスを許可する方が拒否するよりも安全であると考えられます。
例4.3 特定のユーザーおよびグループへのアクセス許可
以下の例では、他のユーザーすべてに対して、アクセスを拒否する一方で、user1、user2、および group1 のメンバーにアクセスを許可します。
[domain/your-domain-name] access_provider = simple simple_allow_users = user1, user2 simple_allow_groups = group1
-
グループへのアクセスを許可するには、
拒否リストを空にすると、すべてのユーザーがアクセスできるようになります。
関連情報
-
sssd-simple5
man ページ
4.6. LDAP アクセスフィルターを適用するための SSSD 設定
/etc/sssd/sssd.conf
で access_provider
オプションが設定されている場合に、SSSD は指定されたアクセスプロバイダーを使用して、システムにアクセスできるユーザーを評価します。使用しているアクセスプロバイダーが LDAP プロバイダータイプの拡張の場合には、システムへのアクセス許可に必要な LDAP アクセス制御フィルターを指定することもできます。
たとえば、Active Directory (AD) サーバーをアクセスプロバイダーとして使用する場合は、Linux システムへのアクセスを制限できます。指定されたフィルターに該当しない他のユーザーはすべて、アクセスが拒否されます。
アクセスフィルターは LDAP ユーザーエントリーにのみ適用されます。そのため、ネスト化されたグループでこのタイプのアクセス制御を使用すると機能しない可能性があります。ネストされたグループにアクセス制御を適用するには、Simple
アクセスプロバイダールールの設定 を参照してください。
オフラインキャッシュを使用する場合、SSSD は、ユーザーが最後にオンラインログインの試行に成功したかどうかを確認します。直近のオンラインログイン中に正常にログインしたユーザーは、アクセスフィルターに一致しない場合でも、オフラインでログインできるようになります。
前提条件
-
root
アクセス
手順
-
/etc/sssd/sssd.conf
ファイルを開きます。 [domain]
セクションで、LDAP アクセス制御フィルターを指定します。-
LDAP アクセスプロバイダーの場合は、
ldap_access_filter
オプションを使用します。詳細はsssd-ldap(5)
man ページを参照してください。 AD アクセスプロバイダーの場合は、
ad_access_filter
オプションを使用します。詳細はsssd-ad(5)
man ページを参照してください。例4.4 特定の AD ユーザーへのアクセス許可
たとえば、
admins
ユーザーグループに属し、属性セットがunixHomeDirectory
の AD ユーザーにのみアクセスを許可するには、以下を使用します。[domain/your-AD-domain-name] access provider = ad [... file truncated ...] ad_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*))
-
LDAP アクセスプロバイダーの場合は、
SSSD は、エントリーの authorizedService
または host
属性により結果を確認することもできます。実際、ユーザーエントリーおよび設定に応じて、全オプションの MDASH LDAP フィルター、authorizedService
および host
の MDASH を評価できます。ldap_access_order
パラメーターは、評価すべき順に、使用するアクセスコントロールの手法をすべて表示します。
[domain/example.com] access_provider = ldap ldap_access_filter = memberOf=cn=allowedusers,ou=Groups,dc=example,dc=com ldap_access_order = filter, host, authorized_service
関連情報
-
sssd-ldap(5)
の man ページ
第5章 SSSD クライアント側のビュー
SSSD には sss_override
ユーティリティーがあるので、ローカルマシンに固有の POSIX ユーザーまたはグループ属性の値を表示するローカルビューを作成できます。ipa
以外の全 id_provider
値に上書きを設定できます。
ipa
プロバイダーを使用している場合は、IPA で ID ビューを一元的に定義します。詳細は ID ビューを使用した IdM クライアントのユーザー属性値の上書き を参照してください。
SSSD のパフォーマンスに与える可能性のある悪影響については、SSSD パフォーマンスにおける ID ビューによる悪影響の可能性 を参照してください。
5.1. LDAP ユーザー名属性の上書き
管理者は、既存のホストが LDAP からアカウントを使用するように設定できます。ただし、LDAP のユーザー (名前、UID、GID、ホームディレクトリー、シェル) の値は、ローカルシステムの値とは異なります。以下の手順でセカンダリーの username
を定義して LDAP の username
属性を上書きできます。
前提条件
-
root
アクセス -
sssd-tools
がインストールされている
手順
ユーザーの現在の情報を表示します。
# id username
username は、ユーザー名に置き換えます。
セカンダリーの
ユーザー名
を追加します。# sss_override user-add username -n secondary-username
username はユーザー名に、secondary-username は新しい
ユーザー名
に置き換えます。sss_override user-add
コマンドを使用して最初の上書きを作成したら、SSSD を再起動して変更を反映します。# systemctl restart sssd
検証手順
新しい
ユーザー名
が追加されたことを確認します。# id secondary-username
任意です。ユーザーの上書きを表示します。
# sss_override user-show user-name user@ldap.example.com:secondary-username::::::
例5.1 セカンダリーユーザー名の定義
ユーザー sjones にセカンダリーの
username
の sarah を追加するには以下を実行します。ユーザー sjones の現在の情報を表示します。
# id sjones uid=1001(sjones) gid=6003 groups=6003,10(wheel)
セカンダリーの
ユーザー名
を追加します。# sss_override user-add sjones -n sarah
新しい
ユーザー名
が追加され、ユーザーの上書きが正しく表示されることを確認します。# id sarah uid=1001(sjones) gid=6003(sjones) groups=6003(sjones),10(wheel) # sss_override user-show sjones user@ldap.example.com:sarah::::::
関連情報
-
sss_override の
man ページ
5.2. LDAP UID 属性の上書き
管理者は、既存のホストが LDAP からアカウントを使用するように設定できます。ただし、LDAP のユーザー (名前、UID、GID、ホームディレクトリー、シェル) の値は、ローカルシステムの値とは異なります。以下の手順で異なる UID を定義して LDAP UID 属性を上書きできます。
前提条件
-
root
アクセス -
sssd-tools
がインストールされている
手順
ユーザーの現在の UID を表示します。
# id -u user-name
user-name は、ユーザー名に置き換えます。
ユーザーのアカウントの UID を上書きします。
# sss_override user-add user-name -u new-UID
user-name はユーザー名に、new-UID は新しい UID 番号に置き換えます。
インメモリーキャッシュを失効させます。
# sss_cache --users
sss_override user-add
コマンドを使用して最初の上書きを作成したら、SSSD を再起動して変更を反映します。# systemctl restart sssd
検証手順
新しい UID が適用されていることを確認します。
# id -u user-name
任意です。ユーザーの上書きを表示します。
# sss_override user-show user-name user@ldap.example.com::new-UID:::::
例5.2 ユーザーの UID の上書き
ユーザー sarah の UID を 6666 に上書きするには、次のコマンドを実行します。
ユーザー sarah の現在の UID を表示します。
# id -u sarah 1001
ユーザー sarah のアカウントの UID を 6666 に上書きします。
# sss_override user-add sarah -u 6666
インメモリーキャッシュを手動で失効させます。
# sss_cache --users
SSSD を再起動して変更を適用します。
# systemctl restart sssd
新しい UID が適用され、ユーザーの上書きが正しく表示されていることを確認します。
# id sarah 6666 # sss_override user-show sarah user@ldap.example.com::6666:::::
関連情報
-
sss_override の
man ページ
5.3. LDAP GID 属性の上書き
管理者は、既存のホストが LDAP からアカウントを使用するように設定できます。ただし、LDAP のユーザー (名前、UID、GID、ホームディレクトリー、シェル) の値は、ローカルシステムの値とは異なります。以下の手順で別の GID を定義して、LDAP GID 属性を上書きできます。
前提条件
-
root
アクセス -
sssd-tools
がインストールされている
手順
ユーザーの現在の GID を表示します。
# id -g user-name
user-name は、ユーザー名に置き換えます。
ユーザーのアカウントの GID を上書きします。
# sss_override user-add user-name -g new-GID
user-name はユーザー名に、new-GID は新しい GID 番号に置き換えます。
インメモリーキャッシュを失効させます。
# sss_cache --users
sss_override user-add
コマンドを使用して最初の上書きを作成したら、SSSD を再起動して変更を反映します。# systemctl restart sssd
検証手順
新しい GID が適用されていることを確認します。
# id -g user-name
任意です。ユーザーの上書きを表示します。
# sss_override user-show user-name user@ldap.example.com:::6666::::
例5.3 ユーザーの GID の上書き
ユーザー sarah の GID を 6666 に上書きするには、次のコマンドを実行します。
ユーザー sarah の現在の GID を表示します。
# id -g sarah 6003
ユーザー sarah アカウントの GID を 6666 に上書きします。
# sss_override user-add sarah -g 6666
インメモリーキャッシュを手動で失効させます。
# sss_cache --users
これが最初の上書きの場合には、SSSD を再起動して変更を反映します。
# systemctl restart sssd
新しい GID が適用され、ユーザーの上書きが正しく表示されていることを確認します。
# id -g sarah 6666 # sss_override user-show sarah user@ldap.example.com::6666:::::
関連情報
-
sss_override の
man ページ
5.4. LDAP ホームディレクトリー属性の上書き
管理者は、既存のホストが LDAP からアカウントを使用するように設定できます。ただし、LDAP のユーザー (名前、UID、GID、ホームディレクトリー、シェル) の値は、ローカルシステムの値とは異なります。以下の手順で別のホームディレクトリーを定義して、LDAP ホームディレクトリー属性を上書きできます。
前提条件
-
root
アクセス -
sssd-tools
がインストールされている
手順
ユーザーの現在のホームディレクトリーを表示します。
# getent passwd user-name user-name:x:XXXX:XXXX::/home/home-directory:/bin/bash
user-name は、ユーザー名に置き換えます。
ユーザーのホームディレクトリーを上書きします。
# sss_override user-add user-name -h new-home-directory
user-name はユーザー名に、new-home-directory は新しいホームディレクトリーに置き換えます。
SSSD を再起動して変更を適用します。
# systemctl restart sssd
検証手順
新しいホームディレクトリーが定義されていることを確認します。
# getent passwd user-name user-name:x:XXXX:XXXX::/home/new-home-directory:/bin/bash
任意です。ユーザーの上書きを表示します。
# sss_override user-show user-name user@ldap.example.com:::::::new-home-directory::
例5.4 ユーザーのホームディレクトリーの上書き
ユーザー sarah のホームディレクトリーを admin に上書きするには、次のコマンドを実行します。
ユーザー sarah の現在のホームディレクトリーを表示します。
# getent passwd sarah sarah:x:1001:6003::sarah:/bin/bash
ユーザー sarah のホームディレクトリーは、新しいユーザーのホームディレクトリー admin に上書きします。
# sss_override user-add sarah -h admin
SSSD を再起動して変更を適用します。
# systemctl restart sssd
新しいホームディレクトリーが定義され、ユーザーの上書きが正しく表示されることを確認します。
# getent passwd sarah sarah:x:1001:6003::admin:/bin/bash # sss_override user-show user-name user@ldap.example.com:::::::admin::
関連情報
-
sss_override の
man ページ
5.5. LDAP シェル属性の上書き
管理者は、既存のホストが LDAP からアカウントを使用するように設定できます。ただし、LDAP のユーザー (名前、UID、GID、ホームディレクトリー、シェル) の値は、ローカルシステムの値とは異なります。以下の手順で別のシェルを定義して、LDAP シェル属性を上書きできます。
前提条件
-
root
アクセス -
sssd-tools
がインストールされている
手順
ユーザーの現在のシェルを表示します。
# getent passwd user-name user-name:x:XXXX:XXXX::/home/home-directory:/bin/bash
user-name は、ユーザー名に置き換えます。
ユーザーのシェルを上書きします。
# sss_override user-add user-name -s new-shell
user-name はユーザーの名前に、new-shell は新しいシェルに置き換えます。
SSSD を再起動して変更を適用します。
# systemctl restart sssd
検証手順
新しいシェルが定義されていることを確認します。
# getent passwd user-name user-name:x:XXXX:XXXX::/home/home-directory:new-shell
任意です。ユーザーの上書きを表示します。
# sss_override user-show user-name user@ldap.example.com::::::new-shell:
例5.5 ユーザーのシェルの上書き
ユーザー sarah のシェルを
/bin/bash
からsbin/nologin
に変更するには、次のコマンドを実行 します。ユーザー sarah の現在のシェルを表示します。
# getent passwd sarah sarah:x:1001:6003::sarah:/bin/bash
ユーザー sarah のシェルを新しい
/sbin/nologin
シェルに上書きします。# sss_override user-add sarah -s /sbin/nologin
SSSD を再起動して変更を適用します。
# systemctl restart sssd
新しいシェルが定義され、ユーザーの上書きが正しく表示されることを確認します。
# getent passwd sarah sarah:x:1001:6003::sarah:/sbin/nologin # sss_override user-show user-name user@ldap.example.com::::::/sbin/nologin:
関連情報
-
sss_override の
man ページ
5.6. ホストの上書きの一覧表示
管理者は、ホスト上の全ユーザーおよびグループの上書きを一覧表示し、正しい属性が上書きされたことを確認できます。
前提条件
-
root
アクセス -
sssd-tools
がインストールされている
手順
全ユーザーの上書きを一覧表示します。
# sss_override user-find user1@ldap.example.com::8000::::/bin/zsh: user2@ldap.example.com::8001::::/bin/bash: ...
全グループの上書きを一覧表示します。
# sss_override group-find group1@ldap.example.com::7000 group2@ldap.example.com::7001 ...
5.7. ローカルの上書きの削除
グローバル LDAP ディレクトリーに定義されているローカルの上書きを削除するには、以下の手順を使用します。
前提条件
-
root
アクセス -
sssd-tools
がインストールされている
手順
ユーザーアカウントの上書きを削除するには、以下を使用します。
# sss_override user-del user-name
user-name は、ユーザー名に置き換えます。変更はすぐに有効になります。
グループの上書きを削除するには、以下を使用します。
# sss_override group-del group-name
sss_override user-del
またはsss_override group-del
コマンドを使用して最初の上書きを削除したら、SSSD を再起動して変更を反映します。# systemctl restart sssd
ユーザーまたはグループの上書きを削除すると、このオブジェクトの上書きがすべて削除されます。
5.8. ローカルビューのエクスポートおよびインポート
ローカルの上書きは、ローカルの SSSD キャッシュに保存されています。このキャッシュからファイルにユーザーおよびグループの上書きをエクスポートして、バックアップを作成できます。バックアップを作成することでキャッシュが削除されても、後で設定を復元できます。
前提条件
-
root
アクセス -
sssd-tools
がインストールされている
手順
ユーザーおよびグループビューのバックアップを作成するには、以下を使用します。
# sss_override user-export /var/lib/sss/backup/sssd_user_overrides.bak # sss_override group-export /var/lib/sss/backup/sssd_group_overrides.bak
ユーザーおよびグループビューを復元するには、以下を使用します。
# sss_override user-import /var/lib/sss/backup/sssd_user_overrides.bak # sss_override group-import /var/lib/sss/backup/sssd_group_overrides.bak
第6章 AD を認証プロバイダーとして使用する RHEL ホストの設定
システム管理者は、ホストを AD に参加させずに、Red Hat Enterprise Linux (RHEL) ホストの認証プロバイダーとして Active Directory (AD) を使用できます。
たとえば、以下のような場合に実行できます。
- AD 管理者に対して、ホストの有効化および無効化の制御を付与しない場合。
- そのホスト (企業 PC) は、社内で 1 人のユーザーのみが使用する予定である。
この手順は、このアプローチが推奨される場合に限り実装してください。通常は推奨されません。
代わりに、システムを AD または Red Hat Identity Management (IdM) に完全に参加させることを検討してください。RHEL ホストをドメインに参加させると、設定を簡単に管理できます。クライアントを直接 AD に参加させることに関連するクライアントアクセスライセンスについて懸念がある場合は、AD との信頼関係にある IdM サーバーを活用することを検討してください。IdM-AD 信頼の詳細は、IdM と AD との間のフォレスト間の信頼の計画 と IdM と AD との間のフォレスト間の信頼のインストール を参照してください。
この手順を実行すると、AD_user という名前のユーザーが、example.com ドメインの Active Directory (AD) ユーザーデータベースに設定されたパスワードを使用して、rhel_host システムにログインできるようになります。この例では、Kerberos レルム EXAMPLE.COM は example.com ドメインに対応します。
前提条件
- rhel_host への root アクセスがある。
- AD_user ユーザーアカウントが example.com ドメインにある。
- Kerberos レルムが EXAMPLE.COM である。
-
realm join
コマンドを使用して、rhel_host が AD に参加していません。
手順
パスワードを割り当てずに、AD_user ユーザーアカウントをローカルに作成します。
# useradd AD_user
/etc/nsswitch.conf
ファイルを開いて編集し、以下の行が含まれていることを確認します。passwd: sss files systemd group: sss files systemd shadow: files sss
/etc/krb5.conf
ファイルを開いて編集し、以下のセクションと項目が含まれるようにします。# To opt out of the system crypto-policies configuration of krb5, remove the # symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated. includedir /etc/krb5.conf.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] dns_lookup_realm = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt spake_preauth_groups = edwards25519 default_realm = EXAMPLE.COM default_ccache_name = KEYRING:persistent:%{uid} [realms] EXAMPLE.COM = { kdc = ad.example.com admin_server = ad.example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
/etc/sssd/sssd.conf
ファイルを作成し、以下のセクションと行をそのファイルに追加します。[sssd] services = nss, pam domains = EXAMPLE.COM [domain/EXAMPLE.COM] id_provider = files auth_provider = krb5 krb5_realm = EXAMPLE.COM krb5_server = ad.example.com
/etc/sssd/sssd.conf
ファイルの権限を変更します。# chmod 600 /etc/sssd/sssd.conf
SSSD (Security System Services Daemon) を起動します。
# systemctl start sssd
SSSD を有効にします。
# systemctl enable sssd
/etc/pam.d/system-auth
ファイルを開き、以下のセクションと行が含まれるように変更します。# Generated by authselect on Wed May 8 08:55:04 2019 # Do not modify this file manually. auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet auth [default=1 ignore=ignore success=ok] pam_localuser.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so forward_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
/etc/pam.d/system-auth
ファイルの内容を/etc/pam.d/password-auth
ファイルにコピーします。yes と入力して、ファイルの現在の内容を上書きします。# cp /etc/pam.d/system-auth /etc/pam.d/password-auth cp: overwrite '/etc/pam.d/password-auth'? yes
検証手順
AD_user 用の Kerberos チケット保証チケット (TGT) を要求します。AD_user のパスワードを必要に応じて入力します。
# kinit AD_user Password for AD_user@EXAMPLE.COM:
取得した TGT を表示します。
# klist Ticket cache: KEYRING:persistent:0:0 Default principal: AD_user@EXAMPLE.COM Valid starting Expires Service principal 11/02/20 04:16:38 11/02/20 14:16:38 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 18/02/20 04:16:34
AD_user は、Kerberos ドメイン EXAMPLE.COM の認証情報を使用して rhel_host に正常にログインしました。
第7章 SSSD を使用したホストのユーザーアクセスに関するレポート
SSSD (Security System Services Daemon) は、どのユーザーがクライアントにアクセスできるか、またはできないかを追跡します。本章では、sssctl
ツールを使用してアクセス制御レポートを作成し、ユーザーデータを表示する方法を説明します。
前提条件
- SSSD パッケージがネットワーク環境にインストールされている。
7.1. sssctl コマンド
sssctl
は、SSSD (Security System Services Daemon) のステータスに関する情報を取得できるように一貫した方法を提供するコマンドラインツールです。
sssctl
ユーティリティーを使用して、以下の情報を収集できます。
- ドメインの状態
- クライアントユーザー認証
- 特定のドメインのクライアントへのユーザーアクセス
- キャッシュされたコンテンツに関する情報
sssctl
ツールを使用すると、以下が可能になります。
- SSSD キャッシュの管理
- ログの管理
- 設定ファイルの確認
sssctl
ツールは、sss_cache
ツールおよび sss_debuglevel
ツールに代わるものです。
関連情報
-
sssctl --help
7.2. sssctl を使用したアクセス制御レポートの生成
SSSD は、クライアントにログインできるユーザーを制御するため、レポートを実行しているマシンに適用されるアクセス制御ルールを一覧表示できます。
キー配布センター (KDC) がロックアウトしたユーザーをツールが追跡しないため、アクセスレポートは正確ではありません。
前提条件
- 管理者権限でログインしている。
-
sssctl
ツールが RHEL 7 および RHEL 8 システムで利用できる
手順
idm.example.com
ドメインのレポートを生成するには、以下を入力します。[root@client1 ~]# sssctl access-report idm.example.com 1 rule cached Rule name: example.user Member users: example.user Member services: sshd
7.3. sssctl でユーザー認可の詳細の表示
sssctl user-checks
コマンドは、SSSD (System Security Services Daemon) をユーザールックアップ、認証、および認可に使用するアプリケーションでの問題のデバッグに役立ちます。
sssctl user-checks [USER_NAME]
コマンドは、NSS (Name Service Switch) および D-Bus インターフェイスの InfoPipe レスポンダーで利用可能なユーザーデータを表示します。表示されるデータは、ユーザーが system-auth
の PAM (Pluggable Authentication Module) サービスを使用してログインすることを許可されているかどうかを示します。
コマンドには、2 つのオプションがあります。
-
-a
(PAM アクション用) -
-s
(PAM サービス用)
-a
オプションおよび -s
オプションを定義しない場合、sssctl
ツールはデフォルトのオプション -a acct -s system-auth
を使用します。
前提条件
- 管理者権限でログインしている。
-
sssctl
ツールが RHEL 7 および RHEL 8 システムで利用できる
手順
特定ユーザーのユーザーデータを表示するには、以下を入力します。
[root@client1 ~]# sssctl user-checks -a acct -s sshd example.user user: example.user action: acct service: sshd ....
関連情報
-
sssctl user-checks --help
第8章 SSSD を使用したドメイン情報のクエリー
SSSD (Security System Services Daemon) は、Identity Management (IdM) のドメインと、フォレスト間の信頼で IdM に接続する Active Directory のドメインを一覧表示できます。
8.1. sssctl を使用したドメインの一覧表示
sssctl domain-list
コマンドを使用して、ドメイントポロジーの問題をデバッグできます。
ステータスはすぐに利用できない可能性があります。ドメインが表示されない場合は、コマンドを繰り返します。
前提条件
- 管理者権限でログインしている。
-
sssctl
ツールが RHEL 7 および RHEL 8 システムで利用できる
手順
sssctl コマンドのヘルプを表示するには、以下のコマンドを実行します。
[root@client1 ~]# sssctl --help ....
- 利用可能なドメインの一覧を表示するには、以下を入力します。
[root@client1 ~]# sssctl domain-list
implicit_files
idm.example.com
ad.example.com
sub1.ad.example.com
一覧には、Active Directory と Identity Management との間でフォレスト間の信頼関係にあるドメインが含まれます。
8.2. sssctl でドメインステータスの確認
sssctl domain-status
コマンドを使用して、ドメイントポロジーの問題をデバッグできます。
ステータスはすぐに利用できない可能性があります。ドメインが表示されない場合は、コマンドを繰り返します。
前提条件
- 管理者権限でログインしている。
-
sssctl
ツールが RHEL 7 および RHEL 8 システムで利用できる
手順
sssctl コマンドのヘルプを表示するには、以下のコマンドを実行します。
[root@client1 ~]# sssctl --help
特定ドメインのユーザーデータを表示するには、以下を入力します。
[root@client1 ~]# sssctl domain-status idm.example.com Online status: Online Active servers: IPA: server.idm.example.com Discovered IPA servers: - server.idm.example.com
ドメイン idm.example.com
はオンラインになり、コマンドを設定したクライアントから表示されます。
ドメインが利用できないと、結果は以下のようになります。
[root@client1 ~]# sssctl domain-status ad.example.com
Unable to get online status
第9章 SSSD を使用した PAM サービスのドメインの制限
プラグ可能な認証モジュール (PAM) は、認証および認可の一般的なフレームワークです。Red Hat Enterprise Linux のシステムアプリケーションの多くは、認証および承認の基礎となる PAM 設定により異なります。
SSSD (System Security Services Daemon) を使用すると、PAM サービスがアクセスできるドメインを制限できます。SSSD は、特定の PAM サービスを実行するユーザーに基づいて PAM サービスからの認証要求を評価します。つまり、PAM サービスユーザーが SSSD ドメインにアクセスできる場合は、PAM サービスもそのドメインにアクセスできることを意味します。
9.1. PAM について
Pluggable Authentication Module (PAM) は、システムアプリケーションが、中央で設定したフレームワークに認証を中継するのに使用できる集中認証メカニズムを提供します。
PAM モジュールは、Kerberos、SSSD、NIS、ローカルファイルシステムなどのさまざまなタイプの認証ソースに存在するため、PAM はプラグ可能です。別の認証ソースに優先順位を付けることができます。
このモジュラーアーキテクチャーにより、管理者はシステムの認証ポリシーを柔軟に設定することができます。PAM は、開発者および管理者にとって以下のような便利なシステムです。
- PAM は、幅広いアプリケーションで使用できる一般的な認証スキームを提供します。
- PAM は、システム管理者に対して、優れた柔軟性と制御性を提供します。
- PAM では、完全にドキュメント化されたライブラリーが 1 つ提供され、開発者が独自の認証スキームを作成しなくてもプログラムを作成できるようになります。
9.2. ドメインアクセス制限のオプション
選択したドメインへのアクセスを制限するには、以下のオプションを使用できます。
pam_trusted_users
in/etc/sssd/sssd.conf
-
このオプションでは、SSSD が信頼する PAM サービスを表す数値の UID またはユーザー名の一覧を使用できます。デフォルト設定は
all
です。つまり、すべてのサービスユーザーが信頼され、どのドメインにもアクセスできます。 pam_public_domains
in/etc/sssd/sssd.conf
-
このオプションは、パブリック SSSD ドメインの一覧を受け入れます。パブリックドメインは、信頼できない PAM サービスユーザーであってもドメインにアクセスできます。このオプションでは、
all
とnone
の値も使用できます。既定値はnone
です。つまり、ドメインが公開されておらず、信頼できないサービスユーザーはどのドメインにもアクセスできません。 - PAM 設定ファイルの
domain
このオプションは、PAM サービスが認証できるドメインの一覧を指定します。ドメインを指定せずに
domain
を使用すると、以下のようなドメインに対しては認証されません。auth required pam_sss.so domains=
PAM 設定ファイルで
Domains
を使用する場合は、そのサービスを信頼できるユーザーで実行しているときに、すべてのドメインに対して PAM サービスを認証できます。/etc/sssd/sssd.conf
SSSD 設定ファイルのdomain
オプションは、SSSD が認証を試行するドメインの一覧を指定します。PAM 設定ファイルのdomain
オプションは、sssd.conf
ではドメインの一覧を拡張できないため、短縮した一覧を指定することで、ドメインのsssd.conf
の一覧を制限することしかできないことに注意してください。そのため、ドメインが PAM ファイルで指定されていても、sssd.conf
では指定されていない場合、PAM サービスはドメインに対して認証を行いません。
デフォルト設定の pam_trusted_users = all
および pam_public_domains = none
では、すべての PAM サービスユーザーが信頼され、任意のドメインにアクセスできることを指定します。PAM 設定ファイルに domain
を使用すると、ドメインへのアクセスが制限されます。
sssd.conf
に pam_public_domains
が含まれる場合に PAM 設定ファイルで domain
を使用してドメインを指定するには、pam_public_domains
でドメインを指定する必要があります。必要なドメインを含まない pam_public_domains
オプションを使用すると、信頼できないユーザーでサービスを実行している場合に、ドメインに対する PAM サービスの認証が失敗します。
PAM 設定ファイルで定義するドメインの制限は、認証アクションにのみ適用され、ユーザーのルックアップには適用されません。
関連情報
-
pam_trusted_users
オプションおよびpam_public_domains
オプションの詳細は、man ページのsssd.conf(5)
を参照してください。 -
PAM 設定ファイルで使用される
ドメイン
オプションの詳細は、man ページのpam_sss(8)
を参照してください。
9.3. PAM サービスのドメインの制限
この手順では、ドメインに対して PAM サービス認証を制限する方法を示します。
前提条件
- SSSD がインストールされ、実行している。
手順
必要なドメインにアクセスするように SSSD を設定します。
/etc/sssd/sssd.conf
ファイルーのドメイン
で、SSSD が認証できるドメインを定義します。[sssd] domains = domain1, domain2, domain3
PAM 設定ファイルで
domain
オプションを設定することで、PAM サービスが認証できるドメインを指定します。以下に例を示します。auth sufficient pam_sss.so forward_pass domains=domain1 account [default=bad success=ok user_unknown=ignore] pam_sss.so password sufficient pam_sss.so use_authtok
この例では、
domain1
に対する認証のみを許可します。
検証手順
-
domain1
に対して認証を行います。それは成功する必要があります。
第10章 nslcd から SSSD への認証の移行
10.1. RHEL クライアントを nslcd から SSSD に移行する
nss-pam-ldapd
パッケージが RHEL から削除されたため、Red Hat は SSSD
とその ldap
プロバイダーに移行することをお勧めします。これは nslcd
サービスの機能を置き換えます。次の手順では、nss-pam-ldap
認証設定を使用するように以前に設定されたクライアントで LDAP ユーザーを認証するように SSSD
を設定する方法について説明します。
前提条件
- RHEL クライアントは RHEL8 または RHEL 9 上にあります。
-
以前に、
nslcd
サービスを使用して LDAP ディレクトリーサーバーに対して認証するように RHEL クライアントを設定しました。 - LDAP ディレクトリーサービスは、RFC-2307 で定義されたスキーマを使用します。
手順
現在の認証設定をバックアップします。
# authselect apply-changes -b --backup=ldap-configuration-backup
SSSD
パッケージをインストールします。# yum install sssd-ldap sssd-ad sssd-client \ sssd-common sssd-common-pac \ sssd-krb5 sssd-krb5-common
nslcd
およびnscd
サービスを停止して無効にします。# systemctl stop nslcd nscd # systemctl disable nslcd nscd
SSSD
で認証を設定します:# authselect select sssd with-mkhomedir --force
SSSD
設定ファイルに必要な所有権と権限を設定します。# chown root:root /etc/sssd/sssd.conf # chmod 600 /etc/sssd/sssd.conf
-
/etc/sssd/sssd.conf
ファイルを開いて編集します。 次の設定を入力し、
example.com
やdc=example,dc=com
などの値をご使用の環境に適した値に置き換えます。[sssd] config_file_version = 2 services = nss, pam domains = EXAMPLE.COM debug_level = 6 [domain/EXAMPLE.COM] id_provider = ldap auth_provider = ldap ldap_uri = ldap://server.example.com/ ldap_search_base = dc=example,dc=com ldap_default_bind_dn = CN=binddn,DC=example,DC=com ldap_default_authtok_type = password ldap_default_authtok = <bind_account_password> cache_credentials = True
注記SSSD
設定で LDAP スキーマを指定する必要がある場合があります。ディレクトリーサーバーで RFC-2307bis スキーマを使用している場合は、
[domain/EXAMPLE.COM]
セクションに次の行を追加します。ldap_schema = rfc2307bis
Microsoft Active Directory サーバーを使用している場合は、
[domain/EXAMPLE.COM]
セクションに次の行を追加して、LDAP ベースの認証を有効にします。ldap_schema = ad
Kerberos 認証が必要な場合、Red Hat は、
SSSD
サービスを自動的に設定するrealm
コマンドを使用して RHEL クライアントを AD ドメインに参加させることをお勧めします。SSSD
サービスを有効にして開始します。# systemctl enable sssd # systemctl start sssd
検証手順
LDAP ユーザーに関する情報を取得できることを確認します。
# id ldapuser uid=100424(ldapuser) gid=100424(ldapuser) groups=100424(ldapuser) # getent passwd ldapuser ldapuser:*: 100424: 100424:User, LDAP:/home/ldapuser:/bin/bash
LDAP ユーザーとしてログインできることを確認します。
# ssh -l ldapuser localhost ldapuser@localhost's password: Last login: Tue Dec 07 19:34:35 2021 from localhost -sh-4.2$
nslcd
と nscd
を使用して元の LDAP 設定を復元する必要がある場合は、次のコマンドを使用します。
# authselect backup-restore=ldap-configuration-backup # systemctl stop sssd && systemctl disable sssd # systemctl start nslcd nscd # systemctl enable nslcd nscd
10.2. nslcd.conf
オプションに相当する sssd.conf
オプション
nslcd
から SSSD
への移行を支援するために、次の表に、nslcd.conf
設定ファイルの一般的なオプションと sssd.conf
設定ファイルの同等のオプションを示します。
表10.1 nslcd.conf
オプションに相当する sssd.conf
オプション
nslcd.conf オプション | sssd.conf オプション | 説明 |
---|---|---|
| 該当なし |
デーモンを実行するためのユーザー ID。デフォルトでは、SSSD は |
| 該当なし |
デーモンを実行する際に使用するグループ ID。デフォルトでは、SSSD は |
|
|
次の形式の LDAP サーバーの URI: |
|
| 検索ベースの識別名。 |
|
| LDAP 操作の実行に使用するデフォルトのバインド DN。 |
|
| デフォルトのバインド DN の認証トークン。現在、クリアテキストのパスワードのみがサポートされています。 |
|
| デフォルトのバインド DN の認証トークン。現在、クリアテキストのパスワードのみがサポートされています。 |
|
| サーバー提供の証明書に対して実行するチェックを指定します。 |
|
| すべての認証局の証明書を含むファイル。 |
|
| 個別のファイルに認証局証明書が含まれているディレクトリーのパス。 |
|
| ユーザーの LDAP 検索を制限するためのベース DN、検索範囲、LDAP フィルターをオプションで指定します。 |
|
| グループの LDAP 検索を制限するためのオプションのベース DN、検索範囲、および LDAP フィルター。 |
関連情報
-
nslcd.conf(5)
man ページ -
sssd-ldap(5)
man ページ
第11章 ローカル SSSD 設定の誤字の排除
sssctl config-check
コマンドを使用して、ホストの /etc/sssd/sssd.conf
ファイルに誤字のエラーがあるかどうかをテストできます。
前提条件
- root でログインしている。
-
sssd-tools
パッケージがインストールされている。
手順
sssctl config-check
コマンドを実行します。# sssctl config-check Issues identified by validators: 1 [rule/allowed_domain_options]: Attribute 'ldap_search' is not allowed in section 'domain/example1'. Check for typos. Messages generated during configuration merging: 0 Used configuration snippet files: 0
/etc/sssd/sssd.conf
ファイルを開き、タイプミスを修正します。前の例でエラーメッセージが発生した場合は、ldap_search を ldap_search_base に置き換えます。[...] [domain/example1] ldap_search_base = dc=example,dc=com [...]
- ファイルを保存します。
SSSD を再起動します。
# systemctl restart sssd
検証手順
sssctl config-check
コマンドを実行します。# sssctl config-check Issues identified by validators: 0 Messages generated during configuration merging: 0 Used configuration snippet files: 0
/etc/sssd/sssd.conf
ファイルで、誤字がなくなりました。
第12章 IdM で SSSD を使用した認証のトラブルシューティング
Identity Management (IdM) 環境の認証には、さまざまなコンポーネントが含まれます。
IdM クライアントで、以下を行います。
- SSSD サービス
- Name Services Switch (NSS)
- PAM (プラグ可能な認証モジュール)
IdM サーバーで、以下を行います。
- SSSD サービス
- IdM Directory Server。
- IdM Kerberos Key Distribution Center (KDC)
Active Directory (AD) ユーザーとして認証している場合は、以下を行います。
- AD ドメインコントローラー上の Directory Server。
- AD ドメインコントローラー上の Kerberos サーバー
ユーザーを認証するには、SSSD サービスで以下の機能を実行できる必要があります。
- 認証サーバーからユーザー情報を取得します。
- ユーザーに認証情報を求められ、それらの認証情報を認証サーバーに渡し、結果を処理します。
以下のセクションでは、ユーザー情報を保存する SSSD サービスとサーバー間の情報フロー方法を説明し、環境で失敗した認証試行のトラブルシューティングを行うことができます。
- SSSD で IdM ユーザー情報を取得するデータフロー
- SSSD で AD ユーザー情報を取得する際のデータフロー
- IdM で SSSD を使用してユーザーとして認証する場合にデータフロー
- 認証問題の範囲の制限
- SSSD ログファイルおよびログレベル
- sssd.conf ファイルで SSSD の詳細なロギングの有効化
- sssctl コマンドを使用した SSSD の詳細なロギングの有効化
- SSSD サービスからデバッグログを収集し、IdM サーバーによる認証問題のトラブルシューティング
- SSSD サービスからデバッグログを収集し、IdM クライアントによる認証問題のトラブルシューティング
- SSSD バックエンドでのクライアント要求の追跡
- ログアナライザーツールを使用したクライアント要求の追跡
12.1. SSSD で IdM ユーザー情報を取得するデータフロー
以下の図は、getent passwd <idm_user_name>
コマンドを使用して IdM ユーザー情報の要求時に IdM クライアントと IdM サーバーとの間の情報フローを簡単に説明します。
-
getent
コマンドは、libc
ライブラリーからgetpwnam
呼び出しをトリガーします。 -
libc
ライブラリーは、/etc/nsswitch.conf
設定ファイルを参照して、どのサービスがユーザー情報を提供するかを確認し、SSSD サービスのエントリーsss
を検出します。 -
libc
ライブラリーは、nss_sss
モジュールを開きます。 -
nss_sss モジュールは、ユーザー情報のメモリーマップキャッシュを確認します。データがキャッシュに存在する場合は、
nss_sss
モジュールがそれを返します。 -
ユーザー情報が memory-mapped キャッシュにない場合、リクエストは SSSD
sssd_nss
レスポンダープロセスに渡されます。 -
SSSD サービスはキャッシュをチェックします。データがキャッシュに存在し、有効な場合は、
sssd_nss
レスポンダーがキャッシュからデータを読み取って、アプリケーションに返します。 -
データがキャッシュにない場合や期限切れである場合、
sssd_nss
レスポンダーは適切なバックエンドプロセスに対してクエリーを実行し、応答を待機します。SSSD サービスは、sssd.conf
設定ファイルでid_provider=ipa
を設定して有効にした、IdM 環境の IPA バックエンドを使用します。 -
sssd_be
バックエンドプロセスは IdM サーバーに接続して、IdM LDAP Directory Server から情報を要求します。 - IdM サーバーの SSSD バックエンドは、IdM クライアントの SSSD バックエンドプロセスに対応します。
- クライアントの SSSD バックエンドは、生成されるデータを SSSD キャッシュに保存し、キャッシュが更新されたレスポンダープロセスを警告します。
-
sssd_nss
フロントエンドレスプロセスが SSSD キャッシュから情報を取得します。 -
sssd_nss
レスポンダーは、nss_sss
レスポンダーにユーザー情報を送信し、リクエストを完了します。 -
libc
ライブラリーは、要求したアプリケーションにユーザー情報を返します。
12.2. SSSD で AD ユーザー情報を取得する際のデータフロー
IdM 環境と Active Directory( AD) ドメインとの間でフォレスト間の信頼を確立した場合は、IdM クライアントの AD ユーザー情報を取得する際に情報フローが、AD ユーザーデータベースへの追加の手順とともに、IdM クライアントの AD ユーザー情報の取得時に非常に似ています。
以下の図は、getent passwd <ad_user_name@ad.example.com>
コマンドを使用してユーザーが AD ユーザーに関する情報を要求する際に、情報フローを簡素化します。この図には、SSSD で IdM ユーザー情報を取得するデータフロー が含まれません。IdM クライアントの SSSD サービス、IdM サーバーの SSSD サービス、および AD ドメインコントローラー上の LDAP データベースとの間の通信にフォーカスします。
- IdM クライアントは、AD ユーザー情報に関するローカルの SSSD キャッシュを検索します。
-
IdM クライアントにユーザー情報がない場合や、情報が古い場合に、クライアントの SSSD サービスが IdM サーバーの
extdom_extop
プラグインに問い合わせて、LDAP 拡張操作を実行し、情報を要求します。 - IdM サーバーの SSSD サービスは、ローカルキャッシュで AD ユーザー情報を検索します。
- IdM サーバーに SSSD キャッシュにユーザー情報がない場合や、その情報が古い場合は、LDAP 検索を実行して、AD ドメインコントローラーからユーザー情報を要求します。
- IdM サーバーの SSSD サービスは、AD ドメインコントローラーから AD ユーザー情報を受け取り、キャッシュに保存します。
-
extdom_extop
プラグインは、LDAP 拡張操作を完了する IdM サーバーの SSSD サービスから情報を受信します。 - IdM クライアントの SSSD サービスは、LDAP 拡張操作から AD ユーザー情報を受信します。
- IdM クライアントは、AD ユーザー情報を SSSD キャッシュに保存し、要求したアプリケーションに情報を返します。
12.3. IdM で SSSD を使用してユーザーとして認証する場合にデータフロー
IdM サーバーまたはクライアントでユーザーとして認証するには、以下のコンポーネントが必要です。
- sshd サービスなどの認証要求を開始するサービス
- PAM (プラグ可能な認証モジュール) ライブラリーとそのモジュール。
- SSSD サービス、そのレスポンダー、およびバックエンド。
- スマートカード認証が設定されている場合は、スマートカードリーダー。
認証サーバー:
- IdM ユーザーは、IdM Kerberos Key Distribution Center (KDC) に対して認証されます。
- Active Directory (AD) ユーザーは、AD ドメインコントローラー (DC) に対して認証されます。
以下の図は、コマンドラインの SSH サービスを介してホストにローカルでログインしようとすると、情報フローを簡単に認証する必要がある場合を示しています。
-
ssh
コマンドで認証を試みると、libpam
ライブラリーがトリガーされます。 libpam
ライブラリー は、認証の試行を要求するサービスに対応する/etc/pam.d/
ディレクトリーの PAM ファイルを参照します。この例では、ローカルホストの SSH サービス経由で認証されている例では、pam_sss.so
ライブラリーは/etc/pam.d/system-auth
設定ファイルを確認し、SSSD PAM のpam_sss.so
エントリーを検出します。auth sufficient pam_sss.so
-
利用可能な認証方法を判断するため、
libpam
ライブラリーはpam_sss
モジュールを開き、SSSD サービスのsssd _pam
PAM レスポンダーにSSS_PAM_PREAUTH
リクエスト を送信します。 -
スマートカード認証が設定されていると、SSSD サービスは一時的な
p11_child
プロセスを生成し、スマートカードを確認し、そこから証明書を取得します。 -
ユーザーにスマートカード認証が設定されていると、
sssd_pam
レスポンダーは、スマートカードの証明書とユーザーを照合します。sssd_pam
レスポンダーは、グループメンバーシップがアクセス制御に影響する可能性があるため、ユーザーが属するグループの検索も実行します。 -
sssd_pam
レスポンダーは、SSS_PAM_PREAUTH
要求をsssd_be
バックエンドレスに送信し、パスワードや 2 要素認証などのサーバーがサポートする認証方法を表示します。SSSD サービスが IPA レスポンダーを使用する IdM 環境では、デフォルトの認証方法は Kerberos です。この例では、ユーザーは簡単な Kerberos パスワードで認証されます。 -
sssd_be
レスポンダーは一時的なkrb5_child
プロセスを起動します。 -
krb5_child
プロセスは、IdM サーバーの KDC に連絡して、利用可能な認証方法を確認します。 KDC はリクエストに応答します。
-
krb5_child
プロセスは応答を評価し、結果をsssd_be
バックエンドプロセスに送信します。 -
sssd_be
バックエンドプロセスが結果を受け取ります。 -
sssd_pam
レスポンダーは結果を受け取ります。 -
pam_sss
モジュールは結果を受け取ります。
-
-
ユーザーにパスワード認証が設定されていると、
pam_sss
モジュールにより、パスワードの入力が求められます。スマートカード認証が設定されていると、pam_sss
モジュールにより、スマートカードの PIN の入力が求められます。 モジュールは、ユーザー名とパスワードを使用して
SSS_PAM_
AUTHENTICATE 要求を送信します。これは以下が実行されます。-
sssd_pam
レスポンダー。 -
sssd_be
バックエンドプロセス。
-
-
sssd_be
プロセスは、KDC に問い合わせる一時的なkrb5_child
プロセスを起動します。 -
krb5_child
process は、ユーザー名とパスワードを使用して KDC から Kerberos チケット保証チケット (TGT) の取得を試みます。 -
krb5_child
プロセスは、認証の試行の結果を受け取ります。 krb5_child
プロセス:- TGT を認証情報キャッシュに保存します。
-
sssd_be
バックエンドプロセスに認証結果を返します。
認証結果は
sssd_be
プロセスから以下を行います。-
sssd_pam
レスポンダー。 -
pam_sss
モジュール。
-
-
pam_sss
モジュールは、その他のアプリケーションが参照できるように、環境変数をユーザーの TGT の場所で設定します。
12.4. 認証問題の範囲の制限
ユーザーを正常に認証するには、ユーザー情報を保存するデータベースから SSSD サービスでユーザー情報を取得できる必要があります。以下の手順では、認証プロセスの異なるコンポーネントをテストする手順を説明します。これにより、ユーザーがログインできない場合に認証の問題のスコープを制限する方法を説明します。
手順
SSSD サービスおよびそのプロセスが実行していることを確認します。
[root@client ~]# pstree -a | grep sssd |-sssd -i --logger=files | |-sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files | |-sssd_be --domain example.com --uid 0 --gid 0 --logger=files | |-sssd_ifp --uid 0 --gid 0 --logger=files | |-sssd_nss --uid 0 --gid 0 --logger=files | |-sssd_pac --uid 0 --gid 0 --logger=files | |-sssd_pam --uid 0 --gid 0 --logger=files | |-sssd_ssh --uid 0 --gid 0 --logger=files | `-sssd_sudo --uid 0 --gid 0 --logger=files |-sssd_kcm --uid 0 --gid 0 --logger=files
クライアントが IP アドレスを使用してユーザーデータベースサーバーに接続できることを確認します。
[user@client ~]$ ping <IP_address_of_the_database_server>
この手順が失敗した場合は、ネットワークとファイアウォール設定が、IdM クライアントとサーバー間の直接通信が許可されていることを確認してください。firewalld の使用および設定 を参照してください。
クライアントが、完全修飾ホスト名を使用して IdM LDAP サーバー (IdM ユーザー用) または AD ドメインコントローラー (AD ユーザーの場合) を検出して連絡できることを確認します。
[user@client ~]$ dig -t SRV _ldap._tcp.example.com @<name_server> [user@client ~]$ ping <fully_qualified_host_name_of_the_server>
この手順が失敗した場合は、
/etc/resolv.conf
ファイルを含む Dynamic Name Service (DNS) の設定を確認してください。DNS サーバーの順序の設定 を参照してください。注記デフォルトでは、SSSD サービスは DNS サービス (SRV) レコードを介して LDAP サーバーと AD DC を自動的に検出しようとします。
sssd.conf
設定ファイルで以下のオプションを設定すると、SSSD サービスが特定のサーバーを使用するように制限できます。-
ipa_server = <fully_qualified_host_name_of_the_server>
-
ad_server = <fully_qualified_host_name_of_the_server>
-
ldap_uri = <fully_qualified_host_name_of_the_server>
このオプションを使用する場合は、そのオプションに記載されているサーバーと通信できることを確認します。
-
クライアントが LDAP サーバーに対して認証でき、
ldapsearch
コマンドでユーザー情報を取得できることを確認します。LDAP サーバーが
server.example.com
などの IdM サーバーである場合は、ホストの Kerberos チケットを取得し、ホスト Kerberos プリンシパルで認証されるデータベース検索を実行します。[user@client ~]$ kinit -k 'host/client.example.com@EXAMPLE.COM' [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.example.com -b “dc=example,dc=com” uid=<user_name>
LDAP サーバーが
server.example.com
などの Active Directory (AD) Domain Controller (DC) サーバーである場合は、ホストの Kerberos チケットを取得し、ホスト Kerberos プリンシパルで認証されるデータベース検索を実行します。[user@client ~]$ kinit -k 'CLIENT$@AD.EXAMPLE.COM' [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.ad.example.com -b “dc=example,dc=com” sAMAccountname=<user_name>
LDAP サーバーがプレーン LDAP サーバーであり、
sssd.conf
ファイルにldap_default_bind_dn
およびldap_default_authtok
オプションを設定した場合は、同じldap_default_bind_dn
アカウントとして認証されます。[user@client ~]$ ldapsearch -xLLL -D "cn=ldap_default_bind_dn_value" -W -h ldapserver.example.com -b “dc=example,dc=com” uid=<user_name>
この手順が失敗した場合は、データベース設定で、ホストが LDAP サーバーを検索できることを確認します。
SSSD サービスは Kerberos 暗号化を使用するため、ログインできないユーザーとして Kerberos チケットを取得できます。
LDAP サーバーが IdM サーバーの場合:
[user@client ~]$ kinit <user_name>
LDAP サーバーデータベースが AD サーバーの場合:
[user@client ~]$ kinit <user_name@AD.EXAMPLE.COM>
この手順が失敗した場合は、Kerberos サーバーが適切に動作し、すべてのサーバーが同期され、ユーザーアカウントがロックされていないことを確認します。
コマンドラインでユーザー情報を取得できることを確認します。
[user@client ~]$ getent passwd <user_name> [user@client ~]$ id <user_name>
この手順が失敗した場合は、クライアントの SSSD サービスがユーザーデータベースから情報を受信できることを確認します。
-
/var/log/messages
ログファイルのエラーを確認します。 - SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
- (オプション) Red Hat テクニカルサポートケースを作成し、収集したトラブルシューティング情報を提供します。
-
ホストで
sudo
を実行することが許可されている場合は、sssctl
ユーティリティーを使用して、ユーザーがログインを許可されていることを確認します。[user@client ~]$ sudo sssctl user-checks -a auth -s ssh <user_name>
この手順が失敗した場合は、PAM 設定、IdM HBAC ルール、IdM RBAC ルールなどの承認設定を確認します。
-
ユーザーの UID が、
/etc/login.defs
ファイルで定義されているUID_MIN
以上であることを確認してください。 -
/var/log/secure
ログファイルおよび/var/log/messages
ログファイルで認証エラーを確認します。 - SSSD サービスで詳細なロギングを有効にし、デバッグログを収集して、問題のソースに関するログを確認します。
- (オプション) Red Hat テクニカルサポートケースを作成し、収集したトラブルシューティング情報を提供します。
-
ユーザーの UID が、
12.5. SSSD ログファイルおよびログレベル
それぞれの SSSD サービスは、/var/log/sssd/
ディレクトリーに独自のログファイルを記録します。example.com
IdM ドメインの IdM サーバーのログファイルは、以下のようになります。
[root@server ~]# ls -l /var/log/sssd/ total 620 -rw-------. 1 root root 0 Mar 29 09:21 krb5_child.log -rw-------. 1 root root 14324 Mar 29 09:50 ldap_child.log -rw-------. 1 root root 212870 Mar 29 09:50 sssd_example.com.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_ifp.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_implicit_files.log -rw-------. 1 root root 0 Mar 29 09:21 sssd.log -rw-------. 1 root root 219873 Mar 29 10:03 sssd_nss.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_pac.log -rw-------. 1 root root 13105 Mar 29 09:21 sssd_pam.log -rw-------. 1 root root 9390 Mar 29 09:21 sssd_ssh.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_sudo.log
12.5.1. SSSD ログファイルの目的
krb5_child.log
- Kerberos 認証に関連する有効期限の短いヘルパープロセスのログファイル。
ldap_child.log
- LDAP サーバーとの通信用の Kerberos チケットの取得に関連する短期ヘルパープロセスのログファイル。
sssd_<example.com>.log
sssd.conf
ファイルのドメインセクションごとに、SSSD サービスは LDAP サーバーとの通信に関する情報を別のログファイルに記録します。たとえば、example.com
という名前の IdM ドメインがある環境では、SSSD サービスはsssd_example.com.log
という名前のファイルのログにその情報を記録します。ホストがad.example.com
という名前の AD ドメインと直接統合されている場合は、sssd_ad.example.com.log
という名前のファイルのログに情報が記録されます。注記IdM 環境と、AD ドメインを持つフォレスト間の信頼があると、AD ドメインに関する情報は引き続き IdM ドメインのログファイルに記録されます。
同様に、ホストが AD ドメインに直接統合されている場合は、プライマリードメインのログファイルに、子ドメインに関する情報が書き込まれます。
selinux_child.log
- SELinux 情報を取得および設定する短期間ヘルパープロセスのログファイル。
sssd.log
- SSSD を監視して、レスポンダーおよびバックエンドプロセスと通信するためのログファイル。
sssd_ifp.log
- InfoPipe レスポンダーのログファイル。システムバスからアクセス可能なパブリック D-Bus インターフェイスを提供します。
sssd_nss.log
- ユーザーおよびグループ情報を取得する Name Services Switch (NSS) レスポンダーのログファイル。
sssd_pac.log
- AD Kerberos チケットから PAC を収集する Microsoft Privilege Attribute Certificate (PAC) レスポンダー用のログファイルは、PAC から PAC に関する情報を取得します。これにより、AD ユーザーを直接要求しないようにします。
sssd_pam.log
- PAM (Pluggable Authentication Module) レスポンダー用のログファイルです。
sssd_ssh.log
- SSH レスポンダープロセスのログファイル。
12.5.2. SSSD ロギングレベル
デバッグレベルを設定すると、それ下のすべてのデバッグレベルが有効になります。たとえば、debug レベルを 6 に設定すると、デバッグレベル 0 から 5 も有効になります。
表12.1 SSSD ロギングレベル
レベル | 説明 |
---|---|
0 | 致命的な障害が発生しました。SSSD サービスが起動しなかったり、終了しないようにするエラー。これは、RHEL 8.3 以前のデフォルトのデバッグログレベルです。 |
1 | 重大なエラーSSSD サービスを終了しないものの、主要な機能は 1 つ以上正しく機能しません。 |
2 | 深刻なエラー。特定の要求または操作が失敗したことを示すエラー。これは、RHEL 8.4 以降のデフォルトのデバッグログレベルです。 |
3 | マイナーな障害が発生しました。レベル 2 で操作の失敗がキャプチャーされたエラー。 |
4 | 設定。 |
5 | 関数 データ。 |
6 | 操作関数のメッセージを追跡します。 |
7 | 内部制御 関数のメッセージトレース。 |
8 | 関数内部 変数の内容。 |
9 | 非常に 低いレベルのトレース 情報。 |
12.6. sssd.conf ファイルで SSSD の詳細なロギングの有効化
デフォルトでは、RHEL 8.4 以降の SSSD サービスは、重大な失敗 (デバッグレベル 2) のみをログに記録しますが、認証問題のトラブルシューティングに必要な詳細レベルではログに記録されません。
SSSD サービスの再起動時に詳細なロギングを有効にするには、/etc/sssd/sssd.conf
設定ファイルの各セクションに debug_level=<integer>
オプションを追加します。ここで、<integer>
の値は 0 から 9 の数字になります。デバッグレベルは最大 3 つのログで、最大 3 つのログで、レベル 8 以上では、多くの詳細なログメッセージを提供します。レベル 6 は、認証の問題のデバッグに役立ちます。
前提条件
-
sssd.conf
設定ファイルを編集し、SSSD サービスを再起動するには、root パスワードが必要です。
手順
-
テキストエディターで
/etc/sssd/sssd.conf
ファイルを開きます。 debug_level
オプションをファイルのすべてのセクションに追加し、デバッグレベルを、選択した詳細に設定します。[domain/example.com] debug_level = 6 id_provider = ipa ... [sssd] debug_level = 6 services = nss, pam, ifp, ssh, sudo domains = example.com [nss] debug_level = 6 [pam] debug_level = 6 [sudo] debug_level = 6 [ssh] debug_level = 6 [pac] debug_level = 6 [ifp] debug_level = 6
-
sssd.conf
ファイルを保存して閉じます。 SSSD サービスを再起動して、新しい設定を読み込みます。
[root@server ~]# systemctl restart sssd
関連情報
12.7. sssctl コマンドを使用した SSSD の詳細なロギングの有効化
デフォルトでは、RHEL 8.4 以降の SSSD サービスは、重大な失敗 (デバッグレベル 2) のみをログに記録しますが、認証問題のトラブルシューティングに必要な詳細レベルではログに記録されません。
sssctl debug-level <integer>
コマンドを使用して、コマンドラインで SSSD サービスのデバッグレベルを変更できます。ここで、<integer>
の値は 0 から 9 の数字になります。デバッグレベルは最大 3 つのログで、最大 3 つのログで、レベル 8 以上では、多くの詳細なログメッセージを提供します。レベル 6 は、認証の問題のデバッグに役立ちます。
前提条件
-
sssctl
コマンドを実行するには、root パスワードが必要です。
手順
sssctl debug-level コマンドを使用して、希望の詳細度に対して選択したデバッグレベルを設定します。
[root@server ~]# sssctl debug-level 6
関連情報
12.8. SSSD サービスからデバッグログを収集し、IdM サーバーによる認証問題のトラブルシューティング
IdM ユーザーが IdM サーバーへの認証を試行する際に問題が発生した場合は、サーバー上の SSSD サービスで詳細なデバッグロギングを有効にし、ユーザーに関する情報の取得を試行するログを収集します。
前提条件
-
sssctl
コマンドを実行して SSSD サービスを再起動するには、root パスワードが必要です。
手順
IdM サーバーで詳細な SSSD デバッグロギングを有効にします。
[root@server ~]# sssctl debug-level 6
認証問題が発生しているユーザーの SSSD キャッシュでオブジェクトを無効にするため、LDAP サーバーを省略し、SSSD がすでにキャッシュされている情報を取得しません。
[root@server ~]# sssctl cache-expire -u idmuser
古い SSSD ログを削除して、トラブルシューティングのデータセットを最小限に抑える。
[root@server ~]# sssctl logs-remove
認証問題が発生し、試行前後にタイムスタンプを収集する際に、ユーザーが認証問題が発生しようと試みます。これらのタイムスタンプは、データセットのスコープをさらに絞り込むことができます。
[root@server sssd]# date; su idmuser; date Mon Mar 29 15:33:48 EDT 2021 su: user idmuser does not exist Mon Mar 29 15:33:49 EDT 2021
(オプション) 詳細な SSSD ログの収集を続行しない場合は、デバッグレベルを下げます。
[root@server ~]# sssctl debug-level 2
障害のある要求に関する情報を SSSD ログで確認します。たとえば、
/var/log/sssd/sssd_example.com.log
ファイルを確認すると、SSSD サービスがcn=accounts,dc=example,dc=com
LDAP サブツリーでユーザーを見つけられなかったことを示しています。これは、ユーザーが存在しないか、または別の場所に存在することを示しています。(Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [dp_get_account_info_send] (0x0200): Got request for [0x1][BE_REQ_USER][name=idmuser@example.com] ... (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=idmuser)(objectclass=posixAccount)(uid=)(&(uidNumber=)(!(uidNumber=0))))][cn=accounts,dc=example,dc=com]. (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results. (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory) (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Mon Mar 29 15:33:49 2021) [sssd[be[example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request
認証問題の原因を判断できない場合は、以下を行います。
最近生成した SSSD ログを収集します。
[root@server ~]# sssctl logs-fetch sssd-logs-Mar29.tar
Red Hat テクニカルサポートケースを作成し、以下を提供します。
-
SSSD ログ:
sssd-logs-Mar29.tar
ログに対応する要求のタイムスタンプおよびユーザー名を含むコンソールの出力。
[root@server sssd]# date; id idmuser; date Mon Mar 29 15:33:48 EDT 2021 id: ‘idmuser’: no such user Mon Mar 29 15:33:49 EDT 2021
-
SSSD ログ:
12.9. SSSD サービスからデバッグログを収集し、IdM クライアントによる認証問題のトラブルシューティング
IdM クライアントに IdM ユーザーとして認証を試行する際に問題が発生した場合は、IdM サーバーでユーザー情報を取得できることを確認します。IdM サーバーでユーザー情報を取得できない場合は、(IdM サーバーから情報を取得する) IdM クライアントでそれを取得できなくなります。
認証の問題が IdM サーバーから生成されていないことを確認したら、IdM サーバーと IdM クライアントの両方から SSSD デバッグログを収集していました。
前提条件
- IdM サーバーではなく、IdM クライアントで認証の問題のみがあります。
-
sssctl
コマンドを実行して SSSD サービスを再起動するには、root パスワードが必要です。
手順
-
クライアントで、テキストエディターで
/etc/sssd/sssd.conf
ファイルを開きます。 クライアントで、
ipa_server
オプションをファイルの[domain]
セクションに追加し、IdM サーバーに設定します。これにより、IdM クライアントは他の IdM サーバーの自動検出を避け、このテストを 1 つのクライアントおよびサーバー 1 台だけに制限します。[domain/example.com] ipa_server = server.example.com ...
-
クライアントで
sssd.conf
ファイルを保存して閉じます。 クライアントで SSSD サービスを再起動して、設定の変更を読み込みます。
[root@client ~]# systemctl restart sssd
サーバーおよびクライアントで、詳細な SSSD デバッグロギングを有効にします。
[root@server ~]# sssctl debug-level 6
[root@client ~]# sssctl debug-level 6
サーバーおよびクライアントで、認証問題が発生しているユーザーの SSSD キャッシュの検証オブジェクトでは、LDAP データベースを迂回せず、SSSD がすでにキャッシュされています。
[root@server ~]# sssctl cache-expire -u idmuser
[root@client ~]# sssctl cache-expire -u idmuser
サーバーおよびクライアントで、古い SSSD ログを削除して、トラブルシューティングのデータセットを最小限に抑える。
[root@server ~]# sssctl logs-remove
[root@server ~]# sssctl logs-remove
クライアントで、認証問題が発生し、試行前後にタイムスタンプを収集する際に、ユーザーが認証問題が発生しようと試みます。これらのタイムスタンプは、データセットのスコープをさらに絞り込むことができます。
[root@client sssd]# date; su idmuser; date Mon Mar 29 16:20:13 EDT 2021 su: user idmuser does not exist Mon Mar 29 16:20:14 EDT 2021
(オプション) サーバーおよびクライアント 詳細な SSSD ログの収集したくない場合はデバッグレベルを下げます。
[root@server ~]# sssctl debug-level 0
[root@client ~]# sssctl debug-level 0
サーバーおよびクライアントで、失敗した要求に関する情報を SSSD ログを確認します。
- クライアントログのクライアントからの要求を確認します。
- サーバーログのクライアントからの要求を確認します。
- サーバーログでリクエストの結果を確認します。
- サーバーからリクエストの結果を受信するクライアントの結果を確認します。
認証問題の原因を判断できない場合は、以下を行います。
IdM サーバーおよび IdM クライアントで最近生成した SSSD ログを収集します。ホスト名またはロールに応じてラベルを付けます。
[root@server ~]# sssctl logs-fetch sssd-logs-server-Mar29.tar
[root@client ~]# sssctl logs-fetch sssd-logs-client-Mar29.tar
Red Hat テクニカルサポートケースを作成し、以下を提供します。
SSSD デバッグログ:
-
サーバーから
sssd-logs-server-Mar29.tar
-
クライアントからの
sssd-logs-client-Mar29.tar
-
サーバーから
ログに対応する要求のタイムスタンプおよびユーザー名を含むコンソールの出力。
[root@client sssd]# date; su idmuser; date Mon Mar 29 16:20:13 EDT 2021 su: user idmuser does not exist Mon Mar 29 16:20:14 EDT 2021
12.10. SSSD バックエンドでのクライアント要求の追跡
SSSD は要求を非同期に処理します。別の要求のメッセージが同じログファイルに追加されるため、一意の要求識別子とクライアント ID を使用して、バックエンドログ内のクライアント要求を追跡できます。一意のリクエスト識別子は、RID#<integer>
の形式でデバッグログに追加され、クライアント ID はフォーム [CID #<integer]
に追加されます。これにより、個々の要求に関連するログを分離でき、複数の SSSD コンポーネントからのログファイル全体でリクエストを最初から最後まで追跡できます。
前提条件
- デバッグロギングを有効にし、IdM クライアントから要求が送信されている。
- SSSD ログファイルの内容を表示するための root 権限を持っている。
手順
SSSD ログファイルを確認するには、
less
ユーティリティーを使用してログファイルを開きます。たとえば、/var/log/sssd/sssd_example.com.log
を表示するには、次のコマンドを実行します。[root@server ~]# less /var/log/sssd/sssd_example.com.log
クライアント要求に関する情報は、SSSD ログを確認します。
(2021-07-26 18:26:37): [be[testidm.com]] [dp_req_destructor] (0x0400): [RID#3] Number of active DP request: 0 (2021-07-26 18:26:37): [be[testidm.com]] [dp_req_reply_std] (0x1000): [RID#3] DP Request AccountDomain #3: Returning [Internal Error]: 3,1432158301,GetAccountDomain() not supported (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] DP Request Account #4: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] Number of active DP request: 1
SSSD ログファイルからのこの出力例は、2 つの異なる要求について一意の識別子の
RID#3
およびRID#4
を示しています。
ただし、SSSD クライアントインターフェイスへの 1 つのクライアント要求が、バックエンドで複数の要求をトリガーすることが多いため、クライアント要求とバックエンドの要求との間に 1 対 1 の相関関係がなくなります。バックエンド内の複数のリクエストには異なる RID 番号がありますが、最初の各バックエンドリクエストには一意のクライアント ID が含まれているため、管理者は単一のクライアントリクエストに対して複数の RID 番号を追跡できます。
以下の例は、1 つのクライアントリクエスト [sssd.nss CID #1]
と、バックエンドで生成された複数のリクエスト ([RID#5]
から [RID#13]
) を示しています。
(2021-10-29 13:24:16): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#5] DP Request [Account #5]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:16): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#6] DP Request [AccountDomain #6]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:16): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#7] DP Request [Account #7]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#8] DP Request [Initgroups #8]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#9] DP Request [Account #9]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#10] DP Request [Account #10]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#11] DP Request [Account #11]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#12] DP Request [Account #12]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001]. (2021-10-29 13:24:17): [be[ad.vm]] [dp_attach_req] (0x0400): [RID#13] DP Request [Account #13]: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
12.11. ログアナライザーツールを使用したクライアント要求の追跡
System Security Services Daemon (SSSD) には、複数の SSSD コンポーネントからのログファイル全体でリクエストを最初から最後まで追跡するために使用できるログ解析ツールが含まれています。
12.11.1. ログアナライザツールのしくみ
ログ解析ツールを使用すると、複数の SSSD コンポーネントからのログファイル全体で SSSD リクエストを最初から最後まで追跡できます。sssctl analyze
コマンドを使用してアナライザーツールを実行します。
ログアナライザツールは、SSSD の NSS および PAM の問題をトラブルシューティングし、SSSD デバッグログをより簡単に確認するのに役立ちます。SSSD プロセス全体の特定のクライアントリクエストにのみ関連する SSSD ログを抽出して出力できます。
SSSD は、ユーザー認証 (su
、ssh
) 情報とは別に、ユーザーおよびグループの ID 情報 (id
、getent
) を追跡します。NSS レスポンダのクライアント ID(CID) は PAM レスポンダーの CID とは独立しており、NSS と PAM のリクエストを解析すると重複した数値が表示されます。--pam
オプションを sssctl analyze
コマンドとともに使用して、PAM リクエストを確認します。
SSSD メモリーキャッシュから返されたリクエストはログに記録されず、ログアナライザツールで追跡できません。
関連情報
-
sudo sssctl analyze request --help
-
sudo sssctl analyze --help
-
sssd.conf
man ページ -
sssctl
の man ページ
12.11.2. ログアナライザツールの実行
この手順では、ログアナライザツールを使用して SSSD でクライアントリクエストを追跡する方法について説明します。
前提条件
-
ログ解析機能を有効にするには、
/etc/sssd/sssd.conf
ファイルの [$responder] セクション、および [domain/$domain] セクションでdebug_level
を 7 以上に設定する必要がある。 -
分析するログは、
libtevent
チェーン ID をサポートする互換性のあるバージョンの SSSD、つまり RHEL 8.5 以降の SSSD からのものである必要がある。
手順
ログアナライザツールを list モードで実行して、追跡しているリクエストのクライアント ID を特定し、
-v
オプションを追加して詳細な出力を表示します。# sssctl analyze request list -v
SSSD に対して行われた最近のクライアントリクエストの詳細なリストが表示されます。
注記PAM リクエストを分析する場合は、
sssctl analyze request list
コマンドを-pam
オプション付きで実行します。show [unique client ID]
オプションを指定してログアナライザツールを実行し、指定したクライアント ID 番号に関連するログを表示します。# sssctl analyze request show 20
必要に応じて、ログファイルに対してログアナライザツールを実行できます。次に例を示します。
# sssctl analyze request --logdir=/tmp/var/log/sssd
関連情報
-
sssctl analyze request list --help
-
sssctl analyze request show --help
-
sssctl
の man ページ。
12.12. 関連情報
第13章 シングルサインオン用のアプリケーションの設定
シングルサインオン (SSO) は、1 回のログイン手順で複数のシステムにログインできる認証スキームです。ユーザーの認証手段として、Kerberos チケット、SSL 認定、またはトークンを使用するように、ブラウザーとメールクライアントを設定できます。
アプリケーションによって設定が異なる場合があります。本章では、Mozilla Thunderbird メールクライアントおよび Mozilla Firefox Web ブラウザーに SSO 認証スキーマを設定する方法を例として説明します。
13.1. 前提条件
以下のアプリケーションをインストールしている。
- Mozilla Firefox バージョン 88
- Mozilla Thunderbird バージョン 78
13.2. シングルサインオンに Kerberos を使用するように Firefox を設定する
Firefox は、イントラネットサイトやその他の保護された Web サイトへのシングルサインオン (SSO) に Kerberos を使用するように設定できます。これを行うには、最初に、Kerberos 認証情報を適切な鍵配布センター (KDC) に送信するように Firefox を設定する必要があります。
Firefox が Kerberos 認証情報を渡すように設定した後でも、有効な Kerberos チケットが必要になります。Kerberos チケットを生成するには、kinit
コマンドを使用して、KDC 上のユーザーのユーザーパスワードを指定します。
[jsmith@host ~] $ kinit Password for jsmith@EXAMPLE.COM:
手順
-
Firefox のアドレスバーに
about:config
と入力し、現在の設定オプションの一覧を表示します。 -
Filter
フィールドにnegotiate
と入力して、オプションの一覧を制限します。 -
network.negotiate-auth.trusted-uris
のエントリーをダブルクリックします。 先行ピリオド (.) を含む、認証に使用するドメイン名を入力します。複数のドメインを追加する場合は、ドメインをコンマ区切りで入力します。
図13.1 Firefox の手動設定
関連情報
- Identity Management で Kerberos を使用するように Firefox を設定する方法は、Linux ドメイン Identity、Authentication、およびポリシーガイドの対応するセクション を参照してください。
13.3. Firefox で証明書の表示
以下の例は、Mozilla Firefox で証明書を表示する方法を示しています。
Firefox で証明書を表示するには、Certificate Manager
を開く必要があります。
手順
Mozilla Firefox で Firefox メニューを開き、Preferences を選択します。
左側のウィンドウで、
Privacy & Security
セクションを選択します。-
Certifications
までスクロールします。 View Certificates を選択して、
Certificate Manager
を開きます。
13.4. Firefox で CA 証明書のインポート
以下の例は、Mozilla Firefox で証明書をインポートする方法を示しています。
前提条件
- デバイスに CA 証明書がある。
CA 証明書をインポートするには、以下を実行します。
手順
-
Certificate Manager
を開きます。 Authorities
を選択し、Import をクリックします。図13.2 Firefox での CA 証明書のインポート
- デバイスからダウンロードした CA 証明書を選択します。
13.5. Firefox で証明書の信頼設定の編集
以下の例は、Mozilla Firefox で証明書設定を編集する方法を示しています。
前提条件
- 証明書が正常にインポートされました。
証明書のトラスト設定を設定するには、以下を行います。
手順
-
Certificate Manager
を開きます。 -
Authe
タブで、適切な証明書を選択し、Edit Trust をクリックします。 証明書トラスト設定を編集します。
図13.3 Firefox での証明書トラスト設定の編集
13.6. Firefox で認証用の個人証明書のインポート
以下の例は、Mozilla Firefox で認証用に個人証明書をインポートする方法を示しています。
前提条件
- デバイスに個人証明書が保存されている。
認証に個人証明書を使用するには、以下を実行します。
手順
-
Certificate Manager
を開きます。 Your Certificates
を選択し、Import をクリックします。図13.4 Firefox での認証用の個人証明書のインポート
- コンピューターから適切な証明書を選択します。
13.7. Thunderbird で証明書の表示
以下の例は、Mozilla Thunderbird メールクライアントで証明書を表示する方法を示しています。
手順
Mozilla Thunderbird で、メインメニューを開き、
Preference
を選択します。図13.5 メニューから環境設定を選ぶ
左側のウィンドウで、
Privacy & Security
セクションを選択します。図13.6 セキュリティーセクションの選択
-
Certifications
までスクロールします。 Manage Certificatesを選択して、
Certificate Manager
を開きます。図13.7 証明書マネージャーの起動
13.8. Thunderbird で証明書のインポート
以下の例は、Mozilla Thunderbird メールクライアントで証明書をインポートする方法を示しています。
前提条件
- デバイスに CA 証明書が保存されている。
CA 証明書をインポートするには、以下を実行します。
手順
-
Certificate Manager
を開きます。 Authorities
を選択し、Import をクリックします。図13.8 Thunderbird で CA 証明書のインポート
- ダウンロードした CA 証明書を選択します。
13.9. Thunderbird で証明書の信頼設定の編集
以下の例は、Mozilla Thunderbird メールクライアントで証明書設定を編集する方法を示しています。
前提条件
- 証明書が正常にインポートされました。
証明書信頼関係を設定するには、以下を行います。
手順
-
Certificate Manager
を開きます。 -
Authe
タブで、適切な証明書を選択し、Edit Trust をクリックします。 証明書トラスト設定を編集します。
図13.9 Thunderbird で証明書の信頼設定の編集
13.10. Thunderbird で個人証明書のインポート
以下の例は、Mozilla Thunderbird メールクライアントで個人認証用の証明書をインポートする方法を示しています。
前提条件
- デバイスに個人証明書が保存されている。
認証に個人証明書を使用するには、以下を実行します。
手順
-
Certificate Manager
を開きます。 Your Certificates
タブで、Import をクリックします。図13.10 Thunderbird で認証用の個人証明書のインポート
- お使いのコンピューターから必要な証明書を選択します。
-
Certificate Manager
を閉じます。 メインメニューを開き、
Account Settings
を選択します。図13.11 メニューからアカウント設定の選択
アカウントのメールアドレスの下にある左側のパネルで
End-To-End Encryption
を選択します。エンドツーエンドの暗号化セクションの選択
-
S/MIME
で、最初の Select を選択して、メッセージの署名に使用する個人証明書を選択します。 S/MIME
で、2 番目の Select を選択して、メッセージの暗号化と復号を行う個人証明書を選択します。署名および暗号化/復号に使用する証明書の選択
有効な証明書を読み込むことを忘れた場合は、Manage S/MIME certificates
を使用して Certificate Manager
を直接開くことができます。