Viscosity kom ihåg lösenordet: vad den kryssrutan gjorde

Den kryssrutan vid inloggningsprompten ser ut som en klientinställning, men på en hanterad maskin är den ofta ett policybeslut. Viscositys kom-ihåg-kontroll lagrar inloggningsuppgiften i macOS-nyckelringen när distributionen tillåter lagring. Myten är att kryssrutan alltid är din att sätta. I praktiken kan tre separata saker blockera den, och bara en av dem handlar om lösenordet.

Vad kryssrutan faktiskt lagrar

Att välja kom-ihåg-alternativet ber klienten behålla värdet för just den anslutningen och kontot. Posten hamnar i nyckelringen, och senare inloggningar återanvänder den via den stödda prompten i stället för via en dold inställning. Ingenting skrivs i själva anslutningsfilen. Den separationen är också skälet till att borttagning av posten senare ger en prompt i stället för en trasig profil.

Det lagrade värdet är indata till den autentisering som servern ändå skulle utföra. Det ändrar inte vad gatewayen kräver, kringgår inte en andra faktor och gör inte en engångskod till en återanvändbar hemlighet. Det som förkortas är skrivandet, inte policyn som distributionen tillämpar på kontot.

Varför kontrollen kan saknas

En administratör kan inaktivera lagring av inloggningsuppgifter för en hanterad installation, och SparkLabs dokumenterar kom-ihåg-kontrollen tillsammans med dess nyckelringsbeteende i guiden för lagring av inloggningsuppgifter. När kryssrutan saknas är den inte trasig, och att leta efter ett inställningskommando som åsidosätter den är fel reaktion.

Fråga ägaren vilket stött arbetsflöde som gäller i stället. En distribution som förbjuder lagring har oftast en anledning, och anledningen är ofta att kontot delas, att enheten inte är betrodd eller att inloggningsuppgiften ska löpa ut enligt ett schema. Att kringgå inställningen förvandlar en avsiktlig kontroll till en incident, och incidenten kommer oftast med någon annans revision bifogad.

På en icke-hanterad installation är en saknad kontroll en supportfråga med ett versionsnummer bifogat. Skicka den installerade klientversionen och vad prompten faktiskt visar, i stället för en gissning om dolda standardvärden.

Tre prompts som inte är samma prompt

En engångskod är inte ett lösenord, ett lösenord är inte en nyckelringsauktorisering, och ett serveravslag är ingen av de tre. Att blanda ihop dem ger fel som läses som felaktiga inloggningsuppgifter, medan det verkliga problemet är ett fält, en dialog eller en rutt.

Nyckelringsdialogen är lokal av design. Den frågar om det här programmet får läsa den här posten på den här maskinen, och att godkänna den säger ingenting till VPN-servern.

Därför ger ett nekande av dialogen ett fel på klientsidan som servern aldrig ser, medan ett felaktigt lösenord ger ett avslag på serversidan som klienten bara kan rapportera. Läs dialogen innan du svarar, och kontrollera att programmet som frågar är den klient du förväntar dig och inte ett installationsprogram eller en hjälpprocess. Skillnaden spelar störst roll på delade maskiner, där posten kan vara nåbar för mer än ett konto.

En andra faktor står utanför allt detta. Att lagra ett lösenord lagrar inte koden, och en distribution som kräver koden kräver den fortfarande vid varje anslutning. Håll det steget synligt under testning, eftersom ett flöde som tyst hoppar över det inte är det flöde du konfigurerade.

Återställa en inloggningsuppgift utan att återställa resten

Om autentiseringen misslyckas efter ett lösenordsbyte, använd klientens dokumenterade väg för ny prompt och uppdatering för just den anslutningen i stället för att redigera nyckelringen för hand. Läs meddelandet innan du ersätter något, eftersom en timeout, ett certifikatavslag eller en saknad rutt inte repareras genom att skriva över ett lagrat lösenord. Att göra det upprepade gånger tränar dig mest i att ignorera felet klienten visar. Uppdatera den berörda inloggningsuppgiften, anslut sedan igen och se vilken prompt som visas.

Den fullständiga återställningen av nyckelringen som supportforum föreslår är en mycket större ändring än problemet. Ett lagrat lösenord för en anslutning har ingenting att göra med en annan anslutnings certifikat, och att rensa allt förvandlar en enda inaktuell post till en hel eftermiddag av nyregistrering.

Avsluta med att koppla från och ansluta igen via de vanliga kontrollerna, och bekräfta att det avsedda kontot används och att borttagning av den lagrade posten ger en prompt i stället för ett fel. Förutsägbar återanvändning med ett tydligt sätt att uppdatera eller ta bort inloggningsuppgiften är resultatet som är värt att testa.