AWS Client VPN SAML kaj Google Workspace: la manko de la resenda voko
Google montras app_not_configured_for_user antaŭ ol ekzistas ia tunelo. La kliento volas simplan HTTP-respondan vokon sur loopback, kiun Workspace ne akceptas.
La paĝo app_not_configured_for_user venas de Google Workspace kaj aperas antaŭ ol eĉ unu tunela pako estas intertraktata. Tiu ordo estas la tuta diagnozo. Reinstali la klienton, redakti la profilon aŭ kontroli la vojojn ne povas forigi paĝon, kiun la fina punkto de VPN ankoraŭ ne vidis. La malsukcesa paŝo estas transdono en la retumilo inter la identecprovizanto kaj aŭskultanto sur la propra maŝino de la uzanto, kaj en tiu transdono indas kontroli ekzakte tri aferojn.
Legu la paĝon kiel deklaron de la identecprovizanto
Google resendas ĉi tion, kiam la SAML-aplikaĵo ne estas ŝaltita por la konto, kiu ensalutis. La aplikaĵo povas esti malŝaltita, la uzanto povas esti ekster la atribuita organiza unuo aŭ grupo, aŭ la agordoj de la servoprovizanto eble ne kongruas kun tio, kion la peto demandis.
Nenio el tio estas problemo pri atestilo, vojo aŭ tunelo, kvankam la uzanto rimarkis ĝin en la VPN-kliento.
La du valoroj, kiujn la kliento akceptos
AWS Client VPN faras servoprovizantan SAML-interŝanĝon, do la kliento malfermas retumilon, la uzanto aŭtentikiĝas, kaj la provizanto resendas subskribitan aserton al la URL de Assertion Consumer Service. Por la labortabla kliento provizita de AWS tiu URL estas aŭskultanto sur loopback, kutime pordo 35001, kaj la atendata publiko estas la ento-identigilo de la Client VPN SAML-aplikaĵo, ne la ensaluta ento de la AWS-konsoleo.
Ambaŭ valoroj devas kongrui kun tio, kion la kliento atendas: kie la aserto estas sendata kaj al kiu ĝi estas adresita. Agordo kopiita el konsolea SSO-aplikaĵo povas aspekti tute kredinda kaj tamen celi la malĝustan paron.
Prenu ambaŭ valorojn el la postuloj de Client VPN SAML, ne el ĝenerala gvidilo pri unueca ensaluto de AWS. La konsolea SSO-ento aspektas sufiĉe simila por esti tentiga. Ĝi estas alia aplikaĵo kun alia publiko, kaj la kliento rifuzas la aserton sen klarigi sin. Kopiu la paron unufoje kaj konservu ĝin apud la profilo.
Google ne akceptos la simplan HTTP-respondan vokon
La administra konsoleo postulas HTTPS-URL por ACS, kaj la resenda voko de la kliento estas simpla HTTP sur loopback. Tiu valoro tute ne estas tajpebla en la agordon de la Workspace-aplikaĵo, kaj tial iuj teamoj provas inversan prokuron, kiu finas TLS kaj plusendas al la loka aŭskultanto. Tio ne riparas la malkongruon: la retumilo vidas unu originon, la kliento anoncas alian, kaj la resendita respondo povas alveni kun la malĝusta celo.
La aranĝo, kiu funkcias, estas pera identecprovizanto. La SAML-aplikaĵo ĉe la peranto ricevas la loopback-respondan vokon kaj la AWS-publikon, kaj la peranto federas la Workspace-konton supren. La HTTPS-regulo de Google restas plenumita, kaj la aserto, kiu atingas la klienton, ankoraŭ nomas la adreson kaj publikon, kiujn ĝi atendas.
Tiu peranto estas administra dependaĵo, kiun iu devas posedi, prigardi kaj inkluzivi en la forigo de la dungito. Ĝi ankaŭ estas dua loko, kie paneo fariĝas ensaluta fiasko. Taksi ĝin antaŭ ol promesi la dezajnon. Se neniu posedos ĝin, la honesta respondo estas, ke la AWS-kliento ne povas uzi Workspace kiel sian solan identecprovizanton.
Atribuo kaj duŝtupa kontrolo
Antaŭ ol redesegni ion ajn, konfirmu, ke la aplikaĵo estas ŝaltita por la ĝusta organiza unuo aŭ grupo, kaj ke triapartaj SAML-aplikaĵoj havas proprajn atribuajn kontrolojn aparte de la aplikaĵa listo ĉe la Google-flanko.
Kontrolu ankaŭ, ĉu la konto havas duŝtupan kontrolon ŝaltita. Google povas postuli ĝin antaŭ ol SAML-aplikaĵo fariĝos uzebla por uzanto, kaj unu respondo en la origina fadeno estis solvita ĝuste tiel. Ĝi estas la plej malmultekosta afero por ekskludi kaj la plej ĝena por malkovri laste.
Kontrolu per pura seanco
Post iu ajn ŝanĝo, testu per freŝa retumila profilo kaj pura klienta agordo. Kaŝmemoritaj asertoj kaj reuzitaj seancoj kaŝas, ĉu la riparo sukcesis.
Poste komparu du rikordojn flanke al flanke: la revizia evento de la identecprovizanto kaj la klienta protokolo. Sukcesa ensaluto sen tunelo montras reen al la resenda voko aŭ al la publiko. Konektita tunelo kun neatingebla rimedo estas problemo pri enkursigo aŭ rajtigo kaj apartenas tute aliloke.
Kion ne ŝanĝi
Ne forprenu auth-federate el la profilo kaj ne malŝaltu atestilajn kontrolojn por pasi la paĝon. Ambaŭ ŝanĝas la aŭtentikigan dezajnon anstataŭ la malsukcesan respondan vokon, kaj ambaŭ kutime rompiĝas ĉe la sekva klienta ĝisdatigo.
Riparu anstataŭe la transdonon, kaj lasu noton, kiu nomas la peranton, la publikon kaj la loopback-pordon. La sekva persono, kiu vidos la paĝon, bezonos ĉiujn tri.