AlmaLinux 9 で SSSD+389ds でLDAP認証を構築してみる

Last updated at 2025-07-13Posted at 2025-07-13

自分用の備忘録です。

学習のために Virtual Box 上の AlmaLinux 9 に、LDAP サーバである 389 Directory Server (389ds) を構築し、SSH 接続の認証で LDAP の情報を使用できるようにします。

389ds を立ち上げるところまでは前回の記事で実施しています。

環境

物理マシン

この記事の本質とはあまり関係ありませんが、一部 Windows 側での操作があるので念のために記載します。

Windows 10 上の Oracle VM VirtualBox

仮想マシン1 (LDAPサーバにするホスト)

389 Directory Server を構築する、今回のメインとなるホストです。

OS: AlmaLinux9
- 「最小インストール」でインストール済み
IPアドレス: 192.168.56.130
ユーザ : se (UID=1000, 管理者)
- 基本的には sudo -s で root になった状態で操作します
- ほかにユーザがあってもよいですが使用しません
仮想ネットワーク設定: NAT, ホストオンリーアダプタ
- インターネット接続と、物理マシン・他の仮想マシンのホストとの通信が可能であればよい
前回の記事で 389ds を立ち上げ済み

仮想マシン2~5 (SSSD を構築し、LDAPサーバを利用するホスト)

LDAP 情報でログインできるようにするホストです。まず仮想マシン2でひととおり設定した後、仮想マシン2を複製して 3, 4, 5 を作成します。

IPアドレス: 192.168.56.131 ～ 134
389ds をインストールしていないこと以外は仮想マシン1と同じ状態です。

ユーザ情報の計画

今回は、下記のグループ・ユーザをLDAP上に登録し、そのユーザとして仮想マシン2~5へ SSH でログインできるようにします。

グループ名	GID	説明
user	10000	今回作成する全ユーザが属するグループ
user01	10001	ユーザ user01 のみが属するグループ
user02	10002	ユーザ user02 のみが属するグループ
admin	11000	このグループに属するユーザに一括で sudo 権限を付与する

ユーザ名	UID	グループ	セカンダリグループ	公開鍵認証
user01	10001	user01	user, admin	公開鍵を登録する
user02	10002	user02	user	公開鍵を登録する

※ホームディレクトリは共通で /home/<ユーザ名> とする
※ログインシェルは共通で /bin/bash とする

UID や GID はそれぞれ一意である必要があり、LDAPによらないユーザ・グループとの重複もあってはいけません。LDAPによらないユーザ・グループのIDは 1000 から連番で付与されるため、今回はそれと重複しないよう 10000 以上の値にしています。

1. LDAP オブジェクトの登録 (仮想マシン1)

前回の記事ではベースドメイン dc=example,dc=com の下に何もオブジェクトを作成していないため、まずはユーザ情報などの必要なオブジェクトを作成します。

作成するオブジェクトの概要

LDAP はオブジェクトをノードとする木構造になっています。多種多様なオブジェクトを作成できますが、今回の目的は SSH 認証に必要な情報を保持することなので、次の種類のオブジェクトを作成します。

木構造の節にあたるオブジェクト (objectClass¹: organizationalUnit)
SSSD が LDAP にログインするときに使用するアカウントを表すオブジェクト
SSH 接続時に指定できるユーザを表すオブジェクト
上記ユーザが属するグループを表すオブジェクト
sodoできるユーザを指定するオブジェクト

今回は、構造は https://qiita.com/y-araki-qiita/items/0c954c3ae25d4ed9dbb8 を、それ以外のオブジェクトは https://qiita.com/mypaceshun/items/9c3b3f0ef9580c6d60ea を参考にしています。

まずは作成するオブジェクトを大雑把に整理するために、ドメインネーム (dn)² と木構造のみを記載します。

dc=example,dc=com
├ ou=tool-admin,dc=example,dc=com
│ └ cn=sssd,ou=tool-admin,dc=example,dc=com   : SSSD が LDAP にログインするときに使用するアカウント
│
├ ou=SUDOers,dc=example,dc=com                : sudo できるユーザの情報をまとめる場所
│ └ cn=%admin,ou=SUDOers,dc=example,dc=com    : admin グループのユーザが sudo できることを表すオブジェクト
│
├ ou=Users,dc=example,dc=com                  : ユーザの情報をまとめる場所
│ ├ cn=user01,ou=Users,dc=example,dc=com      : ユーザ user01 の認証情報
│ └ cn=user02,ou=Users,dc=example,dc=com      : ユーザ user02 の認証情報
│
└ ou=Groups,dc=example,dc=com                 : グループの情報をまとめる場所
  ├ cn=user,ou=Users,dc=example,dc=com        : グループ user の情報
  ├ cn=user01,ou=Users,dc=example,dc=com      : グループ user01 の情報
  ├ cn=user02,ou=Users,dc=example,dc=com      : グループ user02 の情報
  └ cn=admin,ou=Users,dc=example,dc=com       : グループ admin の情報

スキーマの追加

オブジェクト作成の前に、スキーマの追加をします。389ds の場合、公開鍵を記録する属性が定義されていないので、公開鍵を記録できるオブジェクトクラス・属性を定義する必要があります。

「6. LDAPに登録した公開鍵を認証に使用できるようにする」を実施しない場合はスキーマの追加は不要です。その場合、後述するオブジェクト登録用の LDIF ファイル内にある sshPublicKey 属性をすべて削除してください。

まず、下記の LDIF ファイルを作成します。

openssh-lpk_openldap.ldif

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey'
  DESC 'MANDATORY: OpenSSH Public key' 
  EQUALITY octetStringMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
  SINGLE-VALUE )
-
add: objectClasses
objectClasses: ( 1.3.6.1.4.1.24552.500.1.1.2.0 NAME 'ldapPublicKey'
  SUP top AUXILIARY
  DESC 'MANDATORY: OpenSSH LPK objectclass'
  MAY ( sshPublicKey $ uid ) )

属性名 sshPublicKey は、SSSD が公開鍵を参照する際にデフォルトで使用する属性名です。他の属性名を使用する場合、SSSD の設定時にその属性名を明示する必要があります。

次に、この LDIF ファイル適用します。前回の記事で Windows 側にインストールした Apache Directory Studio を使用する場合、メニューの File -> Import... -> LDIF into LDAP から LDIF ファイルを適用できます。

コマンドを使用する場合は次のとおりです。

ldapmodify -D cn=Manager -W -f <LDIFファイルのパス>

オブジェクト登録用の LDIF ファイルの作成

次に、先ほど整理したオブジェクトを LDAP へ登録する際に使用する LDIF ファイルを作成します。ここには、最初に計画したUID, GID 等も含めて、登録する情報をすべて記載します。

sssd.ldif

dn: ou=Users,dc=example,dc=com
objectClass: organizationalUnit
ou: Users
aci: (targetattr="*")(version 3.0; acl "Allow full read to sssd"; allow (read,search,compare) userdn = "ldap:///cn=sssd,ou=tool-admin,dc=example,dc=com";)

dn: ou=Groups,dc=example,dc=com
objectClass: organizationalUnit
ou: Groups
aci: (targetattr="*")(version 3.0; acl "Allow full read to sssd"; allow (read,search,compare) userdn = "ldap:///cn=sssd,ou=tool-admin,dc=example,dc=com";)

dn: ou=tool-admin,dc=example,dc=com
objectClass: organizationalUnit
ou: tool-admin

dn: ou=SUDOers,dc=example,dc=com
objectClass: organizationalUnit
ou: SUDOers
aci: (targetattr="*")(version 3.0; acl "Allow full read to sssd"; allow (read,search,compare) userdn = "ldap:///cn=sssd,ou=tool-admin,dc=example,dc=com";)

dn: cn=sssd,ou=tool-admin,dc=example,dc=com
objectClass: applicationProcess
objectClass: simpleSecurityObject
cn: sssd
userPassword: sssd00

dn: uid=user01,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: ldapPublicKey
uid: user01
cn: user01
sn: user01
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/user01
loginShell: /bin/bash
userPassword: user0100
sshPublicKey: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDIAK0g3hGZyY50azHynBQlmw2U1PQ/U0l4oRK7S2isj tmp1

dn: uid=user02,ou=Users,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: ldapPublicKey
uid: user02
cn: user02
sn: user02
uidNumber: 10002
gidNumber: 10002
homeDirectory: /home/user02
loginShell: /bin/bash
userPassword: user0200
sshPublicKey: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAID5qh3T6puq1s+UqQY2pB9v0w/yn2C7cu/2pE1lYvryS tmp2

dn: cn=user,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: posixGroup
cn: user
gidNumber: 10000
memberUid: user01
memberUid: user02

dn: cn=user01,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: posixGroup
cn: user01
gidNumber: 10001

dn: cn=user02,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: posixGroup
cn: user02
gidNumber: 10002

dn: cn=admin,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: posixGroup
cn: admin
gidNumber: 11000
memberUid: user01

dn: cn=%admin,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: %admin
sudoUser: %admin
sudoHost: ALL
sudoCommand: ALL

sshPublicKey 属性は、あらかじめ用意した公開鍵に置き換えてください。SSH で公開鍵認証をする際に使用されるよう設定する予定です。

「6. LDAPに登録した公開鍵を認証に使用できるようにする」を実施しない場合は sshPublicKey 属性をすべて削除してください。

今回作成した LDIF ファイルはオブジェクト登録用のファイルであり、既存オブジェクトの編集用や削除用のファイルではありません。そのため、このファイルには作成したいオブジェクトのみが記載されていて、各オブジェクトは空行で区切られています。

大雑把に言えば、オブジェクトのうち objectClass が organizationalUnit でドメインネーム (dn) が on=○○ から始まるものが木構造の節（フォルダのようなオブジェクト）です。それ以外のものは木構造の葉であり、今回はユーザ情報やグループの情報等、『作成するオブジェクトの概要』で示したいくつかの種類のオブジェクトがあります。

オブジェクトごとに記載されている項目のうち dn と objectClass 以外がそのオブジェクトが持つ属性とその値です。たとえばオブジェクトクラスが posixAccount (Linux等のログインアカウント) であるオブジェクトは、uidNumber (UID) や userPassword (ログインパスワード) という属性を持っているため、SSSD がユーザ情報として利用できます。

aci 属性は、cn=sssd,ou=tool-admin,dc=example,dc=com で LDAP へアクセスした際に読み取り・検索できるようにするために付けています。3つのオブジェクトについていますが、この3つだけではなくその子孫オブジェクトに対しても適用されるので、ユーザ情報やグループ情報を参照できるようになります。これが無い場合、cn=sssd,ou=tool-admin,dc=example,dc=com として LDAP へログインしたときにユーザ情報等を検索できないため、SSSDが機能しません。

LDIF ファイルの適用

作成した LDIF ファイルを適用します。前回の記事で Windows 側にインストールした Apache Directory Studio を使用する場合、メニューの File -> Import... -> LDIF into LDAP から LDIF ファイルを適用できます。

コマンドを使用する場合、下記のコマンドを仮想マシン1 (389ds を構築したマシン) で実行します。

ldapadd -D cn=Manager -W -f <LDIFファイルのパス>

※ cn=Manager は前回の記事で 389ds をインストールする際に指定した root ユーザ名です。パスワードも前回の記事で設定しています。

登録された LDAP オブジェクトの確認

LDIF ファイルの指定通りにオブジェクトが作成されたことを確認します。Apache Directory Studio を使用してもよいですし、下記のコマンドでも確認できます。

ldapsearch -D cn=Manager -W

読み取り権限の確認

オブジェクトの存在の他に、cn=sssd,... からユーザ情報等を参照できることも確認しておきましょう。Apache Directory Studio を使用する場合、「Bind DN or user」に cn=sssd,ou=tool-admin,dc=example,dc=com を、「Bind password」にそのパスワード (今回の例では LDIF ファイルに書いた sssd00) を入力します。

コマンドを使用する場合、下記のコマンドを仮想マシン1 (389ds を構築したマシン) で実行します。

ldapsearch -D cn=sssd,ou=tool-admin,dc=example,dc=com -W

正しく設定できていれば、登録されたユーザ情報、グループ情報、SUDOers情報が表示されるはずです。この後設定する SSSD もこのユーザを使用して LDAP へアクセスするので、ここで表示されない情報は認証に使用できません。

2. SSSD のインストール (仮想マシン2)

参考
- SSSD とその利点について - RHEL ドキュメント
- OpenLDAPとSSSDを利用したユーザー認証 - Qiita

LDAPサーバ側は前回の記事と合わせて準備が完了したため、次は LDAP を使用した認証でログインできるようにしたい仮想マシン2のセットアップに移ります。SSH 接続時に LDAP の情報で認証できるようにするために、ここでは SSSD を使用します。

dnf でインストールできます。

# dnf install sssd sssd-tools sssd-dbus

（略）
アップグレード済み:
  libldb-4.21.3-7.el9_6.x86_64             libsss_certmap-2.9.6-4.el9_6.2.x86_64  libsss_idmap-2.9.6-4.el9_6.2.x86_64
  libsss_nss_idmap-2.9.6-4.el9_6.2.x86_64  libsss_sudo-2.9.6-4.el9_6.2.x86_64     libtalloc-2.4.2-1.el9.x86_64
  libtdb-1.4.12-1.el9.x86_64               libtevent-0.16.1-1.el9.x86_64          sssd-client-2.9.6-4.el9_6.2.x86_64
  sssd-common-2.9.6-4.el9_6.2.x86_64       sssd-kcm-2.9.6-4.el9_6.2.x86_64
インストール済み:
  adcli-0.9.2-1.el9.x86_64                                    avahi-libs-0.8-22.el9_6.x86_64
  bind-libs-32:9.16.23-29.el9_6.x86_64                        bind-license-32:9.16.23-29.el9_6.noarch
  bind-utils-32:9.16.23-29.el9_6.x86_64                       cyrus-sasl-gssapi-2.1.27-21.el9.x86_64
  fstrm-0.6.1-3.el9.x86_64                                    libicu-67.1-9.el9.x86_64
  libipa_hbac-2.9.6-4.el9_6.2.x86_64                          libmaxminddb-1.5.2-4.el9.x86_64
  libsmbclient-4.21.3-7.el9_6.x86_64                          libtirpc-1.3.3-9.el9.x86_64
  libuv-1:1.42.0-2.el9_4.x86_64                               libwbclient-4.21.3-7.el9_6.x86_64
  protobuf-c-1.3.3-13.el9.x86_64                              python3-sss-2.9.6-4.el9_6.2.x86_64
  python3-sssdconfig-2.9.6-4.el9_6.2.noarch                   samba-client-libs-4.21.3-7.el9_6.x86_64
  samba-common-4.21.3-7.el9_6.noarch                          samba-common-libs-4.21.3-7.el9_6.x86_64
  sssd-2.9.6-4.el9_6.2.x86_64                                 sssd-ad-2.9.6-4.el9_6.2.x86_64
  sssd-common-pac-2.9.6-4.el9_6.2.x86_64                      sssd-dbus-2.9.6-4.el9_6.2.x86_64
  sssd-ipa-2.9.6-4.el9_6.2.x86_64                             sssd-krb5-2.9.6-4.el9_6.2.x86_64
  sssd-krb5-common-2.9.6-4.el9_6.2.x86_64                     sssd-ldap-2.9.6-4.el9_6.2.x86_64
  sssd-proxy-2.9.6-4.el9_6.2.x86_64                           sssd-tools-2.9.6-4.el9_6.2.x86_64

完了しました!

「5. ホームディレクトリの自動生成」の作業を実施する予定がある場合、この時点で oddjob-mkhomedir も同時にインストールしても構いません。その場合、この時点で systemctl enable --now oddjobd.service コマンドで oddjobd を起動・有効化します。

3. SSSD の設定 (仮想マシン2)

参考
- OpenLDAPとSSSDを利用したユーザー認証 - Qiita
- sssd+SSH連携のLDAPクライアント構築手順 - Qiita

systemctl status sssd で確認すると、inactive 状態です。つまり、SSSDがまだ起動していません。この状態のまま、設定を変更します。

空の設定ファイル作成

RHEL9 のドキュメントには「SSSD のデフォルト設定ファイルは /etc/sssd/sssd.conf です」とありますが、下記の通りそのファイルは存在しません。

# ls -l /etc/sssd/
合計 0
drwx--x--x. 2 sssd sssd 6  5月 14 06:18 conf.d
drwx--x--x. 2 root root 6  5月 14 06:18 pki

そこで、下記のように、適切な権限の設定ファイルを作成します。

# touch /etc/sssd/sssd.conf
# chown root:root /etc/sssd/sssd.conf
# chmod 600 /etc/sssd/sssd.conf
#
# ls -l /etc/sssd/sssd.conf
-rw-------. 1 root root 0  7月 13 10:36 /etc/sssd/sssd.conf

設定ファイルへの記入

作成した /etc/sssd/sssd.conf に設定を記入します。

/etc/sssd/sssd.conf

[sssd]
debug_level         = 0
config_file_version = 2
services            = nss, pam, ssh, sudo
domains             = default

[domain/default]
id_provider     = ldap
auth_provider   = ldap
chpass_provider = ldap
sudo_provider   = ldap

ldap_uri              = ldaps://192.168.56.130:636
ldap_default_bind_dn  = cn=sssd,ou=tool-admin,dc=example,dc=com
ldap_default_authtok  = sssd00
ldap_search_base      = dc=example,dc=com
ldap_id_use_start_tls = True
ldap_tls_reqcert      = never

ldap_search_timeout              = 3
ldap_network_timeout             = 3
ldap_opt_timeout                 = 3
ldap_enumeration_search_timeout  = 60
ldap_enumeration_refresh_timeout = 300
ldap_connection_expire_timeout   = 600

ldap_sudo_smart_refresh_interval = 600
ldap_sudo_full_refresh_interval  = 10800

entry_cache_timeout = 1200
cache_credentials   = True

[nss]
homedir_substring = /home

entry_negative_timeout        = 20
entry_cache_nowait_percentage = 50

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]

公開鍵を記録する属性名を変更している場合、ここで ldap_user_ssh_public_key = sshPublicKey のようにして属性名を指定します。

SSSD の起動

設定ファイルを記入したら、下記のように SSSD を起動します。

# systemctl start sssd

起動できたか確認しましょう。

# systemctl status sssd
● sssd.service - System Security Services Daemon
     Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-07-13 10:53:51 JST; 4s ago
   Main PID: 11535 (sssd)
（略）

active になっているので起動できています。

もしここで enabled (自動起動有効) になっていない場合は systemctl enable sssd で自動起動を有効にしておきます。

SSSD の動作確認

SSSD が LDAP から情報を読み取れていることを確認します。

まずは下記のように sssctl domain-status <ドメイン> で接続を確認します（<ドメイン> は先述の /etc/sssd/sssd.conf に domains として指定した文字列）。下記のように「Online」となっていればOKです。「Offline」の場合、/etc/sssd/sssd.conf の設定に誤りが無いか、389ds が起動しているかを確認しましょう。

# sssctl domain-status default
Online status: Online

Active servers:
LDAP: 192.168.56.130

Discovered LDAP servers:
- 192.168.56.130

また、LDAP にユーザ情報のつもりで登録したオブジェクトをユーザ情報として参照できるようになっているはずです。下記のようにユーザ情報を確認してみましょう。

# getent passwd user01 user02
user01:*:10001:10001:user01:/home/user01:/bin/bash
user02:*:10002:10002:user02:/home/user02:/bin/bash

# id user01 user02
uid=10001(user01) gid=10001(user01) groups=10001(user01),11000(admin),10000(user)
uid=10002(user02) gid=10002(user02) groups=10002(user02),10000(user)

上記のようにユーザとして user01, user02 が存在する状態になりました。たとえば chown user01:user <ファイルパス> などユーザ・グループの存在が前提となるコマンドをすでに使用できます。

ただし、この時点では SSH ログインのユーザとしては使用できません。この後は、このユーザを SSH ログインに使用できるようにします。

4. SSSD を SSH ログインの認証に使用する設定 (仮想マシン2)

ここまでで SSSD が LDAP を参照して Linux ユーザとして使用する準備ができたので、ここからは ssh ログインを有効にする設定をします。

現在の設定は下記のように確認することができます。今回はまだ何も設定していないので次のような応答になります。

# authselect current
既存の設定は検出されませんでした。

参考にしたページは CentOS7 のものが多いからか authconfig を使用しているものが多かったのですが、今回の環境には無かったので authselect を使用します。

認証に SSSD を使用するよう設定する

下記のように、authselect select を実行することで SSSD を使用するように設定を変更します。

# authselect select sssd with-sudo --force
バックアップは /var/lib/authselect/backups/2025-07-13-02-03-11.TKGPVT に保存されました
プロファイル "sssd" が設定されました。
以下の nsswitch マップはプロファイルで上書きされます:
- passwd
- group
- netgroup
- automount
- services
- sudoers

Make sure that SSSD service is configured and enabled. See SSSD documentation for more information.

「5. ホームディレクトリの自動生成」の作業を実施する予定がある場合、この時点で with-sudo に並べる形で with-mkhomedir も指定できます。

ログインを試す

これで SSH 接続できるようになりました。下記のように実際に仮想マシン2へSSHログインして確認してみましょう。パスワードは LDIF ファイルに userPassword 属性として記載したものです³。

> ssh user01@192.168.56.131
user01@192.168.56.131's password:
Could not chdir to home directory /home/user01: No such file or directory
[user01@ldapcl00 /]$

ログインはできました。ただし、ホームディレクトリ /home/user01 が存在しないためルートディレクトリがカレントディレクトリとなっています。

sudo を試す

ついでに、sudo を使えることも確認しておきましょう。以下のように sudo できるようになっているはずです。

[user01@ldapcl00 /]$ sudo ls

あなたはシステム管理者から通常の講習を受けたはずです。
これは通常、以下の3点に要約されます:

    #1) 他人のプライバシーを尊重すること。
    #2) タイプする前に考えること。
    #3) 大いなる力には大いなる責任が伴うこと。

パスワード:
afs  bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
[user01@ldapcl00 /]$

なお、user02 で試せば、計画通り user02 では sudo できないことも確認できます。

[user02@ldapcl00 /]$ sudo ls

あなたはシステム管理者から通常の講習を受けたはずです。
これは通常、以下の3点に要約されます:

    #1) 他人のプライバシーを尊重すること。
    #2) タイプする前に考えること。
    #3) 大いなる力には大いなる責任が伴うこと。

パスワード:
user02 は ldapcl00 上で sudo を実行することを許可されていません。この事象は記録・報告されます。
[user02@ldapcl00 /]$

5. ホームディレクトリの自動生成 (仮想マシン2)

参考
- sssd+SSH連携のLDAPクライアント構築手順 - Qiita

ログインを試したとき、ホームディレクトリが存在しない旨のメッセージが表示されていました。事前に作成しておけばよいのですが、LDAPによる認証は基本的に何台ものホストでログインできることを目指すので、そのすべてに対してユーザ作成のたびに手動でホームディレクトリを作成するというのは非現実的です。そのため、ここでは初回ログイン時に自動で作成されるようにします。

ライブラリのインストール

oddjob-mkhomedir を使用するため、インストールします。

# dnf install oddjob-mkhomedir
（略）

インストール済み:
  dbus-tools-1:1.12.20-8.el9.x86_64        oddjob-0.34.7-7.el9.x86_64        oddjob-mkhomedir-0.34.7-7.el9.x86_64

完了しました!

ホームディレクトリ自動生成の有効化

まずは oddjobd を有効にします。

# systemctl enable --now oddjobd.service

次に、認証時にホームディレクトリが生成されるように設定します。

# authselect enable-feature with-mkhomedir

ホームディレクトリが生成されることの確認

ではログインしてみましょう。

> ssh user01@192.168.56.131
user01@192.168.56.131's password:
Last login: Sun Jul 13 15:00:00 2025 from 192.168.56.1
[user01@ldapcl00 ~]$ pwd
/home/user01
[user01@ldapcl00 ~]$

このとおり、ホームディレクトリが作成されます。

なお、ホームディレクトリが作成されるのはログインのタイミングです。そのため、user02 でログインしていない現在のタイミングで /home を見ると user02 のホームディレクトリはまだありません。

# ls -l /home
合計 0
drwx------. 2 se     se     99  7月 13 14:50 se
drwx------. 2 user01 user01 62  7月 13 15:00 user01

6. LDAPに登録した公開鍵を認証に使用できるようにする (仮想サーバ2)

これまでの設定で、SSSD が公開鍵を参照できるようになっています。以下のように確認してみましょう。

# sss_ssh_authorizedkeys -d default user01
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDIAK0g3hGZyY50azHynBQlmw2U1PQ/U0l4oRK7S2isj tmp1

認証設定の変更

ssh の認証でこの情報を使えるようにするために、sshd の設定ファイル /etc/ssh/sshd_config を次のように変更します。

/etc/ssh/sshd_config

- #AuthorizedKeysCommand none
- #AuthorizedKeysCommandUser nobody
+ AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
+ AuthorizedKeysCommandUser nobody

設定を反映するために、sshd を再起動しましょう。

# systemctl restart sshd

認証の確認

では、実際に SSH 接続で公開鍵認証をしてみましょう。以下の例では、-i オプションで秘密鍵ファイルを指定しています。

> ssh -i C:\Users\need_\.ssh\id_ed25519_tmp user01@192.168.56.131
Last login: Sun Jul 13 17:18:59 2025 from 192.168.56.1
[user01@ldapcl00 ~]$

パスワードを入力せずに公開鍵認証でログインできました。

なお、パスワード入力でのログインも可能です。

> ssh user01@192.168.56.131
user01@192.168.56.131's password:
Last login: Sun Jul 13 17:31:31 2025 from 192.168.56.1
[user01@ldapcl00 ~]$

7. 仮想マシンのコピー

これで、仮想マシン2は LDAP の情報に基づいて SSH で認証できるようになりました。他にも共通でしたい設定があれば設定したら、仮想マシンをコピーして 3, 4, 5 を作成します。

なお、今回のような共通の環境の仮想マシンを用意するための複製をする際の確認項目は下記の記事にまとめています。

オブジェクトの種類。オブジェクトクラスによって、指定できる属性や指定が必須の値が設定されている。その設定自体 (スキーマ) も設定できるがここでは扱わない。 ↩
オブジェクトの絶対パスのようなもの。たとえばドメインネームが a=b,c=d,dc=example,dc=com であれば、親オブジェクトは c=d,dc=example,dc=com であり、さらにその親オブジェクトは dc=example,dc=com である。 ↩
LDAP にはハッシュ化して記録されているため、LDAP を参照してパスワードを閲覧することはできません。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up