はじめに
WorkSpacesを導入する認証系部分の検証に、2023年のGWを費やしてしまいましたが、自分がやりたいことをしているブログ（
【APN Ambassadors ブログシリーズ第三弾】Amazon WorkSpaces で多要素認証（MFA）を利用する場合でもユーザは AD だけで管理したい）を発見しまして、こちらを参考に検証・構築をしていきたいと思います。
課題
Amazon WorkSpacesを利用するために、ActiveDirectory(以降、AD)が必須となり、当然ながらユーザはADに登録され管理されている。
ここで課題となっているのが、多要素認証を提供するためには、 FreeRADIUSのローカルにもADと同様のユーザを作成しなければならないことです。
ADにユーザを追加するたびに、FreeRADIUSのローカルにも同様のユーザを追加しないといけないという作業が発生し、最悪ADには登録したけど FreeRADIUSのローカルには登録を忘れてアクセスができないということも考えられます。
【APN Ambassadors ブログシリーズ第三弾】Amazon WorkSpaces で多要素認証（MFA）を利用する場合でもユーザは AD だけで管理したいではタイトルで説明がされていますが、ユーザ管理をADに任せて FreeRADIUS側では管理をしないように設定を行います。
構成図
ハンズオン
構築のながれ
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/)を参照して、テストユーザを作成する
3.EC2(RADIUS)インスタンスをADドメインへ結合（マネジメントコンソール・SSH接続）
3.1.EC2(AD)インスタンス SG設定
RADIUSにアタッチされているSGからのアクセスをすべて受け入れる（※検証のため絞らずに設定）
3.2.EC2(RADIUS)インスタンスの設定（SSH接続）
3.2.1. DHCPオプションの設定
プライベート Amazon EC2 インスタンスが Amazon Linux、Ubuntu、または RHEL で実行中です。再起動中も持続する EC2 インスタンスに静的 DNS サーバーを割り当てる方法を教えてください。を参考に、DHCPオプションに手動でDNSサーバの設定
sudo su -
vi /etc/dhcp/dhclient.conf
supersede domain-name-servers 【DNSサーバ Private IP】,【DNSサーバ Private IP】;
shutdown -r now
3.3.ADへインスタンスの結合
3.3.1.必要パッケージをインストール
sudo su -
sudo yum -y update
yum -y install sssd realmd krb5-workstation samba-common-tool
3.3.2.ディレクトリにインスタンスを結合
途中アカウントのパスワードを入力部分あり
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
3.3.3.ADドメインに結合されたことを確認
idコマンドを実施、レスポンスからユーザ情報が確認できる
id 【ユーザ名】@【ドメイン】
### 例
id user01@tetutetu.com
### レスポンス
uid=1054801104(user01@tetutetu.com) gid=1054800513(domain users@tetutetu.com) groups=1054800513(domain users@tetutetu.com)
4.EC2(RADIUS)でMFA設定（SSH接続）
※先に手順5.を実施することで、ユーザ情報（.google_authenticator）の出力先を変更することが可能
（5/8追加手順）
ユーザの登録自体はADサーバが行っているので、RADIUSでは
冗長化RADIUSサーバのユーザ情報をEFSで共有ハンズオンの5.2.2.Google Authenticatorのコマンド実行に従って Google Authenticatorの設定を実施する
4.1.Google Authenticatorのコマンド実行
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
4.2.登録されたユーザの確認
/home配下に、AD経由でのユーザの情報が配置されていることを確認する
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
## 追加 ユーザファイルの出力先を変更する（5/8追加手順）
5..google_authenticatorの出力先を変更
5.1./etc/pam.d/radiusdの編集
デフォルトだとauth requisite pam_google_authenticator.soしか記載していない項目に secret=/mnt/home/%u/.google_authenticator という記載を追加
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
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に修正する
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
5.2.2.SSSDサービスを再起動
SSSDサービスを再起動して、設定変更を反映させる
sudo systemctl restart sssd
※上記手順 5.を設定後、手順4.を実施してユーザ情報を作成すると.google_authenticatorの出力先が変更される（今回では、/mnt/home 配下に出力される）
さいごに
結果としては、ADからユーザ情報をRADIUSサーバへ共有することができました。
ただしこのままだと昨日検証した、冗長化RADIUSサーバのユーザ情報をEFSで共有ハンズオンが上手く機能しません。
一つ階段をあがり異なる問題はよくあることなので、とりあえず次回の課題が見つかったところで、今回の検証としては終了します。
出力先も変更することができて、どうにか小骨をどうにか飲み込むことができました。