手当たり次第に書くんだ

飽きっぽいのは本能

CentOS 8 389 Directory Server 構築 #1 導入

目次に戻る

概要

389 Directory Serverを使用してLDAPサーバーを構築します。本稿ではインストールからLDAPSの有効化までを説明しています。

追記:
Ubuntu版の389 Directory Serverの導入方法をこちらにまとめています。

前提条件

OS

CentOS Stream 8を使用します。

CentOS Streamの使用を避けるためにCentOS7を使用するケースもあり、CentOS7でも389 Directory Serverの導入が可能ですが、関連するツール類(389-console等)がかなり古いのでお勧めしません。もちろんエンドユーザーの要望であればCentOS7の389 Directory Serverでも十分に動作するので無理にCentOS7を否定しなくとも問題ないと思います。

SELinux

有効です。無効にする場合はこちらを参照して下さい。

Firewalld

無効です。有効化する場合はこちらを参照して必要な許可設定をして下さい。

その他

本稿では389 Directory Serverの初期設定にCockpitを使用する為、EPELリポジトリの389 Directory Serverを使用します。

標準ポート番号

TCP:389 (LDAP), TCP:636 (LDAPS)

所感

OpenLDAPから389 Directory Serverへ

長らくデファクトスタンダードであったOpenLDAPは、CentOS7の後半から非推奨となり389 Directory Serverが後継となりました。389 Directory Serverの前身はFedora Directory Server(FDS)です。機能面は割と現代的になっている印象ですが、まだまだ情報が少なくいろいろと不具合がありそうです。また、各アプリケーションが提供するスキーマもOpenLDAP向けにしか用意されていない場合もあり、注意が必要です。

LDAPについて

LDAP(Lightweight Directory Access Protocol)はディレクトリサービスですが、ディレクトリサービスは端的にいうとデータベースです。認証以外にも様々データを格納して利用でき、利用するアプリケーション側で特別な属性が必要な場合は、専用のスキーマをアプリケーション側が用意します。LDAPはあくまで箱です。LDAPは利用目的に対してどのようなデータ構造とするかが大きな検討要素であり、利用目的を決めるのはLDAPクライアントです。

一般的にLDAPクライアントは一般のユーザーではなくシステム内のアプリケーション(Webサーバー等)です。LDAPはWebサーバーのバックエンドとして動き、一般のユーザーはLDAPを意識せずにWebアプリケーションを利用します。つまりWordPressが使うMariaDBと同じです。WordPressを閲覧するユーザーはApacheにHTTPクライアントとしてアクセスしており、MySQLコマンドは使用していませんね。

LDAPの難しさ

LDAPは主には認証で使われるケースが多いと思いますが、Microsftの認証の仕組みであるActive Directoryも内部ではLDAPが稼働しており、LDAPクライアントでActive Directoryに接続することも可能です。Active Directoryはドメインコントローラーであり、LDAPはそれのコンポーネントのひとつとして内部的に組み込まれています。この為、利用者はLDAPを意識しなくても済むように設計されています。ちなみにアプライアンス等でActive Directory認証対応と謳っているものは実際はLDAPで接続しているものも多くあります(認証に必要な属性を参照できれば良い為)。

対してLDAPは、何の用途に使うか、その用途に対して何の属性が必要となるか?から調べる必要があり、それらはActive Directoryのようにユーザーフレンドリーに作られていません。LDAPはユーザー設定はもちろんLDAP設定自体もLDIFです。また、基本的にはLDAPSが推奨される為、SSLの理解も必要です。LDAP用語も独特です。慣れないうちはLDIFを作成して設定する作業自体に苦しむでしょう。

参考資料

https://www.port389.org/
https://straypenguin.winfield-net.com/389ds.html#prepnofile

設定

インストール

389 Directory ServerはBaseリポジトリには含まれてないためDNFモジュールの有効化が必要です。まずは利用可能なモジュールを確認します(一部抜粋)。AppStreamとEPELリポジトリに389 Directory Serverが存在していることが確認できます。

[root@centos ~]# dnf module list

CentOS Stream 8 - AppStream
Name                     Stream              Profiles                                    Summary
389-ds                   1.4                                                             389 Directory Server (base)

Extra Packages for Enterprise Linux Modular 8 - x86_64
Name                     Stream              Profiles                                    Summary
389-directory-server     next                default, minimal                            389 Directory Server
389-directory-server     stable              default [d], legacy, minimal                389 Directory Server
389-directory-server     testing             default [d], legacy, minimal                389 Directory Server

本稿ではEPELリポジトリのstableの389 Directory Serverを使用します。AppStreamにも389 Directory Serverが存在しますが、これにはCockpitモジュール(cockpit-389-ds)が含まれていません。

[root@centos ~]# dnf module install 389-directory-server:stable/default

初期設定

本稿ではCockpitでの設定とコマンドでの設定が混在しています。

インスタンス作成

Cockpitから作成します。対話形式のスクリプトも用意されていますが省略します。

ツール > 389 Directory Server > Create New Instance

項目名 設定例 説明 備考
Instance Name Instance1 インスタンス名を設定します。
Port 389 LDAPのポート番号です。389はデフォルト値です。
Secure Port 636 LDAPSのポート番号です。636はデフォルト値です。
Create Self-Signed TLS Certificate チェック無し 自己署名証明書の作成有無を指定します。本稿では個別の自己署名証明書を使用する為、チェックを外しています。 チェック有りでは389 Directory Serverが独自に自己署名証明書を作成します。
Directory Manager DN cn=Directory Manager 当該インスタンス全体の管理DNです。cn=Directory Managerはデフォルト値です。
Directory Manager Password パスワード Directory Manager DNのパスワードです。
Confirm Password パスワード Directory Manager Passwordの確認です。
Create Database チェック有り 当該インスタンス作成時点でデータベースの作成有無を指定します。本稿ではデータベースを作成します。
Database Suffix dc=si1230,dc=com データベースのサフィックスを指定します。 一般的にドメイン名に合わせます。
Database Name si1230.com データベース名を指定します。 この値の正確な目的は不明でした。表示上、単にSuffixの別名ではないかと想定されますので、ドメイン名にしておくと管理しやすいと思います。尚、対話形式スクリプトでインスタンスを作成する場合はこの設定値を要求されません。
Database Initialization Do Not Initialize Database サンプルデータの作成有無を指定します。本稿ではサンプルデータを作成しません。 余計なACIが含まれる為、後から手動で作成します。

ルート証明書のインポート

Cockpitからインポートします。対象の389 Directory Server上にルート証明書を配置しておく必要あります。SSL証明書の作成手順はこちらを参照して下さい。

ツール > 389 Directory Server > Server Setting > Secutiry > Security Setting > Certificate Management > Trusted Certificate Authorites > Add CA Certificate

設定項目 設定例 説明
Certificate File /root/ca.crt ルート証明書のLinux上のファイルパスを指定します。
Certificate Nickname CA-Cert NSS Certificate DBで識別する証明書の名前を指定します。

サーバー証明書のインポート

コマンド操作です。まずPKCS#12形式の証明書を作成します。パスワードはインポート時に必要となります。SSL証明書の作成手順はこちらを参照して下さい。

[root@centos ~]# openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12 -nodes -name Server-Cert
Enter Export Password: password
Verifying - Enter Export Password: password
-in
証明書のファイルパスを指定します。
-inkey
証明書の鍵のファイルパスを指定します。
-out
出力するファイル名です。
-name
NSS Certificate DBで識別する証明書の名前です。389 Directory Serverではデフォルトでサーバー証明書のニックネームがServer-Certで指定されていますのでそれに合わせます。変更も可能です。

作成したPKCS#12形式の証明書をインポートします。NSS Certificate DBのパスワードは/etc/dirsrv/slapd-Instance1/pin.txtに記載されています。Cockpitでもサーバー証明書をインポートできそうですが、いくつかのパターンを試しましたが、うまく有効化できませんでした。

[root@centos ~]# pk12util -i server.p12 -d /etc/dirsrv/slapd-Instance1
Enter Password or Pin for "NSS Certificate DB": password
Enter password for PKCS12 file: password
pk12util: PKCS12 IMPORT SUCCESSFUL

※証明書の更新について
証明書の有効期限が切れるとLDAPSに接続不可となりますが、証明書を再作成し、本手順再実施すれば問題ありません。ファイル名、パラメータも同じで問題ありません。

LDAPS有効化

Cockpitから有効化します。

ツール > 389 Directory Server > Server Setting > Secutiry > Security Setting > Security Configuration > Security Enabled

サービス再起動

インスタンスを作成した時点でLDAPは起動しています(自動起動も有効です)。各設定を有効にする為に再起動します。

389 Directory Serverは複数のインスタンスを作成できる為、全てのインスタンスを操作する場合はdirsrv.targetを指定します。下記の例ではInstance1だけを再起動しています。

[root@centos ~]# systemctl restart dirsrv@Instance1.service

その他

LDAPコマンドを使用した動作確認はこちらを参照してください。

本稿の続き(初期データ登録)は下記のリンクから移動して下さい。

LDAPサーバー構築 No.2 初期データ登録

目次に戻る

CentOS 8 389 Directory Server 構築 #1 導入

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

トップへ戻る