AWS Client VPN SAML 与 Google Workspace：回调环节的缺口

app_not_configured_for_user 页面来自 Google Workspace，它出现在任何一个隧道数据包开始协商之前。这个先后顺序本身就是全部诊断。重装客户端、修改配置文件或检查路由，都无法清掉一个 VPN 端点还没见过的页面。失败的那一步是浏览器里身份提供方与用户本机监听端口之间的交接，而这次交接只有三件事值得检查。

把页面读成身份提供方的声明

当已登录账号没有启用该 SAML 应用时，Google 就会返回这个页面。可能是应用被关闭，可能是用户不在被分配的组织单位或群组内，也可能是服务提供方的设置与请求要求不一致。

这些都不是证书、路由或隧道问题，尽管用户是在 VPN 客户端里看到它的。

客户端只接受的两个值

AWS Client VPN 走的是服务提供方发起的 SAML 交换：客户端打开浏览器，用户完成认证，身份提供方把签名断言回传到 Assertion Consumer Service 地址。对 AWS 提供的桌面客户端 来说，这个地址是 loopback 上的监听端口，通常是 35001，而期望的受众是 Client VPN SAML 应用的实体标识，而不是 AWS 控制台的登录实体。

两个值都必须与客户端的期望一致：断言发到哪里，以及它面向谁。从控制台 SSO 应用复制来的配置看起来完全合理，却可能指向错误的一对。

两个值都要取自 Client VPN SAML 的要求，而不是通用的 AWS 单点登录指南。控制台的 SSO 实体看起来足够相似，容易让人误选。它是另一个应用、另一个受众，客户端会直接拒绝断言而不作解释。把这一对抄一次，存在配置文件旁边。

Google 不接受明文 HTTP 回调

管理控制台要求 HTTPS 的 ACS 地址，而客户端的回调是 loopback 上的明文 HTTP。这个值根本无法填进 Workspace 的应用配置，所以有些团队尝试用反向代理终止 TLS 再转发到本地监听端口。这并没有修复不一致：浏览器看到的是一个源，客户端声明的是另一个，返回的响应可能送到错误的地址。

可行的做法是加一个代理型身份提供方。由它那边的 SAML 应用接收 loopback 回调与 AWS 受众，再由它向上游联合 Workspace 账号。Google 的 HTTPS 规则依然满足，抵达客户端的断言仍然写明它期望的地址与受众。

这个中间层是一项管理依赖，必须有人负责、有人监控，也要纳入离职流程。它还是第二个会因为故障而变成登录失败的点。在承诺方案之前先算清成本。如果没有人愿意接手，诚实的答案是：AWS 客户端不能把 Workspace 当作唯一的身份提供方。

分配与两步验证

在重做任何东西之前，先确认应用已对正确的组织单位或群组开启，并确认第三方 SAML 应用有自己独立的分配控制，与 Google 侧的应用列表分开。

还要检查账号是否开启了两步验证。Google 可以在 SAML 应用对用户可用之前就要求它，原帖里有一个回答正是这样解决的。这是最便宜的排除项，也是最后才发现时最烦人的一项。

用干净的会话验证

任何改动之后，都用全新的浏览器配置文件与干净的客户端配置来测试。缓存的断言和复用的会话会掩盖修复是否生效。

然后把两份记录并排比较：身份提供方的审计事件与客户端日志。登录成功但没有隧道，问题就回到回调或受众上。隧道已连接但资源不可达 是路由或授权问题，属于完全不同的地方。

哪些不要改

不要为了让页面过去而从配置里删掉 auth-federate，也不要关闭证书检查。两者改变的是认证设计而不是失败的这一次回调，而且通常会在下一次客户端更新时坏掉。

相反，去修那次交接，并留下一条写明中间层、受众和 loopback 端口的备注。下一个看到这个页面的人三样都会需要。