Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
コンテンツコンテンツ
セキュリティ強化ガイド
  1. 前書き
  2. 1 セキュリティと機密保持
  3. 2 コモンクライテリア (Common Criteria)
  4. I 認証
    1. 3 PAM を利用した認証
    2. 4 NIS の使用
    3. 5 YaST を利用した認証クライアントの設定
    4. 6 389 LDAP ディレクトリサービス
    5. 7 Kerberos を利用したネットワーク認証
    6. 8 Active Directory サポート
    7. 9 FreeRADIUS サーバの構築
  5. II ローカルセキュリティ
    1. 10 物理的なセキュリティ
    2. 11 seccheck を利用した自動的なセキュリティチェック
    3. 12 ソフトウエア管理
    4. 13 ファイルの管理
    5. 14 パーティションやファイルの暗号化
    6. 15 cryptctl を利用したアプリケーション向けのストレージ暗号化
    7. 16 ユーザ管理
    8. 17 Spectre/Meltdown チェッカー
    9. 18 YaST を利用したセキュリティの設定
    10. 19 PolKit による認可制御
    11. 20 Linux でのアクセス制御リスト
    12. 21 証明書ストア
    13. 22 AIDE を利用した侵入検知
  6. III ネットワークセキュリティ
    1. 23 X Window System と X 認証
    2. 24 SSH: 機密を保持するネットワーク操作
    3. 25 マスカレードとファイアウオール
    4. 26 VPN サーバの設定
    5. 27 X Window System で動作する PKI マネージャ XCA による管理
  7. IV AppArmor による権限の制限
    1. 28 AppArmor の紹介
    2. 29 入門
    3. 30 プログラムに対する予防接種
    4. 31 プロファイルのコンポーネントと文法
    5. 32 AppArmor のプロファイルリポジトリ
    6. 33 YaST を利用したプロファイルの構築と管理
    7. 34 コマンドラインからのプロファイル構築
    8. 35 チェンジハット機能による Web アプリケーションのプロファイル作成
    9. 36 pam_apparmor によるユーザの制限
    10. 37 プロファイルを作成したアプリケーションの管理
    11. 38 サポート
    12. 39 AppArmor 用語集
  8. V SELinux
    1. 40 SELinux の設定
  9. VI Linux 監査フレームワーク
    1. 41 Linux 監査システムの概要
    2. 42 Linux 監査フレームワークの設定
    3. 43 監査ルールセットの紹介
    4. 44 その他の情報源
  10. A GNU ライセンス
ナビゲーション
適用先 openSUSE Leap 15.2

6 389 LDAP ディレクトリサービス

概要

軽量ディレクトリアクセスプロトコル (Lightweight Directory Access Protocol (LDAP)) は情報ディレクトリへのアクセスや管理に使用するプロトコルです。 LDAP はユーザやグループのほか、システム設定の管理やアドレスの管理などにも使用することができます。 openSUSE Leap 15.3 では、 389 Directory Server が提供する LDAP サービスを使用することができます。これは従来の OpenLDAP の代替として提供されているものです。

実際には、中央のサーバがディレクトリ内にデータを保管しておき、全てのクライアントに対しては明確に定義されたプロトコルで配布を行います。構造化されたデータの仕組みにより、様々なアプリケーションがそれらのデータにアクセスできるようになります。中央のサーバ (リポジトリとも呼びます) を用意することで管理の手間を省き、 LDAP のようなオープンで標準化されたプロトコルを使用することで、そこで管理されている情報にアクセスするプログラムをできる限り多く用意することができます。

なお、本章での ディレクトリ とは、読み込みや検索の速度や効率性の点で最適化されたデータベースを意味します。ディレクトリ内に保存されたデータは長期にわたって保存され、あまり変更が発生しないものとされます。通常のデータベースシステムであれば、短い時間内にデータの書き込みが多数発生する前提で最適化が行われますが、 LDAP サービスは読み込みに対して大きく最適化されたデータベースとなります。

6.1 LDAP のディレクトリツリー構造

本章では、 LDAP ディレクトリツリーの基本的な配置と、 LDAP に関する基本的な用語を説明しています。 既に LDAP に関する知識をお持ちの場合は、 6.2.1項 「389 Directory Server のインスタンスの構築」 からお読みください。

LDAP ディレクトリはツリー型の構造になっています。ディレクトリ内の全ての項目 (オブジェクトと呼びます) は、この階層構造内での位置が決められています。この階層構造を ディレクトリ情報ツリー (Directory Information Tree (DIT)) と呼びます。また、特定の項目に対して、それを正確に識別するためのパス情報を、 識別名 (Distinguished Name (DN)) と呼びます。またツリー内にあるオブジェクトは 相対識別名 (Relative Distinguished Name (RDN)) でお互いを区別します。 識別名 は、その項目に対する全ての 相対識別名 から構成されています。

LDAP ディレクトリツリーの構造を図に表わすと、 図6.1「LDAP ディレクトリの構造」 のようになります。

LDAP ディレクトリの構造
図 6.1: LDAP ディレクトリの構造

上記は架空のディレクトリ情報ツリーを表わしています。そのうち、 3 階層分の項目のみを図示しています。図の中では、各項目を 1 つの箱として表わしています。たとえば架空の従業員である Geeko Linux に対する完全な 識別名 (DN) は、 cn=Geeko Linux,ou=doc,dc=example,dc=com となります。これは相対識別名である cn=Geeko Linux に対して、階層構造上の親である ou=doc,dc=example,dc=com を追加することによります。

ディレクトリ情報ツリー (DIT) 内に保管できるオブジェクトの種類は、 スキーマ と呼ばれるものに従って設定されます。オブジェクトの種類は オブジェクトクラス と呼ばれ、それに対応するスキーマで、そのオブジェクトが設定しなければならない値や、設定できる値が示されます。そのためスキーマには、 LDAP サーバ内で使用される全てのオブジェクトクラスや属性の定義を含んでいることになります。一方の属性は、構造化されたデータ型です。それらの書式や順序などの情報も、スキーマ内に記述されています。 LDAP サーバには幅広い環境で動作することができるよう、中枢 (コア) スキーマセットが用意されています。必要であれば、独自のスキーマをアップロードすることもできます。

表6.1「よく使用されるオブジェクトクラスと属性」 には、 00core.ldif06inetorgperson.ldif で規定されているオブジェクトクラスの一部と、それらで必須とされている属性、そして属性値の書式を紹介しています。 389-ds パッケージをインストールしている環境であれば、これらは usr/share/dirsrv/schema 内に存在しています。

表 6.1: よく使用されるオブジェクトクラスと属性

オブジェクトクラス

意味

値の例

必須の属性

domain

ドメインの名前パート

example

displayName

organizationalUnit

組織単位

doc

ou

nsPerson

イントラネットもしくはインターネットの個人関連データ

Geeko Linux

cn

また 例6.1「CN=schema からの抜粋」 では、スキーマ定義の例を示しています。

例 6.1: CN=schema からの抜粋
attributetype (1.2.840.113556.1.2.102 NAME 'memberOf' 1
       DESC 'Group that the entry belongs to' 2
       SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 3
       X-ORIGIN 'Netscape Delegated Administrator') 4

objectclass (2.16.840.1.113730.3.2.333 NAME 'nsPerson' 5
       DESC 'A representation of a person in a directory server' 6
       SUP top STRUCTURAL 7
       MUST ( displayName $ cn ) 8
       MAY ( userPassword $ seeAlso $ description $ legalName $ mail \
             $ preferredLanguage ) 9
       X-ORIGIN '389 Directory Server Project'
  ...

1

属性の名前とユニークな OID (オブジェクト識別子 (Object Identifier)) (数字) 、そして属性の略称を表わしています。

2

DESC では属性に対する簡潔な説明を記します。定義の元となった RFC などがあれば、それも記述されます。

3

属性内に保持できるデータの型。この場合、大文字と小文字を区別しない文字列であることを示しています。

4

スキーマ要素のソース (たとえばプロジェクト名) 。

5

オブジェクトクラス nsPerson の定義の始まりです。オブジェクトクラスの定義は属性の定義と同じで、 OID とオブジェクトクラスの名前をそれぞれ記します。

6

そのオブジェクトクラスに対する簡潔な説明です。

7

SUP top と書くことで、このオブジェクトクラスの上位に存在するオブジェクトクラスが存在していないことを表わしています。

8

MUST 以下には、 nsPerson のオブジェクトクラスで、設定されなければならない全ての属性種類を記します。

9

MAY 以下には、そのオブジェクトクラスで設定することのできる全ての属性種類を記します。

6.2 389 Directory Server のインストール

389-ds パッケージには、 389 Directory Server と管理ツールが含まれています。下記のコマンドを入力して実行し、インストールを行ってください:

tux > sudo zypper install 389-ds

インストールを行った後は、サーバの設定を行ってください (詳しくは 6.2.1項 をお読みください)

6.2.1 389 Directory Server のインスタンスの構築

dscreate コマンドを使用することで、 389 Directory Server のインスタンスを作成したりきれいに削除したりすることができます。

インスタンスの作成方法には 2 つの種類があります。 1 つめは設定ファイルを使用する方法、もう 1 つは自動生成されたテンプレート (雛型) ファイルを使用する方法です。なお、自動生成されたテンプレートファイルを使用して本番環境を作成する場合は、内容をよく読んで注意深く設定してください。

インスタンスを作成したら、あとは管理者用のアカウントを作成して、必要なユーザとグループを管理してサービスを動作させてください。

下記の手順を実施することで、いくつかのサンプル用エントリを含むテスト目的や開発目的のインスタンスを構築することができます。

389 Directory Server は主に 3 つのコマンドで制御します:

dsctl

ローカルのインスタンス管理に使用するコマンドで、 root の権限が必要となります。なお、このコマンドを実行するには、ディレクトリサーバインスタンスの動作しているサーバ内にいなければなりません。起動や停止、データベースのバックアップなどを行うことができます。

dsconf

サーバの管理や設定を行うための主要なツールです。外部インターフェイスを介してインスタンスの設定を管理することができます。このコマンドを使用することで、インスタンスをリモートから設定変更することができます。

dsidm

識別子 (ユーザ/グループ/パスワードなど) を管理するために使用します。なお、アクセス制御機能で許可を得ておく必要があります。一般ユーザの場合、自分自身のパスワードのリセットや詳細情報の変更などを行うことができます。

6.2.2 独自の設定ファイルを利用した 389 Directory Server インスタンスの作成

シンプルな設定ファイルを使用することで、新しい 389 Directory Server インスタンスを作成することができます。このファイルは INF と呼ばれる形式でなければなりませんが、ファイル名に関しては任意の名前を使用することができます。

既定のインスタンス名は localhost です。インスタンス名は作成後に変更することができませんので、混乱を避けるとともに、動作を良く理解できるよう、既定値ではなく独自の名前を指定しておくことをお勧めします。

例 6.2 には新しい 389 Directory Server インスタンスを作成する際の設定ファイルの例が示されています。この内容をそのまま利用してもかまいませんが、パスワードについては独自のものを設定しておいてください。

  1. 下記の内容をホームディレクトリ内の ldap1.inf というファイルに保存します:

    例 6.2: 389 Directory Server を構築するための最小限のインスタンス設定ファイル
    # ldap1.inf
            
    [general]
    config_version = 2 1
    
    [slapd]
    root_password = password2
    self_sign_cert = True 3
    instance_name = ldap1
    
    [backend-userroot]
    sample_entries = yes 4
    suffix = dc=ldap1,dc=com

    1

    この行は必ず指定しておいてください。ここでは INF ファイルのバージョンが 2 であることを示しています。

    2

    cn=Directory Manager という LDAP ユーザに対するパスワードを、 root_password で指定しています。このユーザは、ディレクトリサービスに接続 (バインド) するために使用するものです。

    3

    自己署名型のサーバ証明書を /etc/dirsrv/slapd-インスタンス名 に作成することを宣言しています。

    4

    サンプルユーザとサンプルグループをそれぞれ新しいインスタンス内に作成するよう指示しています。

  2. 例 6.2 から 389 Directory Server のインスタンスを作成するには、下記を実行します:

    tux > sudo dscreate -v from-file ldap1.inf | tee ldap1-output.txt

    上記のコマンドを実行するとインスタンスが作成され、作成の際に出力された様々な情報が 389ds-test-output.txt に書き込まれます。出力されたテキストファイルには様々な情報が含まれています。このファイルを作成したくない場合は、上記のコマンドラインのうち、 | tee 389ds-test-output.txt の部分を削除してください。

  3. dscreate コマンドの実行が失敗した場合には、メッセージ内にその理由が示されますので、その原因を解決してからいったんインスタンスを削除 (詳しくは ステップ 5 をお読みください) してから、インスタンスを作成し直してください。

  4. インスタンスの作成が成功すると、 " Completed installation for ldap1 " というメッセージが出力されます。あとは作成したインスタンスの状態を確認します:

    tux > sudo dsctl ldap1 status
    Instance "ldap1" is running
  5. 下記のコマンドはインスタンスをきれいに削除するためのコマンドです。前者のコマンドでは削除が正しくできるかどうかを確認 (ドライラン) し、後者のコマンドで実際の削除を行っています。後者のコマンドでは、 --do-it オプションを忘れずに指定してください:

    tux > sudo dsctl ldap1 remove
    Not removing: if you are sure, add --do-it
    
    tux > sudo dsctl ldap1 remove --do-it

    このコマンドを実行することで、部分的にインストールが完了していたり、壊れてしまったりしたインスタンスを削除することもできます。インスタンスの作成も削除も、必要に応じて何度でも実行することができます。

インスタンス名を忘れてしまった場合は、 dsctl コマンドを実行して全てのインスタンスを表示させてください:

tux > /usr/sbin/dsctl -l
slapd-ldap1

6.2.3 テンプレートからの 389 Directory Server インスタンスの作成

dscreate コマンドを使用することで、テンプレート (雛型) を自動生成することができます。このコマンドでは、そのまま使用できる形でテンプレートが作成されますので、あとは必要に応じて様々な箇所を修正するだけでインスタンスを作成することができます。なお、全ての設定に対する既定値はテンプレートファイル内のコメントとして説明 (英語) が書かれています。設定を変更する場合は既定値のコメント文字 (' を外して、必要な値を記入していってください。いずれのオプションに対しても詳しく説明が書かれています。

下記のコマンドを入力して実行すると、設定例を標準出力に出力することができます:

tux > dscreate create-template

上記のコマンドを実行すると標準出力にテンプレートが出力されますが、このままでは使用できません。下記のようにして任意のファイル名を指定して、そのファイル内にテンプレートを出力してください:

tux > dscreate create-template ldap1-template.txt

下記は出力されたテンプレートの抜粋です:

# full_machine_name (str)
# Description: Sets the fully qualified hostname (FQDN) of this system. When 
# installing this instance with GSSAPI authentication behind a load balancer, set 
# this parameter to the FQDN of the load balancer and, additionally, set 
# "strict_host_checking" to "false".
# Default value: ldapserver1.test.net
;full_machine_name = ldapserver1.test.net

# selinux (bool)
# Description: Enables SELinux detection and integration during the installation 
# of this instance. If set to "True", dscreate auto-detects whether SELinux is 
# enabled. Set this parameter only to "False" in a development environment.
# Default value: True 
;selinux = True

既存の環境からの既定値を自動的に設定している様子がわかるかと思います。あとはこのファイルを何も変更せずそのまま利用して、新しいインスタンスを作成してみます:

tux > sudo dscreate from-file ldap1-template.txt

これにより、 localhost という名前の新しいインスタンスが作成され、作成が完了すると自動的に開始されます:

tux > sudo dsctl localhost status
Instance "localhost" is running

既定値のままインスタンスを作成しても問題なく動作しますが、いくつかの設定値を変更しておくことで、より本番に近い環境を作成することができます。

インスタンス名は作成後に変更することができませんので、混乱を避けるとともに、動作を良く理解できるよう、既定値ではなく独自の名前を指定しておくことをお勧めします。インスタンス名を変更するには、 ;instance_name = localhost の行のコメント文字 (;) を外して、 localhost を任意の名前に変更してください。ここでは ldap1 という名前を使用しています。

また、もう 1 つ変更すべき箇所として、ユーザ例とグループ例の作成機能があります。必要であれば ;sample_entries = no の箇所のコメント文字を外して、 noyes にしてください。

このほか ;root_password の行のコメント文字 (;) を外して、設定したいパスワードを入力してもかまいません。

また、テンプレート内には既定のサフィックス (LDAP での既定のドメイン名) を指定していませんので、下記のようにして suffix 行で指定を行うことができます:

suffix = dc=ldap1,dc=com

作成したインスタンスをきれいに削除してやり直すには、 dsctl で下記のようなコマンドを入力して実行します:

tux > sudo dsctl ldap1 remove --do-it

6.2.4 389 Directory Server の起動と停止

389 Directory Server サーバのインスタンスを管理するには、 systemd を使用します。まずはサービスの状態を表示するには、下記のように入力して実行します:

tux > systemctl status --no-pager --full dirsrv@ldap1.service       
   ● dirsrv@ldap1.service - 389 Directory Server ldap1.
     Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled)
     Active: active (running) since Thu 2021-03-11 08:55:28 PST; 2h 7min ago
    Process: 4451 ExecStartPre=/usr/lib/dirsrv/ds_systemd_ask_password_acl /etc/dirsrv/slapd-ldap1/dse.ldif (code=exited, status=0/SUCCESS)
   Main PID: 4456 (ns-slapd)
     Status: "slapd started: Ready to process requests"
      Tasks: 26
     CGroup: /system.slice/system-dirsrv.slice/dirsrv@ldap1.service
             └─4456 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-ldap1 -i /run/dirsrv/slapd-ldap1.pid

サービスの起動と停止を行うには、それぞれ下記のように入力して実行します:

tux > sudo systemctl start dirsrv@ldap1.service
tux > sudo systemctl stop dirsrv@ldap1.service

systemctl の使用方法について、詳しくは 第10章 「systemd デーモン をお読みください。

なお、 dsctl コマンドでもサービスの起動と停止を行うことができます:

tux > sudo dsctl ldap1 status
tux > sudo dsctl ldap1 stop
tux > sudo dsctl ldap1 restart
tux > sudo dsctl ldap1 start

6.2.5 ローカル管理用の管理者認証情報の設定

389 Directory Server のローカル管理を行う目的で、 /root ディレクトリ内に .dsrc 設定ファイルを作成することができます。これにより、管理者 (root) や sudo 経由で管理権限を取得したユーザが、わざわざ 389 Directory Server の管理者情報を入力したりすることなく管理できるようになります。 例 6.3 には、サーバをローカル管理する場合の例が示されています。下記はインスタンス名が ldap1 、マシンのドメイン名が test3.com である場合の例です。

/root/.dsrc ファイルを作成したら、あとは新しいユーザを作成していきます (詳しくは 6.4項 「LDAP ユーザとグループの作成」 をお読みください) 。

例 6.3: ローカル管理用の .dsrc ファイル
# ldap1 インスタンスを管理するための /root/.dsrc ファイルの例
         
[ldap1] 1

uri = ldapi://%%2fvar%%2frun%%2fslapd-ldap1.socket 2
basedn = dc=ldap1,dc=com
binddn = cn=Directory Manager

1

ここには管理対象のインスタンス名を指定します。

2

ldapi は接続しようとしているユーザの UID や GID を検出することができるプロトコルで、 UID/GID が 0/0 もしくは dirsrv:dirsrv であった場合、ディレクトリサーバに対して管理者 (つまり cn=Directory Manager) でログインできるようになります。

なお URI の指定では、スラッシュを %%2f に置き換える必要があります。この例では、 /var/run/slapd-ldap1.socket というパスを表わしています。

6.3 ファイアウオールの設定

389 Directory Server の既定の TCP ポートは 389 と 636 です。 TCP:389 は暗号化を行わない接続および STARTTLS を使用する接続向けに、 TCP:636 は TLS での暗号化を行う接続向けに使用します。

firewalld は SUSE Linux Enterprise における既定のファイアウオールマネージャです。下記のコマンドを実行すると、 ldap および ldaps の各サービスを有効化することができます:

tux > sudo firewall-cmd --add-service=ldap --zone=ゾーン名
tux > sudo firewall-cmd --add-service=ldaps --zone=ゾーン名
tux > sudo firewall-cmd --runtime-to-permanent

なお、 zone 以下の値はお使いのサーバに合わせて設定してください。なお、 TLS での接続の暗号化に関する詳細は 6.7項 「TLS 向けの CA (証明機関) 証明書の使用」 を、 firewalld に関する詳細は 25.3項 「基本的なファイアウオール処理」 をそれぞれお読みください。

6.4 LDAP ユーザとグループの作成

ユーザとグループは dsidm コマンドで作成および管理を行います。このコマンドは対話的に動作させることができるほか、コマンドラインでパラメータを指定して実行することもできます。

現時点で設定済みのユーザとグループの一覧を表示するには、下記のように入力して実行します:

tux > sudo dsidm ldap1 user list
tux > sudo dsidm ldap1 group list

特定のユーザに対する全ての情報を表示させるには、下記のように入力して実行します:

tux > sudo dsidm ldap1 user get ユーザ名

特定のグループに対する全ての情報を表示させるには、下記のように入力して実行します:

tux > sudo dsidm ldap1 group get グループ名

グループのメンバー一覧を表示するには、下記のように入力して実行します:

tux > sudo dsidm ldap1 group members グループ名

下記の例では 2 人のユーザ wilbergeeko を作成します。このとき、必要なデータはコマンドラインパラメータで指定し、サーバインスタンスは ldap1 、サフィックスは dc=ldap1,dc=com であるものとします。

手順 6.1: LDAP ユーザの作成

LDAP ユーザは一般的なユーザアカウントを表わすもので、ログイン時に使用できるものであるほか、ホームディレクトリも設定することができます。 LDAP サーバにユーザを追加することで、ネットワーク内のユーザアカウントを統一的に管理できるようになります。なお、ユーザを作成するにあたっては、誤った情報を設定しないように注意してください。誤った情報を設定してしまうと、その情報をもとにログインできるようになってしまうためです。設定されている情報を確認したい場合は、 id コマンドで確認してください。下記の例では Wilber Fox というユーザに対する情報を確認しています:

tux > id geeko
uid=1001(wilber) gid=100(users) groups=100(users)
  1. wilber という LDAP ユーザを作成したい場合は、下記のように入力して実行します:

    tux > sudo dsidm ldap1 user create --uid wilber \
      --cn wilber --displayName 'Wilber Fox' --uidNumber 1001 --gidNumber 100 \
      --homeDirectory /home/wilber
  2. ユーザの distinguished name (DN) 名 (ディレクトリオブジェクトに対する完全修飾名、つまり唯一性の保証された名前) を参照するには、下記のように入力して実行します:

    tux > sudo dsidm ldap1 user get wilber
    dn: uid=wilber,ou=people,dc=ldap1,dc=com
    [...]

    ユーザのパスワード変更などの処理を行うには、 distinguished name (DN) を指定する必要があります。

  3. wilber ユーザに対するパスワードを作成するには、下記のように入力して実行します:

    1. tux > sudo dsidm ldap1 account reset_password \
        uid=wilber,ou=people,dc=ldap1,dc=com
    2. あとは wilber に設定するパスワードを 2 回入力します。

      パスワードの設定が完了すると、下記のようなメッセージが表示されるはずです:

      reset password for uid=wilber,ou=people,dc=ldap1,dc=com

      設定済みのパスワードを変更したい場合も、同じコマンドで行うことができます。

  4. 続いて geeko ユーザを作成します:

    tux > sudo dsidm ldap1 user create --uid geeko\
      --cn geeko --displayName 'Suzanne Geeko' \
      --uidNumber 1001 --gidNumber 100 --homeDirectory /home/geeko
      
    tux > sudo dsidm ldap1 account reset_password \
      uid=geeko,ou=people,dc=ldap1,dc=com
  5. 認証が正しく動作することを確認します:

    tux > ldapwhoami -D uid=wilber,ou=people,dc=ldap1,dc=com -W
    Enter LDAP Password: 
    dn: uid=wilber,ou=people,dc=ldap1,dc=com
手順 6.2: LDAP グループの作成とユーザの割り当て

下記の手順では server_admins という名前のグループを作成し、そのグループに wilber ユーザを所属させます。このとき、インスタンス名は ldap1 、サフィックスは dc=ldap1,dc=com であるものとします。

  1. まずはグループを作成します:

    tux > sudo dsidm ldap1 group create

    すると、グループ名の入力を求められます。下記のように入力します:

    Enter value for cn : server_admins
  2. wilber ユーザをグループに追加します:

    tux > sudo dsidm ldap1 group add_member server_admins uid=wilber,ou=people,dc=ldap1,dc=com
    added member: uid=wilber,ou=people,dc=ldap1,dc=com

6.5 SSSD の設定

SSSD (System Security Services Daemon) はリモートの識別子プロバイダとの通信を行い、 pamnsswitch にデータを渡すことのできるデーモンです。 SSSD には複数のバックエンドを設定することができるほか、ユーザとグループのキャッシュ機能や、 SSH の鍵配布などの機能に対応しています。

  1. まずは別のサーバに sssdsssd-ldap の各パッケージをインストールします:

    tux > sudo zypper in sssd sssd-ldap
  2. sssd と衝突してしまうことから、 nscd デーモンを無効化して停止します:

    tux > sudo systemctl disable nscd && systemctl stop nscd
  3. SSSD の設定ファイルを作成して、 手順 6.2 で作成しておいた server_admins グループのメンバーのみがログインできるように設定します:

    ヒント
    ヒント

    なお、 memberOf プラグインを有効化しておく必要があります。これにより、クライアントはログインと認可を行うことができるようになります (詳しくは 6.6項 「モジュールの管理」 をお読みください) 。

    tux > sudo dsidm localhost client_config sssd.conf server_admins
  4. 出力内容を確認して、内容を /etc/sssd/sssd.conf に貼り付けます。必要であれば、ここから設定ファイルを調整してもかまいません。

  5. お使いのクライアントで証明書を設定するには、 LDAP サーバからクライアントに対して、 ca.crt をコピーします:

    tux > sudo mkdir -p /etc/openldap/certs
    cp [...]>/ca.crt /etc/openldap/certs/
    /usr/bin/c_rehash /etc/openldap/certs
  6. SSSD を有効化して開始します:

    tux > sudo systemctl enable sssd
    systemctl start sssd
  7. SSSD を PAM と NSS の一部として動作させる場合は、 https://www.port389.org/docs/389ds/howto/howto-sssd.html にある Configure PAM (SUSE)Configure NSS (SUSE) の手順に従って作業を行ってください。

  8. 全ての設定が完了すると、 wilber は 389 Directory Server の情報をもとに、 SSH を介して SSSD を設定したマシンにログインできるようになります。 wilber がログインできない場合は、 手順 6.2 の手順で示した server_admins グループへの所属をご確認ください。

6.6 モジュールの管理

下記のようにコマンドを入力して実行することで、有効化されているモジュールと無効化されているモジュールの全てを表示することができます:

tux > sudo dsconf -D "cn=Directory Manager" ldap//:ldapserver1 plugin list
    Enter password for cn=Directory Manager on ldap://ldapserver1: 
7-bit check
Account Policy Plugin
Account Usability Plugin
ACL Plugin
ACL preoperation
[...]

たとえば 6.5項 「SSSD の設定」 で言及している memberOf プラグインを有効化するには、下記のように入力して実行します:

tux > sudo dsconf -D "cn=Directory Manager" ldap://ldapserver1 plugin memberof enable

なお、一覧表示した場合とは異なり、プラグイン名は大文字と小文字を区別して扱うことに注意してください。また、プラグインを有効化したあとは、サービスを再起動する必要があります。サービスの再起動を行いたくない場合は、 nsslapd-dynamic-plugins パラメータを on にしてください:

tux > sudo dsconf -D "cn=Directory Manager" ldap://ldapserver1 config replace nsslapd-dynamic-plugins=on
  Enter password for cn=Directory Manager on ldap://ldapserver1: 
Successfully replaced "nsslapd-dynamic-plugins"

6.7 TLS 向けの CA (証明機関) 証明書の使用

389 Directory Server 向けの CA 証明書の管理にあたっては、下記に示すコマンドラインツールを使用することができます: certutil , openssl , pk12util

テスト用に証明書を作成したい場合は、 dscreate コマンドで自己署名証明書を作成することができます。証明書は /etc/dirsrv/slapd-localhost/ca.crt にあるものとして扱われます。リモートから管理を行う場合は、証明書を読み取り可能な場所にコピーしておいてください。本番環境の場合は、ご利用の証明機関にお問い合わせのうえ、サーバ証明書とクライアント証明書、そしてルート証明書をそれぞれ取得してください。

下記の手順を実行する前に、まずは以下の要件を全て満たしていることをご確認ください:

  • TLS 接続時に使用するサーバ証明書と、それに対応する機密鍵を保持していること。

  • NSS (Network Security Services) データベースを設定してあること (例: certutil コマンド) 。

NSS (Network Security Services) データベース内に機密鍵と証明書を取り込む場合には、あらかじめ機密鍵とサーバ証明書をひとまとめにしておく必要があります。ひとまとめにしたファイルは *.p12 (PKCS12 形式) というファイル名になります。

重要
重要: *.p12 ファイルとフレンドリ名について

PKCS12 形式のバンドルファイル (*.p12) を作成する場合、鍵と証明書の対に対してフレンドリ名を設定しなければなりません。

本手順で TLS 接続を有効化する場合は、フレンドリ名を Server-Cert に設定してください。それ以外の名前を使用してしまうと、 389 Directory Server が証明書を検出することができず、 TLS 接続ができなくなってしまいます。

また、 NSS データベースに *.p12 ファイルを取り込んでしまうと、フレンドリ名は変更できなくなりますのでご注意ください。

  1. PKCS12 バンドルファイルを指定のフレンドリ名で作成するには、下記のように入力して実行します:

    root # openssl pkcs12 -export -in SERVER.crt \
      -inkey SERVER.key -out SERVER.p12 \
      -name Server-Cert

    ここで、 SERVER.crt にはサーバの証明書として使用するファイルを、 SERVER.key には対応する機密鍵のファイルをそれぞれ指定します。なお、 -out では *.p12 ファイルのファイル名を指定します。 -name はフレンドリ名を指定する箇所で、ここは必ず Server-Cert のままにしておいてください。

  2. ファイルを NSS データベースに取り込むにあたっては、ファイルのパスワードを指定する必要があります。パスワードを指定するには、下記のようなコマンドを入力して実行します:

    pk12util -i SERVER.p12_ファイルのパス -d sql:NSS_データベースのパス -n Server-cert -W SERVER.p12_ファイルのパスワード

    パスワードを設定すると、 NSS_データベースのパス で指定したディレクトリ内に pwdfile.txt ファイルが作成されます。

  3. あとは SERVER.p12 ファイルを NSS データベース内に取り込みます:

    pk12util -i SERVER.p12 -d NSS_データベースのパス

6.8 さらなる情報

389 Directory Server に関する詳細については、提供元のドキュメンテーションをお読みください。ドキュメンテーションは https://www.port389.org/docs/389ds/documentation.html にあります。

このページを印刷