AWS Client VPN SAML en Google Workspace: it gat yn de weromrop

De side app_not_configured_for_user komt fan Google Workspace en ferskynt foardat der ek mar ien tunnelpakket ûnderhannele is. Dy folchoarder is de hiele diagnoaze. It opnij ynstallearjen fan de klant, it bewurkjen fan it profyl of it kontrolearjen fan rûtes kin gjin side wiskje dy’t it VPN-einpunt noch net sjoen hat. De stap dy’t mislearret is in oerdracht yn de browser tusken de identiteitsleveransier en in listener op de masine fan de brûker sels, en yn dy oerdracht binne der presys trije dingen dy’t it kontrolearjen wurdich binne.

Lês de side as in ferklearring fan de identiteitsleveransier

Google jout dit werom as de SAML-applikaasje net ynskeakele is foar it akkount dat oanmeld is. De app kin út stean, de brûker kin bûten de tawiisde organisaasje-ienheid of groep falle, of de ynstellingen fan de tsjinstleveransier kinne net oerienkomme mei wat it fersyk frege.

Neat dêrfan is in sertifikaat-, rûte- of tunnelprobleem, ek al wie it by de VPN-klant dat de brûker it seach.

De twa wearden dy’t de klant akseptearret

AWS Client VPN docht in SAML-útwikseling dy’t troch de tsjinstleveransier begon is, dus de klant iepenet in browser, de brûker autentisearret him en de leveransier stjoert in ûndertekene bewearing werom nei in Assertion Consumer Service-URL. Foar de desktopklant dy’t AWS leveret is dy URL in listener op loopback, meastentiids poarte 35001, en it ferwachte publyk is de entiteitsidentifikaasje fan de Client VPN SAML-applikaasje, net de oanmeldentiteit fan de AWS-konsoale.

Beide wearden moatte oerienkomme mei wat de klant ferwachtet: wêr’t de bewearing hinne stjoerd wurdt en oan wa’t dy rjochte is. In konfiguraasje dy’t fan in SSO-applikaasje yn de konsonale kopyeare is, kin hielendal betrouber lykje en dochs it ferkearde pear as doel hawwe.

Nim beide wearden út de Client VPN SAML-fereasken, net út in algemiene AWS-hantlieding foar ien kear oanmelde. De SSO-entiteit fan de konsonale liket bot genôch om ferliedlik te wêzen. It is in oare applikaasje mei in oar publyk, en de klant wiist de bewearing ôf sûnder himsels te ferklearjen. Kopyearje it pear ien kear en bewarje it neist it profyl.

Google sil de gewoane HTTP-weromrop net akseptearje

De behearderkonsonale easket in HTTPS-ACS-URL, en de weromrop fan de klant is gewoane HTTP op loopback. Dy wearde kin hielendal net yn de konfiguraasje fan de Workspace-app yntype wurde, en dêrom probearje guon teams in omkearde proxy dy’t TLS beëiniget en nei de pleatslike listener trochstjoert. Dat reparearret de misferhâlding net: de browser sjocht ien oarsprong, de klant advertearret in oare, en it weromstjoerde antwurd kin op it ferkearde plak oankomme.

De regeling dy’t wurket is in tuskenleveransier fan identiteit. De SAML-applikaasje by de tuskenleveransier krijt de loopback-weromrop en it AWS-publyk, en de tuskenleveransier federearret it Workspace-akkount omheech. De HTTPS-regel fan Google bliuwt foldien, en de bewearing dy’t de klant berikt neamt noch altyd it adres en it publyk dy’t it ferwachtet.

Dy tuskenleveransier is in bestjoerlike ôfhinklikheid dy’t immen besitte, kontrolearje en yn de ôffier opnimme moat. It is ek in twadde plak dêr’t in steuring in oanmeldfout wurdt. Priis it foardat jo it ûntwerp taseine. As nimmen it besitte sil, is it earlike antwurd dat de AWS-klant Workspace net as syn iennichste identiteitsleveransier brûke kin.

Tawizing en twastap-ferifikaasje

Foardat jo wat opnij ûntwerpe, befêstigje dat de app oan stiet foar de juste organisaasje-ienheid of groep, en dat SAML-applikaasjes fan tredden har eigen tawizingskontrôles hawwe, los fan de applikaasjelist oan de Google-kant.

Kontrolearje ek oft twastap-ferifikaasje op it akkount oan stiet. Google kin it easkje foardat in SAML-applikaasje foar in brûker brûkber wurdt, en ien antwurd yn de oarspronklike tried is krekt sa oplost. It is it goedkeapste ding om út te sluten en it ferfelendste om as lêste te ûntdekken.

Ferifiearje mei in skjinne sesje

Test nei elke feroaring mei in nij browserprofyl en in skjinne klantkonfiguraasje. Cache-bewearingen en werbrûkte sesjes ferbergje oft de reparaasje oankommen is.

Fergelykje dêrnei twa records njonkeninoar: it auditbarren fan de identiteitsleveransier en it klantlog. In slagge oanmelding sûnder tunnel wiist werom nei de weromrop of it publyk. In ferbûn tunnel mei in net berikber boarne is in rûte- of autorisaasjeprobleem en heart hielendal earne oars.

Wat net te feroarjen

Helje auth-federate net út it profyl en skeakelje sertifikaatkontrôles net út om by de side lâns te kommen. Beide feroarje it ûntwerp fan autentikaasje ynstee fan de mislearjende weromrop, en beide brekke meastentiids by de folgjende klantfernijing.

Reparearje ynstee dêrfan de oerdracht, en lit in notysje efter dy’t de tuskenleveransier, it publyk en de loopback-poarte neamt. De folgjende persoan dy’t de side sjocht sil alle trije nedich hawwe.