AWS Client VPN SAML og Google Workspace: holet i tilbakekallinga

Sida app_not_configured_for_user kjem frå Google Workspace og dukkar opp før ein einaste tunnelpakke er forhandla. Den rekkjefølgja er heile diagnosen. Å installere klienten på nytt, endre profilen eller sjekke ruter kan ikkje fjerne ei side som VPN-endepunktet enno ikkje har sett. Steget som sviktar, er ei overlevering i nettlesaren mellom identitetsleverandøren og ein lyttar på brukaren si eiga maskin, og i den overleveringa er det nøyaktig tre ting som er verdt å sjekke.

Les sida som ei fråsegn frå identitetsleverandøren

Google returnerer dette når SAML-applikasjonen ikkje er aktivert for kontoen som logga inn. Appen kan vera slått av, brukaren kan vera utanfor den tildelte organisasjonseininga eller gruppa, eller innstillingane til tenesteleverandøren passar kanskje ikkje med det førespurnaden bad om.

Ingen av delane er eit sertifikat-, rute- eller tunnelproblem, sjølv om brukaren la merke til det i VPN-klienten.

Dei to verdiane klienten godtek

AWS Client VPN køyrer ei tenesteleverandørinitiert SAML-utveksling, så klienten opnar ein nettlesar, brukaren autentiserer seg, og leverandøren sender ei signert påstand tilbake til ein Assertion Consumer Service-URL. For skrivebordsklienten AWS leverer er den URL-en ein lyttar på loopback, vanlegvis port 35001, og den forventa målgruppa er eininga si identifisering for Client VPN SAML-applikasjonen, ikkje eininga for AWS-konsollinnlogging.

Båe verdiane må samsvare med det klienten ventar: kvar påstanden vert send og kven han er adressert til. Ein konfigurasjon kopiert frå ein SSO-applikasjon i konsollen kan sjå heilt truverdig ut og likevel treffe feil par.

Ta båe verdiane frå Client VPN SAML-krava, ikkje frå ei generell AWS-rettleiding for einskildinnlogging. SSO-eininga i konsollen ser lik nok ut til å vera freistande. Det er ein annan applikasjon med eit anna publikum, og klienten avviser påstanden utan å forklare seg. Kopier paret éin gong, og oppbevar det ved sida av profilen.

Google godtek ikkje den vanlege HTTP-tilbakekallinga

Administrasjonskonsollen krev ein HTTPS ACS-URL, og tilbakekallinga til klienten er vanleg HTTP på loopback. Den verdien kan ikkje skrivast inn i konfigurasjonen til Workspace-appen i det heile, og difor prøver nokre team ein omvend proxy som avsluttar TLS og sender vidare til den lokale lyttaren. Det reparerer ikkje misforholdet: nettlesaren ser éin opphavsstad, klienten annonserer ein annan, og svaret som kjem tilbake kan kome fram til feil mål.

Oppsettet som fungerer, er ein meklar-identitetsleverandør. SAML-applikasjonen hos meklaren får loopback-tilbakekallinga og AWS-målgruppa, og meklaren federerer Workspace-kontoen oppover. HTTPS-regelen til Google er framleis oppfylt, og påstanden som når klienten, namngjev framleis adressa og målgruppa han ventar.

Den meklaren er ein administrativ avhengnad som nokon må eige, overvake og ta med i offboarding. Det er òg ein andre stad der eit avbrot vert ein innloggingsfeil. Prissett det før du lovar designet. Viss ingen vil eige det, er det ærlege svaret at AWS-klienten ikkje kan bruke Workspace som sin einaste identitetsleverandør.

Tildeling og totrinnsstadfesting

Før du gjer noko om att, stadfest at appen er slått på for rett organisasjonseining eller gruppe, og at SAML-appar frå tredjepart har eigne tildelingskontrollar skilde frå applista på Google-sida.

Sjekk òg om kontoen har totrinnsstadfesting slått på. Google kan krevje det før ein SAML-app vert brukande for ein brukar, og eitt svar i den opphavlege tråden vart løyst akkurat slik. Det er det billegaste å utelukke og det mest irriterande å oppdage sist.

Stadfest med ei rein økt

Etter kvar endring, test med ein fersk nettlesarprofil og ein rein klientkonfigurasjon. Bufra påstandar og gjenbrukte økter løyner om rettinga kom fram.

Samanlikn deretter to postar side om side: revisjonshendinga til identitetsleverandøren og klientloggen. Ei vellukka innlogging utan tunnel peikar tilbake på tilbakekallinga eller målgruppa. Ein tilkopla tunnel med ein utilgjengeleg ressurs er eit ruting- eller autorisasjonsproblem og høyrer heilt andre stader heime.

Kva du ikkje bør endre

Ikkje fjern auth-federate frå profilen og ikkje slå av sertifikatkontrollar for å kome forbi sida. Båe endrar autentiseringsdesignet i staden for den sviktande tilbakekallinga, og båe ryker vanlegvis ved neste klientoppdatering.

Rett i staden overleveringa, og legg att eit notat som namngjev meklaren, målgruppa og loopback-porten. Den neste personen som ser sida, vil trengje alle tre.