AWS Client VPN SAML och Google Workspace: glappet i återkallelsen

Sidan app_not_configured_for_user kommer från Google Workspace och visas innan ett enda tunnelpaket har förhandlats. Den ordningen är hela diagnosen. Att installera om klienten, redigera profilen eller kontrollera rutter kan inte rensa en sida som VPN-slutpunkten ännu inte har sett. Steget som misslyckas är en överlämning i webbläsaren mellan identitetsleverantören och en lyssnare på användarens egen maskin, och i den överlämningen är det exakt tre saker som är värda att kontrollera.

Läs sidan som ett uttalande från identitetsleverantören

Google returnerar detta när SAML-applikationen inte är aktiverad för kontot som loggade in. Appen kan vara avstängd, användaren kan ligga utanför den tilldelade organisationsenheten eller gruppen, eller så stämmer kanske inte tjänsteleverantörens inställningar med det som begäran krävde.

Inget av detta är ett certifikat-, rutt- eller tunnelproblem, även om användaren lade märke till det i VPN-klienten.

De två värden som klienten accepterar

AWS Client VPN kör ett tjänsteleverantörsinitierat SAML-utbyte, så klienten öppnar en webbläsare, användaren autentiserar sig och leverantören skickar ett signerat påstående tillbaka till en Assertion Consumer Service-URL. För skrivbordsklienten som AWS tillhandahåller är den URL:en en lyssnare på loopback, vanligtvis port 35001, och den förväntade målgruppen är enhetsidentifieraren för Client VPN SAML-applikationen, inte enheten för AWS-konsolens inloggning.

Båda värdena måste stämma med vad klienten förväntar sig: var påståendet publiceras och vem det är adresserat till. En konfiguration kopierad från en SSO-applikation i konsolen kan se helt trovärdig ut och ändå träffa fel par.

Ta båda värdena från Client VPN SAML-kraven, inte från en allmän AWS-guide för enkel inloggning. SSO-enheten i konsolen ser tillräckligt lik ut för att vara frestande. Det är en annan applikation med en annan målgrupp, och klienten avvisar påståendet utan att förklara sig. Kopiera paret en gång och förvara det bredvid profilen.

Google accepterar inte det vanliga HTTP-återkallelset

Administratörskonsolen kräver en HTTPS ACS-URL, och klientens återkall är vanlig HTTP på loopback. Det värdet kan inte ens skrivas in i Workspace-appens konfiguration, och därför provar vissa team en omvänd proxy som avslutar TLS och vidarebefordrar till den lokala lyssnaren. Det reparerar inte missförhållandet: webbläsaren ser ett ursprung, klienten annonserar ett annat, och svaret som kommer tillbaka kan anlända till fel destination.

Upplägget som fungerar är en mäklar-identitetsleverantör. SAML-applikationen hos mäklaren får loopback-återkallelset och AWS-målgruppen, och mäklaren federerar Workspace-kontot uppåt. Googles HTTPS-regel är fortfarande uppfylld, och påståendet som når klienten namnger fortfarande den adress och målgrupp den förväntar sig.

Den mäklaren är ett administrativt beroende som någon måste äga, övervaka och ta med i offboarding. Det är också en andra plats där ett avbrott blir ett inloggningsfel. Prissätt det innan du lovar designen. Om ingen vill äga det är det ärliga svaret att AWS-klienten inte kan använda Workspace som sin enda identitetsleverantör.

Tilldelning och tvåstegsverifiering

Innan du designar om något, bekräfta att appen är på för rätt organisationsenhet eller grupp, och att SAML-appar från tredje part har egna tilldelningskontroller som är åtskilda från applistan på Google-sidan.

Kontrollera också om kontot har tvåstegsverifiering aktiverat. Google kan kräva det innan en SAML-app blir användbar för en användare, och ett enda svar i den ursprungliga tråden löstes precis så. Det är det billigaste att utesluta och det mest irriterande att upptäcka sist.

Verifiera med en ren session

Efter varje ändring, testa med en ny webbläsarprofil och en ren klientkonfiguration. Cachade påståenden och återanvända sessioner döljer om rättelsen kom fram.

Jämför sedan två poster sida vid sida: identitetsleverantörens granskningshändelse och klientloggen. En lyckad inloggning utan tunnel pekar tillbaka på återkallelset eller målgruppen. En ansluten tunnel med en oåtkomlig resurs är ett rutt- eller behörighetsproblem och hör hemma någon helt annanstans.

Vad du inte ska ändra

Ta inte bort auth-federate från profilen och stäng inte av certifikatkontrollerna för att komma förbi sidan. Båda ändrar autentiseringsdesignen i stället för det misslyckade återkallelset, och båda går oftast sönder vid nästa klientuppdatering.

Reparera i stället överlämningen och lämna en anteckning som namnger mäklaren, målgruppen och loopback-porten. Nästa person som ser sidan kommer att behöva alla tre.