1. システム・ユーザーおよび認証の設定
  2. System Security Services Daemonの使用

3 System Security Services Daemonの使用

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

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

  • システム負荷の削減

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

  • オフライン認証

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

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

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

Oracle Linux sssdプロファイルがデフォルトで使用されるため、SSSDサービスも自動的にインストールされ、新しくインストールされたシステムで有効になります。デフォルトの構成では、システム上のアクセスおよび認証を管理するために、Pluggable Authentication Module (PAM)および名前サービス・スイッチ(NSS)が使用されます。別の認証サービスを使用するか、デフォルト設定の代替値を使用するように構成をカスタマイズする場合を除き、これ以上の構成は必要ありません。

SSSDの詳細は、https://sssd.io/を参照してください。

SSSDのカスタマイズ

デフォルトでは、sssdプロファイルで使用されるSSSDサービスは、システム上のアクセスおよび認証を管理するために、Pluggable Authentication Module (PAM)および名前サービス・スイッチ(NSS)を使用します。プロファイルの追加機能を有効にしてSSSD認証をカスタマイズする場合は、有効にした機能に対して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は、サポートされているサービスを定義し、nss (名前サービス・スイッチ)およびpam (Pluggable Authentication Module)が含まれています。

    • 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サーバーを構成する必要があります。OpenLDAPに対するSASLおよびGSSAPIの構成の詳細は、https://www.openldap.org/doc/admin24/sasl.htmlを参照してください。

    • min_idおよびmax_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)およびその他のマニュアル・ページも参照できます。

Pluggable Authentication Moduleについて

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

各PAM構成ファイルには、認証モジュールに対するコールのリストまたはスタックが含まれます。たとえば、次のリストでは、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)など独自のマニュアル・ページがあります。