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

5 389 Directory Server を利用した LDAP サービス Edit source

概要

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

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

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

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

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

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

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

LDAP ディレクトリの構造
図 5.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 サーバには幅広い環境で動作することができるよう、中枢 (コア) スキーマセットが用意されています。必要であれば、独自のスキーマをアップロードすることもできます。

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

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

オブジェクトクラス

意味

値の例

必須の属性

domain

ドメインの名前パート

example

displayName

organizationalUnit

組織単位

documentationdept

ou

nsPerson

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

Tux Linux

cn

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

例 5.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 以下には、そのオブジェクトクラスで設定することのできる全ての属性を記します。

389 Directory Server の Docker コンテナの作成と管理 Edit source

注記
注記

本章は 任意 で参照すべき項目であり、 389 Directory Server を Docker コンテナ下で動作させたい場合にのみ読むべきものです。通常のサーバ内への 389 Directory Server のインストールや管理については、本章以外の章をお読みください。

389 Directory Server インスタンスを Docker のコンテナとして作成して管理したい場合は、下記の手順をお読みください:

389 Directory Server イメージの取得

コンテナレジストリから 389 Directory Server のイメージを取得するには、下記のようなコマンドを実行します:

>  docker pull 389ds/dirsrv:latest
新しいボリュームの作成

コンテナに対して新しいボリュームを作成するには、下記のようなコマンドを実行します:

>  docker volume create ボリューム名
コンテナの作成 (基本設定も併せて実施)

基本的な設定を行いながらコンテナを作成したい場合は、下記のようなコマンドを実行します:

>  docker create \
 -u ユーザ名 \
 -e SUFFIX_NAME="dc=example,dc=com" \
 -e DS_DM_PASSWORD=パスワード \
 -m 1024M \
 -p 3389:3389 -p 3636:3636 \
 -v ボリューム名:/data \
 --name インスタンス名 \
 389ds/dirsrv:latest
389 Directory Server の Docker コンテナの起動

Docker コンテナを起動するには、下記のようなコマンドを実行します:

>  docker start インスタンス名
動作中の 389 Directory Server コンテナ内でのコマンドの実行

ここでは、コンテナ内でのプライマリプロセス ( PID 1 ) が動作していることを前提にしています。 389 Directory Server コンテナ内でコマンドを実行するには、下記のような書式で記述して実行します:

> sudo docker exec -u ユーザ名 -i -t インスタンス名 コマンド
注記
注記: コマンド は実行可能なものでなければならない件について

複数のコマンドを連続して実行したり、コマンド内で引用符を利用したりしたい場合は、コンテナに添付されている sh シェルを介して実行する方法があります:

> sudo docker exec -u ユーザ名 -i -t インスタンス名 sh -c "コマンド"
389 Directory Server のコンテナの停止

動作中の Docker コンテナを停止するには、下記のようなコマンドを実行します:

>  docker stop インスタンス名
389 Directory Server の Docker コンテナの削除

Docker コンテナを削除するには、下記のようなコマンドを実行します:

>  docker rm インスタンス名

389 Directory Server のインストール Edit source

下記のコマンドで 389 Directory Server をインストールすることができます:

> sudo zypper install 389-ds

インストールを行った後は、 5.3.1項 「389 Directory Server のインスタンスの構築」 に示されている内容に従って、 サーバの設定を行ってください。

5.3.1 389 Directory Server のインスタンスの構築 Edit source

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

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

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

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

dsctl

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

dsconf

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

dsidm

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

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

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

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

既定のインスタンス名は localhost です。インスタンス名は作成後に変更することができませんので、混乱を避けるとともに、動作を良く理解できるよう、既定値ではなく独自の名前を指定しておくことをお勧めします。なお、下記の例では LDAP1 というインスタンス名で、サフィックス (LDAP での既定のドメイン名) が dc= LDAP1 ,dc= COM である場合の例を示しています。

例 5.2 には新しい 389 Directory Server インスタンスを作成する際の設定ファイルの例が示されています。この内容を修正せずそのまま利用してもかまいません。

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

    例 5.2: 389 Directory Server を構築するための最小限のインスタンス設定ファイル
    # LDAP1.inf
    
    [general]
    config_version = 2 1
    
    [slapd]
    root_password = パスワード2
    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-LDAP1 に作成することを宣言しています。

    4

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

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

    > sudo dscreate -v from-file LDAP1.inf | \
    tee LDAP1-OUTPUT.txt

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

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

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

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

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

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

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

> sudo dsctl -l
slapd-LDAP1

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

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

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

> sudo dscreate create-template

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

> sudo dscreate create-template 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

システムの完全修飾ドメイン名 (テンプレート内の full_machine_name) など、既存の環境からの既定値を自動的に設定している様子がわかるかと思います。あとはこのファイルを何も変更せずそのまま利用して、新しいインスタンスを作成してみます:

> sudo dscreate from-file TEMPLATE.txt

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

> sudo dsctl localhost status
Instance "localhost" is running

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

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

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

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

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

suffix = dc=LDAP1,dc=COM

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

> sudo dsctl LDAP1 remove --do-it

5.3.4 389 Directory Server の起動と停止 Edit source

389 Directory Server のインスタンスを管理するには、 systemd を使用します。まずはサービスの状態を表示するには、下記のように入力して実行します (下記はインスタンス名が LDAP1 である場合の例です):

> 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

LDAP サーバの起動/停止/再起動を行うには、それぞれ下記のように入力して実行します:

> sudo systemctl start dirsrv@LDAP1.service
> sudo systemctl stop dirsrv@LDAP1.service
> sudo systemctl restart dirsrv@LDAP1.service

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

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

> sudo dsctl LDAP1 status
> sudo dsctl LDAP1 stop
> sudo dsctl LDAP1 restart
> sudo dsctl LDAP1 start

5.3.5 ローカル管理用の管理者認証情報の設定 Edit source

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

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

例 5.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 というパスを指定しています。

重要
重要: sudoers.ldap の次世代新機能について

sudo 1.9.9 以前のバージョンでは、 sudoers.ldap のうち sudoUser , sudoRunAsUser , sudoRunAsGroup の各属性で否定表現が正しく動作しませんでした。たとえば下記のようになっていました:

 # joe 以外の全員にマッチさせるつもりが、
# 全員を対象外としてしまう例
sudoUser: !joe

# 同様に joe 以外の全員にマッチさせるつもりが、
# joe を含む全員を対象としてしまう例
sudoUser: ALL
sudoUser: !joe

sudo のバージョン 1.9.9 およびそれ以降では、 sudoUser における否定表現が動作するようになっています。詳しくは man 5 sudoers.ldap をお読みください。

ファイアウオールの設定 Edit source

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

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

> sudo firewall-cmd --add-service=ldap --zone=internal
> sudo firewall-cmd --add-service=ldaps --zone=internal
> sudo firewall-cmd --runtime-to-permanent

なお、 zone 以下の値はお使いのサーバに合わせて設定してください。なお、 TLS での接続の暗号化に関する詳細は 5.10項 「TLS 証明書と鍵の取り込み」 を、 firewalld に関する詳細は 23.3項 「基本的なファイアウオール処理」 をそれぞれお読みください。

389 Directory Server でのバックアップと復元 Edit source

389 Directory Server ではオフラインとオンラインの両方のバックアップ形態に対応しています。 dsctl コマンドではオフラインによるデータベースバックアップを、 dsconf コマンドではオンラインによるデータベースバックアップを、それぞれ採取することができます。また、 LDAP サーバの設定ディレクトリをバックアップしておくことで、重大な障害が発生してサーバが復旧不可能になってしまったような場合に対応することもできます。

5.5.1 LDAP サーバ設定のバックアップ Edit source

LDAP のサーバ設定は /etc/dirsrv/slapd-インスタンス名 のディレクトリ内に存在しています。このディレクトリ内には証明書や鍵のほか、 dse.ldif ファイルが含まれています。これらは tar コマンドを利用して圧縮しながらバックアップすることができます:

> sudo tar caf \
config_slapd-インスタンス名-$(date +%Y-%m-%d_%H-%M-%S).tar.gz \
/etc/dirsrv/slapd-インスタンス名/
注記
注記: tar で出力される無害なメッセージについて

なお、上記のような tar コマンドを実行すると、 tar: メンバ名から先頭の `/' を取り除きます のようなメッセージが表示されますが、無視してかまいません。

設定を復元したい場合は、上記で採取したバックアップを同じディレクトリ内に展開します:

  1. まずは既存の設定を上書きしてしまわないよう、既存の設定を移動します:

    > sudo old /etc/dirsrv/slapd-インスタンス名/
  2. 採取したバックアップから展開します:

    > sudo tar -xvzf \
    config_slapd-インスタンス名-日付.tar.gz
  3. 展開したディレクトリとファイルを /etc/dirsrv/slapd-インスタンス名 にコピーします:

    > sudo cp -r etc/dirsrv/slapd-インスタンス名 \
    /etc/dirsrv/slapd-インスタンス名

5.5.2 LDAP データベースに対するオフラインバックアップの採取と復元 Edit source

dsctl コマンドを利用することで、オフラインバックアップを採取することができます。まずはサーバを停止します:

> sudo dsctl インスタンス名 stop
Instance "インスタンス名" has been stopped

下記の例のとおりに実行すると、 /var/lib/dirsrv/slapd-LDAP1/bak/インスタンス名-日付 のようなディレクトリ内にバックアップが作成されます。

> sudo dsctl インスタンス名 db2bak
db2bak successful

たとえばテスト用に作成した ldap1 インスタンスの場合、下記のようなディレクトリになります:

/var/lib/dirsrv/slapd-ldap1/bak/ldap1-2021_10_25_13_03_17

バックアップから復元したい場合は、下記のようにしてバックアップを含むディレクトリを指定します:

> sudo dsctl インスタンス名 bak2db \
/var/lib/dirsrv/slapd-インスタンス名/bak/インスタンス名-日付/
bak2db successful

あとはサーバを起動します:

> sudo dsctl インスタンス名 start
Instance "インスタンス名" has been started

なお、 LDIF 形式でのバックアップを採取することもできます:

> sudo dsctl インスタンス名 db2ldif --replication userRoot
ldiffile: /var/lib/dirsrv/slapd-インスタンス名/ldif/インスタンス名-userRoot-日付.ldif
db2ldif successful

LDIF 形式のバックアップから復元したい場合も同様に、ファイル名を指定して復元し、サーバを起動するだけです:

> sudo dsctl ldif2db userRoot \
/var/lib/dirsrv/slapd-インスタンス名/ldif/インスタンス名-userRoot-日付.ldif
> sudo dsctl インスタンス名 start

5.5.3 LDAP データベースに対するオンラインバックアップの採取と復元 Edit source

dsconf コマンドを利用することで、 LDAP データベースのオンラインバックアップを採取することができます:

> sudo dsconf インスタンス名 backup create
The backup create task has finished successfully

上記を実行すると、 /var/lib/dirsrv/slapd-インスタンス名/bak/インスタンス名-日付 のようなディレクトリ内にバックアップが作成されます。

復元は下記のようにして行います:

> sudo dsconf インスタンス名 backup restore \
/var/lib/dirsrv/slapd-インスタンス名/bak/インスタンス名-日付

LDAP でのユーザとグループの管理 Edit source

ユーザやグループの作成や削除、管理を行うには、 dsidm コマンドを使用します。

5.6.1 既存の LDAP ユーザとグループの表示 Edit source

下記では、既存のユーザとグループを一覧表示する例を示しています。なお、インスタンス名は LDAP1 であるものとします。実際に実行する際には、お使いのインスタンス名に置き換えて実行してください。

> sudo dsidm LDAP1 user list
> sudo dsidm LDAP1 group list

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

> sudo dsidm LDAP1 user get ユーザ名

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

> sudo dsidm LDAP1 group get グループ名

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

> sudo dsidm LDAP1 group members グループ名

5.6.2 ユーザの作成とパスワードの管理 Edit source

下記の例では 1 人のユーザ wilber を作成しています。このとき、サーバインスタンスは LDAP1 、サフィックスは dc=LDAP1,dc=COM であるものとします。

手順 5.1: LDAP ユーザの作成

下記の例では、 389 DS インスタンス内にユーザ Wilber Fox を作成しています:

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

    > sudo dsidm LDAP1 user get wilber
    dn: uid=wilber,ou=people,dc=LDAP1,dc=COM
    [...]

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

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

    1. > 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. 認証が正しく動作することを確認します:

    > ldapwhoami -D uid=wilber,ou=people,dc=LDAP1,dc=COM -W
    Enter LDAP Password: PASSWORD
    dn: uid=wilber,ou=people,dc=LDAP1,dc=COM

5.6.3 グループの作成と管理 Edit source

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

手順 5.2: LDAP グループの作成とユーザの割り当て
  1. まずはグループを作成します:

    > sudo dsidm LDAP1 group create

    すると、グループ名の入力を求められます。たとえば SERVER_ADMINS というグループを作成するには、下記のように入力します:

    Enter value for cn : SERVER_ADMINS
  2. あとは作成したグループに wilber を追加します (ユーザは 手順5.1「LDAP ユーザの作成」 で作成しています):

    > 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

5.6.4 ユーザ/グループの削除、およびグループからのユーザ脱退 Edit source

ユーザの削除やグループからのユーザ脱退、そしてグループそのものの削除についても、 dsidm コマンドで行います。下記の例では、 server_admins グループから wilber ユーザを脱退させています:

> sudo dsidm LDAP1 group remove_member SERVER_ADMINS \
uid=wilber,ou=people,dc=LDAP1,dc=COM

次にユーザを削除します:

> sudo dsidm LDAP1 user delete \
uid=wilber,ou=people,dc=LDAP1,dc=COM

さらにグループを削除します:

> sudo dsidm LDAP1 group delete SERVER_ADMINS

プラグインの管理 Edit source

下記のように入力して実行することで、有効化されているプラグインと無効化されているプラグインの両方を一覧表示することができます。ここでは 389 Directory Server のインスタンス名ではなく、サーバのホスト名を指定することに注意してください。下記はホスト名が LDAPSERVER1 である場合の例です:

> sudo dsconf -D "cn=Directory Manager" ldap://LDAPSERVER1 plugin list
Enter password for cn=Directory Manager on ldap://LDAPSERVER1: PASSWORD

7-bit check
Account Policy Plugin
Account Usability Plugin
ACL Plugin
ACL preoperation
[...]

下記のコマンドは、 5.8項 「LDAP 認証管理のための SSSD の使用」 で利用している MemberOf プラグインを有効化するためのコマンドです。 MemberOf はユーザの検索を簡略化するための仕組みで、コマンドを 1 つ実行するだけで、ユーザが所属するグループの一覧を出力することができます。 MemberOf プラグインがないと、グループへの所属情報を検索するのに複数回のコマンド実行が必要になってしまいます。

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

なお、コマンド内で使用するプラグイン名は、小文字で指定しなければならないことに注意してください。そのため、一覧で表示される名前とは異なる指定になります。プラグイン名の指定が誤っていると、下記のようなエラーメッセージが表示されます:

dsconf instance plugin: error: invalid choice: 'MemberOf' (choose from
'memberof', 'automember', 'referential-integrity', 'root-dn', 'usn',
'account-policy', 'attr-uniq', 'dna', 'linked-attr', 'managed-entries',
'pass-through-auth', 'retro-changelog', 'posix-winsync', 'contentsync', 'list',
'show', 'set')

プラグインを有効化した場合は、サーバの再起動が必要です:

> sudo systemctl restart dirsrv@LDAPSERVER1.service

次にプラグインの設定を行います。下記の例では、 MemberOf プラグインを全ての項目に対して有効化します。なお、ここではサーバのホスト名ではなく、インスタンス名を指定してください:

> sudo dsconf LDAP1 plugin memberOf set --scope dc=example,dc=com
Successfully changed the cn=MemberOf Plugin,cn=plugins,cn=config

MemberOf プラグインを有効化して設定を行うと、全ての新しいユーザやグループは自動的に MemberOf のターゲットとして設定されます。ただし、それまでに作成されたユーザやグループはそうではありません。そのため、手作業でそれらを設定する必要があります:

> sudo dsidm LDAP1 user modify suzanne add:objectclass:nsmemberof
Successfully modified uid=suzanne,ou=people,dc=ldap1,dc=com

これで suzanne 本人の情報とメンバーの情報を、単一のコマンドで出力することができるようになります:

> sudo dsidm LDAP1 user get suzanne
dn: uid=suzanne,ou=people,dc=ldap1,dc=com
cn: suzanne
displayName: Suzanne Geeko
gidNumber: 102
homeDirectory: /home/suzanne
memberOf: cn=SERVER_ADMINS,ou=groups,dc=ldap1,dc=com

多数のユーザを修正する場合はそれなりの負荷がかかります。下記の例では、 1 つの fixup コマンドで既存の全ユーザに対して MemberOf を設定しています:

> sudo dsconf LDAP1 plugin memberof fixup -f '(objectClass=*)' dc=LDAP1,dc=COM

5.7.1 389 Directory Server でのサポート対象外プラグイン Edit source

下記のプラグインは、 389 Directory Server においてサポートされておりません:

  • Distributed Numeric Assignment (分散型数値配置; DNA) プラグイン

  • Managed Entries Plug-in (管理項目プラグイン; MEP)

  • Posix Winsync プラグイン

LDAP 認証管理のための SSSD の使用 Edit source

システムセキュリティサービスデーモン (System Security Services Daemon (SSSD)) は、リモートのユーザに対する認証や識別、アクセス制御などを行うためのシステムです。本章では、 389 Directory Server と SSSD を利用して、ユーザ認証やユーザ識別を行うための手順を説明しています。

SSSD は LDAP サーバとクライアントとの間を仲介します。 LDAP のほか、 Active Directory や Kerberos などのバックエンドにも対応しています。サービス側としては SSH, PAM, NSS, sudo などに対応しています。 SSSD は ID や資格情報をキャッシュする仕組みが存在することから、性能面だけでなく柔軟性も兼ね備えています。キャッシュ機能は 389 Directory Server サーバの負荷を減らすことにつながるばかりか、バックエンドが接続不可能な状態になっても、認証機能を継続して提供することができるようになります。

なお、ネームサービスキャッシュデーモン (Name Services Caching Daemon (nscd)) がネットワーク内で動作している場合は、無効化するか削除しておいてください。 nscd は passwd, group, hosts, service, netgroup などの名前解決要求のみをキャッシュする仕組みであることから、 SSSD と競合してしまうためです。

LDAP サーバをプロバイダ (提供元) として使用する場合、 SSSD のインスタンスはプロバイダに対するクライアントとして動作します。 389 DS サーバ内で SSSD を動作させてもかまいませんが、異なるマシンで動作させることで、 389 DS サーバが接続不可能な状況に陥った場合でもサービスを継続させることができます。下記の手順では、 SSSD クライアントのインストールと設定について説明しています。なお、下記では 389 DS のインスタンス名が LDAP1 であるものとして記しています:

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

    > sudo zypper in sssd sssd-ldap
  2. まずは /etc/sssd/sssd.conf ファイルをバックアップしておきます:

    > sudo old /etc/sssd/sssd.conf
  3. 次に新しい SSSD の設定テンプレートを作成します。出力ファイル名には sssd.confldap.conf のいずれかの名前を指定します。なお display を指定すると、標準出力に出力を行います。下記の例では、 /etc/sssd/sssd.conf ファイルにクライアント設定を出力しています:

    > sudo cd /etc/sssd
    > sudo dsidm LDAP1 client_config sssd.conf
  4. 出力された内容を確認して、環境に合わせた変更を行います。下記は /etc/sssd/sssd.conf ファイルの設定例 (全体) です。

    重要
    重要: MemberOf について

    この LDAP のアクセスフィルタは、 MemberOf プラグインを使用しています。詳しくは 5.7項 「プラグインの管理」 をお読みください。

    [sssd]
    services = nss, pam, ssh, sudo
    config_file_version = 2
    domains = default
    
    [nss]
    homedir_substring = /home
    
    [domain/default]
    # 巨大なグループを扱う場合 (たとえばメンバーが 50 人を超えるような場合) は、
    # True を指定してください
    ignore_group_members = False
    debug_level=3
    cache_credentials = True
    id_provider = ldap
    auth_provider = ldap
    access_provider = ldap
    chpass_provider = ldap
    
    ldap_schema = rfc2307bis
    ldap_search_base = dc=example,dc=com
    # ldaps を使用しておくことを強くお勧めします
    ldap_uri = ldaps://ldap.example.com
    ldap_tls_reqcert = demand
    ldap_tls_cacert = /etc/openldap/ldap.crt
    ldap_access_filter = (|(memberof=cn=<login group>,ou=Groups,dc=example,dc=com))
    enumerate = false
    access_provider = ldap
    
    ldap_user_member_of = memberof
    ldap_user_gecos = cn
    ldap_user_uuid = nsUniqueId
    ldap_group_uuid = nsUniqueId
    ldap_account_expire_policy = rhds
    ldap_access_order = filter, expire
    # 下記の行を /etc/ssh/sshd_config に追加してください:
    #  AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
    #  AuthorizedKeysCommandUser nobody
    ldap_user_ssh_public_key = nsSshPublicKey
  5. ファイルの所有者を root にして、 root のみが読み書きできるように設定します:

    > sudo chown root:root /etc/sssd/sssd.conf
    > sudo chmod 600 /etc/sssd/sssd.conf
  6. SSSD サーバ内の /etc/nsswitch.conf 設定ファイルを編集し、下記のような行が含まれるようにします:

    passwd: compat sss
    group:  compat sss
    shadow: compat sss
  7. SSSD サーバ内の PAM 設定である common-account-pc , common-auth-pc , common-password-pc , common-session-pc をそれぞれ編集します。 openSUSE Leap では pam-config というコマンドを使用することで、これら全てのファイルを一括変更することができます:

    > sudo pam-config -a --sss
  8. あとは修正後の設定を確認します:

    > sudo pam-config -q --sss
    auth:
    account:
    password:
    session:
  9. さらに、 389 Directory Server サーバ内にある /etc/dirsrv/slapd-LDAP1/ca.crt ファイルを SSSD サーバ内の /etc/openldap/certs にコピーして、ハッシュを再作成します:

    > sudo c_rehash /etc/openldap/certs
  10. SSSD を有効化して開始します:

    > sudo systemctl enable --now sssd

systemctl での sssd.service の制御方法については、 第4章 「YaST を利用した認証クライアントの設定 をお読みください。

5.8.1 サポート対象外のパスワードハッシュと認証方式 Edit source

nsslapd-rootpwstorageschemepasswordStorageScheme の設定値として、もしくはアカウントポリシーオブジェクト内での passwordStorageScheme の値としては、下記の値はサポート対象外となっております:

  • SHA

  • SSHA

  • SHA256

  • SSHA256

  • SHA384

  • SSHA384

  • SHA512

  • SSHA512

  • NS-MTA-MD5

  • clear

  • MD5

  • SMD5

注記
注記

なお、これらの値を含むデータベースからのインポートに関しては、 nsslapd-enable-upgrade-hashon (デフォルト値: on) になっていればサポート対象内となります。

OpenLDAP から 389 Directory Server への移行 Edit source

OpenLDAP は 廃止予定となり、 389 Directory Server に置き換えられています。 SUSE ではこの移行作業を支援するため、 389-ds パッケージ内に openldap_to_ds というユーティリティを提供しています。

openldap_to_ds は移行作業をできる限り自動的に実施できるよう設計されています。ですが、それぞれの LDAP 環境は異なるものであることから、全ての環境に適合するツールを作成するのは不可能です。そのため、必要に応じて手作業による介入が必要となるほか、本番環境の移行にあたっては、あらかじめ移行作業のテストを行う必要もあります。

重要
重要: help ページの参照について

移行ツールである openldap_to_ds を使用する前に、あらかじめ openldap_to_ds --help コマンドで表示される内容をよくお読みになることを強くお勧めします。ここには移行ツールに用意されている機能の一覧のほか、制限事項に関する説明も書かれているため、誤った仮定に基づく誤解を防ぐことができるようになっています。

5.9.1 OpenLDAP からのテスト移行 Edit source

OpenLDAP と 389 Directory Server との間にはそれなりの差異が存在することから、移行を行うにあたっても事前のテストと調整を繰り返し実施する必要があります。そのため、手早く移行テストを実施して、必要な追加手順を素早く洗い出すことが肝心です。

あらかじめ用意しておくべきもの:

  • 389 Directory Server インスタンスの動作するマシン

  • OpenLDAP slapd の設定ファイル、もしくは ldif 形式による動的な設定ディレクトリ

  • OpenLDAP データベースの ldif 形式によるフルバックアップ

slapd の設定が動的な ldif 形式ではない場合、まずは slaptest を利用して動的なコピーを作成します。 /root/slapd.d/ のような slapd.d ディレクトリを作成して、下記のコマンドを実行します:

> sudo slaptest -f /etc/openldap/slapd.conf -F /root/slapd.d

上記を実行すると、下記のようにいくつかのファイルが作成されるはずです:

> sudo ls /root/slapd.d/*

/root/slapd.d/cn=config.ldif

/root/slapd.d/cn=config:
cn=module{0}.ldif  cn=schema.ldif                 olcDatabase={0}config.ldif
cn=schema          olcDatabase={-1}frontend.ldif  olcDatabase={1}mdb.ldif

サフィックスごとに 1 つの ldif ファイルが作成されます。以降の例ではサフィックスが dc= LDAP1 ,dc= COM であるものとします。また、 /etc/openldap/slapd.conf 形式を使用している場合は、下記のようなコマンドを実行することで、 ldif のバックアップファイルを作成することができます:

> sudo slapcat -f /etc/openldap/slapd.conf -b dc=LDAP1,dc=COM \
-l /root/LDAP1-COM.ldif

あとは openldap_to_ds ユーティリティを利用して設定とファイルを分析させ、移行プランを表示させます (この時点では何も変更は行われません):

> sudo openldap_to_ds LDAP1\
/root/slapd.d /root/LDAP1-COM.ldif.ldif

前述のとおり上記では何も変更されませんが、下記のような出力が現れるはずです:

Examining OpenLDAP Configuration ...
Completed OpenLDAP Configuration Parsing.
Examining Ldifs ...
Completed Ldif Metadata Parsing.
The following migration steps will be performed:
 * Schema Skip Unsupported Attribute -> otherMailbox (0.9.2342.19200300.100.1.22)
 * Schema Skip Unsupported Attribute -> dSAQuality (0.9.2342.19200300.100.1.49)
 * Schema Skip Unsupported Attribute -> singleLevelQuality (0.9.2342.19200300.100.1.50)
 * Schema Skip Unsupported Attribute -> subtreeMinimumQuality (0.9.2342.19200300.100.1.51)
 * Schema Skip Unsupported Attribute -> subtreeMaximumQuality (0.9.2342.19200300.100.1.52)
 * Schema Create Attribute -> suseDefaultBase (SUSE.YaST.ModuleConfig.Attr:2)
 * Schema Create Attribute -> suseNextUniqueId (SUSE.YaST.ModuleConfig.Attr:3)
[...]
 * Schema Create ObjectClass -> suseDhcpConfiguration (SUSE.YaST.ModuleConfig.OC:10)
 * Schema Create ObjectClass -> suseMailConfiguration (SUSE.YaST.ModuleConfig.OC:11)
 * Database Reindex -> dc=example,dc=com
 * Database Import Ldif -> dc=example,dc=com from example.ldif -
excluding entry attributes = [{'structuralobjectclass', 'entrycsn'}]
No actions taken. To apply migration plan, use '--confirm'

あとは下記のように実行することで、実際の移行を行うことができます。変更しない場合とは出力が異なることに注意してください:

  > sudo openldap_to_ds LDAP1 /root/slapd.d /root/LDAP1-COM.ldif --confirm
Starting Migration ... This may take some time ...
migration: 1 / 40 complete ...
migration: 2 / 40 complete ...
migration: 3 / 40 complete ...
[...]
Index task index_all_05252021_120216 completed successfully
post: 39 / 40 complete ...
post: 40 / 40 complete ...
🎉 Migration complete!
----------------------
You should now review your instance configuration and data:
 * [ ] - Create/Migrate Database Access Controls (ACI)
 * [ ] - Enable and Verify TLS (LDAPS) Operation
 * [ ] - Schedule Automatic Backups
 * [ ] - Verify Accounts Can Bind Correctly
 * [ ] - Review Schema Inconistent ObjectClass -> pilotOrganization (0.9.2342.19200300.100.4.20)
 * [ ] - Review Database Imported Content is Correct -> dc=ldap1,dc=com

移行が完了すると openldap_to_ds は、実施しておかなければならない移行後のチェック作業の一覧を表示します。この作業はいずれも移行を最適に行うために必要な手順ですので、本番環境でも同じようにしておくことをお勧めします。あとはテストクライアントとアプリケーションを、移行後の 389 Directory Server インスタンスに向けてテストを行ってください。

重要
重要: ロールバックプランの策定

移行時、もしくは移行後に何らかの問題に直面することを想定して、ロールバックプラン (手戻りのための手順) と移行の成功判断基準を策定しておくことが重要です。具体的には、動作させなければならないクライアントやアプリケーションは何か、後から移行しても問題のないクライアントやアプリケーションは何か、それらでテストしておくべきことは何か、どのようにして手戻りの被害を最小限にするのか、巻き込むべきチームはどこなのかを事前に決めておく必要があります。

用途や範囲などが環境によって様々に異なることから、画一的な移行プラン/手戻りプランを策定することは難しいモノです。まずは移行処理をおおまかにテストしてみて、そこから少しずつ問題点を洗い出していくのがよいでしょう。また、下記のような一般的な手法も役に立つはずです:

  • ホスト名や DNS の TTL を、一般的な 48 時間から 5 分に短縮しておくことで、手戻りを素早く実施できるようになります。

  • 全てのデータ同期や受信データ処理を一時的に停止してください。これにより、移行時に OpenLDAP 環境が変化しなくなります。

  • 移行前に 389 Directory Server のホストをよく確認しておくことも重要です。

  • テスト移行時に発生した細かい問題などを詳しく記録しておくことも重要です。

5.9.2 saslauthd を使用する OpenLDAP サーバのテスト移行 Edit source

OpenLDAP 環境の場合、パススルー型のユーザ認証を行うのに saslauthd を使用することがあります。この場合、認証処理では下記のようなコンポーネントが関わってきます:

 ┌─────────────────┐
 │                 │
 │LDAP クライアント│
 │                 │
 └─────────────────┘
          │
      バインド
          │
          ▼
 ┌─────────────────┐
 │    OpenLDAP     │
 │     サーバ      │
 │                 │
 └─────────────────┘
          │
          │
          ▼
 ┌─────────────────┐
 │                 │
 │    saslauthd    │
 │                 │
 └─────────────────┘
          │
          │
          ▼
 ┌─────────────────┐
 │                 │
 │     外部認証    │
 │                 │
 └─────────────────┘

設定が正しいことを確認したり、そこから先のトラブルシューティングを実施したりする場合は、下記のような情報が必要となります:

  • OpenLDAP は、ユーザの userPassword 属性が userPassword:{SASL}ユーザ名@レルム の形式になっていることを検出すると、パススルー認証を使用するユーザであると判断します。なお、パススルー認証を使用するには、 OpenLDAP サーバの構築時に --enable-spasswd オプションを指定しておく必要があります。

  • OpenLDAP では、 saslauthd との接続に関する設定を /usr/lib/sasl2/slapd.conf から取得します。

  • saslauthd は、 /etc/sysconfig/saslauthd 内に設定されたコマンドラインパラメータを利用して、関連するモジュールを検出します。

  • saslauthd のバックエンドモジュールは、 man saslauthd に書かれているとおり、独自の設定ファイルを使用します。

OpenLDAP でのパススルー認証に関する詳細については、公式文書である OpenLDAP Admin Guide (英語) をお読みください。

5.9.2.1 SASL パススルー認証を使用している環境での OpenLDAP から 389 Directory Server への移行 Edit source

OpenLDAP で SASL によるパススルー認証を使用している場合、 389 Directory Server への移行は下記の手順が最適です:

  1. まずは移行前に、 OpenLDAP サーバ内で testsaslauthd を実行し、問題が発生しないことを確認しておきます。

    > sudo testsaslauthd -u ユーザ名@レルム -p パスワード

    saslauthd は、レルムの指定から使用すべき認証バックエンドを判断し、ユーザ名は識別子として認証を行います。

  2. 389 Directory Server から saslauthd に接続できるようにするため、 pam_saslauthd パッケージをインストールします。

    > sudo zypper install -y pam_saslauthd
  3. openldap_to_ds コマンドを実行して、 OpenLDAP から 389 Directory Server への移行処理を行います。移行処理に関する詳細は、 5.9.1項 「OpenLDAP からのテスト移行」 をお読みください。

    注記
    注記

    なお、 openldap_to_ds を実行すると、ユーザの userPassword 属性が userPassword: {SASL}ユーザ名@レルム 形式になっていることを検出すると、この属性は削除され、 nsSaslauthId 属性に nsSaslauthId: ユーザ名@レルム が設定されます。これに加えて、この属性に対応するよう、 objectClass: nsSaslauthAccount が自動的に追加されます。

  4. 移行が終わったあとは、下記のようなコマンドを実行して、 PAM のパススルー認証が正しく設定されているかどうかを確認します:

    > sudo dsconf インスタンス名 plugin pass-through-auth show
    > sudo dsconf インスタンス名 plugin pam-pass-through-auth list

移行が全て終わると、パススルー認証は下記のような構成になります:

  ┌─────────────────┐
  │                 │
  │LDAP クライアント│
  │                 │
  └─────────────────┘
           │
       バインド
           │
           ▼
  ┌─────────────────┐
  │     389-DS      │
  │     サーバ      │
  │                 │
  └─────────────────┘
           │
           ▼
  ┌─────────────────┐
  │                 │
  │  pam saslauthd  │
  │                 │
  └─────────────────┘
           │
           ▼
  ┌─────────────────┐
  │                 │
  │    saslauthd    │
  │                 │
  └─────────────────┘
           │
           │
           ▼
  ┌─────────────────┐
  │                 │
  │     外部認証    │
  │                 │
  └─────────────────┘

5.9.2.2 saslauthd パススルー認証のトラブルシューティング Edit source

OpenLDAP から 389 Directory Server への移行前後で発生する saslauthd パススルー認証に関するトラブルシューティングについては、それぞれ下記を確認するとよいでしょう:

testsaslauthdユーザ名@レルム の形式で動作すること。

testsaslauthd での確認手順については、 5.9.2項 「saslauthd を使用する OpenLDAP サーバのテスト移行」 をお読みください。

正しく動作しない場合は、下記を試してみてください:

  • まずは /etc/sysconfig/saslauthd ファイル内で、 saslauthd バックエンドモジュールが正しく設定されていることを確認してください。 saslauthd のバックエンドモジュールに関する詳細と設定方法については、 man saslauthd をお読みください。

  • /etc/sysconfig/saslauthd ファイルに SASLAUTHD_PARAMS="-d" を設定することで、デバッグ出力を有効化することもできます。

  • なお saslauthd のログは、 journalctl で表示することができます。

PAM saslauthd が正しく動作すること。

PAM saslauthd が正しく動作するかどうかを確認したい場合は、 https://github.com/kanidm/pam_tester にある pam_tester ツールをお使いください。

注記
注記

なお、 pam_tester ツールは公式にサポートされているツールではありません。

PAM パススルー認証プラグインが有効化されていること。

PAM パススルー認証の状態を確認するには、下記のようなコマンドを入力して実行します:

> sudo dsconf インスタンス名 plugin pam-passt-through-auth status

プラグインを有効化するには、下記のようなコマンドを入力して実行します:

> sudo dsconf インスタンス名 plugin pam-pass-through-auth enable
PAM パススルー認証プラグインが有効化されていること。

サーバインスタンスに対して PAM パススルー認証の設定がされているかどうかを確認するには、下記のようなコマンドを入力して実行します:

> sudo dsconf インスタンス名 plugin pass-through-auth show
サーバインスタンスのユーザに対して出力されたログ。

ログファイルは /var/lib/サーバユーザ名/インスタンス名/error にあります。

5.9.3 移行の計画 Edit source

OpenLDAP は 様々な部品から構成されるソフトウエアパッケージ であり、様々なカスタマイズを実施できることから、 画一的な手順 で移行ができるものではありません。まずは OpenLDAP の環境と設定、そして使用範囲をよく調査してください。調査の対象としては、下記のようなものがあります (下記だけであるとも限りません):

  • レプリケーションのトポロジ

  • 高可用性と負荷分散の設定

  • 外部のデータフロー (データ管理, 人事管理, Active Directory など)

  • 設定済みのオーバーレイ (389 Directory Server のプラグイン)

  • クライアント側の設定とサーバ側に求められる機能

  • スキーマのカスタマイズ内容

  • TLS の設定

最終的に 389 Directory Server をどのように配置するのかについても、よく計画しておく必要があります。これはオーバーレイをプラグインで置き換えること以外の、サーバの配置やインストールに関する内容です。現在の環境をよく調査し、 389 Directory Server の配置計画を立てたら、あとは移行プランの策定になります。 OpenLDAP の環境と並行して 389 Directory Server の環境を動作させて、お互いに切り替えることができるようにしても良いでしょう。

OpenLDAP から 389 Directory Server への移行は一方通行です。相互運用の意味でもこれらの間には十分な差異がありますし、逆方向 (389 Directory Server から OpenLDAP へ) の移行は提供されていませんので、よく注意しておく必要があります。下記には、様々な類似性と差異の一覧を示しています。

機能OpenLDAP389 Directory Server互換性
双方向レプリケーションSyncREPL389 DS 固有のシステムいいえ
MemberOfオーバーレイプラグインはい (シンプルな設定にのみ対応)
外部認証プロキシ-いいえ
Active Directory との同期-Winsync プラグインいいえ
内蔵スキーマOLDAP スキーマ389 スキーマはい (移行ツールで対応)
独自スキーマOLDAP スキーマ389 スキーマはい (移行ツールで対応)
データベースの取り込みLDIFLDIFはい (移行ツールで対応)
パスワードのハッシュ化各種各種はい (Argon2 を除く全ての形式に対応)
OpenLDAP と 389 DS のレプリケーション--いいえ (389 DS との同期は不可能)
時間ベースのワンタイムパスワード (TOTP)TOTP オーバーレイ-いいえ (現時点でサポートされていません)
entryUUIDOpenLDAP の一部として提供プラグインはい

TLS 証明書と鍵の取り込み Edit source

389 Directory Server の証明書や鍵を管理するには、 certutil , openssl , pk12util のようなコマンドラインツールを使用します。

新しい 389 DS インスタンスを作成すると、 dscreate は独自の証明機関を作成し、自己署名型のサーバ証明書を発行します。こちらはテスト用途にのみ使用されるべきもので、証明書のファイルは /etc/dirsrv/slapd-インスタンス名/ 内に配置されます。

本番環境を構築する場合は、 Let's Encrypt, CAcert.org, SSL.com など、第三者が発行する証明書を使用するようにしてください。それぞれサーバ証明書、クライアント証明書、ルート証明書が必要になります。

重要
重要

また、 Mozilla NSS (Network Security Services ) ツールキットでは、証明書ストア内の証明書に対してニックネーム (名前) を設定しますが、サーバ用の証明書に対しては Server-Cert という名前を指定してください。

  1. インスタンスから自己署名用の証明機関と証明書を削除するには、下記のコマンドを実行します:

    > sudo dsctl インスタンス名 tls remove-cert Self-Signed-CA
    > sudo dsctl インスタンス名 tls remove-cert Server-Cert
    

    ここで、 インスタンス名 にはディレクトリサーバのインスタンス名を指定します。前章での手順では LDAP1 という名前を設定しているものです。

  2. まずは証明書への署名を実施した証明機関の証明書をインポートします。

    > sudo sudo dsctl インスタンス名 tls import-ca
       /path/to/CA/in/PEM/format/CA.pem  CA_の名前
    

    ここで、 インスタンス名 にはディレクトリサーバのインスタンス名を、 /path/to/CA/in/PEM/format/CA.pem には証明機関の証明書 (PEM 形式) のファイルに対するフルパスを指定します。また CA_の名前 には、証明機関の名前を指定します。

  3. あとはサーバ証明書とそれに対応する鍵をインポートします。

    > sudo dsctl インスタンス名 tls import-server-key-cert
      /path/to/SERVER.pem /path/to/SERVER.key

    ここで、 インスタンス名 にはディレクトリサーバのインスタンス名を、 /path/to/SERVER.pem にはサーバ証明書 (PEM 形式) のファイルに対するフルパスを指定します。また /path/to/SERVER.key には、サーバ証明書に対応する機密鍵 (PEM 形式) のファイルに対するフルパスを指定します。

  4. あとはインスタンスを再起動すると、新しい証明書を使用するようになります。

    > sudo systemctl restart dirsrv@インスタンス名.service
    

    ここで、 インスタンス名 にはディレクトリサーバのインスタンス名を指定します。

レプリケーションの設定 Edit source

389 Directory Server では複数のサーバ間でデータベースをレプリケーション (複製) することができます。レプリケーションの構成にもよりますが、下記のような利点を提供することになります:

  • 性能と応答時間の高速化

  • 耐障害性と冗長性の確保

  • 負荷分散

  • 高可用性

データベースは複製可能なディレクトリの最小単位でもあります。データベース全体を複製することはできますが、データベース内のサブツリーのみを複製することはできません。また、 1 つのデータベースは必ず 1 つのサフィックスに結びつけられるものであり、 2 つまたはそれ以上のデータベースにまたがったサフィックスを複製することはできません。

また、複製すべきデータを他に送信するサーバをサプライヤ (supplier) と呼びます。逆に、サプライヤからのデータを受け取るサーバをコンシューマ (consumer) と呼びます。レプリケーションは常にサプライヤ側から行われ、 1 つのサプライヤからは複数のコンシューマに送信することができます。また一般に、マルチサプライヤ (multi-supplier) レプリケーションの場合を除いて、サプライヤは読み書き可能なレプリカとして、コンシューマは読み込み専用のサーバとして提供されます。マルチサプライヤレプリケーションの場合、サプライヤとコンシューマを兼ねるサーバとなります。

5.11.1 非同期書き込み Edit source

389 DS は他のデータベースとは異なるレプリケーション管理を行います。レプリケーションは非同期でありながらも、結果整合性を持つ仕組みになっています。つまり、下記のような動作になります:

  • サーバへの書き込みや変更は、即時に受け入れられます。

  • 特定のサーバ内に書き込まれたあと、他のサーバにレプリケーションされて見えるようになるまでの間に、時間的な遅れが発生します。

  • いずれかのサーバ内での書き込みに矛盾が発生した場合、特定のポイントまでロールバック (巻き戻される) 可能性があります。

  • レプリケーションの遅延により、特定の時点で各サーバ内に存在するデータが異なる可能性があります。

一般的に LDAP は、 書き込みの少ない データベースであるため、これらの特徴を考慮しても、サーバが一貫性のない状態にはならず、常に既知の安定状態に居続けることができます。また、この安定状態からの変更は少しずつしか行われないため、日々の運用ではこのような欠点に気付くようなことはありません。

5.11.2 構成設計 Edit source

レプリケーションの構成 (トポロジ) を設計するにあたっては、下記のような要素を決めておく必要があります。

  • レプリケーションに対する要件: 高可用性、物理的な配置場所、読み込み性能やそれらの組み合わせなど。

  • 構成内に配置するレプリカ (ノード、サーバ) 数。

  • データの流れとその方向。構成内に流入するデータと流出するデータ。

  • クライアント側からリクエストを送信する際の、ノード選択方式 (クライアント側で LDAP URI を複数個指定して分散させるか、 SRV レコードで分散させるか、ロードバランサを用いるか等) 。

これらの要素はいずれも構成そのものに影響します (詳しい構成例については 5.11.3項 「レプリケーションの設計例」 をお読みください) 。

5.11.3 レプリケーションの設計例 Edit source

下記の章では、 2 ノードから 6 ノードまでの 389 Directory Server ノードを使用する、いくつかのレプリケーション構成例を示しています。なお、レプリケーションを構成する際の最大サプライヤ数は 20 ノードまでです。実際の運用経験からすると、レプリケーション効率を高めるための最適なノード数は最大でも 8 ノードまでと考えられています。

5.11.3.1 2 つのレプリカ Edit source

例 5.4: 2 つのサプライヤレプリカ
┌────┐       ┌────┐
│ S1 │◀─────▶│ S2 │
└────┘       └────┘

例5.4「2 つのサプライヤレプリカ」 には S1 と S2 という 2 つのレプリカが示されています。これらは双方向レプリケーションとして構成する場合の例で、これらのノードはいずれもサプライヤとコンシューマの両方を兼ね備えた存在となります。 S1 と S2 は別々のデータセンター内であっても、同じデータセンター内であってもかまいません。 LDAP URI や負荷分散装置、 DNS SRV レコードのいずれかでクライアント側からのアクセスを分散させることができます。また、これは高可用性を提供する際の最もシンプルな構成でもあります。ただし、一方のサーバで障害が発生してオフラインになった場合、他方のサーバでは全てのクライアントからの処理を受け付ける必要があることに注意してください。また、 2 ノードのレプリケーションでは一方のノードがオフラインになった場合、残った 1 つのノードのみで全ての処理を行わなければならないことから、水平分散としては不適切です。

注記
注記: 既定の構成

2 ノードの構成は最も簡単に管理できることから、既定の構成と考えられます。この構成を初期構成として、必要に応じて構成を広げていってもかまいません。

5.11.3.2 4 つのサプライヤレプリカ Edit source

例 5.5: 4 つのサプライヤレプリカ
┌────┐       ┌────┐
│ S1 │◀─────▶│ S2 │
└────┘       └────┘
   ▲            ▲
   │            │
   ▼            ▼
┌────┐       ┌────┐
│ S3 │◀─────▶│ S4 │
└────┘       └────┘

例5.5「4 つのサプライヤレプリカ」 は 4 つのサプライヤレプリカを構成する場合の例です。これらは相互にデータを同期する構成で、 4 つのデータセンターに分散させても、 1 つのデータセンターごとに 2 つのサーバを配置してもかまいません。 4 つのデータセンターに分散させた場合、各ノードは 100% のクライアント負荷を受け付ける処理能力が必要となります。 2 つのデータセンターに 2 つのサーバを配置した場合は、各ノードは 50% のクライアント負荷を受け付ければ十分になります。

5.11.3.3 6 つのレプリカ Edit source

例 5.6: 6 つのレプリカ
                  ┌────┐       ┌────┐
                  │ S1 │◀─────▶│ S2 │
                  └────┘       └────┘
                     ▲            ▲
                     │            │
   ┌────────────┬────┴────────────┴─────┬────────────┐
   │            │                       │            │
   ▼            ▼                       ▼            ▼
┌────┐       ┌────┐                  ┌────┐       ┌────┐
│ S3 │◀─────▶│ S4 │                  │ S5 │◀─────▶│ S6 │
└────┘       └────┘                  └────┘       └────┘

例5.6「6 つのレプリカ」 は各サーバ対を別々の場所に配置した場合の構成例です。 S1 と S2 はサプライヤ、 S3, S4, S5, S6 は S1 と S2 のコンシューマとして構成します。また、各サーバ対はお互いにレプリケーションしているものとし、 S3, S4, S5, S6 でも書き込み要求は受け付けるものとしますが、ほとんどのレプリケーションは S1, S2 で行われます、このような構成は、高可用性と分散処理の両方を、地理的な離れた場所から提供する際の例となります。

5.11.3.4 読み込み専用コンシューマのある 6 つのレプリカ Edit source

例 5.7: 読み込み専用コンシューマのある 6 つのレプリカ
             ┌────┐       ┌────┐
             │ S1 │◀─────▶│ S2 │
             └────┘       └────┘
                │            │
                │            │
   ┌────────────┼────────────┼────────────┐
   │            │            │            │
   ▼            ▼            ▼            ▼
┌────┐       ┌────┐       ┌────┐       ┌────┐
│ S3 │       │ S4 │       │ S5 │       │ S6 │
└────┘       └────┘       └────┘       └────┘

例5.7「読み込み専用コンシューマのある 6 つのレプリカ」 では、 S1 と S2 の両方がサプライヤとなり、残りの 4 つのサーバは読み込み専用のコンシューマとして構成する場合の例となります。全ての書き込み要求は S1, S2 でのみ行われ、残りの 4 つのサーバに複製していく構成です。読み込み専用のコンシューマには、データ開示を最小限に留めるため、データベースの一部や項目の一部のみを保存させるようにすることもできます。このように部分的な複製のみを持つ構成は DMZ のようなネットワークを持つ場合に最適で、この場合は DMZ 内に配置したコンシューマへの書き込みはできなくなります。

5.11.4 用語 Edit source

ここまでに説明してきた 389 DS の構成例やこの後の説明では、様々な用語を使用しています。下記ではそれら用語に対する説明を示しています。

レプリカ

データベースを持つ 389 DS のインスタンスを意味しています。

読み書き可能なレプリカ

読み込みと書き込みの両方の要求を受け付けることができる、データベースの完全コピーを持つレプリカを意味しています。

読み込み専用レプリカ

読み込み要求のみを受け付けることができる、データベースの完全コピーを持つレプリカを意味しています。

部分的な複製のみを持つレプリカ

データベースのうちの一部のみを複製し、読み込み要求のみを受け付けることができるレプリカを意味しています。

サプライヤ

他のレプリカにデータベースの内容を提供することができるレプリカを意味しています。

コンシューマ

他のレプリカからデータを受け取って、自身のデータベースに書き込むレプリカを意味しています。

レプリケーション同意

他のレプリカとの関係性 (サプライヤ/コンシューマ) に対するサーバ設定を意味しています。

構成

レプリケーション同意を介したレプリカ同士の接続構成を意味しています。

レプリカ ID

レプリケーション構成内で重複しない 389 Directory Server のインスタンス識別子を意味しています。

レプリケーションマネージャ

ディレクトリ内でレプリケーション権限を持つアカウントを意味しています。

5.11.5 レプリケーションの設定 Edit source

最小構成例として、まずは 2 ノードの双方向レプリケーションと 1 ノードの読み込み専用サーバを構成してみます。下記の例では、読み書き可能なレプリカのサーバ名は RW1, RW2 とし、読み込み専用のレプリカのサーバ名は RO1 とします (もちろん必要に応じて自由な名前を設定してかまいません) 。

この構成内にあるサーバには、全て同じサフィックスを設定する必要があります。また、初期状態では RW1 にのみデータが存在するものとします。

5.11.5.1 2 ノードレプリケーションの設定 Edit source

下記のコマンドは 2 ノード構成 ( 例5.4「2 つのサプライヤレプリカ」 ) の場合のコマンド例で、ホスト名を RW1, RW2 にしています (実際には独自の名前でかまいません) 。

警告
警告: 強力なレプリケーションマネージャパスワードの作成について

レプリケーションマネージャのアカウントはディレクトリマネージャのアカウントと同等の権限を持つことから、セキュリティを確保するために強力なパスワードを設定しておくことを強くお勧めします。

各サーバで異なるレプリケーションマネージャのパスワードを設定する場合は、それぞれのサーバが使用するアカウントをよく覚えておいてください。たとえば RW1 側のレプリケーション同意を設定する場合、パスワードとして設定すべきなのは RW2 側のレプリケーションマネージャのパスワードとなります。

まずは RW1 側を設定します:

> sudo dsconf インスタンス名 replication create-manager
> sudo dsconf インスタンス名 replication enable \
--suffix dc=example,dc=com \
--role supplier --replica-id 1 --bind-dn "cn=replication manager,cn=config"

RW2 側の設定は下記のようになります:

> sudo dsconf インスタンス名 replication create-manager
> sudo dsconf インスタンス名 replication enable \
--suffix dc=example,dc=com \
--role supplier --replica-id 2 --bind-dn "cn=replication manager,cn=config"

上記のコマンドを実行することで、 RW1, RW2 の両方にレプリケーション用のデータを設定することができます。なお、 RW1 と RW2 では replica-id の値が異なっていることに注意してください。また、このコマンドを実行すると、レプリケーションマネージャのアカウントを作成することになります。このアカウントは、 2 つのノードが互いに認証する際に使用するアカウントとなります。

これで RW1 と RW2 の間でレプリケーションを行う準備ができました。あとは RW1 から RW2 に対して、データを発信するための最初の合意を作成します。

> sudo dsconf インスタンス名 repl-agmt create \
--suffix dc=example,dc=com \
--host=RW2 --port=636 --conn-protocol LDAPS --bind-dn "cn=replication manager,cn=config" \
--bind-passwd パスワード --bind-method SIMPLE RW1_to_RW2

上記のコマンドだけではデータベースの同期が始まりません。同期を始めるには、初期化または再初期化と呼ばれる完全同期が必要となります。初期化または再初期化を行うと、 RW2 側の全てのデータがリセットされ、 RW1 と全く同じデータになります。これを行うには、下記のように入力して実行します:

> sudo dsconf インスタンス名 repl-agmt init \
--suffix dc=example,dc=com RW1_to_RW2

あとは RW1 側で下記のようなコマンドを入力して実行し、状況を確認します:

> sudo dsconf インスタンス名 repl-agmt init-status \
--suffix dc=example,dc=com RW1_to_RW2

同期が完了すると、 Agreement successfully initialized というメッセージが表示されるはずです。それ以外のエラーメッセージが表示された場合は、エラーログを調べてみてください。エラーが表示されなければ、 RW1 と RW2 は全く同じデータになっているはずです。

あとはデータを双方向に複製するため、 RW2 から RW1 に対するレプリケーション合意も設定します:

> sudo dsconf インスタンス名 repl-agmt create \
--suffix dc=example,dc=com \
--host=RW1 --port=636 --conn-protocol LDAPS \
--bind-dn "cn=replication manager,cn=config" --bind-passwd パスワード \
--bind-method SIMPLE RW2_to_RW1

これで RW1 と RW2 の双方向レプリケーションが完成し、一方での変更が他方にも反映されるようになっています。いずれかのサーバで下記のようなコマンドを入力して実行し、状態を確認してください:

> sudo dsconf インスタンス名 repl-agmt status \
--suffix dc=example,dc=com \
--bind-dn "cn=replication manager,cn=config" \
--bind-passwd パスワード RW2_to_RW1

5.11.5.2 読み込み専用ノードの設定 Edit source

読み込み専用ノードを作成するには、まずレプリケーションマネージャのアカウントとメタデータを作成するところから始めます。ここでのサーバ名は RO3 とします:

警告
警告: 強力なレプリケーションマネージャパスワードの作成について

レプリケーションマネージャのアカウントはディレクトリマネージャのアカウントと同等の権限を持つことから、セキュリティを確保するために強力なパスワードを設定しておくことを強くお勧めします。

各サーバで異なるレプリケーションマネージャのパスワードを設定する場合は、それぞれのサーバが使用するアカウントをよく覚えておいてください。たとえば RW1 側のレプリケーション同意を設定する場合、パスワードとして設定すべきなのは RW2 側のレプリケーションマネージャのパスワードとなります。

> sudo dsconf インスタンス名 replication create-manager
> sudo  dsconf インスタンス名 \
replication enable --suffix dc=EXAMPLE,dc=COM \
--role consumer --bind-dn "cn=replication manager,cn=config"

なお、読み込み専用のレプリカに対しては、レプリカ ID の指定は不要であるほか、役割の指定を consumer にします。これにより、特殊な読み込み専用のレプリカ ID が割り当てられます。読み込み専用のレプリカを作成したら、あとは RW1, RW2 のそれぞれに対してレプリケーション同意を追加します。下記は RW1 側での実行例です:

> sudo dsconf インスタンス名 \
repl-agmt create --suffix dc=EXAMPLE,dc=COM \
--host=RO3 --port=636 --conn-protocol LDAPS \
--bind-dn "cn=replication manager,cn=config" --bind-passwd パスワード
--bind-method SIMPLE RW1_to_RO3

下記の例は、 RW2 と RO3 との間でのレプリケーション同意を RW2 側で設定する場合の例です:

> sudo dsconf インスタンス名 repl-agmt create \
--suffix dc=EXAMPLE,dc=COM \
--host=RO3 --port=636 --conn-protocol LDAPS \
--bind-dn "cn=replication manager,cn=config" --bind-passwd パスワード \
--bind-method SIMPLE RW2_to_RO3

これらの作業が完了したら、あとは RW1, RW2 から RO3 へデータベースの初期化を行います。下記の例では、 RW2 から RO3 に初期化を行っています:

> sudo dsconf インスタンス名 repl-agmt init
--suffix dc=EXAMPLE,dc=COM RW2_to_RO3

5.11.6 監視とヘルスチェック Edit source

dsconf コマンドには監視オプションが用意されています。このコマンドを実行することで、レプリカ内で直接状態を確認することができるほか、他のホストからでも実行することができます。下記の例は RW1 内での実行例で、 2 つのレプリカに対する状態の確認と、自分自身の確認をそれぞれ行っています:

> sudo dsconf -D "cn=Directory Manager" ldap://RW2 replication monitor
> sudo dsconf -D "cn=Directory Manager" ldap://RO3 replication monitor
> sudo dsconf -D "cn=Directory Manager" ldap://RW1 replication monitor

また、 dsctl コマンドには healthcheck というオプションもあります。下記ではローカルの 389 DS インスタンスに対して、レプリケーションの状態確認を行っています:

> sudo dsctl インスタンス名 healthcheck --check replication

-v オプションを追加すると、 healthcheck で行っていることの詳細を表示することができます:

> sudo dsctl -v インスタンス名 healthcheck --check replication

オプション無しで dsctl インスタンス名 healthcheck を実行すると、一般的な状態確認のみを行います。

下記のようなコマンドを実行することで、 healthcheck を実行した際に行われる処理の内容を調べることもできます:

> sudo dsctl インスタンス名 healthcheck --list-checks
config:hr_timestamp
config:passwordscheme
backends:userroot:cl_trimming
backends:userroot:mappingtree
backends:userroot:search
backends:userroot:virt_attrs
encryption:check_tls_version
fschecks:file_perms
[...]

個別のチェックのみを実行したい場合は、下記のように入力して実行します:

> sudo dsctl インスタンス名 healthcheck \
--check monitor-disk-space:disk_space tls:certificate_expiration

5.11.7 バックアップの作成 Edit source

レプリケーションを有効化した場合は、 389 Directory Server のバックアップについてもいくつかの調整を行う必要があります (一般的なバックアップ方法については 5.5項 「389 Directory Server でのバックアップと復元」 をお読みください) 。具体的には、バックアップ時に db2ldif コマンドを実行している場合、 --replication フラグを指定して、レプリケーションのメタデータを最初にバックアップするようにしてください。また、バックアップは構成内の全てのサーバに対して行うものとし、バックアップからの復元に際しては、構成内の 1 ノードでのみ実施して、残りのノードは再初期化を行ってデータを複製してください。

5.11.8 レプリケーションの一時停止と再開 Edit source

メンテナンスやその他の運用上の理由で、レプリケーションを一時的に停止することができます。なお、一時停止は変更履歴の保持日数で示された期間 (詳しくは 5.11.9項 「Changelog max-age」 をお読みください) まで続けることができます。

レプリケーションを一時停止するには、 repl-agmt コマンドを使用します。 RW2 で一時停止する場合は、下記のように入力して実行します:

> sudo dsconf インスタンス名 repl-agmt disable \
--suffix dc=EXAMPLE,dc=COM RW2_to_RW1

再開する場合は、下記のように入力して実行します:

> sudo dsconf インスタンス名 repl-agmt enable \
--suffix dc=EXAMPLE,dc=COM RW2_to_RW1

5.11.9 Changelog max-age Edit source

レプリカを何らかの理由でしばらくオフラインにする場合には、最大で changelog max-age で指定した時間までが許容されます。 max-age オプションは過去の変更履歴を持つ長さを時間で指定するための値で、ここで指定したよりも過去の履歴は自動的に削除されます。

しばらくオフラインになっていたレプリカが復帰すると、通常のレプリケーションと同様に、他のレプリカとの間で同期が行われます。 max-age で指定したよりも長い時間オフラインであった場合は、一貫性を失うことから、他のノードからの変更を拒否したり、他のノードへの変更送信を拒否したりするようになります。下記の例では、 max-age を 7 日間に設定しています:

> sudo dsconf インスタンス名 \
replication set-changelog --max-age 7d \
--suffix dc=EXAMPLE,dc=COM

5.11.10 レプリカの削除 Edit source

レプリカを削除するには、まず他のノードに対して変更点の送信を停止する必要があります。あとは削除するノードで受け付けていたレプリケーション合意を削除します。下記の例では、 RW2 を削除する場合の例を示しています。まずは RW1 での発信側レプリケーション合意を削除します:

> sudo dsconf インスタンス名 repl-agmt delete \
--suffix dc=EXAMPLE,dc=COM RW1_to_RW2

あとは削除対象のレプリカ (この例では RW2) で、全ての送信側レプリケーション合意を削除します:

> sudo dsconf インスタンス名 repl-agmt delete \
--suffix dc=EXAMPLE,dc=COM RW2_to_RW1
> sudo dsconf インスタンス名 repl-agmt delete \
--suffix dc=EXAMPLE,dc=COM RW2_to_RO3

あとは RW2 インスタンスを停止します:

> sudo systemctl stop dirsrv@INSTANCE_NAME.service

最後に構成内に書かれているレプリカ ID を削除するため、 cleanallruv コマンドを実行します。下記は RW1 で実行した場合の例です:

> sudo dsconf インスタンス名 repl-tasks cleanallruv \
--suffix dc=EXAMPLE,dc=COM --replica-id 2
> sudo dsconf インスタンス名 repl-tasks list-cleanruv-tasks

5.11.11 389 Directory Server でのレプリケーションの制限 Edit source

389 Directory Server でレプリケーションを使用する場合、下記のサポート制限があります:

  • 読み書き可能なノードは最大 8 個まで

  • レプリケーションハブは最大 20 個まで

  • 読み込み専用のサーバは最大 100 個まで

  • 読み書き可能なメンバーとしての Winsync Active Directory コンシューマは最大 1 個まで

Microsoft Active Directory との同期 Edit source

389 Directory Server では、 Microsoft 社の Active Directory からユーザやグループの項目を取得する機能が提供されています。この機能を使用することで、通常は必要とされるドメインへの参加を行うことなく、 389 DS を利用して Linux クライアントが識別情報を取得できるようになります。これにより、 389 DS が Active Directory と相互に運用できるようになり、用途をさらに広げることができるようになっています。

5.12.1 同期トポロジの計画 Edit source

同期の形態にもよりますが、最小構成では 1 台の 389 Directory Server と 1 台の Active Directory サーバで同期を構築することができます。ただし、 Active Directory は完全なドメインコントローラでなければならず、読み込み専用のドメインコントローラ (RODC) であってはなりません。なお、 389 DS はドメイン内の単一フォレストの内容のみを複製するため、グローバルカタログは不要です。

まずはデータの流通方向を選択します。 AD から 389 DS だけでなく、 389 DS から AD や、その両方を指定することもできます。

注記
注記: パスワード同期について

389 DS と Active Directory との間では、パスワードの同期を行うことができません。将来的には Active Directory から 389 DS に対してパスワードを同期できるようになる予定です。

同期の構成を図に表すと、下記のようになります。 389 Directory Server 内や Active Directory 内の構成が異なる場合もありますが、 389 DS と Active Directory は 1 つの接続のみで賄われる点が最も重要です。また、これによって発生しうる、 389 DS と AD の災害対策やバックアップ計画の策定も非常に重要です。これらを計画しておくことで、単一のレプリケーション接続であっても、正しく復元できるように構成できるからです。

┌────────┐     ┌────────┐         ┌────────┐     ┌────────┐
│        │     │        │         │        │     │        │
│ 389-ds │◀───▶│ 389-ds │◀ ─ ─ ─ ▶│   AD   │◀───▶│   AD   │
│        │     │        │         │        │     │        │
└────────┘     └────────┘         └────────┘     └────────┘
    ▲               ▲                  ▲             ▲
    │               │                  │             │
    ▼               ▼                  ▼             ▼
┌────────┐     ┌────────┐         ┌────────┐     ┌────────┐
│        │     │        │         │        │     │        │
│ 389-ds │◀───▶│ 389-ds │         │   AD   │◀───▶│   AD   │
│        │     │        │         │        │     │        │
└────────┘     └────────┘         └────────┘     └────────┘

5.12.2 Active Directory 側の事前要件 Edit source

Replicating Directory Changes (ディレクトリ変更のレプリケート) の権限を持つセキュリティグループが必要となります。たとえば Directory Server Sync という名前のグループを作成します。具体的には、 Microsoft Metadirectory Services ADMA サービス アカウントの 'ディレクトリ変更のレプリケート' アクセス許可を付与する方法 ( https://docs.microsoft.com/ja-JP/troubleshoot/windows-server/windows-security/grant-replicating-directory-changes-permission-adma-service ) をお読みのうえ、手順に従って設定してください。

警告
警告: 強力なセキュリティの必要性について

このグループ内のメンバーを設定する際は、ドメイン管理者と同等の注意を払うようにしてください。このグループのメンバーは Active Directory 環境内の機密情報を読み込むことができるため、ユーザに対しては乱数から生成された強力なパスワードを設定するとともに、グループ内のメンバー追加や削除が不適切に行われないよう注意してください。

また、このグループに所属するサービスアカウントも作成する必要があります。

また、 389 DS と AD との通信を暗号化 (LDAPS) するため、 Active Directory 環境には証明書の設定もしなければなりません。なお、 Generic Security Services API/Kerberos (GSSAPI/KRB) は使用できません。

5.12.3 389 Directory Server 側の事前要件 Edit source

389 Directory Server 側ではバックエンドデータベースを設定し、組織単位 (OU) の各項目を同期できるように設定する必要があります。

また、 389 Directory Server 側ではレプリカ ID を設定して、読み込みと書き込みの両方ができるように設定する必要があります (レプリケーションの設定について、詳しくは 5.11項 「レプリケーションの設定」 をお読みください) 。

5.12.4 Active Directory から 389 Directory Server への同意の作成 Edit source

下記は 389 Directory Server 側で実行すべきコマンドで、 Active Directory から 389 Directory Server への同期合意を作成しています:

> sudo dsconf インスタンス名 repl-winsync-agmt create --suffix dc=example,dc=com \
  --host AD-ホスト名 --port 636 --conn-protocol LDAPS \
  --bind-dn "cn=サービスアカウント名,cn=USERS,dc=AD,dc=EXAMPLE,dc=COM" \
  --bind-passwd "パスワード" --win-subtree "cn=USERS,dc=AD,dc=EXAMPLE,dc=COM" \
  --ds-subtree ou=AD,dc=EXAMPLE,dc=COM --one-way-sync fromWindows \
  --sync-users=on --sync-groups=on --move-action delete \
  --win-domain AD-ドメイン adsync_agreement

合意を作成したあとは、初回の同期を実行します:

> sudo dsconf インスタンス名 repl-winsync-agmt init --suffix dc=example,dc=com adsync_agreement

下記のコマンドを使用することで、同期の状況を確認することができます:

> sudo dsconf インスタンス名 repl-winsync-agmt init-status --suffix dc=example,dc=com adsync_agreement
注記
注記: 項目によっては同期されない問題について

初期の同期が成功していても、場合によっては同期されない項目が現れる場合があります。詳しくは /var/log/dirsrv/slapd-インスタンス名/errors 内にある 389 DS のログファイルをご覧ください。

下記のコマンドを入力して実行し、合意の状態を確認します:

> sudo dsconf インスタンス名 repl-winsync-agmt status --suffix dc=example,dc=com adsync_agreement

Active Directory と 389 Directory Server のトポロジ内でメンテナンスを実行する場合は、下記のようなコマンドを入力して実行し、合意を一時的に停止します:

> sudo dsconf インスタンス名 repl-winsync-agmt disable --suffix dc=example,dc=com adsync_agreement

一時停止した合意は、下記のように入力して実行することで再開できます:

> sudo dsconf インスタンス名 repl-winsync-agmt enable --suffix dc=example,dc=com adsync_agreement

5.13 さらなる情報 Edit source

389 Directory Server に関する詳細については、下記をお読みください (いずれも本書記述時点では英語のみの提供です):

このページを印刷