Vilken klient kan slutföra en SAML-inloggning i AWS Client VPN

Två personer ställer samma fråga om AWS Client VPN och SAML och får motsatta svar. Den ena loggar in från en Ubuntu-bärbar dator varje morgon; den andra har en telefon, en nedladdad profil och en klient som avvisar en rad i den. Skillnaden är inte tur och inte en dold brytare i instrumentpanelen. Allt kokar ner till tre villkor: om plattformen är en som AWS stöder för sin egen klient, om verktyget i din hand kan utföra det federerade webbläsarutbytet och om slutpunkten överhuvudtaget är konfigurerad för SAML. Saknas något av de tre stannar inloggningen på ett annat ställe.

Tre villkor avgör om inloggningen kan slutföras

Plattformen kommer först. AWS levererar sin egen Client VPN-klient för Windows, macOS och Ubuntu på AMD64, och i slutet av oktober 2026 nämner Linux-kravsidan Ubuntu 22.04, 24.04 och 26.04. Ett ompaketerat bygge, ett konverterat paket eller en annan distribution kan fungera, men det är inte en plattform som stöds, och när den går sönder är du supportlinjen.

Klienten kommer som nummer två. Federerad inloggning är inte ett profilval som alla OpenVPN-kompatibla appar tolkar. Den medföljande klienten öppnar din identitetsleverantör i en webbläsare, tar emot det signerade autentiseringssvaret och skickar svaret vidare till slutpunkten. En app som bara läser profilen och reser en tunnel utför inte det här steget, hur rent dess anslutningslogg än ser ut.

Slutpunkten kommer som nummer tre. En slutpunkt med Active Directory-inloggningsuppgifter eller ömsesidiga certifikat har en helt annan ordning, och byte av klienter ändrar inte det. Bekräfta autentiseringsläget med den som utfärdade profilen innan du felsöker något annat.

Tillsammans ger de tre villkoren en kort beslutstabell:

Varför en OpenVPN-import stannar vid auth-federate

En exporterad AWS Client VPN-profil bär ett direktiv som talar om för klienten att autentiseringen sker utanför tunneln, via federation. En generisk OpenVPN-klient avvisar antingen raden direkt eller ignorerar den och har då inga inloggningsuppgifter att erbjuda. Det är här de flesta Android-försök slutar: profilen importeras, appen protesterar, eller anslutningen dör med ett konfigurationsfel innan ett enda paket lämnar enheten.

Att radera auth-federate är det frestande nästa steget, och det gör ett tydligt fel till ett förvirrande. Att ta bort ett direktiv gör inte en SAML-slutpunkt till inloggning med användarnamn och lösenord. Slutpunkten väntar fortfarande på ett signerat SAML-svar och avvisar det klienten skickar i stället. Ditt kontolösenord, den nedladdade profilen och ett kopierat påstående är inte utbytbara inloggningsuppgifter.

Att logga in hos identitetsleverantören i Chrome på telefonen bevisar bara att identitetsleverantören godtog användaren. Det säger ingenting om svaret når en klient som kan skicka tillbaka det till slutpunkten. kraven på federerad autentisering gör den medföljande klienten till en del av flödet just därför: webbläsarsteget är nödvändigt och inte tillräckligt.

Hur den stödda Linux-skrivbordsvägen ser ut

Installera paketet som AWS publicerar för Ubuntu AMD64 med systemets pakethanterare och öppna sedan anslutningen från den klienten i stället för att importera profilen i en allmän VPN-app. Använd profilen som din administratör exporterade för den här slutpunkten; byt inte ut en återkallnings-URL eller en klientidentifierare från en äldre guide, även om klienten accepterar det.

Starta anslutningen, slutför inloggningen och eventuell MFA-förfrågan i webbläsaren som öppnas, och låt returflödet från webbläsaren till klienten bli klart. Begär sedan den privata adress du faktiskt behöver, på nytt. En sida som meddelar lyckad inloggning är inte bevis för att tunneln kom upp.

Linux-klienten reserverar lokala TCP-portar 8096 till 8115 för SAML-svar. När överlämningen hänger efter att identitetsleverantören har godtagit dig, titta på vad som redan lyssnar i det intervallet:

ss -ltnp | grep -E ":809[6-9]|:81(0[0-9]|1[0-5])"

En upptagen port, eller säkerhetsprogramvara på slutpunkten som blockerar loopback-lyssnaren, ger en inloggning som ser ut att slutföras och sedan aldrig ansluter. Håll det intervallet lokalt. Det är en returväg på klientsidan, inte något man öppnar i en EC2-säkerhetsgrupp eller en gateway-brandväggsregel, och att öppna det mot internet ger mer exponering utan att lösa något.

Läs steget som misslyckas innan du ändrar något

Att skylla på klienten är den vanliga reflexen, men varje felpunkt tillhör en annan ägare. Ta först reda på var du faktiskt befinner dig.

• Inget webbläsarfönster öppnas. Kontrollera profilens autentiseringsläge, anslutningen du valde och integrationen med skrivbordets standardwebbläsare.
• Identitetsleverantören avvisar kontot. Kontotilldelning, MFA-registrering eller konfigurationen av SAML-applikationen, allt är administratörens område.
• Webbläsaren blir klar men klienten ansluter aldrig. Ett utgånget eller oanvändbart autentiseringssvar, en blockerad returport eller en misslyckad överlämning.
• Tunneln är uppe men applikationen går inte att nå. Slutpunktens rutter, auktoriseringsregler, säkerhetsgrupper, DNS. Att upprepa webbläsarinloggningen kan inte lägga till en saknad nätverkstillstånd.

Spara klientens feltext och tiden för försöket när du eskalerar. Påståendet att SAML är trasigt och påståendet att klienten aldrig fick ett giltigt autentiseringssvar skickar folk till helt olika ställen.

När kravet ändå är Android

Android är inte en plattform som AWS publicerar sin klient för, så det ärliga svaret är att det inte finns någon stödd mobilklient att installera. Det är en designbegränsning, inte ett pussel som ska lösas på telefonen genom att redigera profilen tills något ansluter.

Det som kan förändras är åtkomsten bakom, och det beslutet tillhör administratören: en godkänd applikationsåtkomstväg till den enda interna tjänsten telefonen behöver, en VPN-produkt med mobilstöd som organisationen redan driver, eller ett stött skrivbord för slutpunkten som bara använder SAML. Varje alternativ tar med sin egen slutpunktskonfiguration, identitetsregistrering och auktoriseringsregler, och inget av det kan en användare skapa utifrån en nedladdad profil.

Tredjepartsverktyg som hävdar att de stänger gapet behöver en uttrycklig granskning av stöd och säkerhet som täcker MFA, hantering av svar, enhetspolicy och uppdateringstakt. Att de finns gör dem inte till en AWS-levererad Android-klient, och du bör inte flytta återanvändbart autentiseringsmaterial till en telefon för att få ett av dem att fungera.

Ge administratören tre fakta i stället för en lång tråd om direktiv: slutpunktens autentiseringsläge, den privata resursen telefonen måste nå och tidsfristen. Det räcker för att välja mellan skrivbord, applikationsåtkomstväg och en ny VPN-produkt.

Kontrollera villkoren i ordning innan du öppnar ännu ett ärende: plattform på listan över medföljande klienter, ett verktyg som kan slutföra webbläsarutbytet, en slutpunkt som verkligen är konfigurerad för federation och, på Linux, loopback-portintervallet. Det första objektet som misslyckas är det som ska åtgärdas. Allt därefter är gissningar.