RADIUSサーバのユーザをAD管理するハンズオン

## はじめに
WorkSpacesを導入する認証系部分の検証に、2023年のGWを費やしてしまいましたが、自分がやりたいことをしているブログ（
[【APN Ambassadors ブログシリーズ第三弾】Amazon WorkSpaces で多要素認証（MFA）を利用する場合でもユーザは AD だけで管理したい](https://aws.amazon.com/jp/blogs/psa/apn-ambassadors-blog-003/)）を発見しまして、こちらを参考に検証・構築をしていきたいと思います。

### 課題
Amazon WorkSpacesを利用するために、ActiveDirectory(以降、AD)が必須となり、当然ながらユーザはADに登録され管理されている。
ここで課題となっているのが、多要素認証を提供するためには、 **FreeRADIUSのローカルにもADと同様のユーザを作成しなければならない**ことです。

ADにユーザを追加するたびに、FreeRADIUSのローカルにも同様のユーザを追加しないといけないという作業が発生し、最悪ADには登録したけど FreeRADIUSのローカルには登録を忘れてアクセスができないということも考えられます。

[【APN Ambassadors ブログシリーズ第三弾】Amazon WorkSpaces で多要素認証（MFA）を利用する場合でもユーザは AD だけで管理したい](https://aws.amazon.com/jp/blogs/psa/apn-ambassadors-blog-003/)ではタイトルで説明がされていますが、ユーザ管理をADに任せて FreeRADIUS側では管理をしないように設定を行います。

<br>

------------

## 構成図
![](https://cloud5.jp/wp-content/uploads/2023/05/スクリーンショット-2023-05-07-21.59.39-640x626.png)
<br>

------------

## ハンズオン
### 構築のながれ
#### 1.EC2(AD)インスタンス構築（マネジメントコンソール）
#### 2.EC2(AD)インスタンスの設定（リモートデスクトップ接続）
#### 3.EC2(RADIUS)インスタンスをADドメインへ結合（マネジメントコンソール・SSH接続）
#### 4.EC2(RADIUS)でMFA設定（SSH接続）
#### 5.(追加)`.google_authenticator`の出力先を変更

-----------

### 1.EC2(AD)インスタンス構築（マネジメントコンソール）
### 2.EC2(AD)インスタンスの設定（リモートデスクトップ接続）
PowerShellでAD構築のハンズオン(https://cloud5.jp/powershell-ad/)を参照して、テストユーザを作成する

<br>

### 3.EC2(RADIUS)インスタンスをADドメインへ結合（マネジメントコンソール・SSH接続）
#### 3.1.EC2(AD)インスタンス SG設定
RADIUSにアタッチされているSGからのアクセスを`すべて`受け入れる（※検証のため絞らずに設定）
![](https://cloud5.jp/wp-content/uploads/2023/05/スクリーンショット-2023-05-07-9.10.11-640x29.png)

<br>

#### 3.2.EC2(RADIUS)インスタンスの設定（SSH接続）
#### 3.2.1. DHCPオプションの設定
[プライベート Amazon EC2 インスタンスが Amazon Linux、Ubuntu、または RHEL で実行中です。再起動中も持続する EC2 インスタンスに静的 DNS サーバーを割り当てる方法を教えてください。](https://repost.aws/ja/knowledge-center/ec2-static-dns-ubuntu-debian)を参考に、DHCPオプションに手動でDNSサーバの設定
```shell
sudo su -
vi /etc/dhcp/dhclient.conf
supersede domain-name-servers 【DNSサーバ Private IP】,【DNSサーバ Private IP】;
shutdown -r now
```
<br>

#### 3.3.ADへインスタンスの結合
##### 3.3.1.必要パッケージをインストール
```shell
sudo su -
sudo yum -y update
yum -y install sssd realmd krb5-workstation samba-common-tool
```
<br>

##### 3.3.2.ディレクトリにインスタンスを結合
途中アカウントのパスワードを入力部分あり

```shell
sudo realm join -U join_account@example.com example.com --verbose

###例
realm join -U adconnector@tetutetu.com tetutetu.com --verbose

###レスポンス（末尾）
* Successfully enrolled machine in realm
```

<br>

##### 3.3.3.ADドメインに結合されたことを確認
`id`コマンドを実施、レスポンスからユーザ情報が確認できる
```shell
id 【ユーザ名】@【ドメイン】

### 例
id user01@tetutetu.com

### レスポンス
uid=1054801104(user01@tetutetu.com) gid=1054800513(domain users@tetutetu.com) groups=1054800513(domain users@tetutetu.com)
```
<br>

### 4.EC2(RADIUS)でMFA設定（SSH接続）
※先に手順5.を実施することで、ユーザ情報（.google_authenticator）の出力先を変更することが可能
（5/8追加手順）


ユーザの登録自体はADサーバが行っているので、RADIUSでは
[冗長化RADIUSサーバのユーザ情報をEFSで共有ハンズオン](https://cloud5.jp/radius-efs/)の`5.2.2.Google Authenticatorのコマンド実行`に従って Google Authenticatorの設定を実施する

#### 4.1.Google Authenticatorのコマンド実行
```shell
sudo -u 【登録ユーザ】 /usr/bin/google-authenticator -tdf -r 3 -R 30 -S 30 -w 5

###例）
sudo -u user01@tetutetu.com /usr/bin/google-authenticator -tdf  -r 3 -R 30 -S 30 -w 5
```
<br>

#### 4.2.登録されたユーザの確認
`/home`配下に、AD経由でのユーザの情報が配置されていることを確認する

```shell
ls -la /home

### レスポンス
total 0
drwx------ 4 ec2-user            ec2-user                  109 May  5 13:40 ec2-user
drwx------ 2 ssm-user            ssm-user                   62 May  6 23:00 ssm-user
drwx------ 2 user01@tetutetu.com domain users@tetutetu.com  91 May  7 01:13 user01@tetutetu.com
```
<br>

------------

##　追加　ユーザファイルの出力先を変更する（5/8追加手順）
### 5.`.google_authenticator`の出力先を変更
#### 5.1.`/etc/pam.d/radiusd`の編集
デフォルトだと`auth requisite pam_google_authenticator.so`しか記載していない項目に `secret=/mnt/home/%u/.google_authenticator
`　という記載を追加

```shell
sudo su -
vi /etc/pam.d/radiusd

### 編集内容
#%PAM-1.0
#auth       include     password-auth
#account    required    pam_nologin.so
#account    include     password-auth
#password   include     password-auth
#session    include     password-auth
auth requisite pam_google_authenticator.so secret=/mnt/home/%u/.google_authenticator
account required pam_permit.so
session required pam_permit.so
```
<br>

#### 5.2.`/etc/sssd/sssd.conf`の編集
##### 5.2.1.`/etc/sssd/sssd.conf`ファイル修正
デフォルトだと`fallback_homedir = /home/%u@%d`となっている項目をEFSマウント配下の`fallback_homedir = /mnt/home/%u@%d`に修正する

```shell
vi /etc/sssd/sssd.conf

[sssd]
domains = tetutetu.com
config_file_version = 2
services = nss, pam

[domain/tetutetu.com]
ad_domain = tetutetu.com
krb5_realm = TETUTETU.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
#修正前
#fallback_homedir = /home/%u@%d
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
#修正後
fallback_homedir = /mnt/home/%u@%d
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
access_provider = ad
```
<br>

##### 5.2.2.SSSDサービスを再起動
SSSDサービスを再起動して、設定変更を反映させる
```shell
sudo systemctl restart sssd
```

<br>

※上記手順 5.を設定後、手順4.を実施してユーザ情報を作成すると`.google_authenticator`の出力先が変更される（今回では、/mnt/home 配下に出力される）

------------

## さいごに
結果としては、ADからユーザ情報をRADIUSサーバへ共有することができました。
~~ただしこのままだと昨日検証した、[冗長化RADIUSサーバのユーザ情報をEFSで共有ハンズオン](https://cloud5.jp/radius-efs/)が上手く機能しません。
一つ階段をあがり異なる問題はよくあることなので、とりあえず次回の課題が見つかったところで、今回の検証としては終了します。~~
出力先も変更することができて、どうにか小骨をどうにか飲み込むことができました。