Ein Windows IKEv2-klient koplar til, og RADIUS-førespurnaden kjem med ei adresse der kontonamnet skulle stå. Ingenting har feila enno, og det er nettopp det forvirrande: gatewayen rapporterer identiteten klienten presenterte på IKE-laget. Brukarnamnet backend-en din vil ha, kan kome frå ei separat EAP-utveksling som enno ikkje har skjedd. Avgjer kven som spør etter det før du endrar kontoen.

To identitetar reiser i éi tilkopling

To namn kan førekome i éi tilkopling. IKE-identiteten identifiserer motparten under tunneloppsettet, og eap-radius-pluginen kopierer han først til RADIUS User-Name. EAP-identiteten er ein annan verdi, brukt til brukarautentisering, og han vert kanskje aldri send om ingen spør etter han.

Difor kan RADIUS-loggen vise ei adresse medan kontoen finst og passordet er rett. Backend-en vert spurd om feil lag. RADIUS-attributtet er berre transporten for namnet som vart valt.

Be gatewayen om å be om ein EAP-identitet

Eitt støtta oppsett lèt gatewayen be om EAP-identiteten før autentiseringa vert overlevert til RADIUS. I seksjonen for fjernautentisering i tilkoplinga set du metoden til eap-radius og ber uttrykkeleg om EAP-identiteten. Fragmentet nedanfor høyrer heime i ein eksisterande tilkoplingsblokk, ikkje i ei eiga fil. Stadfest tilkoplinga og konfigurasjonsbackend-en før du kopierer syntaks frå ein annan utrulling.

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

Med det mottek backend-en identiteten klienten oppgir i EAP-utvekslinga i staden for IKE-adressa. Ingenting anna ved tilkoplinga vert endra.

Eller la RADIUS starte EAP-utvekslinga

Det andre oppsettet legg det første trekket på RADIUS-sida. Pluginen kan sende ein EAP-Start-indikasjon i staden for å vente på ein innleiande identitetsrespons, noko som lèt tenaren styre utvekslinga. Det er konfigurasjon på plugin-nivå, så det påverkar kvar tilkopling som brukar pluginen.

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

Vel eitt oppsett saman med RADIUS-operatøren i staden for å slå på begge og håpe. Dei skildrar ulike arbeidsflytar, og ein tenar som ventar å starte handterer ikkje nødvendigvis ein gateway som byrjar samtalen. Plugin-dokumentasjonen skildrar begge, inkludert kva identitet kvart steg ber.

Følg eitt forsøk gjennom begge loggane

Korreler eitt enkelt forsøk på tvers av begge loggane. Sjå på IKE-identiteten, deretter om det skjer ei EAP-Identity-utveksling, og deretter kva namn autentiseringsteget mottek. Ein backend som avviser adressa før EAP-utvekslinga, kan stoppe prosessen før den tiltenkte identiteten din nokon gong vert sett.

journalctl -u strongswan -f

Hald på det nøyaktige brukarnamnformatet identitetssystemet ventar, inkludert domeneprefikset. Finn aldri opp ein konto frå ein adresseliknande verdi, og slå aldri av autentisering for å oppfylle ein policyregel. Ein EAP-identitet er eit påstått namn, og metoden må framleis prove det. Skriv det resulterande namnet i testprotokollen slik at neste forsøk startar frå ein kjend tilstand.

Viss den korrigerte flyten når rett konto og framleis vert avvist, er det neste beviset EAP-metoden og backend-policyen, ikkje identiteten. Å gjenta ei passordtilbakestilling kan ikkje reparere ein verdi som vart vald på eit tidlegare protokollag.

Relaterte artiklar