FortiGate-VPN hamnar i fel grupp: RADIUS-matchning
Fortinet-Group-Name matchas mot svaret, inte mot din lokala gruppetikett. Gå igenom de tre namnen innan du breddar matchningen till Any.
Inloggningen lyckas, tunneln kommer upp och användaren hamnar på fel policy eller ingen policy alls. Inget i FortiGate-loggen meddelar att gruppen saknades, eftersom autentiseringen fungerade från dess sida och gruppmatchningen helt enkelt inte utlöstes. Kedjan du måste undersöka innehåller tre separata namn, och de är vanligtvis inte samma sträng.
Tre namn med tre uppgifter
Skriv ner alla tre innan du rör någon konfiguration, eftersom två av dem lever i olika system.
| Record | Illustrative value |
|---|---|
| Directory membership checked by the RADIUS policy | Engineering VPN users |
| Returned Fortinet-Group-Name string | vpn-engineering |
| FortiGate local access group | VPN-Engineering |
Kataloggruppen är det som din RADIUS-policy utvärderar. Det returnerade attributet är ett värde inuti Access-Accept-svaret. Den lokala FortiGate-gruppen är en behållare som policyn refererar till vid namn. Att blanda ihop två av dem ger en inloggning som fungerar och en auktorisering som inte gör det.
Var matchningen faktiskt görs
Fortinets förklaring av RADIUS-gruppmatchning anger Fortinet-Group-Name som standardgruppattribut. FortiGate jämför den konfigurerade fjärrservern och gruppnamnsvärdet med det svaret bär, vilket innebär att jämförelsen görs mot den returnerade strängen, inte mot visningsnamnet för din lokala grupp.
Det är därför en lokal grupp som heter VPN-Engineering kan stå bredvid ett returnerat värde vpn-engineering och inte matcha någonting alls. Versaler och stavning är inte kosmetika i den här jämförelsen. Välj en sträng, använd den i svaret och referera till samma sträng i gatewayens matchningsregel.
På FortiAuthenticator måste gruppen kopplas till attributet och tas med i den matchande RADIUS-tjänstepolicyn, med kontrollen för återlämning av gruppattributet aktiverad där det är tillämpligt.
Svaret kan lyckas utan attributet
För NPS eller en annan RADIUS-server, genomdriv kataloggruppsvillkoret i policyn och konfigurera sedan det stödda svarsattributet. En lyckad lösenordskontroll producerar ett Access-Accept av sig själv, och ett Access-Accept utan gruppsträng är ett fullständigt giltigt svar som inte auktoriserar något på FortiGate-sidan. Detta är den vanligaste formen av problemet.
Att definiera en grupp är inte samma sak som att skicka den. Det är två konfigurationssteg på två olika skärmar, och vanligtvis görs bara ett av dem.
Varför matchning med Any är en fälla
En Any-fjärrgruppsmatchning är en legitim design när RADIUS-servern redan släpper in exakt den population du vill ha. Välj den delegeringen medvetet. Att bredda matchningen för att bli av med ett saknat attribut släpper in varje konto som RADIUS-servern råkar acceptera, inklusive de som aldrig var tänkta att ha VPN-åtkomst. Symtomet försvinner och åtkomstkontrollen slutar tyst att existera.
Om du inte kan namnge vem RADIUS-servern ska släppa in är du inte redo för en Any-matchning.
Spara fyra poster för support
När det fortfarande inte fungerar, samla fyra saker: RADIUS-policyn som valdes, gruppattributet som faktiskt returnerades, FortiGate-servern och värdet den matchades mot, och den resulterande lokala gruppen. Dessa fyra poster lokaliserar brottet utan att avslöja lösenord eller ändra gruppmedlemskap för att se vad som händer.
Testa ett auktoriserat och ett konto utanför omfånget under den riktiga regeln, och kontrollera den resulterande policyn och resursåtkomsten samt autentiseringsresultatet. Bara paret berättar om matchningen gör det du tror.