Day 3

ＡＲアドバンストテクノロジ株式会社（ARI） Advent Calendar 2025

Day 25

やさしいアドベントカレンダー Advent Calendar 2025

@kimuni-i(利広木村)

ＡＲアドバンストテクノロジ株式会社（ARI）

AD ユーザで Linux にログインする(ID管理自動化の第一歩)

Last updated at 2025-12-03Posted at 2025-12-03

はじめに

いつも、linuxサーバには、sshでアクセスしてメンテナンスをしていました。しかし、ADのアカウントで、linuxにアクセス出来るんですよね。。学んだことを整理してみました。Linuxのアカウント管理が楽になるのは、嬉しい。

メリット Linuxサーバのアカウント管理を簡素化できる

実務でも使えるようにサンプルを用意しました。

内容としては、AWS Managed Microsoft AD (MS AD) 環境下のEC2インスタンス（Linux）に対し、Ansibleを用いてドメイン参加からセキュリティ設定までを一貫して行うための詳細設計案と、それを実装するためのAnsible Playbook構成案を整理しました。

とはいえ、前提知識がないとなんのことかわからないと思うので、概要を整理しました。

AD（AWS Managed Microsoft AD / オンプレ AD）で作成したユーザを Linux (Amazon Linux / RHEL / Ubuntu など) にログインさせる一般的な方法を、最短で動く形にまとめて説明します。

realmd + SSSD + AD 参加 → realm permit → sshd 設定修正
の流れが最適です。

AD ユーザで Linux にログインする全体フロー

① Linux を AD に参加（realm join）
② SSSD を通して AD 認証を使えるようにする
③ AD のユーザやグループを Linux へログイン許可（realm permit）
④ sshd_config を調整しログイン可能にする
⑤ （必要なら）home ディレクトリ自動作成

1. 必要パッケージのインストール

RHEL / CentOS / Amazon Linux 2

sudo yum install -y realmd sssd adcli oddjob oddjob-mkhomedir samba-common-tools

Ubuntu:

sudo apt install -y realmd sssd sssd-tools adcli oddjob oddjob-mkhomedir samba-common

2. AD の DNS を resolv.conf に設定

Linux が AD の DNS を引けないと Kerberos/LDAP が動かない。

例（AWS Managed AD）

sudo vi /etc/resolv.conf

nameserver <ManagedAD_DNS1>
nameserver <ManagedAD_DNS2>
search corp.example.com

3. realm discover で AD を確認

realm discover corp.example.com

正常例

corp.example.com
  type: kerberos
  server-software: active-directory
  client-software: sssd
  configured: no

4. AD に参加（realm join）

sudo realm join corp.example.com -U Administrator

OU を指定したい場合

sudo realm join corp.example.com \
  --user=Administrator \
  '--computer-ou=OU=Servers,OU=cnskimura,DC=corp,DC=cnskimura,DC=co,DC=jp'

成功例

Successfully enrolled machine in realm

5. AD ユーザにログインを許可（realm permit）

特定ユーザ

sudo realm permit unyou1
sudo realm permit unyou2
sudo realm permit unyouadmin

グループごと許可

sudo realm permit -g "Domain Users"

現在の許可状況

realm list

6. sshd_config を調整

sudo vi /etc/ssh/sshd_config

以下を確認・追記

UsePAM yes
PasswordAuthentication yes

再起動：

sudo systemctl restart sshd

7. home ディレクトリの自動作成を有効化

sudo authselect select sssd with-mkhomedir
sudo systemctl restart sssd

または /etc/sssd/sssd.conf に

override_homedir = /home/%u

8. 実際にログインしてみる

形式は FQDN付き or ユーザ名のみ、両方可能

ssh unyou1@server

または

ssh unyou1@corp.example.com@server

ここまでやれば AD ユーザで Linux へ SSH ログインできます

よくあるハマりポイント（重要）

問題	原因
ログインできない	DNS が AD を参照していない
realm join 失敗	Firewall で 389/636/88/464 が閉じている
ログイン時にユーザ名認識しない	realm permit をしていない
ホームディレクトリが無い	oddjob-mkhomedir が無効
password expired	AD 側のパスワード期限

注意事項

DNS を AD に向ける
realmd / sssd / adcli / samba-common をインストール
realm join
sssd.conf を調整して FQDN なしログイン
sshd_config 修正
realm permit で Domain Users 許可
unyouadmin に sudo 権付与

この状態にすれば OK です。

概要を説明したので、本題に入ります。

AWS MS AD 連携 Linux 環境構築詳細設計（案）

1. システム概要とスコープ

Ansibleを用いてLinuxサーバをAWS Managed Microsoft ADに参加させ、統合認証およびアクセス制御を実現するための構成定義。

対象コンポーネント

認証基盤: AWS Managed Microsoft AD
構成管理: Ansible Controller
対象ノード: Amazon Linux 2023 / RHEL / Ubuntu 等のEC2インスタンス

実装機能範囲

必須パッケージ導入: ドメイン参加および認証に必要なツールのインストール
ドメイン参加: realm コマンドを用いたADへの参加
認証設定 (SSSD): AD連携によるユーザ認証、ホームディレクトリ自動作成
権限管理 (Sudoers): ADグループベースの管理者権限付与

2. 前提条件 (Pre-requisites)

Ansible実行前に以下の環境が整っていることを前提とする。

カテゴリ	項目	内容
AWS MS AD	ステータス	ディレクトリが作成され「Active」であること
	サービスアカウント	ドメイン参加権限を持つADユーザが作成済みであること
Network	VPC DNS	VPC設定で `DNS Resolution`, `DNS Hostnames` が有効であること
	DHCP Option Set	(推奨) ADのDNSサーバIPが配布されるよう設定されていること
	Security Group	EC2からADに対し、TCP/UDP 53, 88, 389, 445 等の通信が許可されていること
EC2 (Client)	名前解決	`/etc/resolv.conf` 等でADのドメイン名が解決可能であること
	ホスト名	ドメイン内で重複しないホスト名が設定されていること（またはAnsibleで設定）

3. Ansible 変数設計 (Variables)

Ansibleで使用する主要な変数を定義する。

変数名	説明	例	備考
`ad_domain`	ドメイン名 (FQDN)	`corp.example.com`
`ad_realm`	レルム名 (大文字)	`CORP.EXAMPLE.COM`	通常はドメイン名の大文字
`ad_join_user`	ドメイン参加用ユーザ	`admin`
`ad_join_pass`	ドメイン参加用パスワード	`********`	Ansible Vaultで暗号化必須
`ad_sudo_group`	sudo権限を与えるADグループ	`LinuxAdmins`	`%`プレフィックス等はテンプレートで処理
`allowed_ad_groups`	ログインを許可するADグループ	`LinuxUsers`, `LinuxAdmins`	アクセス制御用

4. 構成詳細設計

4.1 必要パッケージのインストール

OSに応じた認証・管理用パッケージを選定する。

共通: sssd, sssd-tools, realmd, adcli, krb5-workstation
ホームディレクトリ作成用: oddjob, oddjob-mkhomedir
Sambaツール (デバッグ用): samba-common-tools

4.2 ドメイン参加プロセス (`realm join`)

adcli または realm コマンドを使用し、Kerberos認証を経てコンピュータアカウントを作成する。

自動化のポイント: 既に参加済みかを確認し、未参加の場合のみ実行する（冪等性の担保）。

4.3 SSSD 設定 (`/etc/sssd/sssd.conf`)

認証 (PAM) と名前解決 (NSS) をADに委譲する設定。

services: nss, pam, ssh (SSH鍵管理もADで行う場合)
access_provider: ad (ADのグループポリシーや単純なフィルタリングを使用)
use_fully_qualified_names: False (ユーザ名を user@domain ではなく user だけで扱えるようにする場合。運用負荷軽減のためFalse推奨)
fallback_homedir: /home/%u (ADにホームディレクトリ属性がない場合の自動生成パス)

4.4 Sudoers 設定 (`/etc/sudoers.d/`)

/etc/sudoers を直接編集せず、/etc/sudoers.d/aws-msad-auth 等の専用ファイルを配置する。

設定内容: AD上の特定のセキュリティグループ（例: LinuxAdmins）に対し、パスワードなし、またはありでの ALL=(ALL) 権限を付与する。

5. セキュリティ設計・考慮事項

5.1 アクセス制御 (Access Control)

全ADユーザのログインを許可するのは危険であるため、SSSD側でフィルタリングを行う。

実装: sssd.conf 内で ad_access_filter または simple_allow_groups を使用。
設計: ログイン許可グループ（LinuxUsers）を作成し、そのメンバーのみSSH接続可能とする。

5.2 権限分離 (Separation of Duties)

一般ユーザ: ログインのみ可能。システム変更不可。
管理者: sudo 可能。ただし、操作ログは記録される。

5.3 監査ログ (Audit Logs)

各種ログの出力先と監視対象を明確にする。

認証ログ: /var/log/secure (RHEL系) / /var/log/auth.log (Debian系) - 誰がいつログインしたか。
SSSDログ: /var/log/sssd/ - ADとの通信エラー、認証プロセスの詳細。
Sudoログ: デフォルトで認証ログに出力されるが、監査要件が厳しい場合は log_output 設定で分離も検討。

5.4 GPO (Group Policy) 設定

AWS MS AD側のGPO設定も考慮するが、Linuxへの適用範囲は限定的である。

SSSDは一部のGPO（アクセス制御ポリシーなど）を解釈可能。
高度なGPO適用が必要な場合は、SSSDの設定で ad_gpo_access_control = enforcing (デフォルト) となっていることを確認する。

6. Ansible Playbook 実装例

以下は、上記設計に基づいたディレクトリ構成とPlaybookのサンプルです。

ディレクトリ構成

project/
├── inventory
├── group_vars/
│   └── all.yml
└── roles/
    └── msad_join/
        ├── tasks/
        │   └── main.yml
        ├── templates/
        │   ├── sssd.conf.j2
        │   └── sudoers_ad.j2
        └── vars/
            └── main.yml

`roles/msad_join/tasks/main.yml`

---
# 1. 必要パッケージのインストール
- name: Install required packages for AD integration
  package:
    name:
      - sssd
      - realmd
      - krb5-workstation
      - adcli
      - oddjob
      - oddjob-mkhomedir
      - samba-common-tools
    state: present

# 2. ドメイン参加チェックと参加
- name: Check if machine is already joined to domain
  command: /usr/sbin/realm list
  register: realm_list
  changed_when: false
  ignore_errors: true

- name: Join the machine to the AD domain
  shell: |
    echo "{{ ad_join_pass }}" | realm join -U "{{ ad_join_user }}" "{{ ad_domain }}" --computer-ou="{{ ad_computer_ou | default('CN=Computers,DC=corp,DC=example,DC=com') }}"
  when: ad_domain not in realm_list.stdout
  no_log: true # パスワード漏洩防止
  notify: Restart SSSD

# 3. SSSD 設定ファイルの配置
- name: Configure sssd.conf
  template:
    src: sssd.conf.j2
    dest: /etc/sssd/sssd.conf
    owner: root
    group: root
    mode: '0600'
  notify: Restart SSSD

# 4. ホームディレクトリ自動作成の有効化 (authselect使用の場合: RHEL8/9, AL2023)
- name: Enable home directory creation via authselect
  command: authselect select sssd with-mkhomedir --force
  when: ansible_os_family == 'RedHat' and ansible_distribution_major_version|int >= 8
  changed_when: false

# 5. Sudoers 設定
- name: Configure sudoers for AD Admins
  template:
    src: sudoers_ad.j2
    dest: /etc/sudoers.d/10-ad-admins
    owner: root
    group: root
    mode: '0440'
    validate: 'visudo -cf %s'

# 6. SSH設定 (パスワード認証許可など必要であれば)
- name: Allow Password Authentication for AD users if needed
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^PasswordAuthentication'
    line: 'PasswordAuthentication yes'
  notify: Restart SSH

`roles/msad_join/templates/sssd.conf.j2`

[sssd]
domains = {{ ad_domain }}
config_file_version = 2
services = nss, pam

[domain/{{ ad_domain }}]
ad_domain = {{ ad_domain }}
krb5_realm = {{ ad_realm }}
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True

# ユーザ名の短縮形を使用 (user@domain -> user)
use_fully_qualified_names = False

# ホームディレクトリのフォールバック
fallback_homedir = /home/%u

# アクセス制御: 特定のグループのみ許可
access_provider = ad
# simple_allow_groups = {{ allowed_ad_groups | join(',') }} 
# ※ access_provider=ad の場合は ad_access_filter を使うか、GPOに従うのが一般的ですが、
#   simpleプロバイダ的に使う場合は access_provider=simple に変更してください。
#   AWS MS ADでGPO制御しない場合は以下のようにフィルタをかけると安全です。
ad_access_filter = (memberOf=CN={{ allowed_ad_groups[0] }},CN=Users,DC=corp,DC=example,DC=com)

`roles/msad_join/templates/sudoers_ad.j2`

# Managed by Ansible
# AD Group: {{ ad_sudo_group }} gets sudo access

%{{ ad_sudo_group }} ALL=(ALL) ALL

感想

ADって何？難しいから、理解する事をあきらめてたって人でも、これを機になんだそういう事かと考えるきっかけにしてくれると嬉しいです。

仲間を募集しています！

ARIではエンジニア・ITコンサルタント・PM職全方位で仲間を募集しております。
カジュアル面談、随時受付中です！
ご興味ある方はこちらをご覧ください。

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