第2章 SSSD のアイデンティティープロバイダーとしての Active Directory の使用

System Security Services Daemon (SSSD) は、リモートのディレクトリーと認証メカニズムにアクセスするシステムサービスです。SSSD は、ローカルシステム (SSSD client) と外部のバックエンドシステム (domain) を接続します。これにより、SSSD クライアントが SSSD プロバイダーを使用して、アイデンティティーと認証リモートサービスにアクセスできます。たとえば、これらのリモートサービスには、LDAP ディレクトリー、Identity Management (IdM) または Active Directory (AD) ドメイン、Kerberos レルムなどがあります。
SSSD は、AD 統合のアイデンティティー管理サービスとして使用する場合には、NIS または Winbind などのサービスの代わりとなります。本章では、SSSD が AD とどのように連携するのかを説明します。SSSD の詳細は、システムレベルの認証ガイドを参照してください。

2.1. SSSD 用の AD プロバイダーの設定

AD プロバイダーを使用すると、SSSD が LDAP のアイデンティティープロバイダーと Kerberos 認証プロバイダーを使用し、AD 環境の最適化を図ることができます。

2.1.1. 統合オプションの概要

Linux と Windows のシステムは、ユーザーやグループに異なる識別子を使用します。
  • Linux は、ユーザー ID (UID) および グループ ID (GID) を使用します。『システム管理者のガイド 』の「ユーザーとグループの管理 を参照してください。 Linux UID と GID は、POSIX 標準に準拠します。
  • Windows は セキュリティー ID (SID) を使用します。
AD ユーザーなど、Red Hat Enterprise Linux システムに対して認証を行うユーザーには、必ず UID と GID を割り当てる必要があります。この目的で、SSSD は以下の統合オプションを提供します。
AD ユーザーに対する新規 UID と GID の自動生成
SSSD は、AD ユーザーの SID を使用して、ID マッピング と呼ばれるプロセスで POSIX ID をアルゴリズム的に生成できます。ID マッピングにより、AD の SID と Linux の ID 間のマッピングを作成します。
  • SSSD により新しい AD ドメインが検出されると、この新規ドメインに利用可能な ID 範囲を割り当てます。そのため、すべての SSSD クライアントマシンの各 AD ドメインには同じ ID 範囲が設定されます。
  • AD ユーザーが SSSD クライアントマシンに初めてログインすると、SSSD により、ユーザーの SID やそのドメインの ID 範囲をベースにした UID など、ユーザーのエントリーが SSSD キャッシュに作成されます。
  • AD ユーザーの ID は、同じ SID をもとに 、一貫したかたちで生成されるので、ユーザーはどの Red Hat Enterprise Linux システムにログインする場合も同じ UID と GID を使用します。

注記

全クライアントシステムが SSSD を使用して SID を Linux ID にマッピングする場合には、マッピングは一貫性が保たれますが、一部のクライアントが異なるソフトウェアを使用する場合には、以下のいずれかを選択してください。
  • 同じマッピングアルゴリズムが全クライアントで使用されていることを確認します。
  • AD に定義されている POSIX 属性の使用 で説明されているように、明示的な POSIX 属性を使用します。
AD に定義されている POSIX 属性の使用
AD は、uidNumbergidNumberunixHomeDirectory、または loginShell などの POSIX 属性を作成して保存します。
AD ユーザーに対する新規 UID と GID の自動生成 で説明されている ID マッピングを使用する場合には、SSSD は新しい UID および GID を作成し、AD で定義されている値を上書きします。AD で定義された値を保持するには、SSSD の ID マッピングを無効にします。

2.1.2. SSSD のプロバイダーとして ID マッピングを使用した AD ドメインの設定

前提条件

AD システムと Linux システムの両方が正しく設定されていることを確認してください。
  • 名前解決の設定を確認します。特に、DNS SRV レコードを検証します。たとえば、ad.example.com という名前のドメインの場合には、以下を実行してください。
    • DNS SRV の LDAP レコードを検証します。
      # dig -t SRV _ldap._tcp.ad.example.com
    • AD レコードを検証します。
      # dig -t SRV _ldap._tcp.dc._msdcs.ad.example.com
    後ほど、特定の AD ドメインコントローラーに SSSD を接続する場合には、DNS SRV レコードを検証する必要はありません。
  • 両システムのシステム時刻が同期されていることを確認します。これで、Kerberos が正しく機能できるようになります。
  • Linux システムとすべての AD ドメインコントローラー両方で 必要とされるポート を、Linux システムから AD ドメインコントローラー、AD ドメインコントローラーから Linux システムの両方向で開放します。

    表2.1 SSSD を使用して Linux と AD を直接統合するのに必要なポート

    サービスポートプロトコル備考
    DNS53UDP および TCP 
    LDAP389UDP および TCP 
    Kerberos88UDP および TCP 
    Kerberos464UDP および TCPパスワードの設定や変更に kadminにより使用されます
    LDAP グローバルカタログ3268TCPid_provider = ad オプションを使用する場合
    NTP123UDPオプション

ローカルシステムの設定

Red Hat は、realm join コマンドを使用して、システムを設定することを推奨します。3章realmd を使用した Active Directory ドメインへの接続を参照してください。realmd スイートは、自動的に必要な設定すべてを編集します。以下に例を示します。
# realm join ad.example.com
realmd, を使用しない場合には、手動でシステムを設定できます。Red Hat  ナレッジベースの 「Manually Connecting an SSSD Client to an Active Directory Domain 」 を参照してください。

オプション: ユーザーのホームディレクトリーおよびシェルの設定

pam_oddjob_mkhomedir.so ライブラリーは、ユーザーが Linux システムに初回ログインした時に、自動的にホームディレクトリーを作成します。デフォルトでは、SSSD は AD アイデンティティープロバイダーからホームディレクトリーの形式を取得します。Linux クライアントでディレクトリーの形式をカスタマイズするには、以下を実行します。
  1. /etc/sssd/sssd.conf ファイルを開きます。
  2. [domain] セクションで、以下のオプションのいずれかを使用します。
    • fallback_homedir は、フォールバックするホームディレクトリー形式を設定し、ホームディレクトリーが AD に定義されていない場合のみ使用されます。
    • override_homedir はホームディレクトリーを設定して、AD に定義されているホームディレクトリーを常に上書きします。
    たとえば、/home/domain_name/user_name の形式を常に使用するようにします。
    [domain/EXAMPLE]
    [... file truncated ...]
    override_homedir = /home/%d/%u
    詳細は、sssd.conf(5) man ページを参照してください。
デフォルトでは、SSSD は AD で設定した loginShell パラメーターからユーザーシェルに関する情報を取得します。Linux クライアントでユーザーシェルの設定をカスタマイズするには、以下を実行します。
  1. /etc/sssd/sssd.conf ファイルを開きます。
  2. 以下のオプションを使用して、必要なユーザーシェルの設定を定義します。
    • shell_fallback はフォールバック値を設定し、シェルが AD で定義されていない場合にのみ使用されます。
    • override_shell は、AD で定義したシェルを常に上書きする値を設定します。
    • default_shell はデフォルトのシェル値を設定します。
    • allowed_shells および vetoed_shells は、許可するシェルまたはブラックリストに追加するシェルの一覧を設定します。
    詳細は、sssd.conf(5) man ページを参照してください。

新規設定の読み込み

  • 設定ファイルを変更した後に SSSD を再起動します。
    # systemctl restart sssd.service

その他のリソース

  • LDAP および Kerberos プロバイダーの他の設定オプションについては、sssd-ldap(5) および sssd-krb5(5) man ページを参照してください。
  • AD プロバイダーの他の設定オプションについては、sssd-ad(5) man ページを参照してください。

2.1.3. SSSD が AD で定義されている POSIX 属性を使用するように設定

注記

以前のリリースでは、ユーザーアカウントに POSIX 属性を提供するために UNIX のアイデンティティー管理 拡張が提供されていました。この拡張は、非推奨になりました。詳細は、Microsoft Developer Network を参照してください。
UNIX のアイデンティティー管理を使用してきた場合には、よくある質問の回答については このナレッジ記事 を参照してください。
Unix のアイデンティティー管理およびUnix のサービス パッケージに関する以前の手順については、以下のRed Hat ナレッジアーティクルを参照してください。

推奨情報

最適なパフォーマンスを実現するためには、POSIX 属性を AD グローバルカタログに公開します。POSIX 属性がグローバルカタログにない場合には、SSSD は LDAP ポート上にある個別のドメインコントローラーに直接接続します。

AD ドメインへの Linux システムの参加

SSSD での ID マッピングの無効化

  1. /etc/sssd/sssd.conf ファイルを開きます。
  2. ADドメインのセクションで、ldap_id_mapping = false の設定を追加します。

    注記

    realm ユーティリティーを使用してドメインと結合し、--automatic-id-mapping=no スイッチを追加した場合には、realm ユーティリティーにより SSSD は ldap_id_mapping = false ですでに設定されています。
  3. 以前にデフォルトの ID マッピング設定が指定されたユーザーを要求した場合には、SSSD キャッシュを削除します。
    rm -f /var/lib/sss/db/*
SSSD は、ローカルで作成するのではなく、AD からの POSIX 属性を使用します。