En Windows IKEv2-klient ansluter, och RADIUS-begäran kommer in med en adress där kontonamnet borde stå. Inget har misslyckats ännu, och det är just det som förvirrar: gatewayen rapporterar den identitet som klienten presenterade på IKE-lagret. Användarnamnet som din backend vill ha kan komma från ett separat EAP-utbyte som ännu inte har skett. Bestäm vem som begär det innan du ändrar kontot.

Två identiteter reser i en anslutning

Två namn kan förekomma i en anslutning. IKE-identiteten identifierar motparten under tunneluppsättningen, och eap-radius-insticksmodulen kopierar den först till RADIUS User-Name. EAP-identiteten är ett annat värde, som används för användarautentisering, och den skickas kanske aldrig om ingen begär den.

Därför kan RADIUS-loggen visa en adress medan kontot finns och lösenordet är korrekt. Backend-en tillfrågas om fel lager. RADIUS-attributet är bara transporten för det namn som valdes.

Be gatewayen begära en EAP-identitet

En uppsättning som stöds låter gatewayen begära EAP-identiteten innan autentiseringen lämnas över till RADIUS. I avsnittet för fjärrautentisering i anslutningen ställer du in metoden på eap-radius och begär uttryckligen EAP-identiteten. Fragmentet nedan hör hemma i ett befintligt anslutningsblock, inte i en egen fil. Bekräfta anslutningen och konfigurationsbackend-en innan du kopierar syntax från en annan utrullning.

remote {
    auth = eap-radius
    eap_id = %any
}

Med det tar backend-en emot den identitet som klienten anger i EAP-utbytet i stället för IKE-adressen. Inget annat med anslutningen ändras.

Eller låt RADIUS starta EAP-utbytet

Den andra uppsättningen lägger det första draget på RADIUS-sidan. Insticksmodulen kan skicka en EAP-Start-indikation i stället för att vänta på ett inledande identitetssvar, vilket låter servern styra utbytet. Det är konfiguration på insticksmodulsnivå, så det påverkar varje anslutning som använder insticksmodulen.

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

Välj en uppsättning tillsammans med RADIUS-operatören i stället för att aktivera båda och hoppas. De beskriver olika arbetsflöden, och en server som förväntar sig att starta hanterar inte nödvändigtvis en gateway som börjar samtalet. Insticksmodulens dokumentation beskriver båda, inklusive vilken identitet varje steg bär.

Följ ett försök genom båda loggarna

Korrelera ett enda försök i båda loggarna. Titta på IKE-identiteten, sedan om ett EAP-Identity-utbyte sker, och sedan vilket namn autentiseringssteget får. En backend som avvisar adressen före EAP-utbytet kan stoppa processen innan den avsedda identiteten någonsin ses.

journalctl -u strongswan -f

Behåll det exakta användarnamnsformat som identitetssystemet förväntar sig, inklusive domänprefixet. Hitta aldrig på ett konto från ett adressliknande värde, och slå aldrig av autentisering för att uppfylla en policyregel. En EAP-identitet är ett påstått namn, och metoden måste fortfarande bevisa det. Skriv det resulterande namnet i testprotokollet så att nästa försök börjar från ett känt tillstånd.

Om det korrigerade flödet når rätt konto och fortfarande avvisas, är nästa bevis EAP-metoden och backend-policyn, inte identiteten. Att upprepa en lösenordsåterställning kan inte reparera ett värde som valdes på ett tidigare protokollager.

Relaterade artiklar