機械翻訳について

第2章 システム認証の構成

この章では、Oracle Linuxで使用できるNIS、LDAP、Kerberos、Winbindなどの様々な認証方法を構成する方法、およびSystem Security Services Daemon機能を構成してアイデンティティおよび認証を集中管理する方法について説明します。

2.1 Oracle Linux 8の認証の概要

認証とは、システムに対してエンティティ(ユーザーなど)のアイデンティティを検証することです。 ユーザーはユーザー名とパスワードを入力してログインし、オペレーティング・システムはこの情報とシステムに保存されているデータを比較してユーザーのアイデンティティを認証します。 ログイン資格証明が一致し、ユーザー・アカウントがアクティブな場合、ユーザーは認証され、システムに正常にアクセスできます。

ユーザー・アイデンティティを検証する情報は、/etc/passwdファイルおよび/etc/shadowファイル内のローカル・システム、またはIdentity Policy Audit (IPA)、Lightweight Directory Access Protocol (LDAP)またはWinbindを使用したリモート・システム上にあります。 また、IPAv2およびLDAPデータ・ファイルでは、Kerberos認証プロトコルを使用できます。これにより、セキュアでないネットワークを介して通信するノードは、安全な方法で互いにidを証明できます。

2.1.1 authselectユーティリティについて

以前のリリースでは、authconfigコマンドを使用して、ローカル・システムおよびリモート・システムでのユーザー・ログインの認証を制御していました。 ただし、時間の経過とともに認証メソッドが増加し、これらの各メソッドを使用するさまざまな認証構成も乗算しました。 そのため、authconfigコマンドが複雑になり、中央管理ツールとして機能することや、認証設定の問題をトラブルシューティングすることが可能になりました。

authselectユーティリティの導入により、プロファイル・ベースの認証とは異なるアプローチが反映されます。 これは、Oracle Linux 8のインストールに自動的に含まれます。

authselectユーティリティは、次のコンポーネントで構成されています:

  • システム認証を管理するためのauthselectコマンド。 このコマンドはrootによってのみ実行できます。

  • 特定のタイプの認証を実装する、すぐに使用できる3つのプロファイル。 次のプロファイルが、usr/share/authselect/defaultディレクトリに自動的にインストールされます:

    • sssdプロファイル。 このプロファイルは、sssdサービスを使用してシステム認証を実行します。 Oracle Linux 8のインストール後、このプロファイルはデフォルトで自動的に選択されます。

    • winbindプロファイル。 このプロファイルは、winbindサービスを使用してシステム認証を実行します。

    • nisプロファイルもディレクトリに含まれますが、レガシー構成との互換性を維持する目的でのみ使用されます。 NISはOracle Linux 8で非推奨です。 したがって、sssdプロファイルの使用に変換することを強くお薦めします。

また、authselectユーティリティを使用すると、すでに行ったプロファイルが環境に十分でない場合に、カスタマイズしたプロファイルを作成できます。 このような柔軟性がユーティリティによって提供されるため、認証プロファイルはプロファイルのタイプに応じて格納されます:

  • /usr/share/authselect/defaultには、Oracle Linux 8が提供するすぐに使用できるプロファイルが用意されています。

  • /usr/share/authselect/vendorには、ベンダーによって提供されるプロファイルが含まれています。 これらのプロファイルは、デフォルトのディレクトリ内のプロファイルをオーバーライドできます。

  • /etc/authselect/customには、特定の環境用に作成するプロファイルがすべて含まれています。

重要

authselectユーティリティにより、選択したプロファイルに指定が適用されます。 ただし、このユーティリティでは、プロファイルの基礎となるサービスの構成ファイルは変更されません。 たとえば、sssdプロファイルを使用している場合、サービスが正しく機能するようにSSSDを構成する必要があります。 プロファイル・サービスを構成するために適切なドキュメントを参照してください。 サービスが起動され、有効になっていることも確認する必要があります。

ユーティリティの詳細は、authselect(8)のマニュアル・ページを参照してください。

2.1.2 プロファイルとサポートされる機能について

各プロファイルには、プロファイル・サービスで特定の認証メソッド(スマート・カード認証、フィンガープリント認証、kerberosなど)を実行できるようにするための機能が関連付けられています。 プロファイルを選択して優先機能を有効化すると、authselectによってこれらの機能の適切な構成ファイルが自動的に読み取られ、関連する認証プロセスが実行されます。 ホストにログインするすべてのユーザーは、その構成済プロファイルに基づいて認証されます。

次の表に、sssdプロファイルの機能を示します:

表2.1 Sssdプロファイルでサポートされる機能
機能名 説明
with-faillock 認証の失敗が多すぎた後にアカウントをロックします。
with-mkhomedir ユーザーの初回ログイン時にホーム・ディレクトリを作成します。
with-ecryptfs ユーザーごとに自動ecryptfsを有効にします。
with-smartcard SSSD経由でスマート・カードを認証します。
with-smartcard-lock-on-removal スマート・カードが取り外されたら画面をロックします。 with-smartcardも有効である必要があります。
with-smartcard-required スマート・カード認証のみが操作可能です。他のユーザー(パスワードを含む)は使用不可です。 with-smartcardも有効である必要があります。
with-fingerprint 指紋リーダーを通じて認証します。
with-silent-lastlog ログイン中にpam_lostlogメッセージ生成の無効化
with-sudo /etc/sudoers以外のルールにもSSSDを使用できるようにsudoを有効化します。
with-pamaccess アカウント承認については、/etc/access.confを参照してください。
without-nullock nullockパラメータをpam_unixに追加しない

次の表に、winbindプロファイルの機能を示します:

表2.2 winbind Profileでサポートされる機能
機能名 説明
with-faillock 認証の失敗が多すぎた後にアカウントをロックします。
with-mkhomedir ユーザーの初回ログイン時にホーム・ディレクトリを作成します。
with-ecryptfs ユーザーごとに自動ecryptfsを有効にします。
with-fingerprint 指紋リーダーを通じて認証します。
with-krb5 Kerberos認証を使用します。
with-silent-lastlog ログイン中にpam_lostlogメッセージ生成の無効化
with-pamaccess アカウント承認については、/etc/access.confを参照してください。
without-nullock nullockパラメータをpam_unixに追加しない

各プロファイルの詳細は、対応する/usr/share/authselect/default/profile/READMEファイルを参照してください。 authselect-profiles(5)のマニュアル・ページも参照してください。

2.1.3 デフォルトの認証プロファイルについて

Oracle Linux 8システムでは、システムの認証を管理するために、sssdプロファイルがデフォルトで選択されます。 このプロファイルでは、PAM認証、Kerberosなどを含むほとんどの認証ケースを扱います。 選択のプロファイルとしてsssdが推奨されます。

デフォルト・プロファイルとして、一部のsssd機能は自動的に有効になります。 次のコマンドを使用して、情報を確認できます:

sudo authselect current
Profile ID: sssd
Enabled features:
- with-fingerprint
- with-silent-lastlog

コマンドの出力は、SSDサービスがシステム認証を管理することを示します。 最低でも、指紋リーダーによる認証は、pam_fprintdを介して施行されます。 また、ユーザーがログインしたときにpam_lastlogメッセージが画面に表示されることはありません。

2.1.4 プロファイル機能の有効化と無効化

プロファイルの有効な機能は、システムの認証方法を決定します。 次の2つの方法のいずれかで、プロファイル機能を有効にできます:

プロファイルの機能をさらに有効にするには、次の手順を実行します:

  1. (オプション): 現在のプロファイルを確認します。

    追加機能の有効化は、現在のプロファイルでのみ機能します。 このプロシージャは、未選択のプロファイルに対しては機能しません。

    sudo authselect current
  2. 必要に応じて、機能が正しく動作するために必要な機能要件を特定します。

    sudo authselect requirements profile feature
  3. 必要に応じて、リストされた機能要件を完了します。

  4. 機能を有効にします。

    sudo authselect enable-feature feature

    一度に1つの機能のみを有効にできることに注意してください。

機能を次のように無効にします:

sudo authselect disable-feature feature
例2.1 プロファイル機能の有効化

次の例は、デフォルトのsssdプロファイルに機能を追加する方法を示しています。

  1. 認証の失敗が多すぎると、アカウントを自動的にロックします (with-faillock):

    sudo authselect requirements sssd with-faillock
    Make sure that SSSD service is configured and enabled. See SSSD documentation for more 
    information.
  2. with-mkhomedirに最初にログインするときに、ユーザー・ホーム・ディレクトリを自動的に作成します。

    sudo authselect requirements sssd with-mkhomedir
    Make sure that SSSD service is configured and enabled. See SSSD documentation for more 
    information.
     
    - with-mkhomedir is selected, make sure pam_oddjob_mkhomedir module
      is present and oddjobd service is enabled
      - systemctl enable oddjobd.service
      - systemctl start oddjobd.service
  3. 両方のプロファイル機能を有効にします:

    sudo authselect enable-feature with-faillock
    sudo authselect enable-feature with-mkhomedir
  4. 両方のプロファイル機能が有効になっていることを確認します:

    sudo authselect current
    Profile ID: sssd
    Enabled features:
    - with-fingerprint
    - with-silent-lastlog
    - with-faillock
    - with-mkhomedir

次の例では、/etc/security/access.confを確認してユーザーを認証および認可する例を示します。 この場合、PAMアクセス機能をsssdの有効な機能として追加する必要があります。

  1. PAMアクセスを自動的に有効にします:

    sudo authselect requirements sssd with-pamaccess
    Make sure that SSSD service is configured and enabled. See SSSD documentation for more 
    information.
  2. PAMアクセス・プロファイル機能を有効にします:

    sudo authselect enable-feature sssd with-pamaccess
  3. PAMアクセス・プロファイル機能が有効になっていることを確認します:

    sudo authselect current
    Profile ID: sssd
    Enabled features:
    - with-fingerprint
    - with-silent-lastlog
    - with-faillock
    - with-mkhomedir
    - with-pamaccess
ノート

前述の例では、機能が正しく機能するように/etc/security/access.confを構成していることを前提としています。 詳細は、access.conf(5)のマニュアル・ページを参照してください。

2.1.5 Winbind Profileの選択

Winbindは、Windowsサーバー上でユーザーおよびグループ情報を解決し、Oracle LinuxがWindowsユーザーおよびグループを把握できるようにするためのクライアント側サービスです。

現在のデフォルト・プロファイル(sssd)を使用せず、winbindプロファイルを使用する場合は、次の手順を実行します:

  1. samba-winbindパッケージをインストールします。

    sudo dnf install samba-winbind
  2. winbindプロファイルを選択します。

    プロファイルを選択する場合は、同じコマンドで複数の機能を有効にできます。次に例を示します:

    sudo authselect select winbind with-faillock with-mkhomedir [options]
    Profile "winbind" was selected.
    The following nsswitch maps are overwritten by the profile:
    - passwd
    - group
    
    Make sure that winbind service is configured and enabled. See winbind documentation for 
    more information.
     
    - with-mkhomedir is selected, make sure pam_oddjob_mkhomedir module
      is present and oddjobd service is enabled
      - systemctl enable oddjobd.service
      - systemctl start oddjobd.service

    authselect selectコマンドで使用できるその他のオプションについては、authselect(8)のマニュアル・ページを参照してください。

    出力には、他の情報や、認証を適切に実装するために必要な追加アクションに関する指示が含まれています。 この情報は、特にプロファイルで有効にする様々な機能について重要です。 これらの要件も満たされていることを確認します。

  3. winbindサービスを起動します。

    sudo systemctl start winbind
    sudo systemctl enable winbind
ノート

authselect selectを使用して、すでに最新でアクティブなプロファイルを選択し、同時に機能を有効にした場合、これらの機能は以前に有効にした機能を置き換えます。

2.1.6 読取りプロファイルの変更

すでに作成したプロファイルを変更およびカスタマイズするには、リビジョンをシステムの/etc/nsswitch.confファイルに適用する必要があります。 ただし、/etc/nsswitch.confを直接編集することはできません。 かわりに、これらのステップを実行します:

  1. 必要に応じて、現在のプロファイルを選択します。次に例を示します:

    sudo authselect select sssd
  2. 必要に応じて/etc/authselect/user-nsswitch.confファイルを編集します。

    ファイル内の次の構成のいずれも変更しないでください。 このような変更は無視されます:

    • passwd

    • group

    • netgroup

    • automount

    • services

  3. 変更を適用します。

    sudo authselect apply-changes

    /etc/authselect/user-nsswitch.confでの変更は/etc/nsswitch.confに適用され、現在のプロファイルで使用されます。

ノート

システムがアイデンティティ管理またはActive Directoryを使用する環境の一部である場合、authselectを使用して認証を管理しないでください。 ホストがアイデンティティ管理またはActive Directoryに参加する場合、それぞれのツールが環境の認証を管理する必要があります。

2.1.7 カスタム・プロファイルの作成

Oracle Linux 8またはベンダー提供のプロファイルからすでに作成しているプロファイルを使用しない場合は、独自のプロファイルを作成できます。 次のステップを実行します。

  1. プロファイルを作成します。

    sudo authselect create-profile newprofile -b template \
    --symlink-meta --symlink-pam
    newprofile

    カスタム・プロファイルの名前。

    template

    カスタム・プロファイルに使用されるベース(sssdまたはwinbind)。

    --symlink-meta

    ベースとして使用しているテンプレート・プロファイルの元のディレクトリにあるメタ・ファイルへのシンボリック・リンクを作成します。

    --symlink-pam

    ベースとして使用しているテンプレート・プロファイルの元のディレクトリにあるPAMテンプレートへのシンボリック・リンクを作成します。

    このコマンドによって、元のベース・ディレクトリ内のファイルへのシンボリック・リンクを含む/etc/authselect/custom/newprofileディレクトリが作成されます。 このディレクトリ内のシンボリック・リンクではないファイルはnsswitch.confのみです。

  2. プリファレンスに応じて/etc/authselect/custom/newprofile/ nsswitch.confファイルを編集します。

  3. カスタム・プロファイルを選択します。

    sudo authselect select custom/newprofile

    このコマンドによって、元の/etc/nsswitch.confファイルのバックアップも作成され、カスタム・プロファイル・ディレクトリ内の対応するファイルへのシンボリック・リンクに置換されます。

    この結果をテストするには、シンボリック・リンク/etc/nsswitch.confを元の/etc/nsswitch.conf.bakと比較し、元のファイルの内容が影響を受けていないかどうかを確認します。

  4. 必要に応じて、新規プロファイルの機能を有効にします。

    詳細は、第2.1.4項、「プロファイル機能の有効化および無効化」を参照してください。

  5. (オプション)カスタム・プロファイルの構成を確認します。

    sudo authselect current

2.1.8 authconfigからauthselectへの移行

Oracle Linux 8では、authconfigとの下位互換性に対するauthselectサポートは最小限です。 したがって、authselectへの移行を強くお薦めします。 移行では、次のようないくつかのアクションを実行する必要があります:

  • スクリプトの変換。

    ipa-client-installコマンドまたはrealm joinコマンドを使用してホストをドメインに参加させる場合、スクリプト内のauthconfigコールを削除するだけです。 そうしないと、各authconfigコールを同等のauthselectコールで置き換える必要があります。

  • 構成ファイルの更新

    様々なサービス用のファイルは、次のファイルを含めて再構成する必要があります: Kerberos、LDAP、NIS、SSSD、Winbind。

  • authselectのパスワード品質制限を適用します。

    pam_pwqualityモジュールでは、ローカル・ユーザーに対してパスワードの品質制限が強制されます。 このモジュールは、pam_pwquality(8)のマニュアル・ページで提供される情報に従って/etc/security/pwquality.confファイルで構成します。

  • authconfig cacertdir_rehashツールからネイティブopenssl rehash directoryコマンドに切り替えます。

  • 適切なサービスを起動します。

    authselect実装に対して選択したプロファイルに応じて、そのプロファイルのサービスを開始します。 たとえば、sssdプロファイルを選択した場合は、SSSDサービスを有効にして起動します。

    sudo systemctl start sssd; systemctl enable sssd

移行の手順および例を完了するには、authselect-migration(7)のマニュアル・ページを参照してください。 authselect(8)のマニュアル・ページも参照してください。

2.2 システム・セキュリティ・サービス・デーモンの詳細

System Security Services Daemon (SSSD)機能により、クライアント・システムでリモートのアイデンティティ・プロバイダおよび認証プロバイダにアクセスできます。 SSSDは、ローカル・クライアントと、構成したバックエンド・プロバイダの間の仲介として機能します。

SSSDを構成する利点は、次のとおりです:

  • システム負荷の削減

    クライアントは、識別サーバーまたは認証サーバーと直接通信する必要がありません。

  • オフライン認証

    ユーザーIDおよび資格証明のキャッシュを保持するようにSSSDを構成できます。

  • シングル・サインオン・アクセス

    ネットワーク資格証明を格納するようにSSSDを構成すると、ユーザーは、ネットワーク・リソースにアクセスするために、各セッションで1回のみローカル・システムに認証される必要があります。

Oracle Linux 8 authselect sssdプロファイルはデフォルトで使用されるため、SSSDサービスは新しくインストールされたシステムに自動的にインストールされて有効になります。 デフォルトの構成では、システムに対するアクセスおよび認証を管理するために、プラガブル認証モジュール(PAM)とネーム・サービス・スイッチ(NSS)が使用されます。 異なる認証サービスを使用する場合、またはデフォルト設定に代替値を使用するように構成をカスタマイズする場合を除き、それ以上の構成は必要ありません。

2.2.1 SSSDのカスタマイズ

デフォルトでは、sssdプロファイルで使用されるSSSDサービスは、プラガブル認証モジュール(PAM)とネーム・サービス・スイッチ(NSS)を使用してシステムに対するアクセスと認証を管理します。 SSSD認証をカスタマイズするためのプロファイルに追加機能を有効にする場合は、有効にした機能のSSSDも構成する必要があります。

カスタマイズ構成を実行するには、/etc/sssd/conf.dディレクトリ内に構成ファイルを作成します。 SSSDが起動されたときに有効にするには、各構成ファイルに.confサフィクスが必要です。 構成ファイルは、iniスタイルの構文を使用してフォーマットされ、セクションで構成されます。セクションは大カッコで示され、パラメータはkey = valueエントリとしてリストされます。 SSSDに提供されているマニュアル・ページは包括的で、使用可能なオプションに関する詳細情報を提供します。

次の例は、Kerberosが構成されているLDAPプロバイダに対して認証するためにSSSDを構成する方法を示しています:

  1. 機能の構成ファイルを作成し、これを/etc/sssd/conf.dに格納します(/etc/sssd/conf.d/00-ldap.confなど)

  2. 次のようなパラメータ定義を使用して/etc/sssd/conf.d/00-ldap.confを構成します:

    [sssd]
    config_file_version = 2
    domains = LDAP
    services = nss, pam
    
    [domain/LDAP]
    id_provider = ldap
    ldap_uri = ldap://ldap.mydom.com
    ldap_search_base = dc=mydom,dc=com
    
    auth_provider = krb5
    krb5_server = krbsvr.mydom.com
    krb5_realm = MYDOM.COM
    cache_credentials = true
    
    min_id = 5000
    max_id = 25000
    enumerate = false
    
    [nss]
    filter_groups = root
    filter_users = root
    reconnection_retries = 3
    entry_cache_timeout = 300
    
    [pam]
    reconnection_retries = 3
    offline_credentials_expiration = 2
    offline_failed_login_attempts = 3
    offline_failed_login_delay = 5
    [sssd]

    SSSDモニター・オプション、ドメインおよびサービスの構成設定が含まれています。 SSSD監視サービスは、SSSDで提供されるサービスを管理します。

    • servicesには、サポートされるサービスが定義されており、これには、Name Service Switchのnssおよびプラガブル認証モジュールのpamが含まれます。

    • domainsエントリでは、認証ドメインを定義するセクションの名前を指定します。

    [domain/LDAP]

    Kerberos認証を使用するLDAPアイデンティティ・プロバイダのドメインを定義します。 各ドメインでは、ユーザー情報の格納場所、認証方法および構成オプションを定義します。 SSSDは、LDAPアイデンティティ・プロバイダ(OpenLDAP、Red Hat Directory Server、IPA、Microsoft Active Directoryなど)とともに使用でき、システム固有のLDAPまたはKerberos認証のいずれかを使用できます。

    • id_providerは、プロバイダのタイプ(この例ではLDAP)を指定します。

    • ldap_uriは、SSSDが接続できるLDAPサーバーのUniversal Resource Identifier (URI)のカンマ区切りのリストを、優先して指定します。

    • ldap_search_baseは、一般名(cn)などの相対識別名(RDN)に対するLDAPユーザー操作を実行する際にSSSDが使用するベース識別名(dn)を指定します。

    • auth_providerエントリは、認証プロバイダ(この例ではKerberos)を指定します。

    • krb5_serverでは、SSSDの接続先となるKerberosサーバーのカンマ区切りリストを優先順に指定します。

    • krb5_realmは、Kerberosレルムを指定します。

    • cache_credentialsでは、SSSDがチケットやセッション・キーなどのユーザー資格証明をキャッシュするかどうか、およびオフライン認証とシングル・サインオンをサポートするためのその他の識別情報を指定します。

      ノート

      SSSDがLDAPサーバーでKerberos認証を使用できるようにするには、Simple Authentication and Security Layer (SASL)およびGeneric Security Services API (GSSAPI)の両方を使用するようにLDAPサーバーを構成する必要があります。 SASLおよびGSSAPI for OpenLDAPの構成の詳細は、https://www.openldap.org/doc/admin24/sasl.htmlを参照してください。

    • min_idおよびmax_idは、ユーザーIDとグループidの値の上限と下限を指定します。

    • enumerateは、プロバイダで使用可能なユーザーおよびグループの完全なリストをSSSDがキャッシュするかどうかを指定します。 ドメインに含まれるユーザーまたはグループが比較的少数である場合を除き、Falseに設定することをお薦めします。

    [nss]

    SSSデータベースをNSSに統合するネーム・サービス・スイッチ(NSS)モジュールを構成します。

    • filter_usersおよびfilter_groupsを使用すると、NSSは、SSSから取得される指定されたユーザーおよびグループに関する情報を抽出できません。

    • reconnection_retriesでは、データ・プロバイダがクラッシュした場合にSSSDが再接続を試行する回数を指定します。

    • enum_cache_timeoutは、SSSDがユーザー情報リクエストをキャッシュする秒数を指定します。

    [pam]

    SSSDをPAMと統合するPAMモジュールを構成します。

    • offline_credentials_expirationは、認証プロバイダがオフラインの場合にキャッシュ・ログインを許可する日数を指定します。

    • offline_failed_login_attemptsは、認証プロバイダがオフラインの場合に許容されるログイン試行の失敗回数を指定します。

    • offline_failed_login_delayでは、許可されるログイン試行の制限を超過してから新しいログイン試行が許可されるまでの時間を分単位で指定します。

  3. /etc/sssd/conf.d/00-ldap.confのモードを0600に変更します:

    sudo chmod 0600 /etc/sssd/conf.d/00-ldap.conf
  4. まだ開始されていない場合は、SSSDサービスを有効にします:

  5. sssdプロファイルを選択します。

    sudo authselect select sssd

SSSDサービスの詳細は、sssd(8)のマニュアル・ページおよびhttps://pagure.io/SSSD/sssd/を参照してください。 また、sssd.conf(5)sssd-ldap(5)sssd-krb5(5)sssd-ipa(5)およびその他のマニュアル・ページも参照できます。

2.2.2 Pluggable Authentication Moduleについて

プラガブル認証モジュール(PAM)機能は、sssdプロファイルで使用される認証メカニズムです。アプリケーションが認証を使用してユーザーの識別を検証する方法を構成できます。 /etc/pam.dディレクトリにあるPAM構成ファイルには、アプリケーションでの認証手順が記述されています。 各構成ファイルの名前は、モジュールが認証を提供するアプリケーションの名前と同じかほぼ同じす。 たとえば、passwdおよびsudoの構成ファイルの名前は、passwdおよびsudoです。

各PAM構成ファイルには、認証モジュールのコール用のリストまたはstackが含まれています。 たとえば、次のリストでは、login構成ファイルのデフォルト・コンテンツを示します。

#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth       include      system-auth
auth       include      postlogin
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
session    optional     pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open
session    required     pam_namespace.so
session    optional     pam_keyinit.so force revoke
session    include      system-auth
session    include      postlogin
-session   optional     pam_ck_connector.so

ファイルのコメントは#文字で始まります。 残りの各行で、操作タイプ、制御フラグ、pam_rootok.soなどのモジュール名またはsystem-authなどの含まれている構成ファイル名、およびモジュールに対する引数を定義しています。 PAMは/usr/lib64/securityの共有ライブラリとしての認証モジュールを提供します。

特定の操作タイプの場合、PAMは上から下にスタックを読み取って、構成ファイルに表示されているモジュールをコールします。 各モジュールはコールされると、結果(成功または失敗)を生成します。

使用する操作タイプとして、次のタイプが定義されています。

auth

モジュールは、サービスまたはアプリケーションを使用するために、ユーザーが認証または認可されているかどうかをテストします。 たとえば、モジュールはパスワードをリクエストおよび検証できます。 こうしたモジュールは、グループ・メンバーシップやKerberosチケットなどの資格証明を設定することもできます。

account

モジュールは、認証されたユーザーがサービスまたはアプリケーションへのアクセスを許可されているかどうかをテストします。 たとえば、モジュールはユーザー・アカウントが期限切れかどうか、またはユーザーが指定の時間にサービスの使用を許可されているかどうかを確認できます。

password

モジュールは、認証トークンへの更新を処理します。

session

モジュールは、ユーザーのホーム・ディレクトリのマウントやアンマウントなどの作業を実行して、ユーザー・セッションを構成および管理します。

操作タイプの前にダッシュ(-)が付いていると、そのモジュールがない場合にPAMはシステム・ログ・エントリを作成および追加しません。

include以外の制御フラグは、PAMにモジュールの実行結果に対して行う動作を通知します。 使用する制御フラグとして、次のフラグが定義されています。

optional

それがサービスにリストされている唯一のモジュールである場合、認証にはそのモジュールが必要です。

required

アクセスを付与するには、モジュールが成功する必要があります。 PAMはモジュールが成功しても失敗しても、スタックの残りのモジュールの実行を継続します。 PAMは、失敗をただちにユーザーに通知しません。

requisite

アクセスを付与するには、モジュールが成功する必要があります。 モジュールが成功した場合、PAMはスタック内の残りのモジュールの実行を継続します。 ただし、モジュールが失敗した場合、PAMはただちにユーザーに通知して、スタック内の残りのモジュールの実行を継続しません。

sufficient

モジュールが成功した場合、PAMは同じ操作タイプの残りのモジュールを処理しません。 モジュールが失敗した場合、PAMは同じ操作タイプの残りのモジュールを処理して、全体的な成功または失敗を判断します。

制御フラグ・フィールドでは、モジュールから返された値に応じてPAMが実行すべきアクションを指定する1つ以上のルールも指定できます。 各ルールは、value=actionというフォームをとり、ルールは大カッコで囲まれます。次に例を示します。

[user_unknown=ignore success=ok ignore=ignore default=bad]

モジュールから戻された結果が値に一致する場合は、PAMによって対応するアクションが使用され、一致がない場合はデフォルトのアクションが使用されます。

includeフラグは、PAMが引数として指定されたPAM構成ファイルも参照すべきであることを示します。

ほとんどの認証モジュールおよびPAM構成ファイルには、それぞれ独自のマニュアル・ページがあります。 関連ファイルが/usr/share/doc/pamディレクトリに格納されます。

詳細は、pam(8)マニュアル・ページを参照してください。 また、それぞれのPAMモジュールには、pam_unix(8)postlogin(5)system-auth(5)など独自のマニュアル・ページがあります。