IKEv1 med XAuth och OTP: vad varje prompt frågar efter

IKEv1 med PSK, XAuth och OTP ber inte om ett enda komplicerat lösenord. Det staplar en delad nyckel mellan peers, ett användarutbyte och en andra faktor vars sätt att fråga bestäms av backend. Varje lager har sin egen ägare och sitt eget felmeddelande. Att blanda ihop dem får människor att skriva om en engångskod i ett fält som lagrar en grupphemlighet.

Matcha varje prompt mot det lager som frågar efter den innan du installerar en annan klient eller återställer en inloggningsuppgift.

Tre hemligheter, tre ägare

Den fördelade nyckeln hör till peer-relationen och konfigureras en gång av den som äger båda ändarna. Användarens inloggningsuppgift hör till autentiseringsbackend och valideras vid varje inloggning. Den andra faktorn hör till ett tokensystem vars svar ändras vid varje försök. Ingen ersätter en annan, och en driftsättning som behandlar dem som ett enda lösenord misslyckas i det lager som ingen dokumenterade.

Skriv ner tre kolumner: ägare, livstid och det felmeddelande som var och en ger. Den tabellen är diagnostikverktyget, inte klientens fältnamn.

PSK: peers, inte personens

I den här äldre lösningen autentiserar den fördelade nyckeln gatewayparet, så användarens inloggning ersätter den aldrig. Det är också det värde som oftast är fel på ett sätt som ger ett allmänt förhandlingsfel i stället för en prompt. När tunneln misslyckas innan någon användarprompt visas är nyckeln eller förslagen de misstänkta.

En användaruppgift kan inte reparera ett fel i första fasen. Att rotera den slösar bort den enda uppgift du säkert kan rotera och förstärker den felaktiga teorin.

XAuth: det äldre användarutbytet

XAuth lägger till ett utbyte för användarautentisering ovanpå IKEv1:s peer-autentisering, och gatewayen avgör vilken backend som validerar det. Beroende på den backenden kan utbytet acceptera ett kataloglösenord, en RADIUS-uppgift eller ett tokensvar. Ordet XAuth namnger utbytets transport, inte typen av uppgift.

Kontrollera vilken backend gatewayprofilen pekar på. Det berättar vad användaren kommer att tillfrågas om och vad en lösenordsåterställning faktiskt ändrar, och inget av det syns i en klientprofil.

OTP: vad backend än frågar efter

Vissa driftsättningar frågar efter en separat engångskod efter lösenordet, andra definierar ett kombinerat indataformat med en dokumenterad separator. Båda finns, och profilen framför dig avgör vilket. Att hitta på en sammanslagning för att den fungerade på en annan plats är det vanligaste sättet att bränna en registreringstoken. Gatewayens egen dokumentation är den enda källan som avgör saken.

Använd det dokumenterade formatet med en klient som kan slutföra utbytet som gatewayen erbjuder.

Där klientgränsen biter

Fortinet anger att FortiClient 7.4.4 och senare inte längre stöder IKEv1 för IPsec-VPN:er, vilket är en produkt- och versionsgräns snarare än en generell borttagning, så som FortiClients kompatibilitetsnotering redovisar. Inte heller andra klienter är utbytbara: OpenConnect och openfortivpn talar särskilda gatewayprotokoll, inte godtyckliga IKEv1-profiler. Kontrollera IKE-version, PSK-läge, XAuth-stöd och interaktionsmodell för den installerade klienten var för sig. En klient som ansluter med en annan metod har inte bevisat det ursprungliga kravet.

IKEv1 är föråldrat, så en ny utrullning på en gammal klient utan stöd är en kortlivad lösning. Be gatewayägaren om en migreringsväg med stöd, inklusive hur den andra faktorn ska hanteras där.

Diagnostisera utan att stänga av faktorn

Separera stegen i loggen: peer-förhandling, användarutbytet, resultatet av den andra faktorn och sedan adress- och routetilldelning. Anteckna komponenten och steget i stället för att prova koden i varje fält. Att stänga av faktorn så att ett test går igenom ger en tunnel som inte bevisar något om driftsättningen.

Förvara registreringshemligheter och den delade nyckeln i skyddad lagring enligt organisationens process. En engångskod i en beständig fil är en faktor som har slutat vara en faktor.