目的・やりたいこと
- 閉域環境にあるRadiusサーバにてGoogle Authenticator連携して多要素認証する際に、インターネットに出る必要があるか
- RadiusサーバQR発行はインターネット接続が必要か
対象となる技術
- RADIUS
- Google Authenticator
- WorkSpaces
- MFA
条件（導入にあたって前提事項）
2018年ごろにWorkspace導入
多要素認証を追加したい要望を頂いた。
Radiusサーバ（冗長構成）2台、EFSを追加構築
Workspacesの設定はお客様にて対応
WorkSpacesとAD連携の設定はアイレットにて対応。
Google Authenticatorの事前テストは必要。
Radiusサーバへのアクセスはお客様拠点からのみ（運用フェーズ）
Radiusサーバのインターネット抜けは？なくてもよい→WorkSpacesは将来的には使わなくなる。オンプレに切り替え予定。
RadiusサーバのQR発行はインターネット経由じゃないとできないのでは？→要確認。必要であればNATをつける。
参考URL
- RADIUSサーバーを構築して、WorkSpacesを多要素認証で運用する
- Google Authenticator を使って Amazon WorkSpaces に多要素認証ログイン
- Amazon WorkSpaces 多要素認証による Amazon WorkSpaces の利用
- FreeRADIUS + Google Authenticator + Microsoft ADを使ったClientVPNのMFA構成
2.が2014年と古く、これを元に1.を作成したと思われる
3.はAWS資料なので信ぴょう性高く、活用しやすい
4.が2020年だがおそらく一番新しく最新のUIにも対応している
注意事項
- RADIUSステータスがFailのまま
ディレクトリのRADIUSステータスがずっとFailのままだったので、RADIUSのSGのインバウンドでUDP 1812を許可していることなど何度も確認。しかし落とし穴はまさかのディレクトリ側のSGのアウトバウンド！それでいてSGがどこにあるのか見つけにくいという
ここに関しては参考URL4.の以下の記載で助けられました。
Microsoft ADは、それ自体がディレクトリサービスを提供するものなので、デフォルトではアウトバウンドのセキュリティグループがAD Connectorのものとは異なります。
Microsoft ADでMFAを利用する場合は、RADIUSサーバへの認証の通信が発生するので、このトラフィックを明示的に許可する必要があります。そのため、Microsoft ADのセキュリティグループにアウトバウンドの許可設定を追加しましょう。
まず、Directory Serviceのコンソールから「ディレクトリID」を確認します。次に、VPCまたはEC2のコンソールからセキュリティグループの画面を開いて、確認したディレクトリIDで検索します。（d-xxxxxxx_controllersというグループ名になっています）
自分の場合はディレクトリID「d-956767f1c6」でSG検索すると出てきました。
上のメンバー用のSGではなく、下のコントローラ用のSGになります。ここでUDP 1812を許可する。これでRADIUSステータスが「完了済み」に
- MFAの設定箇所がわからない
1.も2.も、対象のディレクトリを選択してアクションより[Update Details]（詳細の更新）をクリックとあるが、今のUIではアクションからは登録[解除]くらいしか選択できない。
こちらも4.には正しい手順が記載されていた。Directory Serviceからディレクトリの詳細で一番下までスクロールすると、多要素認証の設定が出てくる。
ちなみにSimple ADだと詳細画面でMFAが現れないので、自分はMicrosoft ADで建て直しました。
- Amazon Linux 2（AML）のスペック
自分はt2.microやt3.microじゃ遅すぎてまともに動かなかったので、t3.smallを選びました。もう少し低いインスタンスタイプでも動くかもしれませんが
作業の流れ
概要図
事前作業
- プライベートサブネットにあるAMLをいじってFreeRADIUSとか入れたりするために、パブリックサブネットに作業用踏み台EC2を用意
- インストール作業の時だけAMLが外に出れるように、最初だけNATGWを設置
検証手順
参考URL1.や2.の通りにやればWorkspacesにログインできるところまではいきます。以下検証はそれを前提に、その後の作業を記載
1．インターネットに繋がらない閉域環境を実現するために、NATGWを削除
これでRADIUSがあるプライベートサブネットは閉域に
2．Workspacesログインテスト
無事MFA認証通ってしまった。
もちろん外に繋がってないのでネットワークアイコンが▲！に
NATGWが繋がっていない閉域サブネットにあるRADIUS＋Google AuthenticatorのMFA認証でWorkspaceにログインできてしまいました。
結論的にはよほど時刻がずれていない限り多要素認証はそのまま成功すると思われます。
なのでRADIUSがインターネット時刻同期せずにどのくらい時間がずれるとMFA認証に失敗するか検証してみます。
3．試しに5分遅らせてみる（今11時9分）
# timedatectl set-time "2023-05-24 11:04:00" Failed to set time: Automatic time synchronization is enabled # timedatectl set-ntp no # timedatectl set-time "2023-05-24 11:05:00" # date Wed May 24 11:05:03 JST 2023 # hwclock 2023-05-24 11:05:07.849564+0900
4．再度Workspacesログインテスト
流石にこれは失敗
ただ、EC2ではインターネットに接続することなくAmazon Time Sync Serviceを使って時刻同期されるため、時刻がズレる心配はありません。
Amazon Time Sync Service は、169.254.169.123 IPv4 アドレス または fd00:ec2::123 IPv6 アドレスで NTP を介して利用できます。インスタンスはインターネットにアクセスする必要はなく、アクセスを許可するためにセキュリティグループルールまたはネットワーク ACL ルールを設定する必要はありません。最新バージョンの Amazon Linux 2 および Amazon Linux AMI はデフォルトで Amazon Time Sync Service と同期します。
5．実際インターネットにつながっていないEC2で時刻同期を再度有効にしたところ、2分後には同期された。
# timedatectl set-ntp yes # date Wed May 24 11:12:53 JST 2023 # date Wed May 24 11:22:47 JST 2023
結論として、RADIUSがEC2で構築されているならインターネットにつながっていなくても時刻がズレることがないので、Google Authenticator連携して多要素認証する際に、インターネットに出る必要は全くない！
ちなみにQRコードの発行自体もインターネットにつながってない閉域の状態でできた。
# sudo -u nozaki /usr/bin/google-authenticator Do you want authentication tokens to be time-based (y/n) y Warning: pasting the following URL into your browser exposes the OTP secret to Google: https://www.google.com/chart?chs=200x200&chld=M%7C0&cht=qr&chl=otpauth://totp/nozaki@radius.example.com%3Fsecret%3DQJPYKOYTULJ3F53YDII6GX27WU%26issuer%3Dradius.example.com
所要時間
多少ハマったり、ディレクトリ作成待ちだったりしたので、なんだかんだ3時間
でも最初からスムーズに慣れてる人が構築するなら1、2時間？
いつ頃RADIUSに接続しに行くか？
RADIUSによるMFA認証に切り替える際、Workspacesへの既存のユーザー認証に影響が出るんじゃないかという懸念があるかもしれませんが、Workspacesと連携しているADにてMFA認証を有効化するように設定するときに初めてRadiusに接続しに行きます。
なので、それまでにRadiusを構築・設定しておいても既存環境に影響はありません。
MFAの設定を有効化する前はこのようにRadiusステータスがない状態で、このときにWorkspacesにログインしてみたところ、通常通りにログインできました。
