軽量ディレクトリアクセスプロトコル (Lightweight Directory Access Protocol (LDAP)) は情報ディレクトリへのアクセスや管理に使用するプロトコルです。 LDAP はユーザやグループのほか、システム設定の管理やアドレスの管理などにも使用することができます。 openSUSE Leap 15.6 では、 389 Directory Server が提供する LDAP サービスを使用することができます。これは従来の OpenLDAP の代替として提供されているものです。
実際には、中央のサーバのディレクトリ内にデータを保管しておき、明確に定義されたプロトコルで全てのクライアントに配布します。データは構造化されているため、様々なアプリケーションがそれらのデータにアクセスできるようになります。中央のサーバ (リポジトリとも呼びます) を用意することで管理の手間を省き、 LDAP のようなオープンで標準化されたプロトコルを使用することで、そこで管理されている情報にアクセスするプログラムをできる限り多く用意することができます。
なお、本章での 「ディレクトリ」 とは、読み込みや検索の速度や効率性の点で最適化されたデータベースを意味します。ディレクトリ内に保存されたデータは長期にわたって保存され、あまり変更が発生しないものとされます。通常のデータベースシステムであれば、短い時間内にデータの書き込みが多数発生する前提で最適化が行われますが、 LDAP サービスは読み込みに対して大きく最適化されたデータベースとなります。
本章では、 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 ディレクトリの構造」 のようになります。
上記は架空のディレクトリ情報ツリーを表しています。そのうち、 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.ldif
や 06inetorgperson.ldif
で規定されているオブジェクトクラスの一部と、それらで必須とされている属性、そして属性値の書式を紹介しています。 389 Directory Server パッケージをインストールしている環境であれば、これらは /usr/share/dirsrv/schema
内に存在しています。
オブジェクトクラス |
意味 |
値の例 |
必須の属性 |
---|---|---|---|
|
ドメインの名前パート |
example |
displayName |
|
組織単位 |
|
|
|
イントラネットもしくはインターネットの個人関連データ |
|
|
また 例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' ...
属性の名前とユニークな OID (オブジェクト識別子 (Object Identifier)) (数字) 、そして属性の略称を表しています。 | |
| |
属性内に保持できるデータの型。この場合、大文字と小文字を区別しない文字列であることを示しています。 | |
スキーマ要素のソース (たとえばプロジェクト名) 。 | |
オブジェクトクラス | |
そのオブジェクトクラスに対する簡潔な説明です。 | |
| |
| |
|
本章は 任意 で参照すべき項目であり、 389 Directory Server を Docker コンテナ下で動作させたい場合にのみ読むべきものです。通常のサーバ内への 389 Directory Server のインストールや管理については、本章以外の章をお読みください。
389 Directory Server インスタンスを Docker のコンテナとして作成して管理したい場合は、下記の手順をお読みください:
コンテナレジストリから 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
Docker コンテナを起動するには、下記のようなコマンドを実行します:
>
docker start インスタンス名
ここでは、コンテナ内でのプライマリプロセス ( PID 1
) が動作していることを前提にしています。 389 Directory Server コンテナ内でコマンドを実行するには、下記のような書式で記述して実行します:
>
sudo
docker exec -u ユーザ名 -i -t インスタンス名 コマンド
複数のコマンドを連続して実行したり、コマンド内で引用符を利用したりしたい場合は、コンテナに添付されている sh
シェルを介して実行する方法があります:
>
sudo
docker exec -u ユーザ名 -i -t インスタンス名 sh -c "コマンド"
動作中の Docker コンテナを停止するには、下記のようなコマンドを実行します:
>
docker stop インスタンス名
Docker コンテナを削除するには、下記のようなコマンドを実行します:
>
docker rm インスタンス名
下記のコマンドで 389 Directory Server をインストールすることができます:
>
sudo
zypper install 389-ds
インストールを行った後は、 5.3.1項 「389 Directory Server のインスタンスの構築」 に示されている内容に従って、 サーバの設定を行ってください。
dscreate
コマンドを使用することで、 389 Directory Server のインスタンスを作成したりきれいに削除したりすることができます。
インスタンスの作成方法には 2 つの種類があります。 1 つめは設定ファイルを使用する方法、もう 1 つは自動生成されたテンプレート (雛型) ファイルを使用する方法です。なお、自動生成されたテンプレートファイルを使用して本番環境を作成する場合は、内容をよく読んで注意深く設定してください。
インスタンスを作成したら、あとは管理者用のアカウントを作成して、必要なユーザとグループを管理してサービスを動作させてください。
389 Directory Server は主に 3 つのコマンドで制御します:
dsctl
ローカルのインスタンス管理に使用するコマンドで、 root
の権限が必要となります。なお、このコマンドを実行するには、ディレクトリサーバインスタンスの動作しているサーバ内にいなければなりません。起動や停止、データベースのバックアップなどを行うことができます。
dsconf
サーバの管理や設定を行うための主要なツールです。外部インターフェイスを介してインスタンスの設定を管理することができます。このコマンドを使用することで、インスタンスをリモートから設定変更することができます。
dsidm
識別子 (ユーザ/グループ/パスワードなど) を管理するために使用します。なお、アクセス制御機能で許可を得ておく必要があります。一般ユーザの場合、自分自身のパスワードのリセットや詳細情報の変更などを行うことができます。
下記の手順を実施することで、いくつかのサンプル用エントリを含むテスト目的や開発目的のインスタンスを構築することができます。
シンプルな設定ファイルを使用することで、新しい 389 Directory Server インスタンスを作成することができます。このファイルは INF と呼ばれる形式でなければなりませんが、ファイル名に関しては任意の名前を使用することができます。
既定のインスタンス名は localhost
です。インスタンス名は作成後に変更することができませんので、混乱を避けるとともに、動作を良く理解できるよう、既定値ではなく独自の名前を指定しておくことをお勧めします。なお、下記の例では LDAP1 というインスタンス名で、サフィックス (LDAP での既定のドメイン名) が dc= LDAP1 ,dc= COM である場合の例を示しています。
例 5.2 には新しい 389 Directory Server インスタンスを作成する際の設定ファイルの例が示されています。この内容を修正せずそのまま利用してもかまいません。
下記の内容をホームディレクトリ内の LDAP1.inf
というファイルに保存します:
# 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
例 5.2 から 389 Directory Server のインスタンスを作成するには、下記を実行します:
>
sudo
dscreate -v from-file LDAP1.inf |
\tee LDAP1-OUTPUT.txt
上記のコマンドを実行するとインスタンスが作成され、作成の際に出力された様々な情報が LDAP1-OUTPUT.txt
に書き込まれます。出力されたテキストファイルには様々な情報が含まれています。このファイルを作成したくない場合は、上記のコマンドラインのうち、 | tee LDAP1-OUTPUT.txt
の部分を削除してください。
dscreate
コマンドの実行が失敗した場合には、メッセージ内にその理由が示されますので、その原因を解決してからいったんインスタンスを削除 (詳しくは ステップ 5 をお読みください) してから、インスタンスを作成し直してください。
インスタンスの作成が成功すると、 Completed installation for LDAP1
というメッセージが出力されます。あとは作成したインスタンスの状態を確認します:
>
sudo
dsctl LDAP1 status
Instance "LDAP1" is running
下記のコマンドはインスタンスをきれいに削除するためのコマンドです。前者のコマンドでは削除が正しくできるかどうかを確認 (ドライラン) し、後者のコマンドで実際の削除を行っています。後者のコマンドでは、 --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
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
の箇所のコメント文字を外して、 no
を yes
にしてください。サンプル作成を指定すると、 demo_user
(ユーザ) と demo_group
(グループ) がそれぞれ作成されます。
このほか ;root_password
の行のコメント文字 (;) を外して、設定したいパスワードを入力してもかまいません。
また、テンプレート内には既定のサフィックス (LDAP での既定のドメイン名) を指定していませんので、下記のようにして suffix
行で指定を行うことができます:
suffix = dc=LDAP1,dc=COM
作成したインスタンスをきれいに削除してやり直すには、 dsctl
で下記のようなコマンドを入力して実行します:
>
sudo
dsctl LDAP1 remove --do-it
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
389 Directory Server のローカル管理を行う目的で、 /root
ディレクトリ内に .dsrc
設定ファイルを作成することができます。これにより、管理者 (root) や sudo 経由で管理権限を取得したユーザが、わざわざ 389 Directory Server の管理者情報を入力したりすることなく管理できるようになります。 例 5.3 には、サーバをローカル管理する場合の例が示されています。ここではインスタンス名が LDAP1 、ベース DN が com である場合を示しています。
/root/.dsrc
ファイルを作成したら、あとは新しいユーザを作成していきます (詳しくは 5.6項 「LDAP でのユーザとグループの管理」 をお読みください) 。
.dsrc
ファイル ## LDAP1 インスタンスを管理するための /root/.dsrc ファイルの例 [LDAP1] 1 uri = ldapi://%%2fvar%%2frun%%2fslapd-LDAP1.socket 2 basedn = dc=LDAP1,dc=COM binddn = cn=Directory Manager
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
をお読みください。
389 Directory Server の既定の TCP ポートは 389 と 636 です。 TCP:389 は暗号化を行わない接続および STARTTLS を使用する接続向けに、 TCP:636 は TLS での暗号化を行う接続向けに使用します。
firewalld
は openSUSE 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 ではオフラインとオンラインの両方のバックアップ形態に対応しています。 dsctl
コマンドではオフラインによるデータベースバックアップを、 dsconf
コマンドではオンラインによるデータベースバックアップを、それぞれ採取することができます。また、 LDAP サーバの設定ディレクトリをバックアップしておくことで、重大な障害が発生してサーバが復旧不可能になってしまったような場合に対応することもできます。
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: メンバ名から先頭の `/' を取り除きます
のようなメッセージが表示されますが、無視してかまいません。
設定を復元したい場合は、上記で採取したバックアップを同じディレクトリ内に展開します:
まずは既存の設定を上書きしてしまわないよう、既存の設定を移動します:
>
sudo
old /etc/dirsrv/slapd-インスタンス名/
採取したバックアップから展開します:
>
sudo
tar -xvzf
\config_slapd-インスタンス名-日付.tar.gz
展開したディレクトリとファイルを /etc/dirsrv/slapd-インスタンス名
にコピーします:
>
sudo
cp -r etc/dirsrv/slapd-インスタンス名
\/etc/dirsrv/slapd-インスタンス名
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
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/インスタンス名-日付
ユーザやグループの作成や削除、管理を行うには、 dsidm
コマンドを使用します。
下記では、既存のユーザとグループを一覧表示する例を示しています。なお、インスタンス名は 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 グループ名
下記の例では 1 人のユーザ wilber
を作成しています。このとき、サーバインスタンスは LDAP1
、サフィックスは dc=LDAP1,dc=COM であるものとします。
下記の例では、 389 DS インスタンス内にユーザ Wilber Fox を作成しています:
>
sudo
dsidm LDAP1 user create --uid wilber \
--cn wilber --displayName 'Wilber Fox' --uidNumber 1001 --gidNumber 101 \
--homeDirectory /home/wilber
ユーザの distinguished name
(DN) 名 (ディレクトリオブジェクトに対する完全修飾名、つまり唯一性の保証された名前) を参照するには、下記のように入力して実行します:
>
sudo
dsidm LDAP1 user get wilber
dn: uid=wilber,ou=people,dc=LDAP1,dc=COM [...]
ユーザのパスワード変更などの処理を行うには、 distinguished name
(DN) を指定する必要があります。
wilber
ユーザに対するパスワードを作成するには、下記のように入力して実行します:
>
sudo
dsidm LDAP1 account reset_password \
uid=wilber,ou=people,dc=LDAP1,dc=COM
あとは wilber
に設定するパスワードを 2 回入力します。
パスワードの設定が完了すると、下記のようなメッセージが表示されるはずです:
reset password for uid=wilber,ou=people,dc=LDAP1,dc=COM
設定済みのパスワードを変更したい場合も、同じコマンドで行うことができます。
認証が正しく動作することを確認します:
>
ldapwhoami -D uid=wilber,ou=people,dc=LDAP1,dc=COM -W
Enter LDAP Password: PASSWORD dn: uid=wilber,ou=people,dc=LDAP1,dc=COM
ユーザを作成したあとは、グループを作成してユーザを割り当てます。下記の手順では server_admins という名前のグループを作成し、そのグループに wilber
ユーザを所属させます。このとき、インスタンス名は LDAP1
、サフィックスは dc=LDAP1,dc=COM であるものとします。
まずはグループを作成します:
>
sudo
dsidm LDAP1 group create
すると、グループ名の入力を求められます。たとえば SERVER_ADMINS というグループを作成するには、下記のように入力します:
Enter value for cn : SERVER_ADMINS
あとは作成したグループに 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
ユーザの削除やグループからのユーザ脱退、そしてグループそのものの削除についても、 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
下記のように入力して実行することで、有効化されているプラグインと無効化されているプラグインの両方を一覧表示することができます。ここでは 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
下記のプラグインは、 389 Directory Server においてサポートされておりません:
Distributed Numeric Assignment (分散型数値配置; DNA) プラグイン
Managed Entries Plug-in (管理項目プラグイン; MEP)
Posix Winsync プラグイン
システムセキュリティサービスデーモン (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 であるものとして記しています:
まずは sssd
と sssd-ldap
の各パッケージをインストールします:
>
sudo
zypper in sssd sssd-ldap
まずは /etc/sssd/sssd.conf
ファイルをバックアップしておきます:
>
sudo
old /etc/sssd/sssd.conf
次に新しい SSSD の設定テンプレートを作成します。出力ファイル名には sssd.conf
と ldap.conf
のいずれかの名前を指定します。なお display
を指定すると、標準出力に出力を行います。下記の例では、 /etc/sssd/sssd.conf
ファイルにクライアント設定を出力しています:
>
sudo
cd /etc/sssd
>
sudo
dsidm LDAP1 client_config sssd.conf
出力された内容を確認して、環境に合わせた変更を行います。下記は /etc/sssd/sssd.conf
ファイルの設定例 (全体) です。
この 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
ファイルの所有者を root にして、 root のみが読み書きできるように設定します:
>
sudo
chown root:root /etc/sssd/sssd.conf
>
sudo
chmod 600 /etc/sssd/sssd.conf
SSSD サーバ内の /etc/nsswitch.conf
設定ファイルを編集し、下記のような行が含まれるようにします:
passwd: compat sss group: compat sss shadow: compat sss
SSSD サーバ内の PAM 設定である common-account-pc
, common-auth-pc
, common-password-pc
, common-session-pc
をそれぞれ編集します。 openSUSE Leap では pam-config
というコマンドを使用することで、これら全てのファイルを一括変更することができます:
>
sudo
pam-config -a --sss
あとは修正後の設定を確認します:
>
sudo
pam-config -q --sss
auth: account: password: session:
さらに、 389 Directory Server サーバ内にある /etc/dirsrv/slapd-LDAP1/ca.crt
ファイルを SSSD サーバ内の /etc/openldap/certs
にコピーして、ハッシュを再作成します:
>
sudo
c_rehash /etc/openldap/certs
SSSD を有効化して開始します:
>
sudo
systemctl enable --now sssd
systemctl での sssd.service の制御方法については、 第4章 「YaST を利用した認証クライアントの設定」 をお読みください。
nsslapd-rootpwstoragescheme
や passwordStorageScheme
の設定値として、もしくはアカウントポリシーオブジェクト内での passwordStorageScheme
の値としては、下記の値はサポート対象外となっております:
SHA
SSHA
SHA256
SSHA256
SHA384
SSHA384
SHA512
SSHA512
NS-MTA-MD5
clear
MD5
SMD5
なお、これらの値を含むデータベースからのインポートに関しては、 nsslapd-enable-upgrade-hash
が on
(デフォルト値: on
) になっていればサポート対象内となります。
OpenLDAP は 廃止予定となり、 389 Directory Server に置き換えられています。 SUSE ではこの移行作業を支援するため、 389-ds パッケージ内に openldap_to_ds
というユーティリティを提供しています。
openldap_to_ds
は移行作業をできる限り自動的に実施できるよう設計されています。ですが、それぞれの LDAP 環境は異なるものであることから、全ての環境に適合するツールを作成するのは不可能です。そのため、必要に応じて手作業による介入が必要となるほか、本番環境の移行にあたっては、あらかじめ移行作業のテストを行う必要もあります。
help
ページの参照について移行ツールである openldap_to_ds
を使用する前に、あらかじめ openldap_to_ds --help
コマンドで表示される内容をよくお読みになることを強くお勧めします。ここには移行ツールに用意されている機能の一覧のほか、制限事項に関する説明も書かれているため、誤った仮定に基づく誤解を防ぐことができるようになっています。
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 のホストをよく確認しておくことも重要です。
テスト移行時に発生した細かい問題などを詳しく記録しておくことも重要です。
saslauthd
を使用する OpenLDAP サーバのテスト移行 #Edit sourceOpenLDAP 環境の場合、パススルー型のユーザ認証を行うのに 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 (英語) をお読みください。
OpenLDAP で SASL によるパススルー認証を使用している場合、 389 Directory Server への移行は下記の手順が最適です:
まずは移行前に、 OpenLDAP サーバ内で testsaslauthd
を実行し、問題が発生しないことを確認しておきます。
>
sudo
testsaslauthd -u ユーザ名@レルム -p パスワード
saslauthd
は、レルムの指定から使用すべき認証バックエンドを判断し、ユーザ名は識別子として認証を行います。
389 Directory Server から saslauthd
に接続できるようにするため、 pam_saslauthd パッケージをインストールします。
>
sudo
zypper install -y pam_saslauthd
openldap_to_ds
コマンドを実行して、 OpenLDAP から 389 Directory Server への移行処理を行います。移行処理に関する詳細は、 5.9.1項 「OpenLDAP からのテスト移行」 をお読みください。
なお、 openldap_to_ds
を実行すると、ユーザの userPassword
属性が userPassword: {SASL}ユーザ名@レルム
形式になっていることを検出すると、この属性は削除され、 nsSaslauthId
属性に nsSaslauthId: ユーザ名@レルム
が設定されます。これに加えて、この属性に対応するよう、 objectClass: nsSaslauthAccount
が自動的に追加されます。
移行が終わったあとは、下記のようなコマンドを実行して、 PAM のパススルー認証が正しく設定されているかどうかを確認します:
>
sudo
dsconf インスタンス名 plugin pass-through-auth show
>
sudo
dsconf インスタンス名 plugin pam-pass-through-auth list
移行が全て終わると、パススルー認証は下記のような構成になります:
┌─────────────────┐ │ │ │LDAP クライアント│ │ │ └─────────────────┘ │ バインド │ ▼ ┌─────────────────┐ │ 389-DS │ │ サーバ │ │ │ └─────────────────┘ │ ▼ ┌─────────────────┐ │ │ │ pam saslauthd │ │ │ └─────────────────┘ │ ▼ ┌─────────────────┐ │ │ │ saslauthd │ │ │ └─────────────────┘ │ │ ▼ ┌─────────────────┐ │ │ │ 外部認証 │ │ │ └─────────────────┘
saslauthd
パススルー認証のトラブルシューティング #Edit sourceOpenLDAP から 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
で表示することができます。
saslauthd
が正しく動作すること。PAM saslauthd
が正しく動作するかどうかを確認したい場合は、 https://github.com/kanidm/pam_tester にある pam_tester
ツールをお使いください。
なお、 pam_tester
ツールは公式にサポートされているツールではありません。
PAM パススルー認証プラグインの状態を確認するには、下記のようなコマンドを入力して実行します:
>
sudo
dsconf インスタンス名 plugin pam-pass-through-auth status
プラグインを有効化するには、下記のようなコマンドを入力して実行します:
>
sudo
dsconf インスタンス名 plugin pam-pass-through-auth enable
サーバインスタンスに対して PAM パススルー認証プラグインの設定がされているかどうかを確認するには、下記のようなコマンドを入力して実行します:
>
sudo
dsconf インスタンス名 plugin pass-through-auth show
ログファイルは /var/lib/サーバユーザ名/インスタンス名/error
にあります。
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 へ) の移行は提供されていませんので、よく注意しておく必要があります。下記には、様々な類似性と差異の一覧を示しています。
機能 | OpenLDAP | 389 Directory Server | 互換性 |
---|---|---|---|
双方向レプリケーション | SyncREPL | 389 DS 固有のシステム | いいえ |
MemberOf | オーバーレイ | プラグイン | はい (シンプルな設定にのみ対応) |
外部認証 | プロキシ | - | いいえ |
Active Directory との同期 | - | Winsync プラグイン | いいえ |
内蔵スキーマ | OLDAP スキーマ | 389 スキーマ | はい (移行ツールで対応) |
独自スキーマ | OLDAP スキーマ | 389 スキーマ | はい (移行ツールで対応) |
データベースの取り込み | LDIF | LDIF | はい (移行ツールで対応) |
パスワードのハッシュ化 | 各種 | 各種 | はい (Argon2 を除く全ての形式に対応) |
OpenLDAP と 389 DS のレプリケーション | - | - | いいえ (389 DS との同期は不可能) |
時間ベースのワンタイムパスワード (TOTP) | TOTP オーバーレイ | - | いいえ (現時点でサポートされていません) |
entryUUID | OpenLDAP の一部として提供 | プラグイン | はい |
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 という名前を指定してください。
インスタンスから自己署名用の証明機関と証明書を削除するには、下記のコマンドを実行します:
>
sudo
dsctl インスタンス名 tls remove-cert Self-Signed-CA
>
sudo
dsctl インスタンス名 tls remove-cert Server-Cert
ここで、 インスタンス名 にはディレクトリサーバのインスタンス名を指定します。前章での手順では LDAP1 という名前を設定しているものです。
まずは証明書への署名を実施した証明機関の証明書をインポートします。
>
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_の名前 には、証明機関の名前を指定します。
あとはサーバ証明書とそれに対応する鍵をインポートします。
>
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 形式) のファイルに対するフルパスを指定します。
あとはインスタンスを再起動すると、新しい証明書を使用するようになります。
>
sudo
systemctl restart dirsrv@インスタンス名.service
ここで、 インスタンス名
にはディレクトリサーバのインスタンス名を指定します。
389 Directory Server では複数のサーバ間でデータベースをレプリケーション (複製) することができます。レプリケーションの構成にもよりますが、下記のような利点を提供することになります:
性能と応答時間の高速化
耐障害性と冗長性の確保
負荷分散
高可用性
データベースは複製可能なディレクトリの最小単位でもあります。データベース全体を複製することはできますが、データベース内のサブツリーのみを複製することはできません。また、 1 つのデータベースは必ず 1 つのサフィックスに結びつけられるものであり、 2 つまたはそれ以上のデータベースにまたがったサフィックスを複製することはできません。
また、複製すべきデータを他に送信するサーバをサプライヤ (supplier) と呼びます。逆に、サプライヤからのデータを受け取るサーバをコンシューマ (consumer) と呼びます。レプリケーションは常にサプライヤ側から行われ、 1 つのサプライヤからは複数のコンシューマに送信することができます。また一般に、マルチサプライヤ (multi-supplier) レプリケーションの場合を除いて、サプライヤは読み書き可能なレプリカとして、コンシューマは読み込み専用のサーバとして提供されます。マルチサプライヤレプリケーションの場合、サプライヤとコンシューマを兼ねるサーバとなります。
389 DS は他のデータベースとは異なるレプリケーション管理を行います。レプリケーションは非同期でありながらも、結果整合性を持つ仕組みになっています。つまり、下記のような動作になります:
サーバへの書き込みや変更は、即時に受け入れられます。
特定のサーバ内に書き込まれたあと、他のサーバにレプリケーションされて見えるようになるまでの間に、時間的な遅れが発生します。
いずれかのサーバ内での書き込みに矛盾が発生した場合、特定のポイントまでロールバック (巻き戻される) 可能性があります。
レプリケーションの遅延により、特定の時点で各サーバ内に存在するデータが異なる可能性があります。
一般的に LDAP は、 「書き込みの少ない」 データベースであるため、これらの特徴を考慮しても、サーバが一貫性のない状態にはならず、常に既知の安定状態に居続けることができます。また、この安定状態からの変更は少しずつしか行われないため、日々の運用ではこのような欠点に気付くようなことはありません。
レプリケーションの構成 (トポロジ) を設計するにあたっては、下記のような要素を決めておく必要があります。
レプリケーションに対する要件: 高可用性、物理的な配置場所、読み込み性能やそれらの組み合わせなど。
構成内に配置するレプリカ (ノード、サーバ) 数。
データの流れとその方向。構成内に流入するデータと流出するデータ。
クライアント側からリクエストを送信する際の、ノード選択方式 (クライアント側で LDAP URI を複数個指定して分散させるか、 SRV レコードで分散させるか、ロードバランサを用いるか等) 。
これらの要素はいずれも構成そのものに影響します (詳しい構成例については 5.11.3項 「レプリケーションの設計例」 をお読みください) 。
下記の章では、 2 ノードから 6 ノードまでの 389 Directory Server ノードを使用する、いくつかのレプリケーション構成例を示しています。なお、レプリケーションを構成する際の最大サプライヤ数は 20 ノードまでです。実際の運用経験からすると、レプリケーション効率を高めるための最適なノード数は最大でも 8 ノードまでと考えられています。
┌────┐ ┌────┐ │ S1 │◀─────▶│ S2 │ └────┘ └────┘
例5.4「2 つのサプライヤレプリカ」 には S1 と S2 という 2 つのレプリカが示されています。これらは双方向レプリケーションとして構成する場合の例で、これらのノードはいずれもサプライヤとコンシューマの両方を兼ね備えた存在となります。 S1 と S2 は別々のデータセンター内であっても、同じデータセンター内であってもかまいません。 LDAP URI や負荷分散装置、 DNS SRV レコードのいずれかでクライアント側からのアクセスを分散させることができます。また、これは高可用性を提供する際の最もシンプルな構成でもあります。ただし、一方のサーバで障害が発生してオフラインになった場合、他方のサーバでは全てのクライアントからの処理を受け付ける必要があることに注意してください。また、 2 ノードのレプリケーションでは一方のノードがオフラインになった場合、残った 1 つのノードのみで全ての処理を行わなければならないことから、水平分散としては不適切です。
2 ノードの構成は最も簡単に管理できることから、既定の構成と考えられます。この構成を初期構成として、必要に応じて構成を広げていってもかまいません。
┌────┐ ┌────┐ │ S1 │◀─────▶│ S2 │ └────┘ └────┘ ▲ ▲ │ │ ▼ ▼ ┌────┐ ┌────┐ │ S3 │◀─────▶│ S4 │ └────┘ └────┘
例5.5「4 つのサプライヤレプリカ」 は 4 つのサプライヤレプリカを構成する場合の例です。これらは相互にデータを同期する構成で、 4 つのデータセンターに分散させても、 1 つのデータセンターごとに 2 つのサーバを配置してもかまいません。 4 つのデータセンターに分散させた場合、各ノードは 100% のクライアント負荷を受け付ける処理能力が必要となります。 2 つのデータセンターに 2 つのサーバを配置した場合は、各ノードは 50% のクライアント負荷を受け付ければ十分になります。
┌────┐ ┌────┐ │ S1 │◀─────▶│ S2 │ └────┘ └────┘ ▲ ▲ │ │ ┌────────────┬────┴────────────┴─────┬────────────┐ │ │ │ │ ▼ ▼ ▼ ▼ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │ S3 │◀─────▶│ S4 │ │ S5 │◀─────▶│ S6 │ └────┘ └────┘ └────┘ └────┘
例5.6「6 つのレプリカ」 は各サーバ対を別々の場所に配置した場合の構成例です。 S1 と S2 はサプライヤ、 S3, S4, S5, S6 は S1 と S2 のコンシューマとして構成します。また、各サーバ対はお互いにレプリケーションしているものとし、 S3, S4, S5, S6 でも書き込み要求は受け付けるものとしますが、ほとんどのレプリケーションは S1, S2 で行われます、このような構成は、高可用性と分散処理の両方を、地理的な離れた場所から提供する際の例となります。
┌────┐ ┌────┐ │ S1 │◀─────▶│ S2 │ └────┘ └────┘ │ │ │ │ ┌────────────┼────────────┼────────────┐ │ │ │ │ ▼ ▼ ▼ ▼ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │ S3 │ │ S4 │ │ S5 │ │ S6 │ └────┘ └────┘ └────┘ └────┘
例5.7「読み込み専用コンシューマのある 6 つのレプリカ」 では、 S1 と S2 の両方がサプライヤとなり、残りの 4 つのサーバは読み込み専用のコンシューマとして構成する場合の例となります。全ての書き込み要求は S1, S2 でのみ行われ、残りの 4 つのサーバに複製していく構成です。読み込み専用のコンシューマには、データ開示を最小限に留めるため、データベースの一部や項目の一部のみを保存させるようにすることもできます。このように部分的な複製のみを持つ構成は DMZ のようなネットワークを持つ場合に最適で、この場合は DMZ 内に配置したコンシューマへの書き込みはできなくなります。
ここまでに説明してきた 389 DS の構成例やこの後の説明では、様々な用語を使用しています。下記ではそれら用語に対する説明を示しています。
データベースを持つ 389 DS のインスタンスを意味しています。
読み込みと書き込みの両方の要求を受け付けることができる、データベースの完全コピーを持つレプリカを意味しています。
読み込み要求のみを受け付けることができる、データベースの完全コピーを持つレプリカを意味しています。
データベースのうちの一部のみを複製し、読み込み要求のみを受け付けることができるレプリカを意味しています。
他のレプリカにデータベースの内容を提供することができるレプリカを意味しています。
他のレプリカからデータを受け取って、自身のデータベースに書き込むレプリカを意味しています。
他のレプリカとの関係性 (サプライヤ/コンシューマ) に対するサーバ設定を意味しています。
レプリケーション同意を介したレプリカ同士の接続構成を意味しています。
レプリケーション構成内で重複しない 389 Directory Server のインスタンス識別子を意味しています。
ディレクトリ内でレプリケーション権限を持つアカウントを意味しています。
最小構成例として、まずは 2 ノードの双方向レプリケーションと 1 ノードの読み込み専用サーバを構成してみます。下記の例では、読み書き可能なレプリカのサーバ名は RW1, RW2 とし、読み込み専用のレプリカのサーバ名は RO1 とします (もちろん必要に応じて自由な名前を設定してかまいません) 。
この構成内にあるサーバには、全て同じサフィックスを設定する必要があります。また、初期状態では RW1 にのみデータが存在するものとします。
下記のコマンドは 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
読み込み専用ノードを作成するには、まずレプリケーションマネージャのアカウントとメタデータを作成するところから始めます。ここでのサーバ名は 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
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
レプリケーションを有効化した場合は、 389 Directory Server のバックアップについてもいくつかの調整を行う必要があります (一般的なバックアップ方法については 5.5項 「389 Directory Server でのバックアップと復元」 をお読みください) 。具体的には、バックアップ時に db2ldif
コマンドを実行している場合、 --replication
フラグを指定して、レプリケーションのメタデータを最初にバックアップするようにしてください。また、バックアップは構成内の全てのサーバに対して行うものとし、バックアップからの復元に際しては、構成内の 1 ノードでのみ実施して、残りのノードは再初期化を行ってデータを複製してください。
メンテナンスやその他の運用上の理由で、レプリケーションを一時的に停止することができます。なお、一時停止は変更履歴の保持日数で示された期間 (詳しくは 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
レプリカを何らかの理由でしばらくオフラインにする場合には、最大で changelog max-age
で指定した時間までが許容されます。 max-age
オプションは過去の変更履歴を持つ長さを時間で指定するための値で、ここで指定したよりも過去の履歴は自動的に削除されます。
しばらくオフラインになっていたレプリカが復帰すると、通常のレプリケーションと同様に、他のレプリカとの間で同期が行われます。 max-age
で指定したよりも長い時間オフラインであった場合は、一貫性を失うことから、他のノードからの変更を拒否したり、他のノードへの変更送信を拒否したりするようになります。下記の例では、 max-age
を 7 日間に設定しています:
>
sudo
dsconf インスタンス名
\replication set-changelog --max-age 7d
\--suffix dc=EXAMPLE,dc=COM
レプリカを削除するには、まず他のノードに対して変更点の送信を停止する必要があります。あとは削除するノードで受け付けていたレプリケーション合意を削除します。下記の例では、 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
389 Directory Server でレプリケーションを使用する場合、下記のサポート制限があります:
読み書き可能なノードは最大 8 個まで
レプリケーションハブは最大 20 個まで
読み込み専用のサーバは最大 100 個まで
読み書き可能なメンバーとしての Winsync Active Directory コンシューマは最大 1 個まで
389 Directory Server では、 Microsoft 社の Active Directory からユーザやグループの項目を取得する機能が提供されています。この機能を使用することで、通常は必要とされるドメインへの参加を行うことなく、 389 DS を利用して Linux クライアントが識別情報を取得できるようになります。これにより、 389 DS が Active Directory と相互に運用できるようになり、用途をさらに広げることができるようになっています。
同期の形態にもよりますが、最小構成では 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 │ │ │ │ │ │ │ │ │ └────────┘ └────────┘ └────────┘ └────────┘
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) は使用できません。
389 Directory Server 側ではバックエンドデータベースを設定し、組織単位 (OU) の各項目を同期できるように設定する必要があります。
また、 389 Directory Server 側ではレプリカ ID を設定して、読み込みと書き込みの両方ができるように設定する必要があります (レプリケーションの設定について、詳しくは 5.11項 「レプリケーションの設定」 をお読みください) 。
下記は 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
389 Directory Server に関する詳細については、下記をお読みください (いずれも本書記述時点では英語のみの提供です):
提供元のドキュメンテーションは https://www.port389.org/docs/389ds/documentation.html にあります。
man dsconf
man dsctl
man dsidm
man dscreate