Meraki MRにおいてSplash pageでのGoogle Workspace (旧G Suite)のOAuth認証の設定方法を整理しました。
SSIDへの接続タイミングでの認証ではなく、SSIDに接続した後のSplash page (Captive Portal)による認証であるため、混同しないように注意してください。
本内容は2023年09月頃に検証を行っております。
設定の概要
要件や設計に依存するものもありますが、大きく分けて3つの設定が関連します。
必須: Google OAuthの認証設定
必須: Splash pageのWalled Garden
任意: Splash pageの認証セッションのタイマー (
Splash frequency)
設定手順
対象SSIDへの認証設定への移動
SSID接続タイミングの認証設定
Securityの設定でSSID接続タイミングの認証設定を要件に合わせて修正します。2023年09月頃の時点では下記がGoogle OAuthの設定に対応しております。
Open (no encryption)Opportunistic Wireless Encryption (OWE)PasswordIdentity PSK without RADIUS
筆者の場合は
Password設定によるPSK (Pre Shared Key)の認証を指定して、部外者が接続できないようにしました。![]()
Security設定
Splash pageの挙動の設定
Splash pageの挙動の設定をSign-on withにしてパラメータにGoogle OAuthを指定します。![]()
Splash page の挙動の設定 Allowed domainsでは任意で許可対象のドメインを絞れます。業務で社員のアカウントを認証する場合は、管理外のアカウントで認証をバイパスできないようにドメインを指定するのが好ましいと考えられます。![]()
Allowed domains の設定 (任意)
Walled gardenの設定
Advanced splash settingsで Splash page (Captive Portal)に関わる設定をチューニングします。
Captive portal strengthの設定
Captive portal strengthでは認証前のユーザーの通信がブロックされるようにBlock all access until sign-on is completeを選択します。(デフォルト値です。)![]()
Captive portal strength の設定
Walled garden rangesの設定
Walled gardenをEnabledにして、Google WorkspaceのOAuthの認証に必要な通信を許可します。
Walled garden rangesを公式情報通りに設定
Walled garden rangesには Gmail firewall settings / Gmail のファイアウォールの設定の最新状況を確認した上で設定を行います。
2023年09月頃の時点では下記のようにリストされていました。しかしながら、clients*.google.comの文字列中にワイルド カード (*)があるため、そのままでは Walled garden rangesに登録できません。
*.client-channel.google.com accounts.google.com apis.google.com clients*.google.com contacts.google.com *.googleusercontent.com mail.google.com ssl.gstatic.com www.google.com www.gstatic.com ogs.google.com play.google.com
確実的に許可するのであれば、下記のように clients*.google.comを *.google.comに読み替えるのが良いと思われます。
*.client-channel.google.com accounts.google.com apis.google.com *.google.com contacts.google.com *.googleusercontent.com mail.google.com ssl.gstatic.com www.google.com www.gstatic.com ogs.google.com play.google.com
筆者は clients*.google.comの通信先を展開 (clients1, clients2, clients3, clients4)して下記のように登録しました。
Set up a hostname allowlist / ホスト名の許可リストを設定するのドキュメントなどを参考にして筆者が独自にカスタマイズしたので問題が出る可能性は残ります。
*.client-channel.google.com accounts.google.com apis.google.com clients1.google.com clients2.google.com clients3.google.com clients4.google.com contacts.google.com *.googleusercontent.com mail.google.com ssl.gstatic.com www.google.com www.gstatic.com ogs.google.com play.google.com
Walled garden rangesを自己責任でカスタマイズした通信要件を設定
公式情報の通りに登録すると www.google.comのGoogle検索のドメインが登録されます。
Google検索した後のリンク先への通信は弾かれるので大した問題にはならないとは思いますが、通信要件を厳格に絞りたい要望が想定されるので、アクセス先を更に絞るパターンも実験的に検証してました。
あくまでも参考情報であり、この設定を推奨してるわけではありません。
また、GoogleのOAuthの認証処理で通信が発生するドメインを実機動作から調べています。 ソース コードのレベルでの解析は行っておりません。
アクセス先を更に絞る場合は下記のドメインをまず登録します。
accounts.google.com www.gstatic.com ssl.gstatic.com
そして下記のリージョン別のドメインも登録する必要がありました。アクセス先の国などによって登録対象が変わる可能性があります。
accounts.google.co.jp
そもそもアクセス先を厳格に管理したいのであれば、Guest Wi-Fi向けによく使われるSplash page (Captive Portal)を厳格な通信制御が求まれる企業LANなどの環境に採用して、更に追加でセキュリティ要件を無理やりにでも実現させようとするのは、機能の用途に反する好ましくない設計だと筆者は考えております。
Controller disconnection behaviorの設定
Controller disconnection behaviorの設定は、Meraki MRがMeraki Cloud Controllerに接続できない状態の挙動を設定します。認証済みデバイスのみが接続できるようにRestrictedに設定します。![]()
Controller disconnection behavior の設定 MerakiDashboardの i アイコンをマウスオーバーした際に表示される
Controller disconnection behaviorの説明は下記の通りです。Login attempts on this SSID will be processed by the Meraki Cloud Controller. What should happen to new clients if your Internet uplink is down or the controller is otherwise unreachable?
認証セッションのタイマー (任意の設定)
メニュー:
Wireless > Splash pageから設定対象のSSIDを選択します。![]()
対象SSIDの Splash page 設定への移動 Splash behaviorセクションにあるSplash frequencyが認証セッションのタイマーになるため要件に応じて修正します。デフォルトはEvery dayです。 筆者は検証で認証セッションが切れやすくなるようにEvery half hourを指定して短くしています。![]()
Splash frequency の調整
OAuth認証時のサンプル画面
Splash pageによるOAuth認証は、無線LAN接続端末のHTTP (80/tcp)通信をトリガーにしてSplash pageに誘導します。
Windows系のOSの場合は、SSIDへの接続後に http://www.msftconnecttest.com/redirectへの通信がリダイレクトされてSplash pageに誘導されるケースが想定されます。
Google Workspace側のアプリのアクセス制御
Google Workspace側でアプリのアクセス制御をしている場合は、メニュー: セキュリティ > API の制御 > アプリのアクセス制御 (URL: https://admin.google.com/ac/owl/list?tab=apps )の情報を参照して状況を確認してください。
アプリ名: Splashでアクセス履歴が表示されます。
考慮点
認証セッションのタイマーの間隔の考慮
SSIDへの接続タイミングでは、OSやWebブラウザの動作によってCaptive Portalの検知動作が入るケースがあります。 しかし、SSID接続中に30分のような短い間隔で認証セッションのタイマーが切れると、ユーザーが再認証の必要性に気づかない可能性があり、ユーザー体験 (UX: User eXperience)に影響が出る可能性があります。
実際に筆者が検証で30分の間隔にしていた際の話となりますが、WebサイトにHTTPS (443/tcp)で通信した際に、Splash pageのHTTP (80/tcp)通信のリダイレクト処理が行われず、ロード時間が長いように見えてしまいました。
一般的な会社員であれば24時間以上の連続稼働はないと思われますので、業務時間に合わせて24時間 (1日)の間隔で設計する良いかと考えられます。
Forward ProxyやSWG (Secure Web Gateway)の存在の考慮
一般的な会社の従業員向けの無線LANでは、Captive Portalによる認証は挟まないケースが多いかと思われます。 そこに「運用を楽にしたい」目的や要望のために「無線LANの接続時にGoogle Workspaceの資格情報を用いる」手段を意地でも実現しようとSplash page (Captive Portal)による実装を行うと、Forward ProxyやSWG (Secure Web Gateway)の存在が設計の足かせになる可能性があります。 特に日本ではForward Proxyが多くの会社で利用されていると思います。
通信フローの視点
Captive PortalとForward ProxyやSWGは通信フローに影響を与えるので、相互に競合する可能性があります。
本記事で扱っている設定は、Splash page (Captive Portal)でGoogle WorkspaceのOAuth認証を通す必要があります。
しかし、Forward ProxyやSWGが存在しているとMeraki MRはOAuthの認証前なのでProxy Server宛の通信を通しません。
そうなると、Splash page (Captive Portal)でWalled Gardenで許可設定を行う必要があります。ただし、「Proxy除外による直接通信」と「Proxy Serverを介す通信」の設計依存となる2パターンの考慮が発生します。
「Proxy Serverを介す通信」では、Walled GardenにProxy ServerのIPアドレスを設定するため、宛先対象がOAuth認証の通信であるか否かに関わらず通信が許可されてしまいます。そのため、Proxy Serverの設計へ依存性が出てきます。
「Proxy Serverを介せばどこにでも接続できる」状態を避けようとすると、Proxy Serverでの認証制御も必要になってくるため、当初の「無線LANの接続時にGoogle Workspaceの資格情報を用いたい」から別の問題に派生していきます。
「Proxy除外による直接通信」に関してはPACファイルでの制御が想定されます。Forward ProxyやSWGを介さない通信となり、Firewallは直接宛先 (例:
*.client-channel.google.com)の通信制御をしなければならないため、FQDNやワイルドカードの制御に対応した製品選定や設計が必要になるかもしれません。
このようにして通信フローを踏まえながら様々な要素を考慮する必要が出てくるので、無理やりにでも実装しようと躍起になると、本来の目的を忘れて複雑性の高い代物が出来る上がってしまうかもしれません 。
機能の用途の視点
また機能が想定している用途の側面で考えてみます。 Captive PortalをGuest Wi-Fi用途で利用するのであれば、不特定多数の端末に対する設定の考慮が難しくなるForward ProxyやSWGは利用しないケースが多くなると思います。 しかし、Captive Portalを従業員向けに提供する場合は、要求されるセキュリティ要件が異なってくるため、Forward ProxyやSWGによるアクセス制御が必須になるかもしれません。 そのため、Captive Portalの一般的なユース ケースから逸脱した状態で更に高度なセキュリティ要件が発生すると、機能の組み合わせが想定されておらず破綻しやすくなる可能性があります。
本機能の利用にあたって不安が残るようであれば、ユーザー利便性などを加味してのPoCの実施を検討してください。