「パスワードが多すぎる」問題
HomeLabの構築は、最初は小規模なものです。メディアサーバーのJellyfinをインストールし、コンテナ管理のためにPortainerを導入するといった具合です。その程度の規模なら、1つや2つのアカウントを作成するのは簡単です。しかし、ラボが拡張してNextcloud、Grafana、Gitea、そしていくつかのダッシュボードが含まれるようになると、壁に突き当たります。気づけば、私は12種類もの認証情報を管理していました。マスターパスワードを更新しようとするたびに、個別のウェブインターフェースにログインして手動で変更するのに30分も費やしていたのです。
これは単なる手間ではありません。セキュリティ上の弱点でもあります。めったに使わないサービスのテストアカウントを削除し忘れたら、それはネットワークへの永続的なバックドアになってしまいます。多くの人は、すべてを把握しきれずに、脆弱で同一のパスワードを使い回すという手段に頼ってしまいます。ユーザーを一箇所で管理する方法が必要でしたが、エンタープライズ向けのソリューションは、ハエを叩くのに大型ハンマーを使うような大げさなものばかりでした。
従来のLDAPが大げさに感じられる理由
通常、アプリケーションはユーザーデータを独自の内部SQLiteまたはPostgresデータベースに保存します。これによりデータのサイロ化が発生します。これを解決するために、業界ではLDAP（Lightweight Directory Access Protocol）が使用されています。これにより、アプリが中央サーバーに対して「このユーザーは存在するか？」「このパスワードは正しいか？」と問い合わせることができます。
問題は、従来のLDAPの実装はセットアップが非常に困難であることです。OpenLDAPは強力ですが、難解なスキーマを深く理解する必要があります。FreeIPAも選択肢の一つですが、安定稼働させるだけで少なくとも2GBのRAMを要求するリソース食いです。NUCやRaspberry Piで動作しているささやかなHomeLabにとって、それはリソースの大きな無駄遣いです。
選択肢の比較
私は、最適なツールを見つける前に、認証情報を一元化するいくつかの方法をテストしました。それぞれの比較は以下の通りです。
- OpenLDAP: 40年の歴史を持つ業界標準. 機能はしますが、学習曲線が垂直に近いほど急です。コマンドラインや、LDAP Account Manager (LAM) のような使いにくいツールでの管理はストレスが溜まります。
- Authentik / Authelia: これらは完全なアイデンティティプロバイダー（IdP）です。SAMLやOIDCが必要な場合には優れていますが、動作が重いです。Authentikは特に、複数のコンテナと数ギガバイトのメモリを必要とすることが多いです。
- LLDAP (Lightweight LDAP): Rustで書かれたモダンなサーバーです。クリーンなUI、極小のフットプリント、簡単な統合という基本に焦点を当てています。通常、アイドル時のRAM使用量は15〜20MB程度です。
解決策：DockerでLLDAPを動かす
LLDAPは、セルフホスト派にとってまさに「ちょうどいい」存在です。アプリが必要とするLDAPインターフェースを提供しつつ、シンプルなウェブダッシュボードも備えています。私はこの構成を1年以上運用し、15種類のサービスを管理しています。同期エラーやクラッシュは一度もなく、すべてのログインリクエストを完璧に処理しており、非常に安定しています。
ステップ1：環境の準備
Docker Composeは設定のポータビリティを維持できるため、デプロイに最適な方法です。まず、LLDAPデータ用の専用フォルダを作成します。
mkdir -p ~/homelab/lldap/data
cd ~/homelab/lldapステップ2：Docker Composeの設定
docker-compose.ymlファイルを作成します。LLDAPはPostgresをサポートしていますが、数十人程度のユーザーがいるHomeLabならSQLiteで十分です。データベース全体が1つのファイルになるため、移動も簡単です。
services:
lldap:
image: lldap/lldap:latest
container_name: lldap
ports:
- "17170:17170" # ウェブUI
- "3890:3890" # LDAPポート
environment:
- LLDAP_LDAP_BASE_DN=dc=homelab,dc=local
- LLDAP_LDAP_USER_PASS=MySuperSecretAdminPass
- LLDAP_SERVER_KEY_SEED=ここに長いランダムな文字列を使用してください
- LLDAP_DATABASE_URL=sqlite:///data/users.db
volumes:
- ./data:/data
restart: unless-stoppedプロのヒント：dc=homelab,dc=localを自分のドメインに変更してください。また、セッショントークンの安全性を保つため、LLDAP_SERVER_KEY_SEEDには必ず真にランダムな文字列を設定してください。
ステップ3：起動と初期設定
コマンド1つでコンテナを起動します：
docker compose up -dhttp://[サーバーのIPアドレス]:17170にアクセスし、adminユーザー名でログインします。インターフェースは最小限で高速です。最初の作業として、「users」や「admins」といったグループを作成し、個人のアカウントを追加しましょう。
ステップ4：サービスの接続
LLDAPが起動したら、アプリから接続設定を行います。Gitea、Nextcloud、Jellyfinなど、どのアプリでも設定は概ね以下のようになります：
- LDAPホスト:
192.168.1.50(DockerホストのIP) - ポート:
3890 - Bind DN:
uid=admin,ou=people,dc=homelab,dc=local - ユーザー検索ベース:
ou=people,dc=homelab,dc=local - グループ検索ベース:
ou=groups,dc=homelab,dc=local - ユーザーフィルター:
(uid=%s)
「保存」を押した瞬間から、LLDAPの認証情報を使ってそのアプリにログインできるようになります。そのサービスで手動でアカウントを作成する必要はもう二度とありません。
メンテナンスとバックアップ
LLDAPは非常に軽量なため、バックアップも簡単です。すべてがusers.dbファイルに保存されているため、私は毎晩のResticバックアップに~/homelab/lldap/dataフォルダを含めるだけで済んでいます。万が一サーバーが故障しても、そのフォルダ1つを新しいマシンに復元すれば、60秒以内に復旧できます。
セキュリティのため、LLDAPはローカルネットワーク内に留めておいてください。LDAPS（暗号化LDAP）もサポートしていますが、ほとんどのホームユーザーにとっては、ファイアウォールの内側に置くか、TailscaleのようなVPN経由でアクセスするだけで十分です。どうしても外部に公開する必要がある場合は、必ずSSL証明書を設定してください。
最後に
LLDAPへの移行は、私のサーバー運用において最高のQOL（生活の質）向上アップデートでした。新しいソフトウェアを試す際の設定の手間がなくなり、心理的なハードルが下がったからです。高速で、邪魔にならず、メモリもほとんど消費しません。3つ以上のサービスを管理しているなら、パスワードの使い回しはやめて、LLDAPに重労働を任せてしまいましょう。
