AWS Client VPN SAML și Google Workspace: golul din callback

Pagina app_not_configured_for_user vine de la Google Workspace și apare înainte ca măcar un pachet de tunel să fie negociat. Această ordine este întregul diagnostic. Reinstalarea clientului, editarea profilului sau verificarea rutelor nu pot curăța o pagină pe care punctul final al VPN-ului încă nu a văzut-o. Pasul care eșuează este o predare în browser între furnizorul de identitate și un ascultător de pe mașina utilizatorului, iar în acea predare sunt exact trei lucruri care merită verificate.

Citiți pagina ca o declarație a furnizorului de identitate

Google returnează acest lucru când aplicația SAML nu este activată pentru contul care s-a conectat. Este posibil ca aplicația să fie oprită, utilizatorul să fie în afara unității organizaționale sau a grupului atribuit, ori setările furnizorului de servicii să nu corespundă cererii.

Nimic din toate acestea nu este o problemă de certificat, de rută sau de tunel, deși utilizatorul a observat-o în clientul VPN.

Cele două valori pe care clientul le va accepta

AWS Client VPN face un schimb SAML inițiat de furnizorul de servicii, așa că clientul deschide un browser, utilizatorul se autentifică, iar furnizorul trimite o aserțiune semnată înapoi la un URL Assertion Consumer Service. Pentru clientul desktop oferit de AWS acel URL este un ascultător pe loopback, de obicei portul 35001, iar audiența așteptată este identificatorul de entitate al aplicației SAML Client VPN, nu entitatea de conectare a consolei AWS.

Ambele valori trebuie să corespundă așteptărilor clientului: unde este publicată aserțiunea și cui îi este adresată. O configurație copiată dintr-o aplicație SSO a consolei poate părea perfect plauzibilă și totuși poate viza perechea greșită.

Luați ambele valori din cerințele Client VPN SAML, nu dintr-un ghid generic de autentificare unică AWS. Entitatea SSO a consolei arată suficient de asemănător încât să fie tentantă. Este altă aplicație, cu altă audiență, iar clientul respinge aserțiunea fără să se explice. Copiați perechea o dată și păstrați-o lângă profil.

Google nu va accepta callback-ul HTTP simplu

Consola de administrare cere un URL ACS prin HTTPS, iar callback-ul clientului este HTTP simplu pe loopback. Această valoare nu poate fi introdusă deloc în configurația aplicației Workspace, de aceea unele echipe încearcă un proxy invers care termină TLS și redirecționează către ascultătorul local. Asta nu repară nepotrivirea: browserul vede o origine, clientul anunță alta, iar răspunsul returnat poate ajunge la o destinație greșită.

Soluția care funcționează este un furnizor de identitate intermediar. Aplicația SAML de la intermediar primește callback-ul loopback și audiența AWS, iar intermediarul federează contul Workspace în amonte. Regula HTTPS a Google rămâne îndeplinită, iar aserțiunea care ajunge la client numește în continuare adresa și audiența așteptate.

Acel intermediar este o dependență administrativă pe care cineva trebuie să o dețină, să o monitorizeze și să o includă la offboarding. Este și un al doilea loc în care o pană devine o eroare de conectare. Estimați-i costul înainte de a promite designul. Dacă nimeni nu îl va deține, răspunsul onest este că clientul AWS nu poate folosi Workspace ca unic furnizor de identitate.

Atribuire și verificare în doi pași

Înainte de a reproiecta ceva, confirmați că aplicația este activă pentru unitatea organizațională sau grupul corect și că aplicațiile SAML terțe au propriile controale de atribuire, separate de lista de aplicații din partea Google.

Verificați și dacă contul are activată verificarea în doi pași. Google o poate cere înainte ca o aplicație SAML să devină utilizabilă pentru un utilizator, iar un singur răspuns din firul original a fost rezolvat exact așa. Este cel mai ieftin lucru de exclus și cel mai enervant de descoperit ultimul.

Verificați cu o sesiune curată

După orice modificare, testați cu un profil de browser nou și o configurație de client curată. Aserțiunile din cache și sesiunile reutilizate ascund dacă remedierea a ajuns.

Apoi comparați două înregistrări una lângă alta: evenimentul de audit al furnizorului de identitate și jurnalul clientului. O conectare reușită fără tunel indică înapoi spre callback sau spre audiență. Un tunel conectat cu o resursă inaccesibilă este o problemă de rutare sau de autorizare și aparține cu totul altundeva.

Ce să nu schimbați

Nu eliminați auth-federate din profil și nu dezactivați verificările de certificate pentru a trece de pagină. Ambele schimbă designul autentificării în loc de callback-ul care eșuează și ambele se strică de obicei la următoarea actualizare a clientului.

Remediați în schimb predarea și lăsați o notă care numește intermediarul, audiența și portul loopback. Următoarea persoană care vede pagina va avea nevoie de toate trei.