My Home NW Lab

逸般の誤家庭のネットワーク

Meraki MRによるSplash pageでのGoogle Workspace (旧G Suite)のOAuth認証

Meraki MRにおいてSplash pageでのGoogle Workspace (旧G Suite)のOAuth認証の設定方法を整理しました。

SSIDへの接続タイミングでの認証ではなく、SSIDに接続した後のSplash page (Captive Portal)による認証であるため、混同しないように注意してください。

本内容は2023年09月頃に検証を行っております。

Meraki MRによるSplash pageでのGoogle Workspace (旧G Suite)のOAuth認証

設定の概要

要件や設計に依存するものもありますが、大きく分けて3つの設定が関連します。

  • 必須: Google OAuthの認証設定

  • 必須: Splash pageのWalled Garden

  • 任意: Splash pageの認証セッションのタイマー (Splash frequency)

設定手順

対象SSIDへの認証設定への移動

  • メニュー: Wireless > Access control から設定対象のSSIDを選択します。

    対象SSIDAccess control 設定への移動

SSID接続タイミングの認証設定

  • Security の設定でSSID接続タイミングの認証設定を要件に合わせて修正します。

    2023年09月頃の時点では下記がGoogle OAuthの設定に対応しております。

    • Open (no encryption)
    • Opportunistic Wireless Encryption (OWE)
    • Password
    • Identity 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 gardenEnabled にして、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.comGoogle検索のドメインが登録されます。 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 の設定

    Meraki Dashboardの 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に誘導されるケースが想定されます。

Splash pageによるOAuth認証の要求画面 (1/2)

Splash pageによるOAuth認証の要求画面 (2/2)

Google Workspace側のアプリのアクセス制御

Google Workspace側でアプリのアクセス制御をしている場合は、メニュー: セキュリティ > API の制御 > アプリのアクセス制御 (URL: https://admin.google.com/ac/owl/list?tab=apps )の情報を参照して状況を確認してください。 アプリ名: Splash でアクセス履歴が表示されます。

Splash pageアプリからGoogle Workspaceへのアクセス制御 (1/2)

Splash pageアプリからGoogle Workspaceへのアクセス制御 (2/2)

考慮点

認証セッションのタイマーの間隔の考慮

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の実施を検討してください。

関連ドキュメント

documentation.meraki.com

documentation.meraki.com

documentation.meraki.com

documentation.meraki.com