システムレベルの認証ガイド
アプリケーションおよびサービスを使用したローカルシステムでの認証の設定
概要
『Linux ドメイン ID、認証、およびポリシーガイド』 では、Linux ベースのドメインで ID ストアと認証および承認ポリシーを一元管理して管理するソリューションである Red Hat Identity Management について説明しています。
『Windows 統合ガイド』 では、Identity Management を使用して Linux ドメインを Microsoft Windows Active Directory (AD)と統合する方法を説明します。本ガイドでは、SSSD を使用した Common Internet File System (CIFS)および realmd
システムへのアクセスに SSSD を使用した直接的および間接 AD 統合のさまざまな側面を説明します。
第1章 システム認証の概要
1.1. ユーザーアイデンティティーの確認
- パスワードベースの認証。ほとんどのすべてのソフトウェアは、認識されたユーザー名とパスワードを提供することでユーザーが認証できるようにします。これは 簡易認証 とも呼ばれます。
- 証明書ベースの認証の使用。証明書に基づくクライアント認証は、SSL プロトコルの一部です。クライアントは無作為に生成されたデータの一部に署名し、ネットワーク全体で証明書および署名されたデータの両方を送信します。サーバーは署名を検証し、証明書の有効性を確認します。
- Kerberos 認証。Kerberos は、TGT (ticket-granting tickets) と呼ばれる有効期限の短い認証情報のシステムを確立します。ユーザーは、ユーザーを特定し、ユーザーにチケットを発行できることをシステムに示す認証情報、つまりユーザー名およびパスワードを提示します。TGT は、Web サイトや電子メールなどの他のサービスへのアクセスチケットを要求するために繰り返し使用できます。TGT を使用した認証では、ユーザーはこの方法で単一の認証プロセスのみを実現できます。
- スマートカードベースの認証。これは、証明書ベースの認証のバリアントです。スマートカード (または トークン) は、ユーザー証明書を格納します。ユーザーがトークンをシステムに挿入すると、システムは証明書を読み取り、アクセスを付与できます。スマートカードを使用したシングルサインオンには、以下の 3 つの手順があります。
- ユーザーがスマートカードをカードリーダーに挿入します。Red Hat Enterprise Linux のプラグ可能な認証モジュール (PAM) は、挿入されたスマートカードを検出します。
- システムは、証明書をユーザーエントリーにマップし、スマートカードに表示された証明書を、証明書ベースの認証で説明されているように秘密鍵で暗号化して、ユーザーエントリーに保存されている証明書と比較します。
- 証明書がキー配布センター (KDC) に対して正常に確認されると、ユーザーはログインを許可されます。
スマートカードベースの認証は、追加の識別メカニズムとして証明書を追加し、物理的なアクセス要件を追加することにより、Kerberos によって確立された単純な認証層に基づいています。
1.2. シングルサインオンの計画の追加
- Kerberos レルムと Active Directory ドメインを使用した Kerberos ベースの認証
- スマートカードベースの認証
1.3. 利用可能なサービス
- 認証設定
- 認証設定ツール(authconfig)は、システムにさまざまなアイデンティティーバックエンドと、そのシステムへの認証手段(パスワード、フィンガープリント、スマートカードなど)を設定します。
- Identity バックエンドの設定
- SSSD (Security System Services Daemon) は、Microsoft Active Directory や Red Hat Enterprise Linux IdM などの複数のアイデンティティープロバイダー ) 主に LDAP ベースのディレクトリー) を設定します。これは、ローカルシステムとアプリケーションの両方で使用できます。パスワードとチケットがキャッシュされ、認証情報を再利用することでオフライン認証とシングルサインオンが可能になります。
- realmd サービスは、認証バックエンド(IdM の SSSD)の設定を可能にするコマンドラインユーティリティーです。realmd サービスは、DNS レコードに基づいて利用可能な IdM ドメインを検出し、SSSD を設定してから、システムをアカウントとしてドメインに参加させます。
- NSS (Name Service Switch) は、ユーザー、グループ、またはホストの情報を返す低レベルのシステムコールのメカニズムです。NSS は、必要な情報を取得するのに使用するモジュールであるソースを決定します。たとえば、ユーザー情報は
/etc/passwd
ファイルや LDAP ベースのディレクトリーなどの従来の UNIX ファイルに配置できますが、ホストアドレスは/etc/hosts
ファイルや DNS レコードなどのファイルから読み取ることができます。NSS は情報が保存される場所を特定します。
- 認証メカニズム
- プラグ可能な認証モジュール (PAM) は、認証ポリシーを設定するシステムを提供します。認証に PAM を使用するアプリケーションは、認証のさまざまな側面を制御する異なるモジュールを読み込みます。アプリケーションが使用する PAM モジュールは、アプリケーションの設定方法に基づいています。利用可能な PAM モジュールには、Kerberos、Winbind、またはローカルの UNIX ファイルベースの認証が含まれます。
パート I. システムログイン
authconfig
ツール、ipa-client-install
ツール、および realmd
ツールを使用してシステム認証を設定する方法を説明します。
第2章 システム認証の設定
- Identity Management システム用の
ipa-client-install
ユーティリティーおよびrealmd
システム。詳細は、「システム認証用の Identity Management ツール」 を参照してください。 authconfig
ユーティリティーと、他のシステムの authconfig UI。詳細は、「authconfig
の使用」 を参照してください。
2.1. システム認証用の Identity Management ツール
ipa-client-install
ユーティリティーおよび realmd
システムを使用して、Identity Management マシンでシステム認証を自動的に設定できます。
ipa-client-install
ipa-client-install
ユーティリティーは、Identity Management ドメインに参加するようにシステムを設定します。ipa-client-install
の詳細は、『Linux ドメイン ID、認証、およびポリシーガイドの クライアントの』 インストール を参照してください。Identity Management システムの場合、ipa-client-install
はrealmd
よりも優先されることに注意してください。realmd
realmd
システムは、マシンを Identity Management や Active Directory ドメインなどの ID ドメインに参加させます。realmd
の詳細は、『Windows Integration Guide』 の Using realmd to Connect to an Active Directory Domain を参照してください。
2.2. authconfig
の使用
authconfig
には GUI とコマンドラインオプションの両方があり、ユーザーデータストアを設定できます。authconfig ツールは、異なる形式の認証メカニズムを使用するとともに、ユーザーデータベースに特定のサービス(SSSD、LDAP、NIS、または Winbind)を使用するようにシステムを設定できます。
authconfig
の代わりに ipa-client-install
ユーティリティーまたは realmd
システムを使用することを推奨します。authconfig
ユーティリティーは制限されており、柔軟性は低くなります。詳細は、「システム認証用の Identity Management ツール」 を参照してください。
authconfig
ユーティリティーを使用できます。
authconfig-gtk
は完全なグラフィカルインターフェイスを提供します。authconfig
は、手動設定用のコマンドラインインターフェイスを提供します。authconfig-tui
は、テキストベースの UI を提供します。このユーティリティーは非推奨となっています。
root
として実行する必要があります。
2.2.1. authconfig CLI の使用に関するヒント
- すべてのコマンドで、
--update
オプションまたは--test
オプションのいずれかを使用します。コマンドを正常に実行するには、以下のオプションのいずれかが必要です。--update
を使用すると、設定の変更が書き込まれます。--test
オプションは変更を表示しますが、設定に変更を適用しません。--update
オプションを使用しない場合、変更はシステム設定ファイルには書き込まれません。 - コマンドラインを使用して、既存の設定を更新したり、新しい設定を設定するのに使用することもできます。このため、コマンドラインは、必要な属性が特定の呼び出しで使用されることを強制しません (コマンドが更新されている可能性があるためで、そうでなければ設定を完了します)。認証設定の編集時に、設定が完了して正確である点に留意してください。認証設定を不完全または間違った値に変更すると、ユーザーがシステムからロックされる可能性があります。--test オプションを使用して、--update オプションを使用して書き込む前に設定が適切であることを確認します。
- 有効化オプションには、それぞれ対応する無効化オプションがあります。
2.2.2. authconfig UI のインストール
authconfig-gtk
パッケージをインストールします。これには、authconfig コマンドラインツール、Bash、Python などの一般的なシステムパッケージの依存関係があります。これらのほとんどは、デフォルトでインストールされています。
[root@server ~]# yum install authconfig-gtk Loaded plugins: langpacks, product-id, subscription-manager Resolving Dependencies --> Running transaction check ---> Package authconfig-gtk.x86_64 0:6.2.8-8.el7 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: authconfig-gtk x86_64 6.2.8-8.el7 RHEL-Server 105 k Transaction Summary ================================================================================ Install 1 Package ... 8< ...
2.2.3. authconfig UI の起動
- 端末を開き、root でログインします。
- system-config-authentication コマンドを実行します。
- ID と認証。アイデンティティーストアとして使用するリソースを設定します(ユーザー ID と対応する認証情報が保存されるデータリポジトリー)。
- 高度なオプション。スマートカードやフィンガープリントなどのパスワードや証明書以外の認証方法を設定します。
- パスワードオプション。パスワード認証方法を設定します。
図2.1 認証設定ウィンドウ
2.2.4. 認証設定のテスト
--test
オプションは、考えられるすべての ID および認証メカニズムに対して、システムのすべての認証設定を出力します。これにより、有効になっている領域と無効になっている領域の両方の設定が表示されます。
test
オプションを単独で実行して現在の設定をすべて表示することもできます。または、authconfig コマンドで使用して、(実際に設定を変更せずに) 設定を変更する方法を表示することもでき ます。これは、提案された認証設定が完了し、正確であることの確認に非常に便利です。
[root@server ~]# authconfig --test caching is disabled nss_files is always enabled nss_compat is disabled nss_db is disabled nss_hesiod is disabled hesiod LHS = "" hesiod RHS = "" nss_ldap is disabled LDAP+TLS is disabled LDAP server = "" LDAP base DN = "" nss_nis is disabled NIS server = "" NIS domain = "" nss_nisplus is disabled nss_winbind is disabled SMB workgroup = "MYGROUP" SMB servers = "" SMB security = "user" SMB realm = "" Winbind template shell = "/bin/false" SMB idmap range = "16777216-33554431" nss_sss is enabled by default nss_wins is disabled nss_mdns4_minimal is disabled DNS preference over NSS or WINS is disabled pam_unix is always enabled shadow passwords are enabled password hashing algorithm is sha512 pam_krb5 is disabled krb5 realm = "#" krb5 realm via dns is disabled krb5 kdc = "" krb5 kdc via dns is disabled krb5 admin server = "" pam_ldap is disabled LDAP+TLS is disabled LDAP server = "" LDAP base DN = "" LDAP schema = "rfc2307" pam_pkcs11 is disabled use only smartcard for login is disabled smartcard module = "" smartcard removal action = "" pam_fprintd is disabled pam_ecryptfs is disabled pam_winbind is disabled SMB workgroup = "MYGROUP" SMB servers = "" SMB security = "user" SMB realm = "" pam_sss is disabled by default credential caching in SSSD is enabled SSSD use instead of legacy services if possible is enabled IPAv2 is disabled IPAv2 domain was not joined IPAv2 server = "" IPAv2 realm = "" IPAv2 domain = "" pam_pwquality is enabled (try_first_pass local_users_only retry=3 authtok_type=) pam_passwdqc is disabled () pam_access is disabled () pam_mkhomedir or pam_oddjob_mkhomedir is disabled (umask=0077) Always authorize local users is enabled () Authenticate system accounts against network services is disabled
2.2.5. authconfig
を使用した設定の保存および復元
--savebackup
オプションを使用して行います。
[root@server ~]# authconfig --savebackup=/backups/authconfigbackup20200701
--restorebackup
オプションを使用して使用するバックアップ名を指定し、以前に保存したすべてのバージョンに復元できます。
[root@server ~]# authconfig --restorebackup=/backups/authconfigbackup20200701
--restorelastbackup
オプションを使用して、最後のバックアップを復元できます。
[root@server ~]# authconfig --restorelastbackup
第3章 authconfig
で認証用のアイデンティティーストアの選択
authconfig
UI の Identity & Authentication タブは、ユーザーを認証する方法を設定します。デフォルトでは、ローカルシステム認証を使用します。つまり、ユーザーとパスワードは、ローカルシステムのアカウントに対して確認されます。Red Hat Enterprise Linux マシンは、LDAP、NIS、Winbind などのユーザーおよび認証情報を含む外部リソースを使用することもできます。
3.1. IPAv2
authconfig
で IPAv2 プロバイダーとして設定されます。以前の IdM バージョンおよびコミュニティー FreeIPA サーバーでは、LDAP プロバイダーとして設定されます。
3.1.1. UI での IdM の設定
- authconfig UI を開きます。
- User Account Database ドロップダウンメニューで を選択します。
図3.1 authentication-configuration
- IdM サーバーへの接続に必要な情報を設定します。
- IPA ドメイン は、IdM ドメインの DNS ドメインを提供します。
- IPA レルム は、IdM ドメインの Kerberos ドメインを提供します。
- IPA Server は、IdM ドメイントポロジー内の IdM サーバーのホスト名を指定します。
- NTP を設定しないでください。必要に応じて、クライアントの設定時に NTP サービスを無効にします。IdM サーバーおよびすべてのクライアントが Kerberos 認証および証明書を正しく機能させるには、すべてのクライアントがクロックを同期している必要があるため、通常は推奨されません。これは、IdM サーバーがドメイン内でホストするのではなく、別の NTP サーバーを使用している場合に無効にできます。
- これにより ipa-client-install コマンドが実行され、必要に応じて
ipa-client
パッケージがインストールされます。インストールスクリプトは、ローカルシステムに必要な全システムファイルを自動的に設定し、ドメイン情報を更新するためにドメインサーバーに問い合わせます。
3.1.2. コマンドラインでの IdM の設定
realmd
を使用した Identity ドメインへの接続の realmd など)を使用して、IdM ドメインにシステムを登録することができます。これにより ipa-client-install コマンドを実行すると、必要に応じて ipa-client
パッケージをインストールします。インストールスクリプトは、ローカルシステムに必要な全システムファイルを自動的に設定し、ドメイン情報を更新するためにドメインサーバーに問い合わせます。
--ipav2domain
)、Kerberos レルム名 (--ipav2realm
)、および接続する IdM サーバー (--ipav2server
) の 3 つの情報が必要です。--ipav2join
オプションは、IdM サーバーへの接続に使用する管理者ユーザー名を指定します。通常、これは admin です。
[root@server ~]# authconfig --enableipav2 --ipav2domain=IPAEXAMPLE --ipav2realm=IPAEXAMPLE --ipav2server=ipaexample.com --ipav2join=admin
--disableipav2nontp
オプションを使用して、設定スクリプトが NTP サーバーとして IdM サーバーを使用しないようにすることができます。IdM サーバーおよびすべてのクライアントが Kerberos 認証および証明書を正しく機能させるには、すべてのクライアントがクロックを同期している必要があるため、通常は推奨されません。
3.2. LDAP および IdM
3.2.1. UI での LDAP 認証の設定
- 「authconfig UI の起動」 のように、
authconfig
UI を開きます。 - User Account Database ドロップダウンメニューで を選択します。
- LDAP サーバーへの接続に必要な情報を設定します。
- LDAP 検索ベース DN は、ユーザーディレクトリーのルート接尾辞または 識別名 (DN)を提供します。アイデンティティーまたは認証に使用されるユーザーエントリーはすべて、この親エントリーの下に存在します。たとえば、
ou=people,dc=example,dc=com
です。このフィールドは任意です。これが指定されていない場合、System Security Services Daemon (SSSD)は LDAP サーバーの設定エントリーのnamingContexts
およびdefaultNamingContext
属性を使用して検索ベースを検出しようとします。 - LDAP サーバー は LDAP サーバーの URL を提供します。これには通常、
ldap://ldap.example.com:389
など、LDAP サーバーのホスト名とポート番号の両方が必要です。ldaps://
で始まる URL を使用してセキュアなプロトコルを入力すると、 ボタンが有効になります。これにより、発行した認証局から LDAP サーバーの発行元 CA 証明書を取得します。CA 証明書は、プライバシーにより強化されたメール (PEM) 形式である必要があります。 - 非セキュアな標準ポート接続(
ldap://
で始まる URL)を使用する場合は、Use TLS to encrypt connections チェックボックスを使用し、STARTTLS
を使用して LDAP サーバーとの通信を暗号化できます。このチェックボックスを選択すると、 ボタンも有効になります。注記通信がすでに 暗号化されているため、サーバー URL が LDAPS (LDAP over SSL)セキュアプロトコルを使用している場合は、TLS を使用して接続 を暗号化する チェックボックスを選択する必要はありません。
- 認証方法を選択します。LDAP は、簡単なパスワード認証または Kerberos 認証を許可します。Kerberos の使用については、「UI での Kerberos 認証の設定」 を参照してください。LDAP パスワード オプションは、PAM アプリケーションを使用して LDAP 認証を使用します。このオプションでは、LDAPS または TLS を使用して LDAP サーバーへ接続し、セキュアな接続を設定する必要があります。
3.2.2. コマンドラインでの LDAP ユーザーストアの設定
--enableldap
を使用します。LDAP を認証ソースとして使用する場合は、--enableldapauth
を使用して、LDAP サーバー名、ユーザー接尾辞のベース DN、TLS を使用するかどうか (オプション) など、必要な接続情報を使用します。authconfig コマンドには、ユーザーエントリーの RFC 2307bis スキーマを有効または無効にするオプションもありますが、authconfig UI ではできません。
--enableldaptls
オプションでセキュアな LDAP URL (ldaps)を使用し ない でください。
authconfig --enableldap --enableldapauth --ldapserver=ldap://ldap.example.com:389,ldap://ldap2.example.com:389 --ldapbasedn="ou=people,dc=example,dc=com" --enableldaptls --ldaploadcacert=https://ca.server.example.com/caCert.crt --update
--ldapauth
を使用する代わりに、LDAP ユーザーストアで Kerberos を使用できます。これらのオプションは、「コマンドラインでの Kerberos 認証の設定」 で説明されています。
3.3. NIS
- NIS サーバーは、ユーザーアカウントが設定されている状態で完全に設定する必要があります。
- ypbind パッケージがローカルシステムにインストールされている。これは NIS サービスに必要ですが、デフォルトではインストールされません。
portmap
サービスおよびypbind
サービスは起動時に開始され、起動できるようになります。これは、ypbind パッケージのインストールの一部として設定する必要があります。
3.3.1. UI での NIS 認証の設定
- 「authconfig UI の起動」 のように、authconfig UI を開きます。
- User Account Database ドロップダウンメニューで を選択します。
- NIS サーバーに接続する情報を設定します。つまり、NIS ドメイン名およびサーバーホスト名になります。NIS サーバーが指定されていない場合、authconfig デーモンは NIS サーバーをスキャンします。
- 認証方法を選択します。NIS は、簡単なパスワード認証または Kerberos 認証を許可します。Kerberos の使用については、「UI での Kerberos 認証の設定」 を参照してください。
3.3.2. コマンドラインでの NIS の設定
--enablenis
を使用します。Kerberos パラメーターが明示的に設定されていない場合 (「コマンドラインでの Kerberos 認証の設定」) を除き、これは NIS 認証を自動的に使用します。NIS サーバーと NIS ドメインを識別するための唯一のパラメーターは です。これを使用しないと、authconfig
サービスは NIS サーバーのネットワークをスキャンします。
[root@server ~]# authconfig --enablenis --nisdomain=EXAMPLE --nisserver=nis.example.com --update
3.4. Winbind
3.4.1. authconfig GUI での Winbind の有効化
samba-winbind
パッケージをインストールします。これは、Samba サービスの Windows 統合機能に必要ですが、デフォルトではインストールされません。[root@server ~]# yum install samba-winbind
- authconfig UI を開きます。
[root2server ~]# authconfig-gtk
- アイデンティティーおよび 認証 タブで、ユーザーアカウントデータベース ドロップダウンメニューで を選択します。
- Microsoft Active Directory ドメインコントローラーへの接続に必要な情報を設定します。
- Winbind ドメイン は、接続する Windows ドメインを提供します。これは、DOMAIN などの Windows 2000 形式である必要があります。
- セキュリティーモデル は、Samba クライアントに使用するセキュリティーモデルを設定します。authconfig は、以下の 4 種類のセキュリティーモデルをサポートします。
- ADS は、 Samba が Active Directory Server レルムのドメインメンバーとして機能するように設定します。このモードで操作するには、
krb5-server
パッケージをインストールし、Kerberos を適切に設定する必要があります。 - ドメイン には、Windows サーバーと同様に、Windows のプライマリーまたはバックアップドメインコントローラーを使用して認証することで、Samba がユーザー名とパスワードを検証します。
- サーバー には、Windows サーバーなどの別のサーバーで認証することで、ローカルの Samba サーバーがユーザー名とパスワードを検証します。サーバーの認証を試みると、システムは ユーザー モードを使用した認証を試行します。
- ユーザー は、有効なユーザー名とパスワードでクライアントにログインする必要があります。このモードは、暗号化されたパスワードに対応します。ユーザー名の形式は domain\user である必要があります(例: EXAMPLE\jsmith )。注記特定のユーザーが Windows ドメインに存在することを確認する場合は、
domain\user_name
形式を使用してバックスラッシュ(\)文字をエスケープしてください。以下に例を示します。[root@server ~]# getent passwd domain\\user DOMAIN\user:*:16777216:16777216:Name Surname:/home/DOMAIN/user:/bin/bash
以下はデフォルトのオプションになります。
- Winbind ADS レルム は、Samba サーバーが参加する Active Directory レルムを提供します。これは、ads セキュリティーモデルでのみ使用されます。
- Winbind ドメインコントローラー は、システムの登録に使用するドメインコントローラーのホスト名または IP アドレスを提供します。
- Template Shell は、Windows ユーザーアカウント設定に使用するログインシェルを設定します。
- オフラインログインを許可 すると、認証情報をローカルキャッシュに保存できます。システムがオフライン時に、ユーザーがシステムリソースに認証を試みるとキャッシュが参照されます。
3.4.2. コマンドラインでの Winbind の有効化
--winbindjoin
パラメーターは、Active Directory ドメインへの接続に使用するユーザーを設定し、--enablelocalauthorize
はローカルの承認操作を設定して /etc/passwd
ファイルを確認します。
[root@server ~]# authconfig --enablewinbind --enablewinbindauth --smbsecurity=user|server --enablewinbindoffline --smbservers=ad.example.com --smbworkgroup=EXAMPLE --update --enablelocauthorize --winbindjoin=admin [root@server ~]# net join ads
[root@server ~]# getent passwd domain\\user DOMAIN\user:*:16777216:16777216:Name Surname:/home/DOMAIN/user:/bin/bash
[root@server ~]# authconfig --enablewinbind --enablewinbindauth --smbsecurity ads --enablewinbindoffline --smbservers=ad.example.com --smbworkgroup=EXAMPLE --smbrealm EXAMPLE.COM --winbindtemplateshell=/bin/sh --update
第4章 認証メカニズムの設定
authconfig
ツールを使用して設定することも、場合によっては Identity Management ツールを使用して設定することもできます。
4.1. authconfig
を使用したローカル認証の設定
/etc/security/access.conf
で定義されているように)システムサービスへのユーザーベースの承認を定義します。それ以外の場合は、認証ポリシーはアイデンティティープロバイダーまたはサービス自体内で定義できます。
4.1.1. UI でのローカルアクセス制御の有効化
/etc/security/access.conf
ファイルを確認するようにシステムが設定されます。これは PAM 認証です。
図4.1 ローカルアカウントフィールド
4.1.2. コマンドラインでのローカルアクセス制御の設定
--enablelocauthorize
はネットワーク認証を省略し、システムユーザーのローカルファイルのみを確認します。--enablepamaccess
は、システムが /etc/security/access.conf
でシステム認可ポリシーを検索するように設定します。
[root@server ~]# authconfig --enablelocauthorize --enablepamaccess --update
4.2. authconfig
を使用したシステムパスワードの設定
4.2.1. パスワードセキュリティー
4.2.1.1. UI でのパスワードハッシュの設定
- 「authconfig UI の起動」 のように、authconfig UI を開きます。
- 高度なオプション タブを開きます。
- パスワードハッシュ アルゴリズム ドロップダウンメニューで、使用するアルゴリズムを選択します。
4.2.1.2. コマンドラインでのパスワードハッシュの設定
--passalgo
オプションとアルゴリズムの短縮名を使用します。以下の例では、SHA-512 アルゴリズムを使用しています。
[root@server ~]# authconfig --passalgo=sha512 --update
4.2.2. パスワードの複雑性
4.2.2.1. UI でのパスワードの複雑性の設定
- 「authconfig UI の起動」 のように、authconfig UI を開きます。
- パスワードオプション タブを 開きます。
- パスワードの 最小長 を設定します。
- パスワードの最小長
- パスワードで使用する必要のある文字クラスの最小数。
- パスワードに使用する 必要のある 文字クラスを有効にします。たとえば、任意のパスワードで大文字を使用できますが、Uppercase チェックボックスを選択した場合は、すべてのパスワードで大文字を使用する必要があります。
- 文字または文字クラスが連続して繰り返すことができる回数を設定します。(ゼロに設定すると、制限が繰り返されません。)同じ文字 フィールドの場合、1 文字または文字を繰り返す頻度を設定します。たとえば、これを 2 に設定すると、ssecret は使用できますが、sssecret は使用できません。同様に、同じクラス は、文字クラス(大文字、番号、特殊文字)から文字を繰り返すことができる回数に制限を設定します。これを 3 に設定すると、たとえば secret!! は使用できますが、secret!!@ または secret1234 は使用できません。
4.2.2.2. コマンドラインでのパスワードの複雑性の設定
- 最小長 (
--passminlen
)。 - 使用する必要のあるさまざまなタイプの文字の最小数 (
--passminclass
)。 - 文字が連続して繰り返すことができる回数 (
--passmaxrepeat
)。このパラメーターをゼロに設定すると、繰り返し制限がなくなります。 - (数字など) 同じタイプの文字が 1 行で使用できる回数 (
--passmaxclassrepeat
)。このパラメーターをゼロに設定すると、繰り返し制限がなくなります。
--enablereq
Type オプションを使用すると、指定したクラスが絶対に必要であるか、パスワードが拒否されます。(逆に、型を明示的に拒否することもできます))
- 大文字 (
--enablerequpper
) - 小文字 (
--enablereqlower
) - 番号 (
--enablereqdigit
) - 特殊文字 (
--enablereqother
)
[root@server ~]# authconfig --passminlen=9 --passminclass=3 --passmaxrepeat=2 -passmaxclassrepeat=2 --enablerequpper --enablereqother --update
4.3. authconfig
を使用した Kerberos (LDAP または NIS を使用)の設定
- これは、標準ポートを介した接続を許可する一方で、通信にセキュリティーレイヤーを使用します。
- SSSD で認証情報キャッシュを自動的に使用します。これにより、オフラインログインが可能になります。
krb5-libs
パッケージおよび krb5-workstation
パッケージが必要です。
4.3.1. UI での Kerberos 認証の設定
図4.2 Kerberos フィールド
- realm は、Kerberos サーバーのレルムの名前を指定します。レルムは、Kerberos を使用するネットワークで、1 つ以上の キー配布センター (KDC) と、潜在的に多数のクライアントで設定されます。
- KDC は、Kerberos チケットを発行するサーバーのコンマ区切りリストを提供します。
- 管理サーバー に は、レルムで kadmind プロセスを実行している管理サーバーのリストが表示されます。
- 必要に応じて、DNS を使用してサーバーのホスト名を解決し、レルム内で追加の KDC を見つけます。
4.3.2. コマンドラインでの Kerberos 認証の設定
[root@server ~]# authconfig NIS or LDAP options --enablekrb5 --krb5realm EXAMPLE --krb5kdc kdc.example.com:88,server.example.com:88 --krb5adminserver server.example.com:749 --enablekrb5kdcdns --enablekrb5realmdns --update
4.4. スマートカード
4.4.1. authconfig
を使用したスマートカードの設定
図4.3 スマートカードオプション
- nss-tools
- nss-pam-ldapd
- esc
- pam_pkcs11
- pam_krb5
- opensc
- pcsc-lite-ccid
- gdm
- authconfig
- authconfig-gtk
- krb5-libs
- krb5-workstation
- krb5-pkinit
- pcsc-lite
- pcsc-lite-libs
4.4.1.1. UI でのスマートカード認証の有効化
- root でシステムにログインします。
- ネットワーク用のルート CA 証明書をベース 64 形式でダウンロードし、サーバーにインストールします。証明書は、certutil コマンドを使用して適切なシステムデータベースにインストールされます。以下に例を示します。
[root@server ~]# certutil -A -d /etc/pki/nssdb -n "root CA cert" -t "CT,C,C" -i /tmp/ca_cert.crt
注記インポートされた証明書は、プロセスの後でauthconfig
UI に表示されないことに注意してください。UI に証明書は表示されません。認証中に/etc/pki/nssdb/
ディレクトリーから証明書を取得します。 - トップメニューでメニューを選択し、 を選択してから をクリックします。
- 高度なオプション タブを開きます。
- Enable Smart Card Support チェックボックスをクリックします。
- スマートカードでは 2 つの動作が設定可能です。
- カード 削除アクション メニューは、アクティブなセッション中にスマートカードが削除された場合にシステムが取得する応答を設定します。
無視
オプションは、スマートカードが削除され、Lock
が画面を直ちにロックしている間に、システムが通常通りに機能し続けることを意味します。 - Require smart card for login チェックボックスは、ログインにスマートカードが必要であるかどうかを設定します。このオプションを選択すると、認証の他の方法はすべてブロックされます。警告スマートカードを使用して正常にログイン するまで は、これを選択しないでください。
- デフォルトでは、証明書が失効したかどうかを確認するメカニズム (オンライン証明書ステータスプロトコル、OCSP、応答) は無効です。有効期限が切れる前に証明書を失効したかどうかを検証するには、
cert_policy
ディレクティブにocsp_on
オプションを追加して OCSP チェックを有効にします。pam_pkcs11.conf
ファイルを開きます。vim /etc/pam_pkcs11/pam_pkcs11.conf
ocsp_on
オプションが含まれるように、すべてのcert_policy
行を変更します。cert_policy = ca,
ocsp_on,
signature;注記ファイルの解析方法により、cert_policy と等号記号の間にスペースが 必要 です。そうでない場合は、パラメーターの解析に失敗します。
- (個人証明書とキーによる設定で) スマートカードが登録されていない場合、スマートカードを登録します。
- スマートカードが CAC カードの場合は、CAC ユーザーのホームディレクトリーに
.k5login
ファイルを作成します。CAC カードに Microsoft プリンシパル名を使用するには、.k5login
ファイルが必要です。 - 以下の行を
/etc/pam.d/smartcard-auth
ファイルおよび/etc/pam.d/system-auth
ファイルに追加します。auth optional pam_krb5.so use_first_pass no_subsequent_prompt preauth_options=X509_user_identity=PKCS11:/usr/lib64/pkcs11/opensc-pkcs11.so
OpenSC モジュールが想定どおりに機能しない場合は、coolkey パッケージの モジュール(/usr/lib64/pkcs11/libcoolkeypk11.so
)を使用します。この場合は、Red Hat テクニカルサポートへの問い合わせ、または問題に関する Bugzilla レポートの作成を検討してください。 /etc/krb5.conf
ファイルを設定します。この設定は、CAC カードか Gemalto 64K カードを使用しているかによって異なります。- CAC カードでは、CAC カードの使用に関連するすべてのルート証明書を
pkinit_anchors
で指定します。CAC カードを設定するための/etc/krb5.conf
ファイルの例では、EXAMPLE.COM は CAC カードのレルム名で、kdc.server.hostname.com は KDC サーバーのホスト名です。[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 dns_lookup_kdc = false ticket_lifetime = 1h renew_lifetime = 6h forwardable = true default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc.server.hostname.com admin_server = kdc.server.hostname.com pkinit_anchors = FILE:/etc/pki/nssdb/ca_cert.pem pkinit_anchors = FILE:/etc/pki/nssdb/CAC_CA_cert.pem pkinit_anchors = FILE:/etc/pki/nssdb/CAC_CA_email_cert.pem pkinit_anchors = FILE:/etc/pki/nssdb/CAC_root_ca_cert.pem pkinit_cert_match = CAC card specific information } [domain_realm] EXAMPLE.COM = EXAMPLE.COM .EXAMPLE.COM = EXAMPLE.COM .kdc.server.hostname.com = EXAMPLE.COM kdc.server.hostname.com = EXAMPLE.COM [appdefaults] pam = { debug = true ticket_lifetime = 1h renew_lifetime = 3h forwardable = true krb4_convert = false mappings = username on the CAC card Principal name on the card }
- 以下の Gemalto 64K カードを設定するための
/etc/krb5.conf
ファイルの例では、EXAMPLE.COM は KDC サーバー上に作成されたレルム、kdc-ca.pem は CA 証明書、kdc.server.hostname.com は KDC サーバーのホスト名です。[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 dns_lookup_kdc = false ticket_lifetime = 15m renew_lifetime = 6h forwardable = true default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc.server.hostname.com admin_server = kdc.server.hostname.com pkinit_anchors = FILE:/etc/pki/nssdb/kdc-ca.pem pkinit_cert_match = <KU>digitalSignature pkinit_kdc_hostname = kdc.server.hostname.com } [domain_realm] EXAMPLE.COM = EXAMPLE.COM .EXAMPLE.COM = EXAMPLE.COM .kdc.server.hostname.com = EXAMPLE.COM kdc.server.hostname.com = EXAMPLE.COM [appdefaults] pam = { debug = true ticket_lifetime = 1h renew_lifetime = 3h forwardable = true krb4_convert = false }
pklogin_finder debug
4.4.1.2. コマンドラインでのスマートカード認証の設定
、--enablesmartcard
オプションを設定することだけです。
[root@server ~]# authconfig --enablesmartcard --update
[root@server ~]# authconfig --enablesmartcard --smartcardaction=0 --update
[root@server ~]# authconfig --enablerequiresmartcard --update
--enablerequiresmartcard
オプションを使用しないでください。それ以外の場合は、ユーザーがシステムにログインできなくなる可能性があります。
4.4.2. Identity Management でのスマートカード認証
4.4.3. 対応するスマートカード
スマートカード
- Athena ASECard Crypto スマート、pkcs15-unit
- ATOS (Siemens) CardOS 5.0
- Gemalto ID Classic 230 / TOP IM CY2 64kv2
- Gemalto Cyberflex Access 64k V2c
- Gemalto GemPCKey USB フォームファクターキー
- Giesecke & Devrient (G&D) SmartCafe Expert 6.0 (SCP03)
- Giesecke & Devrient (G&D) SmartCafe Expert 7.0 (SCP03)
- Safenet 330J
- Safenet SC650 (SCP01)
- Siemens Card CardOS M4.4
- Yubikey 4
リーダー
- スマートカードリーダーを内臓した HP キーボード KUS1206
- Omnikey 3121 リーダー
- PID 0x3022 リーダーを備えた Omnikey 3121
- Reiner SCT cyberJack RFID komfort リーダー
- SCR331 CCID リーダー
4.5. ワンタイムパスワード
Red Hat Enterprise Linux のワンタイムパスワード
4.6. authconfig
を使用したフィンガープリントの設定
4.6.1. UI でのフィンガープリント認証の使用
図4.4 フィンガープリントのオプション
4.6.2. コマンドラインでのフィンガープリント認証の設定
authconfig
設定と併用できます。
[root@server ~]# authconfig --enablefingerprint --update
第5章 authconfig
を使用したキックスタートファイルと設定ファイルの管理
--update
オプションは、設定の変更ですべての設定ファイルを更新します。いくつかの代替オプションがあり、動作が若干異なります。
--kickstart
は、更新された設定をキックスタートファイルに書き込みます。--test
は変更と共に完全な設定を表示しますが、設定ファイルは編集しません。
authconfig
を使用して以前の設定をバックアップおよび復元することもできます。すべてのアーカイブは、/var/lib/authconfig/
ディレクトリーの一意のサブディレクトリーに保存されます。たとえば、--savebackup
オプションは、バックアップディレクトリーを 2011-07-01 として指定します。
[root@server ~]# authconfig --savebackup=2011-07-01
/var/lib/authconfig/backup-2011-07-01 ディレクトリーの下にあるすべての認証設定ファイルがバックアップ
されます。
--restorebackup
オプションを使用して設定を復元し、手動で保存した設定の名前を指定します。
[root@server ~]# authconfig --restorebackup=2011-07-01
--update
オプションを使用)。設定は、--restorelastbackup
オプションを使用して完全バックアップを指定することなく、最新の自動バックアップから復元できます。
第6章 authconfig
を使用したカスタムホームディレクトリーの有効化
/home
にないホームディレクトリーがあり、ユーザーが初めてログインしたときにホームディレクトリーを作成するようにシステムが設定されている場合、これらのディレクトリーは間違ったパーミッションで作成されます。
/home
ディレクトリーから、ローカルシステムで作成されたホームディレクトリーに、正しい SELinux コンテキストとパーミッションを適用します。以下に例を示します。[root@server ~]# semanage fcontext -a -e /home /home/locale
oddjob-mkhomedir
パッケージをシステムにインストールします。このパッケージは、authconfig コマンドがホームディレクトリーの作成に使用するpam_oddjob_mkhomedir.so
ライブラリーを提供します。デフォルトのpam_mkhomedir.so
ライブラリーとは異なり、pam_oddjob_mkhomedir.so
ライブラリーは SELinux ラベルを作成できます。authconfig コマンドは、pam_oddjob_mkhomedir.so
ライブラリーが利用可能な場合は自動的に使用します。それ以外の場合は、デフォルトでpam_mkhomedir.so
が使用されます。oddjobd
サービスが実行中であることを確認します。- authconfig コマンドを実行して、ホームディレクトリーを有効にします。コマンドラインでは、
--enablemkhomedir
オプションを指定して実行します。[root@server ~]# authconfig --enablemkhomedir --update
UI には、Advanced Options タブ(最初のログインでホームディレクトリーの作成)に、ユーザーが初めてログインしたときにホームディレクトリーを自動的に作成するオプションがあります。図6.1 ホームディレクトリーオプション
このオプションは、LDAP など、集中管理されているアカウントでは利点があります。ただし、自動マウントなどのシステムがユーザーのホームディレクトリーの管理に使用される場合、このオプションは選択しないでください。
[root@server ~]# semanage fcontext -a -e /home /home/locale # restorecon -R -v /home/locale
パート II. ID ストアと認証ストア
System Security Services Daemon
(SSSD
)を設定する方法、realmd
ツールを使用して ID ドメインに接続する方法、および OpenLDAP
サーバーをインストール、設定、および実行する方法を説明します。
第7章 SSSD の設定
7.1. SSSD の概要
7.1.1. SSSD の仕組み
- クライアントをアイデンティティーストアに接続して認証情報を取得します。
- 取得した認証情報を使用して、クライアントにユーザーと認証情報のローカルキャッシュを作成します。
図7.1 SSSD の仕組み
7.1.2. SSSD を使用する利点
- ID および認証サーバーへの負荷の削減
- 情報を要求すると、SSSD クライアントは SSSD に接続し、SSSD はキャッシュをチェックします。SSSD は、キャッシュで情報が利用できない場合に限り、サーバーに問い合わせます。
- オフライン認証
- SSSD は、必要に応じて、リモートサービスから取得したユーザー ID および認証情報のキャッシュを保持します。この設定では、リモートサーバーまたは SSSD クライアントがオフラインであっても、ユーザーがリソースに対して正常に認証できるようになります。
- 単一のユーザーアカウント: 認証プロセスの一貫性の向上
- SSSD では、オフライン認証用に中央アカウントとローカルユーザーアカウントの両方を維持する必要はありません。リモートユーザーには多くの場合、複数のユーザーアカウントがあります。たとえば、仮想プライベートネットワーク (VPN) に接続するには、リモートユーザーが、ローカルシステム用のアカウントのほかに、VPN システム用の別のアカウントが必要になります。キャッシュおよびオフライン認証により、リモートユーザーはローカルマシンに認証することで、ネットワークリソースに接続できます。SSSD は次にネットワークの認証情報を維持します。
7.2. クライアントごとに複数の SSSD 設定ファイルの使用
/etc/sssd/sssd.conf
です。このファイルとは別に、SSSD は /etc/sssd/conf.d/
ディレクトリー内のすべての *.conf
ファイルから設定を読み取ることができます。
/etc/sssd/sssd.conf
ファイルを使用し、追加の設定ファイルに設定を追加して、クライアントごとに機能を個別に拡張できます。
SSSD が設定ファイルを処理する方法
- プライマリー
/etc/sssd/sssd.conf
ファイル /etc/sssd/conf.d/
の他の*.conf
ファイル(アルファベット順)
conf.d
ディレクトリーの隠しファイル( .
で始まるファイル)を読み取りません。
7.3. SSSD の ID および認証プロバイダーの設定
7.3.1. SSSD の ID プロバイダーおよび認証プロバイダーの概要
SSSD ドメイン。ID プロバイダーおよび認証プロバイダー
- アイデンティティープロバイダー (ユーザー情報用)
- 認証プロバイダー (認証要求用)
- アクセス制御プロバイダー (承認要求用)
- (対応するすべての操作が単一のサーバー内で実行する場合の) これらのプロバイダーの組み合わせ
/etc/sssd/sssd.conf
ファイルの access_provider
オプションは、ドメインに使用されるアクセス制御プロバイダーを設定します。デフォルトでは、オプションは を 許可
し、常にすべてのアクセスを許可します。詳細は sssd.conf(5) の man ページを参照してください。
プロキシープロバイダー
- 指紋スキャナーなどの別の認証方法
- NIS などのレガシーシステム
/etc/passwd
およびリモート認証で定義されたローカルシステムアカウント
ID プロバイダーおよび認証プロバイダーの利用可能な組み合わせ
ID プロバイダー | 認証プロバイダー |
---|---|
Identity Management [a] | Identity Management [a] |
Active Directory [a] | Active Directory [a] |
LDAP | LDAP |
LDAP | Kerberos |
proxy | proxy |
proxy | LDAP |
proxy | Kerberos |
[a]
LDAP プロバイダータイプの拡張
|
- Identity Management に SSSD クライアントを設定するには、Red Hat は
ipa-client-install
ユーティリティーを使用することを推奨します。『Linux Domain Identity, Authentication, and Policy Guide』のInstalling and Uninstalling Identity Management Clients ipa-client-install
を使用せずに Identity Management の SSSD クライアントを手動で設定するには、Red Hat ナレッジベースの Installing and Uninstalling an Identity Management Client Manually を参照してください。- SSSD で使用する Active Directory を設定するには、『Windows 統合ガイド』のActive Directory を SSSD の アイデンティティープロバイダーとして使用を参照してください。
7.3.2. SSSD の LDAP ドメインの設定
前提条件
- SSSD をインストールします。
# yum install sssd
LDAP ドメインを検出するように SSSD を設定
/etc/sssd/sssd.conf
ファイルを開きます。- LDAP ドメインの
[domain]
セクションを作成します。[domain/LDAP_domain_name]
- LDAP サーバーをアイデンティティープロバイダー、認証プロバイダー、またはその両方として使用するかどうかを指定します。
- LDAP サーバーをアイデンティティープロバイダーとして使用するには、
id_provider
オプションをldap
に設定します。 - LDAP サーバーを認証プロバイダーとして使用するには、
auth_provider
オプションをldap
に設定します。
たとえば、両方に LDAP サーバーを使用するには、以下を実行します。[domain/LDAP_domain_name]
id_provider = ldap
auth_provider = ldap
- LDAP サーバーを指定します。以下のいずれかを選択します。
- サーバーを明示的に定義するには、
ldap_uri
オプションでサーバーの URI を指定します。[domain/LDAP_domain_name] id_provider = ldap auth_provider = ldap
ldap_uri = ldap://ldap.example.com
ldap_uri
オプションは、サーバーの IP アドレスも受け入れます。ただし、サーバー名の代わりに IP アドレスを使用すると、TLS/SSL 接続が失敗する場合があります。Red Hat ナレッジベースのConfiguring an SSSD Provider to Use an IP Address in the Certificate Subject Nameを参照してください。 - DNS サービス検出を使用してサーバーを動的に検出するように SSSD を設定するには、「DNS サービスディスカバリーの設定」 を参照してください。
必要に応じて、ldap_backup_uri
オプションでバックアップサーバーを指定します。 ldap_search_base
オプションで LDAP サーバーの検索ベースを指定します。[domain/LDAP_domain_name] id_provider = ldap auth_provider = ldap ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com
- LDAP サーバーへのセキュアな接続を確立する方法を指定します。TLS 接続を使用することが推奨されます。これを行うには、
ldap_id_use_start_tls
オプションを有効にし、以下の CA 証明書関連のオプションを使用します。ldap_tls_reqcert
は、クライアントがサーバー証明書を要求するかどうか、および証明書で実行されるチェックを行うかどうかを指定しますldap_tls_cacert
証明書を含むファイルを指定します。
[domain/LDAP_domain_name] id_provider = ldap auth_provider = ldap ldap_uri = ldap://ldap.example.com ldap_search_base = dc=example,dc=com
ldap_id_use_start_tls = true
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
注記SSSD は、認証に暗号化されたチャンネルを常に使用します。これにより、暗号化されていないネットワーク上でパスワードが送信されなくなります。ldap_id_use_start_tls = true
を使用すると、ID ルックアップ(id
ユーティリティーまたはgetent
ユーティリティーに基づくコマンドなど)も暗号化されます。 [sssd]
セクションのdomains
オプションに新しいドメインを追加します。このオプションは、SSSD がクエリーするドメインを一覧表示します。以下に例を示します。domains =
LDAP_domain_name
, domain2
関連情報
- sssd.conf(5) の man ページ。ここでは、すべてのタイプのドメインで利用可能なグローバルオプションを説明します。
- sssd-ldap(5) の man ページ。ここでは、LDAP に固有のオプションを説明します。
7.3.3. SSSD のファイルプロバイダーの設定
files
プロバイダーは、/etc/passwd
および /etc/groups
ファイルの内容をミラーリングし、SSSD でこれらのファイルからのユーザーおよびグループを利用できるようにします。これにより、sss データベースを、/etc/nsswitch.conf
ファイルのユーザーおよびグループの最初のソースとして設定できます。
passwd: sss files group: sss files
files
プロバイダーが /etc/sssd/sssd.conf
に設定されている場合、Red Hat Enterprise Linux は最初にユーザーおよびグループのすべてのクエリーを SSSD に送信します。SSSD が実行していない場合、または SSSD が要求されたエントリーが見つからない場合、システムはフォールバックしてローカルファイルでユーザーおよびグループを検索します。ほとんどのユーザーとグループを LDAP ディレクトリーなどの中央データベースに保存する場合、この設定により、ユーザーとグループの検索速度が向上します。
前提条件
- SSSD をインストールします。
# yum install sssd
ファイルドメインを検出するように SSSD を設定
/etc/sssd/sssd.conf
ファイルに以下のセクションを追加します。[domain/files] id_provider = files
- 必要に応じて、sss データベースを、
/etc/sssd/sssd.conf
ファイルでユーザーおよびグループの検索の最初のソースとして設定します。passwd: sss files group: sss files
- システムの起動時に
sssd
サービスが起動する方法でシステムを設定します。# systemctl enable sssd
sssd
サービスを再起動します。# systemctl restart sssd
関連情報
files
プロバイダーの基本オプションを示しています。詳細は、以下を参照してください。
- sssd.conf(5) の man ページ。ここでは、すべてのタイプのドメインで利用可能なグローバルオプションを説明します。
- sssd-files(5) の man ページ。これは、
files
プロバイダーに固有のオプションを説明します。
7.3.4. SSSD のプロキシープロバイダーの設定
前提条件
- SSSD をインストールします。
# yum install sssd
プロキシードメインを検出するように SSSD を設定
/etc/sssd/sssd.conf
ファイルを開きます。- プロキシープロバイダーの
[domain]
セクションを作成します。[domain/proxy_name]
- 認証プロバイダーを指定するには、以下を実行します。
auth_provider
オプションをプロキシー
に設定します。proxy_pam_target
オプションを使用して、認証プロキシーとして PAM サービスを指定します。
以下に例を示します。[domain/proxy_name]
auth_provider = proxy
proxy_pam_target = sssdpamproxy
重要プロキシー PAM スタックにpam_sss.so
が再帰的に含まれて いない ことを確認します。 - アイデンティティープロバイダーを指定するには、以下を実行します。
id_provider
オプションをプロキシー
に設定します。- NSS ライブラリーを ID プロキシーとして指定するには、
proxy_lib_name
オプションを使用します。
以下に例を示します。[domain/proxy_name]
id_provider = proxy
proxy_lib_name = nis
[sssd]
セクションのdomains
オプションに新しいドメインを追加します。このオプションは、SSSD がクエリーするドメインを一覧表示します。以下に例を示します。domains =
proxy_name
, domain2
関連情報
7.3.5. Kerberos 認証プロバイダーの設定
前提条件
- SSSD をインストールします。
# yum install sssd
Kerberos ドメインを検出するように SSSD を設定
/etc/sssd/sssd.conf
ファイルを開きます。- SSSD ドメインの
[domain]
セクションを作成します。[domain/Kerberos_domain_name]
- アイデンティティープロバイダーを指定します。たとえば、LDAP アイデンティティープロバイダーの設定に関する詳細は、「SSSD の LDAP ドメインの設定」 を参照してください。Kerberos プリンシパル名が指定のアイデンティティープロバイダーで利用できない場合、SSSD は username@REALM 形式を使用してプリンシパルを構築します。
- Kerberos 認証プロバイダーの詳細を指定します。
auth_provider
オプションをkrb5
に設定します。[domain/Kerberos_domain_name] id_provider = ldap
auth_provider = krb5
- Kerberos サーバーを指定します。
- サーバーを明示的に定義するには、
krb5_server
オプションを使用します。このオプションは、サーバーのホスト名または IP アドレスを受け入れます。[domain/Kerberos_domain_name] id_provider = ldap auth_provider = krb5
krb5_server = kdc.example.com
- DNS サービス検出を使用してサーバーを動的に検出するように SSSD を設定するには、「DNS サービスディスカバリーの設定」 を参照してください。
必要に応じて、krb5_backup_
server オプションでバックアップサーバーを指定します。 - krb5_server または
krb5_
オプションを使用して、サービスが実行しているサーバーを指定します。backup_server
で指定された KDC で Change Password サービスが実行されていない場合は、krb5_
passwd[domain/Kerberos_domain_name] id_provider = ldap auth_provider = krb5 krb5_server = kdc.example.com krb5_backup_server = kerberos.example.com
krb5_passwd = kerberos.admin.example.com
krb5_passwd
を使用しないと、SSSD は krb5_server またはkrb5
_backup_server
で指定された KDC を使用します。 krb5_realm
オプションを使用して、Kerberos レルムの名前を指定します。[domain/Kerberos_domain_name] id_provider = ldap auth_provider = krb5 krb5_server = kerberos.example.com krb5_backup_server = kerberos2.example.com krb5_passwd = kerberos.admin.example.com
krb5_realm = EXAMPLE.COM
[sssd]
セクションのdomains
オプションに新しいドメインを追加します。このオプションは、SSSD がクエリーするドメインを一覧表示します。以下に例を示します。domains =
Kerberos_domain_name
, domain2
関連情報
- sssd.conf(5) の man ページ。ここでは、すべてのタイプのドメインで利用可能なグローバルオプションを説明します。
- sssd-krb5(5) の man ページ。ここでは、Kerberos 固有のオプションを説明します。
7.4. ID プロバイダーおよび認証プロバイダーの追加設定
7.4.1. ユーザー名の形式の調整
7.4.1.1. 完全なユーザー名を解析するための正規表現の定義
user_name@domain_name
形式の完全なユーザー名を解釈します。
(?P<name>[^@]+)@?(?P<domain>[^@]*$)
user_name@domain_name
または NetBIOS_name\user_name
です。
/etc/sssd/sssd.conf
ファイルを開きます。re_expression
オプションを使用して、カスタムの正規表現を定義します。- すべてのドメインに対してグローバルに正規表現を定義するには、
sssd.conf
の[sssd]
セクションにre_expression
を追加します。 - 特定のドメインに対して個別に正規表現を定義するには、
sssd.conf
の対応するドメインセクションにre_expression
を追加します。
[domain/LDAP]
[... file truncated ...]
re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)
SPECIAL SECTIONS
および DOMAIN SECTIONS
部分の re_expression
の説明を参照してください。
7.4.1.2. SSSD 出力の完全ユーザー名の定義
/etc/sssd/sssd.conf
ファイルで use_fully_qualified_names
オプションが有効になっている場合、SSSD は、デフォルトで以下の拡張に基づいて @domain
形式で完全なユーザー名を出力します。
%1$s@%2$s
use_fully_qualified_names
が設定されていない場合や、信頼されるドメインに対して明示的に false
に設定されている場合には、ドメインコンポーネントなしでユーザー名のみが出力されます。
/etc/sssd/sssd.conf
ファイルを開きます。full_name_format
オプションを使用して、完全なユーザー名形式の拡張を定義します。- すべてのドメインに対してグローバルに拡張を定義するには、
sssd.conf
の[sssd]
セクションにfull_name_format
を追加します。 - 特定のドメインに拡張を個別に定義するには、
sssd.conf
の対応するドメインセクションにfull_name_format
を追加します。
SPECIAL SECTIONS
および DOMAIN SECTIONS
部分の full_name_format
の説明を参照してください。
full_name_format
を標準以外の値に設定すると、警告により、これをより標準形式に変更するように求められます。
7.4.2. オフライン認証の有効化
/etc/sssd/sssd.conf
ファイルを開きます。- ドメインセクションで、
cache_credentials = true
設定を追加します。[domain/domain_name]
cache_credentials = true
- 任意ですが、推奨されます。アイデンティティープロバイダーが利用できない場合に SSSD がオフライン認証の許可期間に制限を設定します。
- SSSD と連携するように PAM サービスを設定します。「サービスの設定: PAM」を参照してください。
offline_credentials_expiration
オプションを使用して時間制限を指定します。たとえば、最終ログインに成功してから 3 日間、オフライン認証を可能にするには、次のようにします。[pam]
offline_credentials_expiration = 3
offline_credentials_expiration
の詳細は、sssd.conf(5) の man ページを参照してください。
7.4.3. DNS サービスディスカバリーの設定
/etc/sssd/sssd.conf
ファイルで明示的に定義されていない場合、SSSD は DNS サービス検出を使用してサーバーを動的に検出できます。 [1]をクリックします。
sssd.conf
に id_provider = ldap
設定が含まれているものの、ldap_uri
オプションでホスト名または IP アドレスが指定されていない場合、SSSD は DNS サービス検出を使用してサーバーを動的に検出します。
DNS サービス検出のための SSSD の設定
/etc/sssd/sssd.conf
ファイルを開きます。- プライマリーサーバーの値を
_srv_
に設定します。LDAP プロバイダーの場合、プライマリーサーバーはldap_uri
オプションを使用して設定されます。[domain/domain_name] id_provider = ldap
ldap_uri = _srv_
- パスワード変更プロバイダーでサービス検出を有効にするには、サービスタイプを設定します。
[domain/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
オプションを使用します。詳細は sssd.conf(5) の man ページを参照してください。 - サービス検出を使用するすべてのサービスについて、DNS レコードを DNS サーバーに追加します。
_service._protocol._domain TTL priority weight port host_name
7.4.4. simple
アクセスプロバイダーを使用したアクセス制御の定義
simple
アクセスプロバイダーは、ユーザー名またはグループの一覧に基づいてアクセスを許可または拒否します。これにより、特定のマシンへのアクセスを制限できます。
Simple アクセスプロバイダーを使用して
、特定のユーザーまたは特定のグループのみへのアクセスを制限できます。他のユーザーまたはグループは、設定済みの認証プロバイダーに対して正常に認証されている場合でもログインできません。
Simple
Access Provider ルールの設定
/etc/sssd/sssd.conf
ファイルを開きます。access_provider
オプションをsimple
に設定します。[domain/domain_name]
access_provider = simple
- ユーザーのアクセス制御ルールを定義します。以下のいずれかを選択します。
- ユーザーへのアクセスを許可するには、
simple_allow_users
オプションを使用します。 - ユーザーへのアクセスを拒否するには、
simple_deny_users
オプションを使用します。重要特定ユーザーにアクセスを許可する方が拒否するよりも安全であると考えられます。特定のユーザーへのアクセスを拒否する場合には、他のユーザーすべてにアクセスを自動的に許可します。
- グループのアクセス制御ルールを定義します。以下のいずれかを選択します。
- グループへのアクセスを許可するには、
simple_allow_groups
オプションを使用します。 - グループへのアクセスを拒否するには、
simple_deny_groups
オプションを使用します。重要特定グループにアクセスを許可する方が拒否するよりも安全であると考えられます。特定のグループへのアクセスを拒否する場合には、他のグループすべてに、アクセスを自動的に許可します。
group1
の user1
、user2
、および メンバーへのアクセスを許可し、他のすべてのユーザーへのアクセスを拒否します。
[domain/domain_name] access_provider = simplesimple_allow_users = user1, user2
simple_allow_groups = group1
7.4.5. LDAP アクセスフィルターを使用したアクセス制御の定義
/etc/sssd/sssd.conf
で access_provider
オプションが設定されている場合、SSSD は指定されたアクセスプロバイダーを使用して、システムにアクセスできるユーザーを評価します。使用しているアクセスプロバイダーが LDAP プロバイダータイプの拡張の場合には、システムへのアクセス許可に必要な LDAP アクセス制御フィルターを指定することもできます。
simple
アクセスプロバイダーを使用したアクセス制御の定義」 を参照してください。
LDAP アクセスフィルターを適用するための SSSD 設定
/etc/sssd/sssd.conf
ファイルを開きます。[domain]
セクションで、LDAP アクセス制御フィルターを指定します。- LDAP アクセスプロバイダーの場合は、
ldap_access_filter
オプションを使用します。詳細は sssd-ldap(5) の man ページを参照してください。 - AD アクセスプロバイダーの場合は、
ad_access_filter
オプションを使用します。詳細は sssd-ad(5) の man ページを参照してください。
たとえば、admins
ユーザーグループに属し、unixHomeDirectory
属性が設定されている AD ユーザーにのみアクセスを許可するには、次のコマンドを実行します。[domain/AD_domain_name] access provider = ad [... file truncated ...]
ad_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*))
authorizedService
または host
属性で結果を確認することもできます。実際、ユーザーエントリーおよび設定に応じて、すべてのオプション(LDAP フィルター、authorizedService
、および host
)を評価できます。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 ページに一覧表示されます。
7.5. SSSD のシステムサービスの設定
- Name Service Switch (NSS)
- 「サービスの設定: NSS」 を参照してください。
- PAM (プラグ可能な認証モジュール)
- 「サービスの設定: PAM」 を参照してください。
- OpenSSH
- 『Linux ドメイン ID、認証、およびポリシーガイド』のOpenSSH サービスのキャッシュを提供するように SSSD の設定を参照してください。
autofs
- 「サービスの設定:
autofs
」 を参照してください。 sudo
- 「サービスの設定:
sudo
」 を参照してください。
7.5.1. サービスの設定: NSS
NSS での SSSD の仕組み
- ユーザー情報(
passwd
マップ) - グループ(
groups
マップ) - netgroups (
netgroups
マップ) - サービス(
services
マップ)
前提条件
- SSSD をインストールします。
# yum install sssd
SSSD を使用するように NSS サービスを設定する
authconfig
ユーティリティーを使用して SSSD を有効にします。[root@server ~]# authconfig --enablesssd --update
これにより、/etc/nsswitch.conf
ファイルが更新され、以下の NSS マップが SSSD を使用できるようになります。passwd: files sss shadow: files sss group: files sss netgroup: files sss
/etc/nsswitch.conf
を開き、services
マップ行にsss
を追加します。services: files
sss
NSS で動作するように SSSD を設定する
/etc/sssd/sssd.conf
ファイルを開きます。[sssd]
セクションで、NSS が SSSD と連携するサービスの 1 つとしてリストされていることを確認します。[sssd] [... file truncated ...] services =
nss
, pam[nss]
セクションで、SSSD が NSS と対話する方法を設定します。以下に例を示します。[nss] filter_groups = root filter_users = root entry_cache_timeout = 300 entry_cache_nowait_percentage = 75
利用可能なオプションの一覧は、sssd.conf(5) man ページのNSS configuration options
を参照してください。- SSSD を再起動します。
# systemctl restart sssd.service
インテグレーションの動作が正しく行われることのテスト
- id user
- getent passwd user
7.5.2. サービスの設定: PAM
SSSD を使用するように PAM を設定する
authconfig
ユーティリティーを使用して SSSD を有効にします。# authconfig --enablesssdauth --update
これにより、SSSD モジュール(通常は/etc/pam.d/system-auth
ファイルおよび/etc/pam.d/password-auth
ファイル)を参照する PAM 設定が更新されます。以下に例を示します。[... file truncated ...] auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so [... file truncated ...]
SSSD が PAM と連携するように設定する
/etc/sssd/sssd.conf
ファイルを開きます。[sssd]
セクションで、PAM が SSSD と連携するサービスの 1 つとしてリストされていることを確認します。[sssd] [... file truncated ...] services = nss,
pam
[pam]
セクションで、SSSD が PAM と対話する方法を設定します。以下に例を示します。[pam] offline_credentials_expiration = 2 offline_failed_login_attempts = 3 offline_failed_login_delay = 5
利用可能なオプションの一覧は、sssd.conf(5) man ページのPAM 設定オプション
を参照してください。- SSSD を再起動します。
# systemctl restart sssd.service
インテグレーションの動作が正しく行われることのテスト
- ユーザーとしてログインしてみてください。
- sssctl user-checks user_name auth コマンドを使用して、SSSD 設定を確認します。詳細は、sssctl user-checks --help コマンドを使用します。
7.5.3. サービスの設定: autofs
automount
での SSSD の仕組み
automount
ユーティリティーは、NFS ファイルシステムを自動的にマウントおよびアンマウントできます(オンデマンドマウント)。これにより、システムリソースが保存されます。自動マウント
の詳細は、ストレージ 『管理ガイドの autofs を参照』 してください。
automount
が SSSD をポイントするように設定できます。この設定では、以下が行われます。
- ユーザーがディレクトリーのマウントを試みると、SSSD は LDAP に接続して、現在の
自動
マウント設定に関する必要な情報を取得します。 - SSSD は、
自動
マウントで必要な情報をキャッシュに保存します。これにより、LDAP サーバーがオフラインであっても、ユーザーはディレクトリーをマウントできます。
SSSD を使用するように autofs
を設定する
- autofs パッケージをインストールしている。
# yum install autofs
/etc/nsswitch.conf
ファイルを開きます。automount
ldap
からsss
に変更します。automount: files
sss
autofs
と連携するように SSSD を設定
/etc/sssd/sssd.conf
ファイルを開きます。[sssd]
セクションで、SSSD が管理するサービス一覧にautofs
を追加します。[sssd] services = nss,pam,
autofs
[autofs]
セクションを新規作成します。空欄のままにすることができます。[autofs]
利用可能なオプションの一覧は、sssd.conf(5) man ページのAUTOFS 設定オプション
を参照してください。- SSSD が LDAP から
自動マウント
情報を読み取れるように、LDAP ドメインがsssd.conf
で利用可能であることを確認してください。「SSSD の LDAP ドメインの設定」 を参照してください。sssd.conf
の[domain]
セクションは、いくつかのautofs
関連のオプションを受け入れます。以下に例を示します。[domain/LDAP] [... file truncated ...]
autofs_provider=ldap
ldap_autofs_search_base=cn=automount,dc=example,dc=com
ldap_autofs_map_object_class=automountMap
ldap_autofs_entry_object_class=automount
ldap_autofs_map_name=automountMapName
ldap_autofs_entry_key=automountKey
ldap_autofs_entry_value=automountInformation
利用可能なオプションの一覧は、sssd.conf(5) man ページのDOMAIN SECTIONS
を参照してください。autofs
オプションを追加で指定しない場合、設定はアイデンティティープロバイダーの設定によって異なります。 - SSSD を再起動します。
# systemctl restart sssd.service
設定のテスト
- automount -m コマンドを使用して、SSSD からマップを出力します。
7.5.4. サービスの設定: sudo
sudo
での SSSD の仕組み
sudo
が SSSD を参照するように設定できます。この設定では、以下が行われます。
- ユーザーが
sudo
操作を試みると、SSSD は LDAP または AD に問い合わせ、現在のsudo
設定に関する必要な情報を取得します。 - SSSD は
sudo
情報をキャッシュに保存します。これにより、LDAP または AD サーバーがオフラインであってもsudo
操作を実行できます。
sudo
Host
属性の値に応じて、ローカルシステムに適用される sudo ルールのみをキャッシュします。詳細は sssd-sudo(5) の man ページを参照してください。
SSSD を使用するように sudo
を設定する
/etc/nsswitch.conf
ファイルを開きます。- SSSD を
sudoers
行の一覧に追加します。sudoers: files
sss
sudo
で動作するように SSSD を設定
/etc/sssd/sssd.conf
ファイルを開きます。[sssd]
セクションで、sudo
を SSSD が管理するサービス一覧に追加します。[sssd] services = nss,pam,
sudo
[sudo]
セクションを新たに作成します。空欄のままにすることができます。[sudo]
利用可能なオプションの一覧は、sssd.conf(5) man ページのSUDO 設定オプション
を参照してください。- SSSD がディレクトリーから
sudo
情報を読み取れるように、LDAP または AD ドメインがsssd.conf
で利用可能であることを確認してください。詳細は、次を参照してください。- 『Windows 統合ガイド』のSSSD の ID プロバイダーとして Active Directory の使用
LDAP または AD ドメインの[domain]
セクションには、以下のsudo
関連のパラメーターを含める必要があります。[domain/LDAP_or_AD_domain] ...
sudo_provider = ldap
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
注記ID プロバイダーとして Identity Management または AD を設定すると、sudo
プロバイダーが自動的に有効になります。この場合、sudo_provider
パラメーターを指定する必要はありません。利用可能なオプションの一覧は、sssd.conf(5) man ページのDOMAIN SECTIONS
を参照してください。sudo
プロバイダーに利用可能なオプションは、sssd-ldap(5) の man ページを参照してください。 - SSSD を再起動します。
# systemctl restart sssd.service
sudo
ルールをサポートする必要があります。詳細は sudo
ドキュメントを参照してください。
sudo
ルールを提供する方法は、sudoers.ldap(5) の man ページを参照してください。
7.6. SSSD クライアント側のビュー
ipa
を除き、すべての id_provider
値にクライアント側の上書きを設定できます。ipa
プロバイダーを使用している場合は、IdM で ID ビューを一元的に定義します。Linux Domain Identity, Authentication, and Policy Guideの該当するセクションを参照してください。
# systemctl restart sssd
7.6.1. ユーザーアカウントの異なる属性値の定義
- オプション。user アカウントの現在の UID を表示します。
# id user uid=1241400014(user_name) gid=1241400014(user_name) Groups=1241400014(user_name)
- アカウントの UID を 6666 に上書きします。
# sss_override user-add user -u 6666
- インメモリーキャッシュの有効期限が切れるまで待ちます。手動で期限切れにするには、以下を実行します。
# sss_cache --users
- 新しい UID が適用されていることを確認します。
# id user uid=6666(user_name) gid=1241400014(user_name) Groups=1241400014(user_name)
- オプション。ユーザーの上書きを表示します。
# sss_override user-show user user@ldap.example.com::6666:::::
--help
を追加して、コマンドラインオプションを一覧表示します。
# sss_override user-add --help
7.6.2. ホストですべての上書きの一覧表示
# 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 ...
7.6.3. ローカルの上書きの削除
# sss_override user-del user
# sss_override group-del group
7.6.4. ローカルビューのエクスポートおよびインポート
# 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
7.7. SSSD のダウングレード
(Wed Nov 28 21:25:50 2012) [sssd] [sysdb_domain_init_internal] (0x0010): Unknown DB version [0.14], expected [0.10] for domain AD!
- 既存のキャッシュデータベースファイルを削除します。
[root@server ~]# rm -rf /var/lib/sss/db/*
- SSSD プロセスを再起動します。
[root@server ~]# systemctl restart sssd.service
7.8. SSSD での NSCD の使用
resolv.conf
ファイルを読み取ります。このファイルは、通常 1 回だけ読み取るため、このファイルへの変更は自動的に適用されません。これにより、サービスを手動で再起動しない限り、NSCD サービスが実行されているマシンで NFS ロックが失敗する可能性があります。
/etc/nscd.conf
ファイルの ホスト
でのみキャッシュを有効にし、passwd
、group
、services
、および netgroup
エントリーの SSSD キャッシュに依存します。
/etc/nscd.conf
ファイルを変更します。
enable-cache hosts yes enable-cache passwd no enable-cache group no enable-cache netgroup no enable-cache services no
7.9. 関連情報
- SSSD 関連の man ページの完全なリストは、sssd(8) man ページの
SEE ALSO
セクションを参照してください。 - トラブルシューティングに関するアドバイス: 「SSSD のトラブルシューティング」
- SSSD がサーバーから送信されるパスワード有効期限の警告を処理し、ローカルシステムでユーザーに表示される手順: Red Hat ナレッジベースのSetting Password Expiry
- SSSD クライアントは、LDAP サーバーから取得した全ユーザーに対して GID を自動的に作成でき、GID 番号がすでに取得されていない限り、GID がユーザーの UID と一致することを確認します。Active Directory に直接統合される SSSD クライアントで GID の自動作成を行う方法を確認するには、Windows 統合ガイドの該当するセクションを参照してください。
第8章 realmd
を使用した Identity ドメインへの接続
realmd
システムは、アイデンティティードメインを検出して参加する明確で簡単な方法を提供します。ドメイン自体に接続されませんが、ドメインに接続するように SSSD や Winbind などの基礎となる Linux システムサービスを設定します。
realmd
を使用して Microsoft Active Directory (AD)ドメインに接続する方法を説明します。realmd
を使用して AD 以外の ID ドメインに接続する場合も同じ手順が適用されます。『Windows Integration Guide』のUsing realmd to Connect to an Active Directory Domainを参照してください。
第9章 LDAP サーバー
LDAP
(Lightweight Directory Access Protocol)は、ネットワーク上で一元的に保存された情報にアクセスするために使用されるオープンプロトコルのセットです。ディレクトリー共有の X.500 標準に
基づいていますが、より複雑でリソースを大量に消費します。このため、LDAP は 「X.500 Lite」 と呼ばれることもあります。
9.1. Red Hat Directory Server
9.2. OpenLDAP
9.2.1. LDAP の概要
SSLv3
プロトコルに依存しないことを推奨しています。OpenLDAP は、SSLv3
を効果的に無効にできるようにする設定パラメーターを提供しないシステムコンポーネントの 1 つです。リスクを軽減するには、stunnel コマンドを使用してセキュアなトンネルを提供し、SSLv3
の使用から stunnel を無効にすることが推奨されます。stunnel の使用に関する詳細は、Red Hat Enterprise Linux 7 セキュリティーガイド を参照してください。
9.2.1.1. LDAP の用語
- entry
- LDAP ディレクトリー内の単一のユニット。各エントリーは、固有の 識別名 (DN) で識別されます。
- attribute
- エントリーに直接関連付けられた情報。たとえば、組織が LDAP エントリーとして表される場合、この組織に関連付けられている属性にはアドレス、fax 番号などが含まれる場合があります。同様に、個人の電話番号やメールアドレスなどの一般的な属性のエントリーとして、ユーザーを表示することもできます。属性は、単一の値、または順序付けられていないスペースで区切られた値のリストのいずれかを持つことができます。特定の属性は任意ですが、その他は必須です。必要な属性は
objectClass
定義を使用して指定し、/etc/openldap/slapd.d/cn=config/cn=schema/
ディレクトリーにあるスキーマファイルにあります。属性とそれに対応する値のアサーションは、RDN (Relative Distinguished Name) とも呼ばれます。グローバルで一意となる識別名とは異なり、相対識別名はエントリーごとに一意のみになります。 - LDIF
- LDAP データ交換形式 (LDIF) は LDAP エントリーのプレーンテキスト表現です。以下の形式を取ります。
[id] dn: distinguished_name attribute_type: attribute_value… attribute_type: attribute_value… …
任意の id は、エントリーの編集に使用されるアプリケーションによって決定される数値です。各エントリーには、対応するスキーマファイルにすべて定義されている限り、必要が数の attribute_type と attribute_value のペアを含めることができます。空白行は、エントリーの最後を示します。
9.2.1.2. OpenLDAP の機能
- LDAPv3 サポート: LDAP バージョン 2 以降のプロトコルの変更の多くは、LDAP よりセキュアにするように設計されています。そのため、これには SASL (Simple Authentication and Security Layer)、TLS (Transport Layer Security)、および SSL (Secure Sockets Layer) プロトコルのサポートが含まれます。
- LDAP Over IPC: プロセス間の通信 (IPC) を使用すると、ネットワーク上で通信する必要がなくなります。
- IPv6 サポート: OpenLDAP は、インターネットプロトコルの次世代である IPv6 (Internet Protocol version 6) に準拠しています。
- LDIFv1 サポート: OpenLDAP は LDIF バージョン 1 に完全に準拠しています。
- 更新された C API: 現在の C API は、プログラマーが LDAP ディレクトリーサーバーに接続し、使用する方法を向上させます。
- 強化されたスタンドアロン LDAP サーバー: これには、更新されたアクセス制御システム、スレッドプール、より良いツールなどが含まれています。
9.2.1.3. OpenLDAP サーバーの設定
- OpenLDAP スイートをインストールします。必要なパッケージの詳細は、「OpenLDAP スイートのインストール」 を参照してください。
- 「OpenLDAP サーバーの設定」 の説明に従って設定をカスタマイズします。
- 「OpenLDAP サーバーの実行」 の説明に従って
slapd
サービスを起動します。 - ldapadd ユーティリティーを使用して、エントリーを LDAP ディレクトリーに追加します。
- ldapsearch ユーティリティーを使用して、
slapd
サービスが情報に正しくアクセスしていることを確認します。
9.2.2. OpenLDAP スイートのインストール
パッケージ | Description |
---|---|
openldap | OpenLDAP サーバーとクライアントアプリケーションの実行に必要なライブラリーを含むパッケージ。 |
openldap-clients | LDAP サーバーのディレクトリーを表示および変更するコマンドラインユーティリティーを含むパッケージ。 |
openldap-servers | LDAP サーバーを設定し、実行するサービスとユーティリティーの両方を含むパッケージ。これには、スタンドアロンの LDAP デーモン slapd が含まれます。 |
compat-openldap | OpenLDAP 互換性ライブラリーを含むパッケージ。 |
パッケージ | Description |
---|---|
nss-pam-ldapd | nslcd を含むパッケージ。ユーザーがローカル LDAP クエリーを実行できるようにするローカルの LDAP 名サービス。 |
mod_ldap | mod_authnz_ldap モジュールおよび mod_ldap モジュールを含むパッケージ。mod_authnz_ldap モジュールは、Apache HTTP Server の LDAP 承認モジュールです。このモジュールは、LDAP ディレクトリーに対してユーザーの認証情報を認証でき、ユーザー名、完全な DN、グループメンバーシップ、任意の属性、または完全なフィルター文字列に基づいてアクセス制御を強制できます。同じパッケージに含まれる mod_ldap モジュールは、設定可能な共有メモリーキャッシュを提供し、多くの HTTP リクエストでのディレクトリーアクセスの繰り返しを回避し、SSL/TLS もサポートします。このパッケージは Optional チャンネルにより提供されることに注意してください。Red Hat 追加チャンネルの詳細は、『System Administrator's Guide』のAdding the Optional and Supplementary Repositoriesを参照してください。
|
yum install
package…
~]# yum install openldap openldap-clients openldap-servers
root
でログインしている必要があります)。Red Hat Enterprise Linux に新しいパッケージをインストールする方法の詳細は、『System Administrator's Guide』のInstalling Packagesを参照してください。
9.2.2.1. OpenLDAP サーバーユーティリティーの概要
slapd
サービスとともに以下のユーティリティーがインストールされます。
コマンド | Description |
---|---|
slapacl | 属性の一覧へのアクセスを確認できます。 |
slapadd | LDIF ファイルから LDAP ディレクトリーにエントリーを追加できます。 |
slapauth | 認証および承認権限の ID のリストを確認できます。 |
slapcat | デフォルト形式の LDAP ディレクトリーからエントリーを取得し、LDIF ファイルに保存できます。 |
slapdn | 利用可能なスキーマ構文に基づいて、識別名 (DN) の一覧を確認できます。 |
slapindex | 現在のコンテンツに基づいて slapd ディレクトリーを再インデックス化できます。設定ファイルのインデックスオプションを変更する場合に、このユーティリティーを実行します。 |
slappasswd | ldapmodify ユーティリティーまたは slapd 設定ファイルで使用する暗号化されたユーザーパスワードを作成できます。 |
slapschema | 対応するスキーマでデータベースのコンプライアンスを確認できます。 |
slaptest | LDAP サーバー設定を確認できるようにします。 |
root
のみですが、slapd
サービスは ldap
ユーザーとして実行します。このため、ディレクトリーサーバーは、slapadd で作成したファイルを変更できません。この問題を修正するには、slapdadd ユーティリティーの実行後に、シェルプロンプトで以下を入力します。
~]# chown -R ldap:ldap /var/lib/ldap
slapd
サービスを停止します。これを行うには、シェルプロンプトで以下を実行できます。
~]# systemctl stop slapd.service
slapd
サービスの現在の状態の開始、停止、再起動、および確認の方法は、「OpenLDAP サーバーの実行」 を参照してください。
9.2.2.2. OpenLDAP クライアントユーティリティーの概要
コマンド | Description |
---|---|
ldapadd | エントリーは、ファイルまたは標準入力から LDAP ディレクトリーに追加できます。これは、ldapmodify -a へのシンボリックリンクです。 |
ldapcompare | 指定属性を LDAP ディレクトリーエントリーと比較できます。 |
ldapdelete | LDAP ディレクトリーからエントリーを削除できます。 |
ldapexop | 拡張 LDAP 操作を実行できます。 |
ldapmodify | LDAP ディレクトリー (ファイルまたは標準入力のいずれか) のエントリーを変更できます。 |
ldapmodrdn | LDAP ディレクトリーエントリーの RDN 値を変更できます。 |
ldappasswd | LDAP ユーザーのパスワードを設定または変更できるようにします。 |
ldapsearch | LDAP ディレクトリーエントリーを検索できます。 |
ldapurl | LDAP URL の組み立てまたは分解を可能にします。 |
ldapwhoami | LDAP サーバーで whoami 操作を実行できます。 |
9.2.2.3. 共通 LDAP クライアントアプリケーションの概要
9.2.3. OpenLDAP サーバーの設定
/etc/openldap/
ディレクトリーに保存されます。以下の表は、このディレクトリー内の最も重要なディレクトリーおよびファイルを示しています。
パス | Description |
---|---|
/etc/openldap/ldap.conf | OpenLDAP ライブラリーを使用するクライアントアプリケーションの設定ファイルこれには、ldapadd、ldapsearch、Evolution などが含まれます。 |
/etc/openldap/slapd.d/ | slapd 設定を含むディレクトリー。 |
/etc/openldap/slapd.conf
ファイルから設定を読み取らなくなりました。代わりに、/etc/openldap/slapd.d/
ディレクトリーにある設定データベースを使用します。以前のインストールの既存の slapd.conf
ファイルがある場合は、以下のコマンドを実行して新しい形式に変換できます。
~]# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/
slapd
設定は、階層的なディレクトリー構造で整理された LDIF エントリーで設定され、これらのエントリーを編集する方法として、「OpenLDAP サーバーユーティリティーの概要」 で説明されているサーバーユーティリティーを使用することが推奨されます。
slapd
サービスが起動しないことがあります。このため、/etc/openldap/slapd.d/
内の LDIF ファイルを直接編集しないことが強く推奨されます。
9.2.3.1. グローバル設定の変更
/etc/openldap/slapd.d/cn=config.ldif
ファイルに保存されます。一般的には、以下のディレクティブが使用されます。
-
olcAllows
olcAllows
ディレクティブを使用すると、有効にする機能を指定できます。以下の形式を取ります。olcAllows
: feature…表9.6「利用可能なolcAllows
オプション」 に記載されている、スペースで区切られた機能のリストを受け入れます。デフォルトオプションはbind_v2
です。表9.6 利用可能な olcAllows オプション オプション Description bind_v2
LDAP バージョン 2 バインド要求の受け入れを有効にします。 bind_anon_cred
識別名 (DN) が空でない場合は匿名バインドを有効にします。 bind_anon_dn
識別名 (DN) が空 でない 場合は匿名バインドを有効にします。 update_anon
匿名更新操作の処理を有効にします。 proxy_authz_anon
匿名プロキシーの承認制御の処理を有効にします。 例9.1
olcAllows
ディレクティブの使用olcAllows: bind_v2 update_anon
-
olcConnMaxPending
olcConnMaxPending
ディレクティブを使用すると、匿名セッションの保留中の要求の最大数を指定できます。以下の形式を取ります。olcConnMaxPending
: numberデフォルトオプションは100
です。例9.2
olcConnMaxPending
ディレクティブの使用olcConnMaxPending: 100
-
olcConnMaxPendingAuth
olcConnMaxPendingAuth
ディレクティブを使用すると、認証されたセッションの保留中のリクエストの最大数を指定できます。以下の形式を取ります。olcConnMaxPendingAuth
: numberデフォルトオプションは1000
です。例9.3
olcConnMaxPendingAuth
ディレクティブの使用olcConnMaxPendingAuth: 1000
-
olcDisallows
olcDisallows
ディレクティブを使用すると、無効にする機能を指定できます。以下の形式を取ります。olcDisallows
: feature…表9.7「利用可能なolcDisallows
オプション」 に記載されている、スペースで区切られた機能のリストを受け入れます。デフォルトでは、機能は無効になりません。表9.7 利用可能な olcDisallows オプション オプション Description bind_anon
匿名バインド要求の受け入れを無効にします。 bind_simple
簡単なバインド認証メカニズムを無効にします。 tls_2_anon
STARTTLS コマンドを受け取ると、匿名セッションの強制を無効にします。 tls_authc
認証時に STARTTLS コマンドを許可しません。 例9.4
olcDisallows
ディレクティブの使用olcDisallows: bind_anon
-
olcIdleTimeout
olcIdleTimeout
ディレクティブを使用すると、アイドル状態の接続を閉じる前に待機する秒数を指定できます。以下の形式を取ります。olcIdleTimeout
: numberこのオプションは、デフォルトでは無効になっています (つまり0
に設定されます)。例9.5
olcIdleTimeout
ディレクティブの使用olcIdleTimeout: 180
-
olcLogFile
olcLogFile
ディレクティブを使用すると、ログメッセージを書き込むファイルを指定できます。以下の形式を取ります。olcLogFile
: file_nameログメッセージはデフォルトで標準エラーに書き込まれます。例9.6
olcLogFile
ディレクティブの使用olcLogFile: /var/log/slapd.log
-
olcReferral
olcReferral
オプションでは、サーバーがこれを処理できない場合に、要求を処理するサーバーの URL を指定できます。以下の形式を取ります。olcReferral
: URLこのオプションはデフォルトで無効になっています。例9.7
olcReferral
ディレクティブの使用olcReferral: ldap://root.openldap.org
-
olcWriteTimeout
olcWriteTimeout
オプションでは、未処理の書き込み要求との接続を閉じる前に待機する秒数を指定できます。以下の形式を取ります。olcWriteTimeout
このオプションは、デフォルトでは無効になっています (つまり0
に設定されます)。例9.8
olcWriteTimeout
ディレクティブの使用olcWriteTimeout: 180
9.2.3.2. フロントエンド設定
etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif
ファイルに保存され、アクセス制御リスト(ACL)などのグローバルデータベースオプションを定義します。詳細は、slapd-config(5) の man ページの Global Database Options セクションを参照してください。
9.2.3.3. Monitor バックエンド
/etc/openldap/slapd.d/cn=config/olcDatabase=psycmonitor.ldif
ファイルは、OpenLDAP モニターのバックエンドを制御します。これを有効にすると、デーモンの実行ステータスに関する情報で、OpenLDAP により自動生成され、動的に更新されます。接尾辞は cn=Monitor
で、変更できません。詳細は、slapd-monitor(5) の man ページをご覧ください。
9.2.3.4. データベース固有の設定
hdb
データベースバックエンドを使用します。サブツリーの名前をサポートする階層データベースレイアウトを使用する他に、bdb
バックエンドと同じであり、同じ設定オプションを使用します。このデータベースバックエンドの設定は、/etc/openldap/slapd.d/cn=config/olcDatabase={2}hdb.ldif
ファイルに保存されます。
# man slapd-hdb
bdb
バックエンドおよび hdb
バックエンドは非推奨になりました。代わりに、新規インストールに mdb
バックエンドを使用することを検討してください。
-
olcReadOnly
olcReadOnly
ディレクティブを使用すると、データベースを読み取り専用モードで使用できます。以下の形式を取ります。olcReadOnly
: booleanTRUE
(読み取り専用モードを有効) またはFALSE
(データベースの変更を有効) のいずれかを受け入れます。デフォルトのオプションはFALSE
です。例9.9
olcReadOnly
ディレクティブの使用olcReadOnly: TRUE
-
olcRootDN
olcRootDN
ディレクティブを使用すると、LDAP ディレクトリー上の操作に設定されたアクセス制御または管理制限パラメーターが無制限のユーザーを指定できます。以下の形式を取ります。olcRootDN
: distinguished_name識別名 (DN) を受け入れます。デフォルトのオプションはcn=Manager,dn=my-domain,dc=com
です。例9.10
olcRootDN
ディレクティブの使用olcRootDN: cn=root,dn=example,dn=com
-
olcRootPW
olcRootPW
ディレクティブを使用すると、olcRootDN
ディレクティブを使用して指定されるユーザーのパスワードを設定できます。以下の形式を取ります。olcRootPW
: passwordプレーンテキストの文字列またはハッシュのいずれかを指定できます。ハッシュを生成するには、シェルプロンプトで以下を入力します。~]$ slappaswd New password: Re-enter new password: {SSHA}WczWsyPEnMchFf1GRTweq2q7XJcvmSxD
例9.11
olcRootPW
ディレクティブの使用olcRootPW: {SSHA}WczWsyPEnMchFf1GRTweq2q7XJcvmSxD
-
olcSuffix
olcSuffix
ディレクティブでは、情報を提供するドメインを指定できます。以下の形式を取ります。olcSuffix
: domain_name完全修飾ドメイン名 (FQDN) を受け入れます。デフォルトのオプションはdc=my-domain,dc=com
です。例9.12
olcSuffix
ディレクティブの使用olcSuffix: dc=example,dc=com
9.2.3.5. スキーマの拡張
/etc/openldap/slapd.d/
ディレクトリーには、/etc/openldap/schema/
に以前あった LDAP 定義も含まれます。OpenLDAP で使用されるスキーマを拡張して、デフォルトのスキーマファイルをガイドとして使用して、追加の属性タイプとオブジェクトクラスをサポートすることができます。ただし、このタスクは本章の範囲外です。このトピックの詳細については、https://openldap.org/doc/admin24/schema.html を参照してください。
9.2.3.6. セキュアな接続の確立
サーバー設定
/etc/openldap/ slapd
.d/cn=config.ldif
ファイルで指定する必要がある slapd のグローバル設定ディレクティブを一覧表示します。
/usr/local/etc/openldap/slapd.conf
としてインストールされますが、新しいスタイルは slapd
バックエンドデータベースを使用して設定を保存します。設定データベースは通常、/usr/local/etc/openldap/slapd.d/
ディレクトリーにあります。
/etc/sysconfig/slapd
ファイルを編集し、SLAPD_URLS
ディレクティブで指定された URL のリストに ldaps:
/// 文字列を追加します。
-
olcTLSCACertificateFile
olcTLSCACertificateFile
ディレクティブは、信頼された CA 証明書が含まれる PEM (Privacy-enhanced mail) スキーマでエンコードされるファイルを指定します。ディレクティブは以下の形式になります。olcTLSCACertificateFile
: pathpath を、CA 証明書ファイルへのパスに置き換えます。-
olcTLSCACertificatePath
olcTLSCACertificatePath
ディレクティブは、個別の CA 証明書が含まれるディレクトリーへのパスを指定します。このディレクトリーは、実際の証明書ファイルを参照するハッシュ化された名前でシンボリックリンクを生成する OpenSSL c_rehash ユーティリティーで特別に管理する必要があります。通常、代わりにolcTLSCACertificateFile
ディレクティブを使用することが推奨されます。ディレクティブは以下の形式になります。olcTLSCACertificatePath
: pathpath を、CA 証明書ファイルを含むディレクトリーのパスに置き換えます。指定したディレクトリーは OpenSSL c_rehash ユーティリティーで管理する必要があります。-
olcTLSCertificateFile
olcTLSCertificateFile
ディレクティブは、slapd
サーバー証明書を含むファイルを指定します。ディレクティブは以下の形式になります。olcTLSCertificateFile
: pathpath を、slapd
サービスのサーバー証明書ファイルへのパスに置き換えます。-
olcTLSCertificateKeyFile
olcTLSCertificateKeyFile
ディレクティブは、olcTLSCertificateFile
で指定されたファイルに保存された証明書に一致する秘密鍵が含まれるファイルを指定します。現在の実装は暗号化された秘密鍵に対応していないため、そのファイルが十分に保護されている必要があることに注意してください。ディレクティブは以下の形式になります。olcTLSCertificateKeyFile
: pathpath を、秘密鍵ファイルへのパスに置き換えます。
クライアント設定
/etc/openldap/ldap.conf
設定ファイルで以下のディレクティブを指定します。これらのディレクティブのほとんどは、サーバー設定オプションと並行して行います。/etc/openldap/ldap.conf
のディレクティブはシステム全体で設定されますが、各ユーザーは ~/.ldaprc
ファイルで上書きすることができます。
ldaps://
文字列は、ldapsearch などの OpenLDAP コマンドの ldap://
の代わりに使用する必要があります。これにより、コマンドはサーバーで設定された SSL のデフォルトポートであるポート 636 を使用するように強制されます。
-
TLS_CACERT
TLS_CACERT
ディレクティブは、クライアントが認識するすべての認証局の証明書を含むファイルを指定します。これは、サーバーのolcTLSCACertificateFile
ディレクティブと同じです。TLS_CACERT
は、/etc/openldap/ldap.conf
のTLS_CACERTDIR
の前に常に指定する必要があります。ディレクティブは以下の形式になります。TLS_CACERT
pathpath を、CA 証明書ファイルへのパスに置き換えます。-
TLS_CACERTDIR
TLS_CACERTDIR
ディレクティブは、別のファイルに認証局証明書が含まれるディレクトリーへのパスを指定します。サーバーのolcTLSCACertificatePath
と同様に、指定されたディレクトリーは OpenSSL c_rehash ユーティリティーで管理する必要があります。TLS_CACERTDIR
directorydirectory を、CA 証明書ファイルを含むディレクトリーのパスに置き換えます。-
TLS_CERT
TLS_CERT
は、クライアント証明書が含まれるファイルを指定します。このディレクティブは、ユーザーの~/.ldaprc
ファイルでのみ指定できます。ディレクティブは以下の形式になります。TLS_CERT
pathpath を、クライアント証明書ファイルへのパスに置き換えます。-
TLS_KEY
TLS_KEY
は、TLS_CERT
ディレクティブで指定されたファイルに保存されている証明書に一致する秘密鍵が含まれるファイルを指定します。サーバーでolcTLSCertificateFile
と同様に、暗号化された鍵ファイルはサポートされません。ファイル自体は注意して保護する必要があります。このオプションは、ユーザーの~/.ldaprc
ファイルでのみ設定できます。TLS_KEY
ディレクティブは以下の形式になります。TLS_KEY
pathpath を、クライアント証明書ファイルへのパスに置き換えます。
9.2.3.7. レプリケーションの設定
/etc/openldap/slapd.d/
で以下のいずれかのディレクティブを使用します。
-
olcMirrorMode
olcMirrorMode
ディレクティブは、ミラーのレプリケーションモードを有効にします。以下の形式を取ります。olcMirrorMode
on
このオプションは、プロバイダーとコンシューマーの両方で指定する必要があります。serverID
は、syncrepl
オプションと共に指定する必要があります。詳細は、18.3.4.OpenLDAP ソフトウェア管理ガイド の MirrorMode セクション (「インストールされているドキュメント」を参照)-
olcSyncrepl
olcSyncrepl
ディレクティブは、sync レプリケーションモードを有効にします。以下の形式を取ります。olcSyncrepl
on
同期のレプリケーションモードでは、プロバイダーとコンシューマーの両方に特定の設定が必要になります。この設定は、OpenLDAP ソフトウェア管理ガイド の 18.3.1. Syncrepl セクション (「インストールされているドキュメント」) を参照してください。
9.2.3.8. モジュールとバックエンドの読み込み
slapd
サービスを強化できます。これらのモジュールのサポートは、slapd
の設定時に --enable-modules
オプションを使用して有効にする必要があります。モジュールは、拡張子が .la のファイルに保存されます。
module_name.la
slapd
にコンパイルするか、モジュールサポートが有効になっている場合は、動的に読み込むことができます。後者の場合は、以下の命名規則が適用されます。
back_backend_name.la
/etc/openldap/slapd.d/
で以下のディレクティブを使用します。
-
olcModuleLoad
olcModuleLoad
ディレクティブは、読み込むモジュール (動的に読み込み可能) を指定します。以下の形式を取ります。olcModuleLoad
: moduleここで、module は、読み込むモジュールまたはバックエンドを含むファイルを表します。
9.2.4. LDAP を使用したアプリケーションの SELinux ポリシー
allow_ypbind
を有効にする必要があります。特定のアプリケーションでは、このシナリオで有効な authlogin_nsswitch_use_ldap
ブール値も要求します。次のコマンドを実行して、前述のブール値を有効にします。
~]# setsebool-P
allow_ypbind
=1
~]# setsebool-P
authlogin_nsswitch_use_ldap
=1
-P
オプションを使用すると、システムを再起動してもこの設定が維持されます。SELinux に関する詳細情報は、Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide も併せて参照してください。
9.2.5. OpenLDAP サーバーの実行
9.2.5.1. サービスの起動
slapd
サービスを起動するには、root
で次のコマンドを実行します。
~]# systemctl start slapd.service
root
で以下のコマンドを実行します。
~]# systemctl enable slapd.service
ln -s '/usr/lib/systemd/system/slapd.service' '/etc/systemd/system/multi-user.target.wants/slapd.service'
9.2.5.2. サービスの停止
slapd
サービスを停止するには、root
で次のコマンドを実行します。
~]# systemctl stop slapd.service
root
で以下を入力します。
~]# systemctl disable slapd.service
rm '/etc/systemd/system/multi-user.target.wants/slapd.service'
9.2.5.3. サービスの再起動
slapd
サービスを再起動するには、シェルプロンプトで以下を入力します。
~]# systemctl restart slapd.service
9.2.5.4. サービスステータスの確認
slapd
サービスが実行していることを確認するには、シェルプロンプトで以下を入力します。
~]$ systemctl is-active slapd.service
active
9.2.6. OpenLDAP を使用してシステムを認証するためのシステムの設定
~]# yum install openldap openldap-clients nss-pam-ldapd
9.2.6.1. 以前の認証情報の LDAP 形式への移行
~]# yum install migrationtools
/usr/share/migrationtools/
ディレクトリーにインストールされます。インストールが完了したら、/usr/share/migrationtools/migrate_common.ph
ファイルを編集し、以下の行を変更して正しいドメインを反映させます。
# Default DNS domain $DEFAULT_MAIL_DOMAIN = "example.com"; # Default base $DEFAULT_BASE = "dc=example,dc=com";
dc=example,dc=com
に設定して migrate_all_online.sh
スクリプトを実行するには、以下を入力します。
~]# export DEFAULT_BASE="dc=example,dc=com" \ /usr/share/migrationtools/migrate_all_online.sh
既存のネームサービス | LDAP が実行しているか ? | 使用するスクリプト |
---|---|---|
/etc フラットファイル | はい | migrate_all_online.sh |
/etc フラットファイル | いいえ | migrate_all_offline.sh |
NetInfo | はい | migrate_all_netinfo_online.sh |
NetInfo | いいえ | migrate_all_netinfo_offline.sh |
NIS (YP) | はい | migrate_all_nis_online.sh |
NIS (YP) | いいえ | migrate_all_nis_offline.sh |
/usr/share/doc/migrationtools-version/
ディレクトリーの README
ファイルおよび migration-tools.txt
ファイルを参照してください。
9.2.7. 関連情報
インストールされているドキュメント
/usr/share/doc/openldap-servers-version/guide.html
: 『OpenLDAP ソフトウェア管理者ガイド』 のコピー。/usr/share/doc/openldap-servers-version/README.schema
: インストールされたスキーマファイルの説明が含まれる README ファイル。
- クライアントアプリケーション
- ldapadd(1) : ldapadd コマンドの man ページでは、LDAP ディレクトリーにエントリーを追加する方法を説明します。
- ldapdelete(1) : ldapdelete コマンドの man ページでは、LDAP ディレクトリー内のエントリーを削除する方法を説明します。
- ldapmodify(1) : ldapmodify コマンドの man ページでは、LDAP ディレクトリー内のエントリーを変更する方法を説明します。
- ldapsearch(1) : ldapsearch コマンドの man ページでは、LDAP ディレクトリー内のエントリーを検索する方法を説明します。
- ldappasswd(1) : ldappasswd コマンドの man ページでは、LDAP ユーザーのパスワードを設定または変更する方法を説明します。
- ldapcompare(1) : ldapcompare ツールの使用方法を説明します。
- ldapwhoami(1) : ldapwhoami ツールの使用方法を説明します。
- ldapmodrdn(1): エントリーの RDN を変更する方法を説明します。
- サーバーアプリケーション
- slapd(8C): LDAP サーバーのコマンドラインオプションを説明します。
- 管理アプリケーション
- slapadd(8C) : slapd データベースにエントリーを追加するために使用されるコマンドラインオプションを説明します。
- slapcat(8C) : slapd データベースから LDIF ファイルを生成するために使用されるコマンドラインオプションを説明します。
- slapindex(8C) : slapd データベースの内容に基づいてインデックスを再生成するために使用されるコマンドラインオプションを説明します。
- slappasswd(8C): LDAP ディレクトリーのユーザーパスワードを生成するのに使用されるコマンドラインオプションを説明します。
- 設定ファイル
- ldap.conf(5) :
ldap.conf
ファイルの man ページでは、LDAP クライアントの設定ファイル内で利用可能な形式およびオプションが説明されています。 - slapd-config(5) :
/etc/openldap/slapd.d
設定ディレクトリーで利用可能な形式およびオプションを説明します。
その他リソース
- 『OpenLDAP および Mozilla NSS 互換性レイヤー』 NSS データベース後方互換性に関する実装の詳細。
- 『How do I use TLS/SSL?』OpenLDAP が OpenSSL を使用するように設定する方法に関する情報
パート III. セキュアなアプリケーション
PAM
( Pluggable Authentication Modules
)の使用方法、Kerberos
認証プロトコルと certmonger
デーモンの使用方法、最後に シングルサインオン
(SSO
)用にアプリケーションを設定する方法の詳細を提供します。
第10章 PAM (プラグ可能な認証モジュール) の使用
10.1. PAM について
- PAM は、多様なアプリケーションで使用できる共通の認証スキームを提供します。
- PAM は、システム管理者に対して、優れた柔軟性と制御性を提供します。
- PAM は、完全に文書化された単一ライブラリーを提供します。開発者は、独自の認証スキームを作成することなくプログラムの作成ができます。
10.1.1. その他の PAM リソース
/usr/share/doc/pam-
version#
/
ディレクトリーには、『システム管理者ガイド』、『モジュールライターのマニュアル』、および 『アプリケーション開発者のマニュアル』、および PAM 標準 DCE-RFC 86.0 のコピーが含まれています。
10.1.2. カスタム PAM モジュール
/usr/share/doc/pam-devel-
version#
/
ディレクトリーに含まれています。
10.2. PAM 設定ファイルについて
/etc/pam.d/
ディレクトリーに ファイルがあります。このディレクトリーの各ファイルは、アクセスを制御するサービスと同じ名前を持ちます。たとえば、 login プログラムはログインとしてサービス名を定義し、/etc/pam.d/login
PAM 設定ファイルをインストールします。
10.2.1. PAM 設定ファイル形式
module_interface control_flag module_name module_arguments
auth required pam_unix.so
- auth: このモジュールインターフェイスはユーザーを認証します。たとえば、パスワードの有効性を要求し、検証します。このインターフェイスを持つモジュールは、グループメンバーシップなどの認証情報を設定することもできます。
- account: このモジュールインターフェイスは、アクセスが許可されていることを確認します。たとえば、ユーザーアカウントの有効期限が切れたか、または特定の時間にユーザーがログインできるかどうかを確認します。
- password: このモジュールインターフェイスは、ユーザーパスワードの変更に使用されます。
- session: このモジュールインターフェイスはユーザーセッションを設定および管理します。このインターフェイスのあるモジュールは、ユーザーのホームディレクトリーをマウントしたり、ユーザーのメールボックスを利用可能にするなど、アクセスを許可するために必要な追加のタスクも実行できます。
pam_unix.so
は 4 つのモジュールインターフェイスをすべて提供します。
libpam
にリンクされているため、ディレクトリー名は省略され、モジュールの正しいバージョンを見つけることができます。
- required: 認証を続行するには、モジュール結果が成功する 必要 があります。この時点でテストが失敗すると、そのインターフェイスを参照するすべてのモジュールテストの結果が完了するまでユーザーには通知されません。
- 必須 - 認証を続行するには、モジュールの結果が正常に実行される必要があります。ただし、この時点でテストが失敗すると、最初に失敗した required また は requisite モジュールテストを反映したメッセージとともに、すぐにユーザーに通知されます。
- sufficient - モジュールが失敗する場合、結果は無視されます。ただし、モジュールフラグ付きの sufficient の結果が成功し、以前のモジュールフラグ付きの required が失敗していない場合は、その他の結果は不要で、ユーザーはサービスに対して認証されます。
- オプション - モジュールの結果は無視されます。他のモジュールがインターフェイスを参照していない場合に、認証を成功させるには、optional としてフラグが付いたモジュールが必要です。
- include: 他の制御とは異なり、モジュールの結果の処理方法とは関係ありません。このフラグは、指定のパラメーターに一致する設定ファイルのすべての行でプルし、それらをモジュールに引数として追加します。
sufficient
値または requisite
値が使用される場合、モジュールを一覧表示する順序は認証プロセスで重要になります。
[root@MyServer ~]# cat /etc/pam.d/setup auth sufficient pam_rootok.so auth include system-auth account required pam_permit.so session required pam_permit.so
auth sufficient pam_rootok.so
- この行は、UID が 0 であることを確認することで、pam_rootok.so
モジュールを使用して現在のユーザーが root かどうかを確認します。このテストに成功すると、他のモジュールは参照されず、コマンドが実行されます。このテストが失敗すると、次のモジュールが参照されます。auth include system-auth
: この行には、/etc/pam.d/system-auth
モジュールの内容が含まれ、認証のためにこのコンテンツを処理します。account required pam_permit.so
- この行は、pam_permit.so
モジュールを使用して、root ユーザーまたはコンソールにログインしているすべてのユーザーがシステムを再起動します。session required pam_permit.so
- この行はセッション設定に関連します。pam_permit.so
を使用すると、setup
ユーティリティーが失敗しないようにします。
pam_pwquality.so
モジュールはパスワードの強度をチェックし、いくつかの引数を取ることができます。以下の例では、enforce_for_root
は、root ユーザーのパスワードでも強度チェックに合格する必要があることを指定し、retry
は、ユーザーが強力なパスワードを入力する 3 つの機会を受け取ることを定義します。
password requisite pam_pwquality.so enforce_for_root retry=3
journald
サービスに報告します。journald
および関連する journalctl
ツールの使用方法は、システム管理者のガイドを参照し てください。
journald
サービスは Red Hat Enterprise Linux 7.1 で導入されました。以前のバージョンの Red Hat Enterprise Linux では、ほとんどのモジュールはエラーを /var/log/secure
ファイルに報告します。
10.2.2. アノテーション付き PAM 設定例
例10.1 シンプルな PAM 設定
#%PAM-1.0 auth required pam_securetty.so auth required pam_unix.so nullok auth required pam_nologin.so account required pam_unix.so password required pam_pwquality.so retry=3 password required pam_unix.so shadow nullok use_authtok session required pam_unix.so
- 最初の行はコメントで、行頭のハッシュマーク(#)で示されます。
- 2 行目から 4 行目は、ログイン認証用に 3 つのモジュールをスタックしています。auth required pam_securetty.so - このモジュールは、ユーザーが root としてログインしようとしている 場合 に、そのファイルが存在する 場合 は、ユーザーがログインする TTY が
/etc/securetty
ファイルに一覧表示されます。TTY がファイルに記載されていない場合は、root でログインしようとすると、Login incorrect
メッセージを表示して失敗します。auth required pam_unix.so nullok - このモジュールはユーザーにパスワードを要求し、/etc/passwd
に保存されている情報を使用してパスワードをチェックし、存在する場合は/etc/shadow
。引数は、pam_unix.so
モジュールに空のパスワードを許可するように nullok に指示します。 - auth required pam_nologin.so - これは、認証の最終ステップです。
/etc/nologin
ファイルが存在するかどうかを確認します。ユーザーが存在して root でない場合は、認証に失敗します。注記この例では、最初の auth モジュールが失敗しても、3 つの auth モジュールがすべてチェックされます。これにより、ユーザーは認証に失敗したステージを把握できません。攻撃者のこのような知識により、システムのクラッキング方法がより簡単に推測される可能性があります。 - account required pam_unix.so - このモジュールは、必要なアカウントの検証を実行します。たとえば、シャドウパスワードが有効になっている場合、
pam_unix.so
モジュールのアカウントインターフェイスは、アカウントの有効期限が切れたかどうか、または許可された猶予期間内にユーザーがパスワードを変更していないかどうかを確認します。 - password required pam_pwquality.so retry=3 - パスワードの有効期限が切れると、
pam_pwquality.so
モジュールのパスワードコンポーネントは新しいパスワードを要求します。その後、新たに作成されたパスワードをテストして、辞書ベースのパスワードクラッキングプログラムで簡単に判別できるかどうかを確認します。引数 retry=3 は、テストが初めて失敗すると、強力なパスワードを作成する可能性が 2 つあります。 - password required pam_unix.so shadow nullok use_authtok - この行は、
pam_unix.so
モジュールの password インターフェイスを使用して、プログラムがユーザーの パスワード を変更するかどうかを指定します。- 引数 shadow は、ユーザーのパスワードを更新する際にシャドウパスワードを作成するようモジュールに指示します。
- 引数 nullok は、ユーザーが空のパスワード から パスワードを変更できるようにするようにモジュールに指示します。それ以外の場合は、null パスワードはアカウントロックとして扱われます。
- この行の最後の引数 use_authtok は、PAM モジュールをスタックする際の順序の重要性の例を提供します。この引数は、ユーザーに新しいパスワードを要求しないようにモジュールに指示します。代わりに、以前のパスワードモジュールで記録されたパスワードを受け入れます。このようにして、新しいパスワードはすべて、受け入れられる前に、安全なパスワードについて
pam_pwquality.so
テストを渡す必要があります。
- session required pam_unix.so - 最後の行は、
pam_unix.so
モジュールのセッションインターフェイスにセッションを管理します。このモジュールは、各セッションの開始と終了時に、ユーザー名とサービスタイプを/var/log/secure
に記録します。このモジュールは、追加機能のために他のセッションモジュールとスタックすることで補足できます。
10.3. PAM と管理認証情報のキャッシング
control-center
など、Red Hat Enterprise Linux の多くのグラフィカル管理ツールは、pam_timestamp.so
モジュールを使用して最大 5 分間ユーザーに昇格された特権を提供します。このメカニズムの仕組みを理解することが重要です。これは、pam_timestamp.so
が有効であるときに端末から離れたユーザーが、コンソールに物理的にアクセスできるユーザーによってマシンを開いたままにするためです。
pam_timestamp.so
モジュールはタイムスタンプファイルを作成します。デフォルトでは、これは /var/run/sudo/
ディレクトリーに作成されます。タイムスタンプファイルがすでに存在する場合は、グラフィカル管理プログラムではパスワードの入力が求められません。代わりに、pam_timestamp.so
モジュールはタイムスタンプファイルを最新の状態にし、ユーザーの不完全な管理アクセスを 5 分追加で保持します。
/var/run/sudo/
ユーザー ディレクトリーのファイルを確認して、タイムスタンプファイルの実際の状態を確認できます。デスクトップでは、関連するファイルは unknown:root
です。これが存在し、タイムスタンプが 5 分未満の場合は、認証情報が有効です。
図10.1 認証アイコン
[D]
10.3.1. 一般的な pam_timestamp ディレクティブ
pam_timestamp.so
モジュールは、以下の 2 つのインターフェイスを提供します。
- auth
- session
pam_timestamp.so
では、以下のオプションを利用できます。
- timestamp_timeout: タイムスタンプファイルの有効期間(秒単位)を指定します。デフォルトは 300 (5 分)です。
- timestampdir: タイムスタンプファイルを保存するディレクトリーを指定します。デフォルトは /var/run/sudo/ です。
- 詳細メッセージには verbose または debug を使用することもできます。
auth sufficient pam_timestamp.so timestamp_timeout=600 session optional pam_timestamp.so
pam_timestamp (8)
man ページと pam.conf (5
)の man ページも参照してください。
10.3.2. タイムスタンプファイルの削除
図10.2 認証ダイアログを閉じる
[D]
- ssh を使用してシステムにリモートでログインしている場合は、/sbin/pam_timestamp_check -k root コマンドを使用してタイムスタンプファイルを破棄します。
- 特権アプリケーションが起動されたものと同じターミナルウィンドウから /sbin/pam_timestamp_check -k root コマンドを実行します。
pam_timestamp.so
モジュールを最初に起動したログイン済みユーザーは、/sbin/pam_timestamp_check -k コマンドを実行するユーザーである必要があります。このコマンドは、root で実行しないでください。- アイコン上の /sbin/pam_timestamp_check コマンドを使用します。アクションを使用せずにデスクトップで認証情報を強制終了するには、
/sbin/pam_timestamp_check -k root </dev/null >/dev/null 2>/dev/null
他の方法は、コマンドが実行される PTY から認証情報を削除するだけです。
pam_timestamp_check
を使用してタイムスタンプファイルを破棄する方法は、pam_timestamp_check の man ページを参照してください。
10.4. PAM サービスのドメイン制限
pam_ldap
などのレガシー PAM モジュールと似ていますが、個別の設定ファイルを PAM モジュールのパラメーターとして使用できました。
ドメインへのアクセスを制限するオプション
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 設定ファイルの
domains
- このオプションは、PAM サービスが認証できるドメインの一覧を指定します。ドメインを指定せずに
domains
を使用する場合、PAM サービスはドメインに対して認証できなくなります。auth required pam_sss.so domains=
ドメイン
が PAM 設定ファイルで使用されていない場合、PAM サービスは、サービスが信頼できるユーザーで実行している条件で、すべてのドメインに対して認証できます。/etc/sssd/sssd.conf
SSSD 設定ファイルのdomains
オプションは、SSSD が認証を試行するドメインの一覧も指定します。PAM 設定ファイルのdomains
オプションは、sssd.conf
のドメイン一覧を拡張することができないことに注意してください。短いリストを指定することで、ドメインのsssd.conf
リストを制限することしかできません。したがって、ドメインが PAM ファイルで指定され、sssd.conf
で指定されていない場合、PAM サービスはドメインに対して認証できなくなります。
pam_trusted_users = all
および pam_public_domains = none
は、すべての PAM サービスユーザーが信頼され、任意のドメインにアクセスできることを示しています。この場合、PAM 設定ファイルの domains
オプションを使用して、アクセスできるドメインを制限することができます。
sssd.conf
に pam_public_ domains
が含まれているときに PAM 設定ファイルでドメインを使用してドメインを指定する場合は、pam_public_domains
でもドメインを指定する必要がある場合があります。pam_public_domains
が使用されていても、必要なドメインが含まれていない場合、PAM サービスは信頼できないユーザーで実行していると、ドメインに対して正常に認証できなくなります。
pam_trusted_users
オプションおよび pam_public_domains
オプションの詳細は、sssd.conf(5) の man ページを参照してください。PAM 設定ファイルで使用される domains
オプションの詳細は、pam_sss(8) の man ページを参照してください。
例10.2 PAM サービスのドメインの制限
- 必要なドメインにアクセスするように SSSD が設定されていることを確認してください。SSSD が認証できるドメインは、
/etc/sssd/sssd.conf
ファイルのdomains
オプションで定義されます。[sssd] domains = domain1, domain2, domain3
- PAM サービスが認証できるドメインを指定します。これには、PAM 設定ファイルに
domains
オプションを設定します。以下に例を示します。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
に対してのみ認証できるようになりました。
第11章 Kerberos の使用
11.1. Kerberos について
11.1.1. Kerberos の仕組みの基本
図11.1 Kerberos 認証
- Red Hat Enterprise Linux 7 のデフォルトのキャッシュである KEYRING ccache タイプ
- System Security Services Daemon (SSSD) Kerberos Credential Manager (KCM) (Red Hat Enterprise Linux 7.4 の代替オプション)
- FILE
- DIR
- MEMORY
kinit
などのアプリケーションによって通常使用される Kerberos ライブラリーは KCM クライアントであり、デーモンは KCM サーバーと呼ばれます。
- デーモンはステートフルであり、Kerberos 認証情報キャッシュの更新や古い ccache の取得などのタスクを実行できます。更新と追跡は、SSSD 自体が取得したチケット(通常は
pam_sss.so
を介したログインを介して)や、kinit などで取得したチケットに対しても可能となります。 - プロセスはユーザースペースで実行されるため、カーネル KEYRING とは異なり、UID 名前空間の影響を受けます。
- 呼び出し元の UID に完全に依存し、コンテナー化された環境ではすべてのコンテナー間で共有されるカーネル KEYRING ベースのキャッシュとは異なり、KCM サーバーのエントリーポイントは、選択したコンテナーにのみバインドマウントできる UNIX ソケットです。
11.1.2. Kerberos プリンシパル名について
identifier@REALM
service/FQDN@REALM
sshd
デーモンはホストサービスプリンシパルを使用します。
/etc/krb5.keytab
に保存されます。
www.example.com CNAME web-01.example.com web-01.example.com A 192.0.2.145
$ ssh www.example.com
11.1.3. ドメインからレルムへのマッピング
foo.example.org → EXAMPLE.ORG foo.example.com → EXAMPLE.COM foo.hq.example.com → HQ.EXAMPLE.COM
/etc/krb5.conf
ファイルの domain_realm セクションで指定する必要があります。以下に例を示します。
[domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
$ORIGIN example.com _kerberos TXT "EXAMPLE.COM"
11.1.4. 環境要件
/usr/share/doc/krb5-server-version- number
の Kerberos ドキュメントで説明されています。
ntpd
サービスの詳細は、/usr/share/doc/ntp-
version-number/html/index.html
または ntpd(8) の man ページを参照してください。
11.1.5. Kerberos 導入における考慮点
- Kerberos は、各ユーザーが信頼されていて、信頼できないネットワーク上で信頼できないホストを使用していることを前提としています。その主な目的は、暗号化されていないパスワードがそのネットワーク上で送信されないようにすることです。ただし、認証に使用されるチケットを発行するホスト (KDC) に適切なユーザー以外のユーザーがアクセスすると、Kerberos 認証システム全体が危険にさらされます。
- アプリケーションが Kerberos を使用するには、そのソースを変更して Kerberos ライブラリーに適切な呼び出しを行う必要があります。この方法で変更したアプリケーションは、Kerberos 対応 として考慮されます。アプリケーションによっては、アプリケーションのサイズや設計により、非常に問題になる場合があります。その他の互換性のないアプリケーションでは、サーバーとクライアントが通信する方法に変更を加える必要があります。ここでも、大幅なプログラミングが必要になる場合があります。デフォルトでは Kerberos サポートのないクローズソースアプリケーションは、多くの場合最も問題となります。
- Kerberos でネットワークの安全を図るには、暗号化されていないパスワードを送信する すべての クライアントアプリケーションおよびサーバーアプリケーションのバージョンで Kerberos 対応のものを使用するか、そのようなクライアントアプリケーションおよびサーバーアプリケーションをまったく使用しないかのどちらかにする必要があります。
/etc/passwd
や/etc/shadow
などの標準の UNIX パスワードデータベースから Kerberos パスワードデータベースにユーザーパスワードを移行するのは面倒です。このタスクを実行する自動メカニズムはありません。移行方法は、Kerberos のデプロイ方法によって大きく異なる可能性があります。このため、Identity Management 機能を使用することが推奨されます。これには、移行用の特別なツールおよびメソッドがあります。
11.1.6. Kerberos に関するその他のリソース
資料 | 場所 |
---|---|
Kerberos V5 Installation Guide (PostScript と HTML の両方) | /usr/share/doc/krb5-server-version-number |
Kerberos V5 System Administrator's Guide (PostScript と HTML の両方) | /usr/share/doc/krb5-server-version-number |
Kerberos V5 UNIX User's Guide (PostScript と HTML の両方) | /usr/share/doc/krb5-workstation-version-number |
Kerberos: The Network Authentication Protocol (MIT のウェブページ) | http://web.mit.edu/kerberos/www/ |
『Designing an Authentication System: a Dialogue in Four Scenes』。原板は Bill Bryant により 1988 年にリリースされ、1997 年に Theodore Ts'o によって改訂されています。本書は、Kerberos スタイルの認証システムの作成を考慮している 2 人の開発者の会話を表しています。この対話形式のディスカッションを参照することで、Kerberos に完全に精通していない人にとって、良い開始地点となります。 | http://web.mit.edu/kerberos/www/dialogue.html |
ネットワーク Kerberos に対応するための記事。 | http://www.ornl.gov/~jar/HowToKerb.html |
man ページ | 説明 |
---|---|
クライアントアプリケーション | |
Kerberos | Kerberos システムの概要では、認証情報がどのように機能するかを説明し、Kerberos チケットの取得および破棄に関する推奨事項を提供します。man ページの下部では、関連する man ページが多数参照されています。 |
kinit | このコマンドを使用して ticket-granting ticket を取得、キャッシュする方法が説明されています。 |
kdestroy | このコマンドを使用して Kerberos 認証情報を破棄する方法が説明されています。 |
klist | このコマンドを使用して、キャッシュされた Kerberos 認証情報を一覧表示する方法が説明されています。 |
管理アプリケーション | |
kadmin | このコマンドを使用して Kerberos V5 データベースを管理する方法が説明されています。 |
kdb5_util | このコマンドを使用して Kerberos V5 データベース上で低レベルの管理機能を作成、実行する方法が説明されています。 |
サーバーアプリケーション | |
krb5kdc | Kerberos V5 KDC に利用可能なコマンドラインオプションが説明されています。 |
kadmind | Kerberos V5 管理サーバー に利用可能なコマンドラインオプションが説明されています。 |
設定ファイル | |
krb5.conf | Kerberos V5 ライブラリー用の設定ファイル内で利用可能な形式とオプションを説明しています。 |
kdc.conf | Kerberos V5 AS および KDC 用の設定ファイル内で利用可能な形式とオプションを説明しています。 |
11.2. Kerberos KDC の設定
11.2.1. マスター KDC サーバーの設定
- KDC に必要なパッケージをインストールします。
[root@server ~]# yum install krb5-server krb5-libs krb5-workstation
/etc/krb5.conf
および/var/kerberos/krb5kdc/kdc.conf
設定ファイルを編集して、レルム名とドメインからレルムへのマッピングを反映します。以下に例を示します。[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true allow_weak_crypto = true [realms] EXAMPLE.COM = { kdc = kdc.example.com.:88 admin_server = kdc.example.com default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
シンプルなレルムは、EXAMPLE.COM と example.com のインスタンスを正しいドメイン名で置き換えることで設定できます。これは、正しい形式で大文字と小文字の名前を維持することが確実にでき、KDC を kerberos.example.com から Kerberos サーバーの名前に変更することで設定できます。通常、レルム名はすべて大文字で、DNS ホスト名およびドメイン名はすべて小文字になります。これらの設定ファイルの man ページには、ファイル形式に関する詳細が記載されています。- kdb5_util ユーティリティーを使用してデータベースを作成します。
[root@server ~]# kdb5_util create -s
create コマンドは、Kerberos レルムのキーを保存するデータベースを作成します。-s 引数は、マスターサーバーキーが保存される stash ファイルを作成します。キーの読み取り元となる stash ファイルがない場合、Kerberos サーバー(krb5kdc)は起動時に毎回マスターサーバーパスワード(キーを再生成するために使用できる)を要求します。 /var/kerberos/krb5kdc/kadm5.acl
ファイルを編集します。このファイルは、Kerberos データベースへの管理アクセス権とそのアクセスレベルを決定するために kadmind によって使用されます。以下に例を示します。*/admin@EXAMPLE.COM *
多くのユーザーは、データベース内で単一のプリンシパルで表されます (joe@EXAMPLE.COM などの NULL または空のインスタンス)。この設定では、admin (例: joe/admin@EXAMPLE.COM) のインスタンスを持つ 2 番目のプリンシパルを持つユーザーは、レルムの Kerberos データベースに対する完全な管理制御を強化できます。kadmind がサーバーで起動した後、ユーザーはレルム内のいずれかのクライアントまたはサーバーで kadmin を実行してサービスにアクセスできます。ただし、kadm5.acl
ファイルにリストされているユーザーのみが、自身のパスワードを変更することを除いて、いつでもデータベースを変更できます。注記kadmin ユーティリティーはネットワーク経由で kadmind サーバーと通信し、Kerberos を使用して認証を処理します。したがって、ネットワーク経由でサーバーに接続してサーバーを管理するには、最初のプリンシパルがすでに存在している必要があります。kadmin.local コマンドを使用して最初のプリンシパルを作成します。これは、KDC と同じホストで使用するように特別に設計されており、認証に Kerberos を使用しません。- KDC 端末で kadmin.local を使用して最初のプリンシパルを作成します。
[root@server ~]# kadmin.local -q "addprinc username/admin"
- 以下のコマンドを使用して Kerberos を起動します。
[root@server ~]# systemctl start krb5kdc.service [root@server ~]# systemctl start kadmin.service
- kadmin 内で addprinc コマンドを使用してユーザーのプリンシパルを追加します。kadmin および kadmin.local は、KDC へのコマンドラインインターフェイスです。そのため、addprinc などの多くのコマンドは、kadmin プログラムの起動後に利用できます。詳細は、kadmin の man ページを参照してください。
- KDC がチケットを発行していることを確認します。まず、kinit を実行してチケットを取得し、認証情報キャッシュファイルに保存します。次に、klist を使用してキャッシュ内の認証情報の一覧を表示し、kdestroy を使用してキャッシュと含まれる認証情報を破棄します。注記デフォルトでは、kinit は、(Kerberos サーバーではなく)同じシステムログインユーザー名を使用して認証を試みます。ユーザー名が Kerberos データベースのプリンシパルに対応しない場合は、kinit がエラーメッセージを発行します。その場合は、コマンドラインの引数として、正しいプリンシパルの名前で kinit を指定します。
kinit principal
11.2.2. セカンダリー KDC の設定
- KDC に必要なパッケージをインストールします。
[root@slavekdc ~]# yum install krb5-server krb5-libs krb5-workstation
- マスター KDC の
krb5.conf および
ファイルをセカンダリー KDC にコピーします。kdc.conf
- マスター KDC の root シェルから kadmin.local を起動します。
- kadmin.local add_principal コマンドを使用して、マスター KDC の host サービスの新規エントリーを作成します。
[root@masterkdc ~]# kadmin.local -r EXAMPLE.COM Authenticating as principal root/admin@EXAMPLE.COM with password. kadmin: add_principal -randkey host/masterkdc.example.com Principal "host/masterkdc.example.com@EXAMPLE.COM" created. kadmin: ktadd host/masterkdc.example.com Entry for principal host/masterkdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab. kadmin: quit
- kadmin.local ktadd コマンドを使用してサービスにランダムにキーを設定し、その鍵をマスターのデフォルト keytab ファイルに保存します。注記このキーは、kprop コマンドがセカンダリーサーバーに認証するために使用されます。インストールするセカンダリー KDC サーバーの数にかかわらず、これは一度だけ実行する必要があります。
- セカンダリー KDC で root シェルから kadmin を起動します。
- kadmin.local add_principal コマンドを使用して、セカンダリー KDC の host サービスの新規エントリーを作成します。
[root@slavekdc ~]# kadmin -p jsmith/admin@EXAMPLE.COM -r EXAMPLE.COM Authenticating as principal jsmith/admin@EXAMPLE.COM with password. Password for jsmith/admin@EXAMPLE.COM: kadmin: add_principal -randkey host/slavekdc.example.com Principal "host/slavekdc.example.com@EXAMPLE.COM" created. kadmin: ktadd host/slavekdc.example.com@EXAMPLE.COM Entry for principal host/slavekdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab. kadmin: quit
- kadmin.local ktadd コマンドを使用してサービス用のランダムキーを設定し、ランダムキーをセカンダリー KDC サーバーのデフォルト keytab ファイルに保存します。このキーは、クライアントの認証時に kpropd サービスによって使用されます。
- セカンダリー KDC はサービスキーを使用して、接続するクライアントをすべて認証できます。すべてのクライアントが新しいレルムデータベースで kprop サービスを提供することができるわけではありません。アクセスを制限するために、セカンダリー KDC 上の kprop サービスは、プリンシパル名が
/var/kerberos/krb5kdc/kpropd.acl
に記載されているクライアントからの更新のみを受け入れます。マスター KDC のホストサービス名をこのファイルに追加します。[root@slavekdc ~]# echo host/masterkdc.example.com@EXAMPLE.COM > /var/kerberos/krb5kdc/kpropd.acl
- セカンダリー KDC がデータベースのコピーを取得したら、暗号化に使用したマスターキーも必要になります。KDC データベースのマスターキーがマスター KDC の stash ファイルに保存されている場合(通常は
/var/kerberos/krb5kdc/.k5.REALM
)、利用可能な安全な方法を使用してセカンダリー KDC にコピーするか、kdb5_util create を実行して同じパスワードを指定して、セカンダリー KDC にダミーデータベースと同一の stash ファイルを作成します。ダミーデータベースは、最初に成功したデータベースの伝播によって上書きされます。 - セカンダリー KDC のファイアウォールで、マスター KDC がポート 754 (krb5_prop)で TCP を使用して接続し、kprop サービスを起動します。
- kadmin サービスが を 無効 にしていることを確認します。
- マスター KDC のレルムデータベースを、kprop コマンドが読み取るデフォルトのデータファイル(
/var/kerberos/krb5kdc/slave_datatrans
)にダンプして、手動でデータベース伝搬テストを実行します。[root@masterkdc ~]# kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans
- kprop コマンドを使用して、そのコンテンツをセカンダリー KDC に送信します。
[root@masterkdc ~]# kprop slavekdc.example.com
- kinit を使用して、クライアントシステムが KDC から正しく初期認証情報を取得できることを確認します。クライアントの
/etc/krb5.conf
は、KDC の一覧のセカンダリー KDC のみを一覧表示する必要があります。[realms] EXAMPLE.COM = {
kdc = slavekdc.example.com.:88
admin_server = kdc.example.com default_domain = example.com } - レルムデータベースをダンプし、kprop コマンドを実行してデータベースを各セカンダリー KDC に送信するスクリプトを作成し、cron サービスがスクリプトを定期的に実行するように設定します。
11.2.3. Kerberos キー配布センタープロキシー
HTTPS
ポート 443 経由で Kerberos と通信するプロキシーとして HTTPS
サービスを使用できます。
KKDCP サーバー
/etc/httpd/conf.d/ipa-kdc-proxy.conf
が作成されます。したがって、シンボリックリンクが存在することを確認することで、IdM サーバーで KKDCP が有効になっていることを確認できます。
$ ls -l /etc/httpd/conf.d/ipa-kdc-proxy.conf lrwxrwxrwx. 1 root root 36 Aug 15 09:37 /etc/httpd/conf.d/ipa-kdc-proxy.conf -> /etc/ipa/kdcproxy/ipa-kdc-proxy.conf
例11.1 KKDCP サーバー I の設定
/etc/ipa/kdcproxy/kdcproxy.conf
ファイルで、[global] セクションのuse_dns
パラメーターを false に設定します。[global] use_dns = false
- プロキシー化されたレルム情報を
/etc/ipa/kdcproxy/kdcproxy.conf
ファイルに配置します。プロキシーを使用する [AD.EXAMPLE.COM] レルムの場合は、たとえば次のようにレルム設定パラメーターを一覧表示します。[AD.EXAMPLE.COM] kerberos = kerberos+tcp://1.2.3.4:88 kerberos+tcp://5.6.7.8:88 kpasswd = kpasswd+tcp://1.2.3.4:464 kpasswd+tcp://5.6.7.8:464
重要レルム設定パラメーターは、特定のオプションを複数回指定する可能性がある/etc/krb5.conf および
ではなく、スペースで区切られた複数のサーバーをリストする必要があります。kdc.conf
- IdM サービスを再起動します。
# ipactl restart
例11.2 KKDCP サーバー II の設定
/etc/ipa/kdcproxy/kdcproxy.conf
ファイルの [global] セクションで、use_dns
パラメーターを true に設定します。[global] configs = mit use_dns = true
configs
パラメーターを使用すると、他の設定モジュールをロードできます。この場合、設定は MITlibkrb5
ライブラリーから読み込まれます。- オプション: DNS サービスレコードを使用しない場合は、明示的な AD サーバーを
/etc/krb5.conf
ファイルの [realms] セクションに追加します。たとえば、プロキシーを使用するレルムが AD.EXAMPLE.COM の場合は、以下を追加します。[realms] AD.EXAMPLE.COM = { kdc = ad-server.ad.example.com kpasswd_server = ad-server.ad.example.com }
- IdM サービスを再起動します。
# ipactl restart
KKDCP クライアント
/etc/krb5.conf
ファイルを介してポイントします。この手順に従って、AD サーバーに到達します。
- クライアントで
/etc/krb5.conf
ファイルを開き、AD レルムの名前を [realms] セクションに追加します。[realms] AD.EXAMPLE.COM { kdc = https://ipa-server.example.com/KdcProxy kdc = https://ipa-server2.example.com/KdcProxy kpasswd_server = https://ipa-server.example.com/KdcProxy kpasswd_server = https://ipa-server2.example.com/KdcProxy }
/etc/sssd/sssd.conf
ファイルを開き、krb5_use_kdcinfo = False 行を IdM ドメインセクションに追加します。[domain/example.com] krb5_use_kdcinfo = False
SSSD
サービスを再起動します。# systemctl restart sssd.service
関連情報
- Active Directory レルムの KKDCP の設定に関する詳細は、Red Hat ナレッジベースのConfigure IPA server as a KDC Proxy for AD Kerberos communicationを参照してください。
11.3. Kerberos クライアントの設定
krb5.conf
設定ファイルを指定することです。ssh および slogin は、クライアントシステムにリモートでログインする方法が推奨されますが、Kerberos 対応のバージョンの rsh および rlogin は引き続き利用でき、追加の設定変更が可能です。
- すべてのクライアントマシン
に krb5-libs
パッケージおよびkrb5-workstation
パッケージをインストールします。[root@server ~]# yum install krb5-workstation krb5-libs
- 各クライアントに有効な
/etc/krb5.conf
ファイルを指定します。通常、これは Kerberos Distribution Center (KDC)が使用する同じkrb5.conf
ファイルになります。以下に例を示します。[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true allow_weak_crypto = true [realms] EXAMPLE.COM = { kdc = kdc.example.com.:88 admin_server = kdc.example.com default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
一部の環境では、KDC は HTTPS Kerberos Key Distribution Center Proxy (KKDCP) を使用してのみアクセスできます。この場合は、以下の変更を加えます。- ホスト名の代わりに KKDCP の URL を [realms] セクションの kdc オプションおよび admin_server オプションに割り当てます。
[realms] EXAMPLE.COM = { kdc = https://kdc.example.com/KdcProxy admin_server = https://kdc.example.com/KdcProxy kpasswd_server = https://kdc.example.com/KdcProxy default_domain = example.com }
冗長性を確保するために、パラメーターkdc
、admin_server
、およびkpasswd_server
は、異なる KKDCP サーバーを使用して複数回追加できます。 - IdM クライアントで sssd サービスを再起動して、変更を適用します。
[root@server ~]# systemctl restart sssd
- Kerberos 対応の rsh および rlogin サービスを使用するには、
rsh
パッケージをインストールします。 - ワークステーションが Kerberos を使用して、ssh、rsh、または rlogin を使用して接続するユーザーを認証する前に、Kerberos データベースに独自のホストプリンシパルが必要です。sshd、kshd、および klogind サーバープログラムはすべて、ホストサービスのプリンシパルのキーへのアクセスが必要になります。
- kadmin を使用して、KDC 上のワークステーションのホストプリンシパルを追加します。この場合のインスタンスはワークステーションのホスト名です。kadmin のaddprinc コマンドに -randkey オプションを使用してプリンシパルを作成し、ランダムなキーを割り当てます。
addprinc -randkey host/server.example.com
- ワークステーション 自体で kadmin を実行し、ktadd コマンドを使用すると、鍵をワークステーション 用に抽出できます。
ktadd -k /etc/krb5.keytab host/server.example.com
- その他の Kerberos 対応ネットワークサービスを使用するには、krb5-server パッケージをインストールしてサービスを起動します。Kerberos 対応のサービスは、表11.3「一般的な Kerberos 対応のサービス」 に一覧表示されます。
サービス名 | 使用方法 |
---|---|
ssh | クライアントとサーバー両方の設定で GSSAPIAuthentication が有効な場合に、OpenSSH は GSS-API を使用してサーバーにユーザーを認証します。クライアントでも GSSAPIDelegateCredentials が有効な場合は、ユーザーの認証情報がリモートシステムで利用可能になります。OpenSSH には sftp ツールも含まれています。このツールは SFTP サーバーに FTP のようなインターフェイスを提供し、GSS-API を使用できます。 |
IMAP | cyrus-imap パッケージもインストールされている場合、cyrus-sasl-gssapi パッケージは Kerberos 5 を使用します。cyrus-sasl-gssapi パッケージには、GSS-API 認証をサポートする Cyrus SASL プラグインが含まれています。Cyrus IMAP 関数は、cyrus ユーザーが /etc/krb5.keytab で適切な鍵を見つけ、プリンシパルの root が imap ( kadminで作成した)に設定されている限り Kerberos で適切に機能します。
cyrus-imap の代替は、dovecot パッケージにあります。これは、Red Hat Enterprise Linux にも含まれています。このパッケージには IMAP サーバーが含まれていますが、現在のところ GSS-API および Kerberos には対応していません。
|
11.4. スマートカード用の Kerberos クライアントの設定
- 他のクライアントパッケージと共に、必要となる PKI/OpenSSL パッケージをインストールします。
[root@server ~]# yum install krb5-pkinit [root@server ~]# yum install krb5-workstation krb5-libs
/etc/krb5.conf
設定ファイルを編集して、公開鍵インフラストラクチャー(PKI)のパラメーターを設定の [realms] セクションに追加します。pkinit_anchors
パラメーターは、CA 証明書バンドルファイルの場所を設定します。[realms] EXAMPLE.COM = { kdc = kdc.example.com.:88 admin_server = kdc.example.com default_domain = example.com ... pkinit_anchors = FILE:/usr/local/example.com.crt }
- スマートカード認証(
/etc/pam.d/smartcard-auth
)とシステム認証(/etc/pam.d/system-auth
)の両方の PAM 設定に PKI モジュール情報を追加します。両方のファイルに追加する行は、以下のとおりです。auth optional pam_krb5.so use_first_pass no_subsequent_prompt preauth_options=X509_user_identity=PKCS11:/usr/lib64/pkcs11/opensc-pkcs11.so
OpenSC モジュールが想定どおりに機能しない場合は、coolkey パッケージの モジュール(/usr/lib64/pkcs11/libcoolkeypk11.so
)を使用します。この場合は、Red Hat テクニカルサポートへの問い合わせ、または問題に関する Bugzilla レポートの作成を検討してください。
11.5. クロスレルムの Kerberos 信頼の設定
11.5.1. 信頼関係
図11.2 基本的な信頼
- 両方のレルムに存在します。
- キーが作成されると、同じパスワードが両方のレルムで使用されます。
- キーには、同じキーバージョン番号(
kvno
)があります。
B.EXAMPLE.COM
レルムは A.EXAMPLE.COM
レルムのサービスに対して認証するために信頼されています。反対方向の信頼を確立するには、両方のレルムが krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM
サービスの鍵を共有する必要があります。これは、前述の例とは反対のマッピングのエントリーになります。
図11.3 推移的な信頼
/etc/krb5.conf
ファイルの [domain_realm]
セクションを使用します。暗黙的なマッピングでは、ドメイン名が大文字に変換されます。変換された名前は、検索する Kerberos レルムであると想定されます。
図11.4 同じドメインの信頼
図11.5 同じドメインの子/親の信頼
図11.6 異なるドメインの信頼
[capaths]
セクション
/etc/krb5.conf
ファイルの [capaths]
セクションは、異なるレルム間の信頼フローを定義します。
[capaths]
セクションの形式は比較的簡単です。クライアントがプリンシパルを持つ各レルムにメインエントリーがあり、各レルムセクションにはクライアントが認証情報を取得する中間レルムのリストになります。
[capaths]
を使用して認証情報を取得するために以下のプロセスを指定できます。
- レルム A からのクレデンシャルでは、クライアントは Realm A の KDC から
krbtgt/A@A
チケットを取得します。このチケットを使用して、クライアントはkrbtgt/B@A
チケットを要求します。Realm A の KDC が発行するkrbtgt/B@A
チケットは、レルム間のチケット付与チケット です。クライアントは、Realm B の KDC に対してチケットを Realm B のサービスプリンシパルに要求できます。 krbtgt/B@A
チケットを使用すると、クライアントはkrbtgt/C@B
クロスレルムチケットを要求します。- Realm B の KDC が発行する
krbtgt/C@B
チケットを使用すると、クライアントはkrbtgt/D@C
クロスレルムチケットを要求します。 - Realm C の KDC が発行する
krbtgt/D@C
チケットを使用すると、クライアントは Realm D の KDC にレルム D のサービスプリンシパルへのチケットを要求します。
krbtgt/A@A
、krbtgt/B@A
、krbtgt/C@B
、krbtgt/D@C
、および service/hostname@D
のチケットが含まれます。service/hostname@D
チケットを取得するには、3 つの中間レルムチケットを取得する必要があります。
[capaths]
設定の例を含む [capaths]
セクションの詳細は、krb5.conf(5) の man ページを参照してください。
11.5.2. レルム信頼の設定
[root@server ~]# kadmin -r A.EXAMPLE.COM kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created. quit
[root@server ~]# kadmin -r B.EXAMPLE.COM kadmin: add_principal krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM Enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM": Re-enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM": Principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM" created. quit
kvno
の値)と暗号化タイプの両方が一致することを確認します。
-randkey
オプションを使用しようとすることです。データベースダンプに含まれる鍵自体がマスターキーを使用して暗号化されるため、レルムデータベースのマスターキーが同一でない限り動作しません。
第12章 certmonger を使った作業
certmonger
サービスは、アプリケーションの証明書のライフサイクルを管理し、適切に設定されている場合は、認証局(CA)と連携して証明書を更新できます。
certmonger
デーモンとそのコマンドラインクライアントを使うと、公開鍵と秘密鍵のペア生成や証明書リクエストの作成、CA に対する署名のリクエスト提出といった処理を簡素化することができます。certmonger
デーモンは、証明書の有効期限を監視し、有効期限が近づいている証明書を更新できます。certmonger
が監視する証明書はファイルで追跡しており、このファイルは設定可能なディレクトリー内に保存します。デフォルトの場所は /var/lib/certmonger/requests
です。
certmonger
デーモンは証明書を取り消すことができません。証明書は、関連する認証局のみが取り消すことができます。この認証局は、証明書を無効にし、証明書失効リストを更新する必要があります。
12.1. certmonger および認証局
- 自己署名証明書各証明書は証明書独自のキーを使用して署名されるため、自己署名証明書の生成には CA は全く関与しません。自己署名証明書を検証するソフトウェアは、証明書を検証するために、その証明書を直接信頼するように指示する必要があります。自己署名証明書を取得するには、selfsign-getcert コマンドを実行します。
- Red Hat Enterprise Linux IdM の一部として Dogtag Certificate System CA からの証明書IdM サーバーを使用して証明書を取得するには、ipa-getcert コマンドを実行します。
- システムに存在するローカル CA により署名された証明書ローカル署名者が署名した証明書を検証するソフトウェアは、証明書を検証するためにこのローカル署名から証明書を信頼するように指示する必要があります。ローカル署名の証明書を取得するには、local-getcert コマンドを実行します。
12.2. certmonger を使用した自己署名証明書の要求
certmonger
で証明書を要求するには、getcert request ユーティリティーを使用します。
.pem
拡張子または NSS データベースを持つプレーンテキストファイルにローカルに保存されます。証明書をリクエストする際には、リクエストで証明書の保存場所とニックネームを特定します。以下に例を示します。
[root@server ~]# selfsign-getcert request -d /etc/pki/nssdb -n Server-Cert
/etc/pki/nssdb
ファイルはグローバル NSS データベースで、Server-Cert
はこの証明書のニックネームです。証明書のニックネームはこのデータベース内で一意のものである必要があります。
-r
は、キーペアがすでに存在する場合に失効日が近づくと証明書を自動的に更新します。このオプションはデフォルトで使用されます。-f
は、指定したファイルに証明書を保存します。-k
は、鍵を特定ファイルに保存するか、鍵のファイルが存在する場合は、ファイル内の鍵を使用します。-K
は、証明書を使用するサービスの Kerberos プリンシパル名を指定します。-K
は、IdM サーバーから証明書を要求する際に必要であり、自己署名の証明書またはローカルで署名された証明書を要求する場合は任意になります。-N
はサブジェクト名を指定します。-d
は、DNS ドメイン名をsubjectAltName
値として証明書に含めるよう要求します。-u
は、拡張キー使用フラグを設定します。-A
は、subjectAltName
値として証明書に含まれる IP アドレスを要求します。-I
はタスクの名前を設定します。certmonger
はこの名前を使用して、ストレージの場所と要求オプションの組み合わせを参照し、getcert list コマンドの出力にも表示されます。このオプションを指定しないと、certmonger
はタスクに自動生成された名前を割り当てます。
-K
、-N
、-D
、-U
、および -A
オプションを使用して署名要求で指定したものをすべて無視できます。たとえば、IdM では、-K
と -N
がローカルホスト名に合意する必要があります。selfsign-getcert コマンドおよび local-getcert コマンドを使用して生成される証明書は、ポリシーを強制しないため、指定するオプションに同意します。
例12.1 サービスにおける certmonger の使用
[root@server ~]# selfsign-getcert request -f /etc/httpd/conf/ssl.crt/server.crt -k /etc/httpd/conf/ssl.key/server.key -N CN=`hostname --fqdn` -D `hostname` -U id-kp-serverAuth
12.3. SCEP 経由での CA 署名証明書の要求
certmonger
に追加し、新しい証明書を要求し、ローカルの NSS データベースに追加します。
- CA 設定を
certmonger
に追加します。[root@server ~]# getcert add-scep-ca -c CA_Name -u SCEP_URL
- -c: CA 設定に必要なニックネーム。後で同じ値を他の getcert コマンドに渡すことができます。
- -u: サーバーの SCEP インターフェイスへの URL。
- HTTPS URL を使用する場合は必須のパラメーターです。-R CA_Filename: HTTPS 暗号化に使用される SCEP サーバーの CA 証明書の PEM 形式のコピーの場所。
- CA 設定が正常に追加されたことを確認します。
[root@server ~]# getcert list-cas -c CA_Name CA 'CA_Name': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/scep-submit -u http://SCEP_server_enrollment_interface_URL SCEP CA certificate thumbprint (MD5): A67C2D4B 771AC186 FCCA654A 5E55AAF7 SCEP CA certificate thumbprint (SHA1): FBFF096C 6455E8E9 BD55F4A5 5787C43F 1F512279
CA 証明書のサムプリントが SCEP で取得され、コマンドの出力に表示される際に、CA 設定が正常に追加されました。暗号化されていない HTTP でサーバーにアクセスすると、中間者攻撃を防ぐため、サムプリントを SCEP サーバーに表示されるものと手動で比較します。 - CA から証明書を要求します。
[root@server ~]# getcert request -I Task_Name -c CA_Name -d /etc/pki/nssdb -n Certificate_Name -N cn="Subject Name" -L one-time_PIN
- -i: タスクの名前。後で同じ値を getcert list コマンドに渡すことができます。
- -c: 要求を送信する CA 設定。
- -d: 証明書とキーを格納するための NSS データベースを備えたディレクトリー。
- -n: NSS データベースで使用される証明書のニックネーム。
- -n: CSR のサブジェクト名。
- -l: CA が発行する Time-time PIN。
- 要求の送信直後に、証明書が発行され、ローカルデータベースに正しく保存されていることを確認します。
[root@server ~]# getcert list -I TaskName Request ID 'Task_Name': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='TestCert',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='TestCert',token='NSS Certificate DB' signing request thumbprint (MD5): 503A8EDD DE2BE17E 5BAA3A57 D68C9C1B signing request thumbprint (SHA1): B411ECE4 D45B883A 75A6F14D 7E3037F1 D53625F4 CA: AD-Name issuer: CN=windows-CA,DC=ad,DC=example,DC=com subject: CN=Test Certificate expires: 2018-05-06 10:28:06 UTC key usage: digitalSignature,keyEncipherment eku: iso.org.dod.internet.security.mechanisms.8.2.2 certificate template/profile: IPSECIntermediateOffline pre-save command: post-save command: track: yes auto-renew: yes
ステータス MONITORING は、発行した証明書の取得に成功したことを表します。getcert-list (1) の man ページには、他の可能な状態とその意味が一覧表示されます。
12.4. NSS データベースでの証明書の保存
.pem
ファイルを使用して鍵と証明書を保存します。鍵と証明書を NSS データベースに保存するには、証明書の要求に使用するコマンドで-d
および -n
を指定します。
-d
はセキュリティーデータベースの場所を設定します。-n
は、NSS データベースの証明書に使用される証明書のニックネームを指定します。
.pem
ファイルを提供する -f
オプションおよび -k
オプションの代わりに、-d
オプションおよび -n
オプションが使用されます。
[root@server ~]# selfsign-getcert request -d /export/alias -n ServerCert ...
-F
は、CA の証明書を保存するファイルを指定します。-a
は、CA の証明書が保存される NSS データベースの場所を指定します。
-F
オプションおよび -a
オプションを指定する必要はありません。
-F
オプション、-a
オプション、または local-getcert の両方を指定すると、ローカル署名者が発行した証明書を検証するために必要な CA 証明書のコピーを取得できます。以下に例を示します。
[root@server ~]# local-getcert request -F /etc/httpd/conf/ssl.crt/ca.crt -n ServerCert -f /etc/httpd/conf/ssl.crt/server.crt -k /etc/httpd/conf/ssl.key/server.key
12.5. certmonger を使った証明書の追跡
certmonger
に手動で指示する必要があります。
-r
は、キーペアがすでに存在する場合に失効日が近づくと証明書を自動的に更新します。このオプションはデフォルトで使用されます。-I
は、追跡要求の名前を設定します。certmonger
はこの名前を使用して、ストレージの場所と要求オプションの組み合わせを参照し、getcert list コマンドの出力にも表示されます。このオプションを指定しないと、certmonger
はタスクの名前を自動的に生成します。
[root@server ~]# getcert start-tracking -I cert1-tracker -d /export/alias -n ServerCert
第13章 アプリケーションをシングルサインオン向けに設定
13.1. Firefox でシングルサインオンに Kerberos を使用する設定
[jsmith@host ~] $ kinit Password for jsmith@EXAMPLE.COM:
- Firefox のアドレスバーに、
about:config
と入力して現在の設定オプションの一覧を表示します。 - Filter フィールドに、オプションのリストを制限するために
negotiate
と入力します。 - network.negotiate-auth.trusted-uris エントリーをダブルクリックします。
- 先行ピリオド (.) を含む、認証に使用するドメイン名を入力します。複数のドメインを追加する場合は、コンマ区切りのリストを入力します。
図13.1 Firefox の手動設定
13.2. Firefox での証明書管理
- Mozilla Firefox で Firefox メニューを開き、をクリックします。
図13.2 Firefox の設定
- Advanced セクションを開き、Certificates タブを選択します。
図13.3 Firefox の証明書タブ
- Certificate Manager を開きます。をクリックして、
- CA 証明書をダウンロードし、コンピューターに保存します。
- Certificate Manager で Authorities タブを選択し、 をクリックします。
図13.4 Firefox での CA 証明書のインポート
- ダウンロードした CA 証明書を選択します。
- Certificate Manager の Authorities タブで、適切な証明書を選択し、 をクリックします。
- 証明書トラスト設定を編集します。
図13.5 Firefox での証明書トラスト設定の編集
- Certificate Manager の Your Certificates タブで、 をクリックします。
図13.6 Firefox での認証用の個人証明書のインポート
- お使いのコンピューターから必要な証明書を選択します。
13.3. メールクライアントの証明書管理
- Mozilla Thunderbird で、Thunderbird のメインメニューを開き、Preferences → Account Settings の順に選択します。
- Security 項目を選択し、 をクリックして Certificate Manager を開きます。
図13.7 Thunderbird のアカウント設定
- CA 証明書をダウンロードし、コンピューターに保存します。
- Certificate Manager で Authorities タブを選択し、 をクリックします。
図13.8 Thunderbird での CA 証明書のインポート
- ダウンロードした CA 証明書を選択します。
- Certificate Manager の Authorities タブで、適切な証明書を選択し、 をクリックします。
- 証明書トラスト設定を編集します。
図13.9 Thunderbird での証明書トラスト設定の編集
- Certificate Manager の Your Certificates タブで、 をクリックします。
図13.10 Thunderbird での認証用の個人証明書のインポート
- お使いのコンピューターから必要な証明書を選択します。
- Certificate Manager を閉じ、Account Settings の Security 項目に戻ります。
- フォームの Digital Signing セクションで、Select をクリックしてメッセージの署名に使用する個人証明書を します。
- Encryption で Select をクリックして、メッセージを暗号化および復号する個人証明書を します。
付録A トラブルシューティング
A.1. SSSD のトラブルシューティング
A.1.1. SSSD ドメインのデバッグログの設定
sssd.conf
ファイルの各セクションに debug_level
パラメーターを設定して、追加のログを生成します。以下に例を示します。
[domain/LDAP]
cache_credentials = true
debug_level = 9
レベル | 説明 |
---|---|
0 | 致命的な障害。SSSD の起動を妨げる、または SSSD の実行を停止させるもの。 |
1 | 重大なエラー。SSSD を強制終了しないものの、少なくとも 1 つの主要な機能が機能しなくなったことを示すエラー。 |
2 | 深刻なエラー。特定の要求または操作が失敗したことを示すエラー。 |
3 | マイナーな障害。これらのエラーが浸透して、2 の動作不良の原因となるのです。 |
4 | 設定設定。 |
5 | 関数データ。 |
6 | 操作関数のメッセージを追跡します。 |
7 | 内部制御関数のメッセージのトレース。 |
8 | 対象の関数内部変数の内容。 |
9 | 非常に低いレベルのトレース情報。 |
sssd-tools
パッケージに含まれる sss_debuglevel
ユーティリティーを使用します。仕組みの詳細は、sss_debuglevel の man ページを参照してください。
A.1.2. SSSD ログファイルの確認
/var/log/sssd/
ディレクトリーにある操作に関する情報を報告します。SSSD は、各ドメインのログファイルと sssd_pam.log
および sssd_nss.log
ファイルを生成します。
krb5_child.log
: Kerberos 認証に関連する有効期限の短いヘルパープロセスのログファイルldap_child.log
: LDAP サーバーと通信に関連する有効期限の短いヘルパープロセスのログファイルselinux_child.log
: SELinux 情報を取得する有効期限の短いヘルパープロセスのログファイルsssd.log
: レスポンダープロセスと通信する SSSD のログファイルsssd_[domain].log
: 各 SSSD ドメインセクションは、LDAP サーバーとの通信に関する情報を別のログファイルに記録します。sssd_ifp.log
: InfoPipe レスポンダーのログファイル。システムバスを介してアクセス可能なパブリック D-Bus インターフェイスを提供します。sssd_nss.log
: ユーザーおよびグループ情報を取得する Name Services Switch (NSS)レスポンダーのログファイル。sssd_pac.log
: Active Directory ユーザーおよびグループの管理に SSSD が Kerberos と動作する方法を定義する Microsoft Privilege Attribute Certificate (PAC)レスポンダーサービスのログファイルです。sssd_pam.log
: Pluggable Authentication Module (PAM)レスポンダーのログファイルsssd_ssh.log
: SSH レスポンダープロセスのログファイルです。
/var/log/secure
ファイルは認証の失敗と失敗の原因をログに記録します。
A.1.3. SSSD 設定に関する問題
- 問: SSSD が起動に失敗する
- 問: getent group の id またはグループメンバーを持つグループは表示されません。
- 問: 認証は LDAP に対して失敗します。
- 問: 非標準ポートで LDAP サーバーへの接続に失敗します。
- 問: NSS がユーザー情報を返すことができません
- 問: NSS が間違ったユーザー情報を返す
- 問: ローカルの SSSD ユーザーのパスワードを設定すると、パスワードが 2 回要求されます。
- 問: Active Directory ID プロバイダーは sssd.conf ファイルで適切に設定されていますが、SSSD は接続に失敗し、GSS-API エラーが発生します。
- 問: SSSD が中央認証用に設定されましたが、アプリケーション (Firefox、Adobe など) が複数起動しません。
- 問: SSSD は、削除された自動マウントの場所を表示します。
- SSSD では、サービスが起動する前に、最低でもドメインを適切に設定する必要があります。ドメインがないと、SSSD を起動すると、ドメインが設定されていないエラーが返されます。
# sssd -d4 -i [sssd] [ldb] (3): server_sort:Unable to register control with rootdse! [sssd] [confdb_get_domains] (0): No domains configured, fatal error! [sssd] [get_monitor_config] (0): No domains configured.
/etc/sssd/sssd.conf
ファイルを編集し、ドメインを 1 つ以上作成します。 - SSSD は、開始する前に、少なくとも 1 つ以上の利用可能なサービスプロバイダーも必要です。問題がサービスプロバイダー設定にある場合、エラーメッセージはサービスが設定されていないことを示します。
[sssd] [get_monitor_config] (0): No services configured!
/etc/sssd/sssd.conf
ファイルを編集し、少なくとも 1 つのサービスプロバイダーを設定します。重要SSSD では、サービスプロバイダーを/etc/sssd/sssd.conf
ファイルの単一のservices
エントリーでコンマ区切りのリストとして設定する必要があります。サービスが複数のエントリーに一覧表示されます。最後のエントリーのみが SSSD によって認識されます。 - SSSD では、
/etc/sssd/sssd.conf
の所有権とパーミッションを正しく設定する必要があります。所有者またはパーミッションが誤って設定されている場合は、SSSD を開始しようとすると、以下のエラーメッセージが返されます。[sssd] [confdb_ldif_from_ini_file] (0x0020): Permission check on config file failed. [sssd] [confdb_init_db] (0x0020): Cannot convert INI to LDIF [1]: [Operation not permitted] [sssd] [confdb_setup] (0x0010): ConfDB initialization has failed [1]: Operation not permitted [sssd] [load_configuration] (0x0010): Unable to setup ConfDB [1]: Operation not permitted [sssd] [main] (0x0020): Cannot read config file /etc/sssd/sssd.conf. Please check that the file is accessible only by the owner and owned by root.root.
/etc/sssd/sssd.conf
ファイルの正しい所有権と権限を設定します。# chmod 600 /etc/sssd/sssd.conf # chown root:root /etc/sssd/sssd.conf
sssd.conf
の [domain/DOMAINNAME] セクションに誤った ldap_schema 設定が原因である可能性があります。
memberuid
属性として保存されます。RFC2307bis サーバーでは、グループメンバーは、このグループの メンバー
であるユーザーまたはグループの DN を含む多値 member または uniqueMember
属性として保存されます。RFC2307bis を使用すると、ネストされたグループも保守できます。
- ldap_schema を rfc2307bis に設定します。
- Delete
/var/lib/sss/db/cache_DOMAINNAME.ldb
. - SSSD を再起動します。
sssd.conf
に追加します。
ldap_group_name = uniqueMember
sssd.conf
が標準プロトコル(ldap://
)に接続するように設定されていると、Start TLS で通信チャネルの暗号化を試みます。sssd.conf
が安全なプロトコル(ldaps://
)に接続するように設定されている場合、SSSD は SSL を使用します。
syslog
メッセージが書き込まれ、TLS 暗号化を開始できなかったことを示します。証明書設定は、SSSD とは別に LDAP サーバーにアクセスできるかどうかを確認してテストできます。たとえば、以下は、test.example.com への TLS 接続で匿名バインドをテストします。
$ ldapsearch -x -ZZ -h test.example.com -b dc=example,dc=com
ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Unknown code ___f 13
- LDAP サーバー証明書に署名するために使用される認証局の公開 CA 証明書のコピーを取得してローカルシステムに保存します。
- ファイルシステムの CA 証明書を参照する
sssd.conf
ファイルに行を追加します。ldap_tls_cacert = /path/to/cacert
- LDAP サーバーが自己署名証明書を使用する場合は、
sssd.conf
ファイルから ldap_tls_reqcert 行を削除します。このパラメーターにより、SSSD が CA 証明書により発行された証明書を信頼するように指示します。これは、自己署名の CA 証明書を使用するセキュリティーリスクになります。
# semanage port -a -t ldap_port_t -p tcp 1389
- NSS サービスが実行していることを確認します。
# service sssd status Redirecting to /bin/systemctl status sssd.service sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) Active: active (running) since Wed 2015-01-14 10:17:26 CET; 1min 30s ago Process: 683 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS) Main PID: 745 (sssd) CGroup: /system.slice/sssd.service ├─745 /usr/sbin/sssd -D -f ├─746 /usr/libexec/sssd/sssd_be --domain default --debug-to-files... ├─804 /usr/libexec/sssd/sssd_nss --debug-to-files └─805 /usr/libexec/sssd/sssd_pam --debug-to-files
SSSD がActive: active (running)
状態にあり、出力にsssd_nss
が含まれると、NSS サービスが実行されている。 - NSS を実行している場合は、プロバイダーが
/etc/sssd/sssd.conf
ファイルの[nss]
セクションで適切に設定されていることを確認します。特に、filter_users
属性およびfilter_groups
属性を確認します。 - NSS が SSSD が使用するサービスの一覧に含まれていることを確認します。
/etc/nsswitch.conf
ファイルの設定を確認します。詳細は、「SSSD を使用するように NSS サービスを設定する」 を参照してください。
/etc/sssd/sssd.conf
ファイルで use_fully_qualified_domains
属性を true
に設定します。これは、同じ名前の異なるドメインの異なるユーザーを区別します。
[root@clientF11 tmp]# passwd user1000 Changing password for user user1000. New password: Retype new password: New Password: Reenter new Password: passwd: all authentication tokens updated successfully.
/etc/pam.d/system-auth
ファイルで use_authtok
オプションが正しく設定されていることを確認します。正しい設定例については、「サービスの設定: PAM」 を参照してください。
sssd.conf
ファイルで適切に設定されていますが、SSSD は接続に失敗し、GSS-API エラーが発生します。
[domain/ADEXAMPLE]
debug_level = 0xFFF0
id_provider = ad
ad_server = 172.16.0.1
ad_domain = example.com
krb5_canonicalize = False
(Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot determine realm for numeric host address)]
ad_server
を Active Directory ホストの名前に設定するか、「DNS サービスディスカバリーの設定」 で説明されているように _srv_
キーワードを使用して DNS サービス検出を使用します。
Failed to contact configuration server. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: IOR file '/tmp/gconfd-somebody/lock/ior' not opened successfully, no gconfd located: Permission denied 2: IOR file '/tmp/gconfd-somebody/lock/ior' not opened successfully, no gconfd located: Permission denied)
[jsmith@server ~]$ acroread (acroread:12739): GLib-WARNING **: getpwuid_r(): failed due to unknown user id (366)
- 「UID または GID の変更後にユーザーがログインできません。」 の説明に従って、autofs キャッシュを削除します。
- SSSD を再起動します。
# systemctl restart sssd
A.1.4. UID または GID の変更後にユーザーがログインできません。
エラー内容:
解決方法:
sss_cache
ユーティリティーを使用して SSSD キャッシュを削除します。
- sssd-tools がインストールされている。
- 特定ユーザーの SSSD キャッシュをクリアし、その他のキャッシュレコードをそのまま残すには、次のコマンドを実行します。
# sss_cache --user user_name
ドメイン全体のキャッシュを消去するには、以下のコマンドを実行します。# sss_cache --domain domain_name
sss_cache
の詳細は、sss_cache(8) の man ページを参照してください。
A.1.5. SSSD コントロールおよび Status ユーティリティー
- sssctl を使用するには、sssd-tools パッケージをインストールします。
[root@server ~]# yum install sssd-tools
- sssctl の一部のオプションは、SSSD InfoPipe レスポンダーを使用します。これを有効にするには、
/etc/sssd/sssd.conf
のservices
オプションにifp
を追加します。[sssd] services = nss, sudo, pam, ssh, ifp
- SSSD を再起動します。
[root@server ~]# systemctl restart sssd.service
A.1.5.1. SSSD 設定検証
/etc/sssd/sssd.conf
ファイルおよび / etc/sssd/conf.d/*
ファイルを検証して、SSSD を再起動する前にレポートを受け取ることができます。
- パーミッション
- 所有者およびグループの所有者は
root:root
に、パーミッションを600
に設定する必要があります。 - ファイル名
/etc/sssd/conf.d/
のファイル名は、接尾辞.conf
を使用し、ピリオド(非表示ファイル)で開始しないでください。- 誤植
- セクションとオプション名で誤字のエラーがチェックされます。値はチェックされません。
- オプション
- オプションは正しいセクションに配置する必要があります。
# sssctl config-check Issues identified by validators: 3 [rule/allowed_sections]: Section [paM] is not allowed. Check for typos. [rule/allowed_domain_options]: Attribute 'offline_timeoutX' is not allowed in section 'domain/idm.example.com'. Check for typos. [rule/allowed_sudo_options]: Attribute 'homedir_substring' is not allowed in section 'sudo'. Check for typos. Messages generated during configuration merging: 2 File /etc/sssd/conf.d/wrong-file-permissions.conf did not pass access check. Skipping. File configuration.conf.disabled did not match provided patterns. Skipping. Used configuration snippet files: 1 /etc/sssd/conf.d/sample.conf
A.1.5.2. ユーザーデータの表示
system-auth
PAM サービスを使用してログインすることを許可されているかどうかを示します。
admin
ユーザーのユーザーデータを表示するには、次のコマンドを実行します。
# sssctl user-checks admin user: admin action: acct service: system-auth SSSD nss user lookup result: - user name: admin - user id: 1194200000 - group id: 1194200000 - gecos: Administrator - home directory: /home/admin - shell: /bin/bash SSSD InfoPipe user lookup result: - name: admin - uidNumber: 1194200000 - gidNumber: 1194200000 - gecos: Administrator - homeDirectory: /home/admin - loginShell: /bin/bash testing pam_acct_mgmt pam_acct_mgmt: Success PAM Environment: - no env -
A.1.5.3. ドメイン情報
- 信頼されたドメインを含む、SSSD 内で利用可能なドメインの一覧を表示します。
[root@server ~]# sssctl domain-list idm.example.com ad.example.com
- ドメイン idm.example.com のステータスを取得します。
[root@server ~]# sssctl domain-status idm.example.com Online status: Online
A.1.5.4. キャッシュされたエントリー情報
admin
のキャッシュ情報をクエリーするには、以下を実行します。
[root@server ~]# sssctl user-show admin Name: admin Cache entry creation date: 07/10/16 16:09:18 Cache entry last update time: 07/14/16 10:13:32 Cache entry expiration time: 07/14/16 11:43:32 Initgroups expiration time: Expired Cached in InfoPipe: No
[root@server ~]# sssctl group-show groupname [root@server ~]# sssctl netgroup-show netgroupname
A.1.5.5. ログファイルの切り捨て
/var/log/sssd/
ディレクトリー内のすべての SSSD ログファイルを切り捨て、新たに作成されたエントリーのみをキャプチャーできます。
[root@server ~]# sssctl logs-remove Truncating log files...
A.1.5.6. SSSD キャッシュの削除
remove-cache
オプションを提供します。データベースを削除する前に、このコマンドにより自動的にバックアップが作成されます。
[root@server ~]# sssctl cache-remove SSSD must not be running. Stop SSSD now? (yes/no) [yes] Creating backup of local data... Removing cache files... SSSD needs to be running. Start SSSD now? (yes/no) [yes]
/var/lib/sss/backup/
ディレクトリーに保存します。
A.1.5.7. LDAP グループに関する情報の取得には時間がかかる
エラー内容:
解決方法:
/etc/sssd/sssd.conf
ファイルを開きます。[domain]
セクションで、ignore_group_members
オプションをtrue
に設定します。[domain/domain_name] [... file truncated ...]
ignore_group_members = true
true
に設定しないでください。
A.2. SSSD および sudo Debugging Logs を使用した sudo のトラブルシューティング
A.2.1. SSSD および sudo デバッグロギング
sudo デバッグログファイル
- 以下の行を
/etc/sudo.conf
に追加します。Debug sudo /var/log/sudo_debug.log all@debug Debug sudoers.so /var/log/sudo_debug.log all@debug
- デバッグするユーザーとして sudo コマンドを実行します。
/var/log/sudo_debug.log
ファイルが自動的に作成され、以下のような質問に回答するための詳細情報が提供されます。
- sudo コマンドの実行時にユーザーと環境についてどのような情報が利用できますか?
sudo[22259] settings: debug_flags=all@debug sudo[22259] settings: run_shell=true sudo[22259] settings: progname=sudo sudo[22259] settings: network_addrs=192.0.2.1/255.255.255.0 fe80::250:56ff:feb9:7d6/ffff:ffff:ffff:ffff:: sudo[22259] user_info: user=user_name sudo[22259] user_info: pid=22259 sudo[22259] user_info: ppid=22172 sudo[22259] user_info: pgid=22259 sudo[22259] user_info: tcpgid=22259 sudo[22259] user_info: sid=22172 sudo[22259] user_info: uid=10000 sudo[22259] user_info: euid=0 sudo[22259] user_info: gid=554801393 sudo[22259] user_info: egid=554801393 sudo[22259] user_info: groups=498,6004,6005,7001,106501,554800513,554801107,554801108,554801393,554801503,554802131,554802244,554807670 sudo[22259] user_info: cwd=/ sudo[22259] user_info: tty=/dev/pts/1 sudo[22259] user_info: host=client sudo[22259] user_info: lines=31 sudo[22259] user_info: cols=237
- sudo ルールの取得に使用されるデータソース。
sudo[22259] <- sudo_parseln @ ./fileops.c:178 := sudoers: files sss
- SSSD プラグインは以下の行で始まります。
sudo[22259] <- sudo_sss_open @ ./sssd.c:305 := 0
- SSSD が返すルールの数
sudo[22259] Received 3 rule(s)
- ルールが一致しているかどうか。
sudo[22259] sssd/ldap sudoHost 'ALL' ... MATCH! sudo[22259] <- user_in_group @ ./pwutil.c:1010 := false
SSSD デバッグログファイル
/etc/sssd/sssd.conf
ファイルの[sudo]
セクションおよび[domain/domain_name]
セクションにdebug_level
オプションを追加します。[domain/domain_name] debug_level = 0x3ff0 ... [sudo] debug_level = 0x3ff0
- SSSD を再起動します。
# systemctl restart sssd
- sudo コマンドを実行して、デバッグ情報をログファイルに書き込みます。
- ドメインログファイル:
/var/log/sssd/sssd_domain_name.log
- このログファイルは、以下のような質問に回答するのに役立ちます。
- SSSD が返すルールの数
[sdap_sudo_refresh_load_done] (0x0400): Received 4-rules rules
- SSSD はサーバーからどの sudo ルールをダウンロードしましたか。
[sssd[be[LDAP.PB]]] [sysdb_save_sudorule] (0x0400): Adding sudo rule demo-name
- マッチングルールはキャッシュに保存されますか。
[sdap_sudo_refresh_load_done] (0x0400): Sudoers is successfully stored in cache
- サーバーからルールをダウンロードするために使用されたのはどのフィルターですか。
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=client.example.com)(sudoHost=client)(sudoHost=192.0.2.1)(sudoHost=192.0.2.0/24)(sudoHost=2620:52:0:224e:21a:4aff:fe23:1394)(sudoHost=2620:52:0:224e::/64)(sudoHost=fe80::21a:4aff:fe23:1394)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\2A*)(sudoHost=*[*]*))))][dc=example,dc=com]
このフィルターを使用して、IdM データベースのルールを検索します。# ldapsearch -x -D "cn=Directory Manager" -W -H ldap://server.example.com -b dc=example,dc=com '(&(objectClass=sudoRole)...)'
- sudo レスポンダーログファイル:
/var/log/sssd/sssd_sudo.log
- このログファイルは、以下のような質問に回答するのに役立ちます。
- SSSD が返すルールの数
[sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 4-rules rules for [user@idm.example.com]
- SSSD のキャッシュの検索に適用されたフィルター。
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=user)(sudoUser=#10001)(sudoUser=%group-1)(sudoUser=%user)(sudoUser=+*)))]
- SSSD キャッシュから返されるルールを検索するにはどうすればいいですか。以下のフィルターを使用してルールを検索します。
# ldbsearch -H /var/lib/sss/db/cache_domain_name.ldb -b cn=sysdb '(&(objectClass=sudoRule)...)'
注記ldbsearch
ユーティリティーは、ldb-tools パッケージに含まれています。
A.3. Firefox Kerberos 設定のトラブルシューティング
- Firefox のすべてのインスタンスを閉じます。
- コマンドプロンプトで、
NSPR_LOG_*
変数の値をエクスポートします。export NSPR_LOG_MODULES=negotiateauth:5 export NSPR_LOG_FILE=/tmp/moz.log
- そのシェルから Firefox を再起動し、Kerberos 認証に失敗していた Web サイトを開きます。
/tmp/moz.log
ファイルで、メッセージの nsNegotiateAuth でエラーメッセージを確認します。
- 認証情報が見つかりません
-1208550944[90039d0]: entering nsNegotiateAuth::GetNextToken() -1208550944[90039d0]: gss_init_sec_context() failed: Miscellaneous failure No credentials cache found
これは、Kerberos チケットが利用できないことを意味します (つまり、有効期限が切れたか、生成されていません)。これを修正するには、kinit を実行して Kerberos チケットを生成し、Web サイトを再度開きます。- サーバーが Kerberos データベースで見つかりません
-1208994096[8d683d8]: entering nsAuthGSSAPI::GetNextToken() -1208994096[8d683d8]: gss_init_sec_context() failed: Miscellaneous failure Server not found in Kerberos database
これは、ブラウザーが KDC と通信できないことを意味します。通常、これは Kerberos 設定の問題です。正しいエントリーは、ドメインを識別するために/etc/krb5.conf
ファイルの [domain_realm] セクションになければなりません。以下に例を示します。.example.com = EXAMPLE.COM example.com = EXAMPLE.COM
- ログにエラーはありません
- HTTP プロキシーサーバーが Kerberos 認証に必要な HTTP ヘッダーを削除している可能性があります。HTTPS を使用してサイトへの接続を試みます。これにより、要求を変更せずに渡すことができます。
付録B 更新履歴
改訂履歴 | |||
---|---|---|---|
改訂 7.0-31 | Wed Nov 11 2020 | ||
| |||
改訂 7.0-30 | Tue Aug 06 2019 | ||
| |||
改訂 7.0-29 | Tue Apr 08 2019 | ||
| |||
改訂 7.0-28 | Fri Oct 26 2018 | ||
| |||
改訂 7.0-27 | Mon Jun 25 2018 | ||
| |||
改訂 7.0-26 | Tue Apr 10 2018 | ||
| |||
改訂 7.0-25 | Mon Mar 19 2018 | ||
| |||
改訂 7.0-24 | Mon Feb 12 2018 | ||
| |||
改訂 7.0-23 | Mon Jan 29 2018 | ||
| |||
改訂 7.0-22 | Mon Dec 4 2017 | ||
| |||
改訂 7.0-21 | Mon Nov 20 2017 | ||
| |||
改訂 7.0-20 | Mon Nov 6 2017 | ||
| |||
改訂 7.0-19 | Mon Aug 14 2017 | ||
| |||
改訂 7.0-18 | Tue Jul 18 2017 | ||
| |||
改訂 7.0-17 | Mon Mar 27 2017 | ||
| |||
改訂 7.0-16 | Mon Feb 27 2017 | ||
| |||
改訂 7.0-15 | Wed Dec 7 2016 | ||
| |||
改訂 7.0-14 | Tue Oct 18 2016 | ||
| |||
改訂 7.0-13 | Wed Jul 27 2016 | ||
| |||
改訂 7.0-11 | Thu Mar 03 2016 | ||
| |||
改訂 7.0-10 | Tue Feb 09 2016 | ||
| |||
改訂 7.0-9 | Thu Nov 12 2015 | ||
| |||
改訂 7.0-8 | Fri Mar 13 2015 | ||
| |||
改訂 7.0-6 | Wed Feb 25 2015 | ||
| |||
改訂 7.0-4 | Fri Dec 05 2014 | ||
| |||
改訂 7.0-1 | July 16, 2014 | ||
|