Een gebruiker aan een VPN-groep toevoegen geeft nog geen toegang
Groepslidmaatschap is één voorwaarde, geen toestemming. Kijk wat de gateway werkelijk heeft vergeleken, lees de accept- of weigerrecord en test beide uitkomsten.
Het account staat in de juiste groep, de aanmelding lukt, en de verbinding wordt alsnog geweigerd of bereikt niets bruikbaars. De gebruikelijke reflex is de gebruiker in meer groepen zetten tot iets toegeeft, en zo verlenen organisaties veel meer dan de ticket vroeg. Groepslidmaatschap is één invoer voor de autorisatiebeslissing, nooit de beslissing zelf: de gateway verzamelt feiten over de sessie, vergelijkt ze met geordend beleid en beslist dan pas waar de sessie aan mag komen. Als een andere voorwaarde faalde, verandert de groep niets behalve uw blootstelling.
Groepslidmaatschap is een voorwaarde, geen toestemming
In RADIUS komt de groep binnen als autorisatieattribuut, en attributen beschrijven de sessie in plaats van haar toe te staan. De server antwoordt met Access-Accept of Access-Reject; bij acceptatie kan hij Filter-Id, Class of de tunnelattributen uit RFC 2868 toevoegen, en de netwerkapparatuur aan de andere kant interpreteert ze zoals de leverancier bepaalde. Niets in het protocol vertaalt een groep naar volledige toegang; die vertaling schrijft wie het beleid op de gateway of de netwerktoegangsserver instelde.
Daarom gedraagt eenzelfde groepsnaam zich anders op twee systemen. Microsoft NPS stelt netwerkbeleid samen uit voorwaarden, beperkingen en instellingen en evalueert dat in een vaste volgorde. OpenVPN Access Server heeft zijn eigen groeps- en toegangsregelmodel, terwijl een community-OpenVPN-server de vraag vaak aan een client-connect-script of een client-config-dir-bestand overlaat.
De regel die overeenkwam beslist, niet de groep die u verwachtte
De meeste engines stoppen bij het eerste overeenkomende beleid of bij het meest specifieke. Als beleid 3 weigert en beleid 7 toestaat, kan een sessie mislukken zonder ooit de regel te bereiken die haar zou doorlaten. De volgorde is een echte instelling op NPS en de meeste netwerktoegangscontroleproducten, en schuift over de jaren.
De voorwaarden die met de groep meelopen zijn de andere helft. Apparaatstatus, authenticatiemethode, afgeronde MFA, bronnetwerk, certificaatonderwerp of een tijdvenster kunnen in hetzelfde beleid staan. Ontbreekt er één, dan past het beleid niet, de engine valt door en de standaardweigering geldt. Vanaf de gebruikersstoel lijkt de groep genegeerd; vanaf de motorstoel is de groep nooit gevraagd.
Directorydetails maken dezelfde illusie. Beleid dat op Windows-groepslidmaatschap matcht leest de SID’s in het token, en daar worden alleen beveiligingsgroepen opgesomd, een distributiegroep verschijnt nooit. De primaire groep staat in een eigen veld, niet in de lijst, dus beleid dat daaraan hangt kan stil falen.
Lees de accept- of weigerrecord voordat u een groep aanraakt
Stel eerst één vraag: heeft het verzoek de autorisatiefase whatsoever bereikt? Op NPS staat het antwoord in het gebeurtenislog, waar 6272 toegekende toegang noteert, 6273 een weigering en 6274 een verzoek dat de server vóór de beleidsevaluatie weggooide. Die drie nummers splitsen het probleem in drie onderzoeken, en slechts één gaat over groepen.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
Is het log onbereikbaar, vraag de server dan direct en lees wat hij teruggeeft. Een antwoord zonder Filter-Id en zonder tunnelattributen betekent dat de server de sessie gewoon vindt en de gateway eigen regels toepast. Een antwoord met attributen die het handhavingspunt niet implementeert is een ander defect: de autorisatie slaagde en het apparaat negeerde het resultaat.
radtest alice 'password' 10.0.0.5 0 testing123Vergelijk de teruggegeven attributen met wat de gateway documenteert, niet met wat de groepsnaam suggereert. Die vergelijking scheidt meestal een beleidsprobleem van een handhavingsprobleem.
Een groepswijziging werkt niet met terugwerkende kracht
Autorisatieattributen worden één keer teruggegeven, bij de authenticatie van de sessie. De gateway bewaart ze op de sessie en leest de directory niet opnieuw voor elk pakket, waardoor een bestaande sessie blijft werken nadat u iemand uit een groep haalt.
Om de wijziging te laten gelden is een nieuwe autorisatiebeslissing nodig, niet alleen nieuwe sleutels. Waar de server RFC 5176 ondersteunt, dwingt een Disconnect-Request of CoA-Request naar UDP 3799 herbeoordeling af; anders verbreekt u de client en laat hem opnieuw verbinden. Heronderhandeling vernieuwt de tunnelsleutels en laat het autorisatieresultaat meestal ongemoeid.
Repareer de voorwaarde, niet de groep
Zodra u weet welk beleid greep, is de reparatie meestal klein: herorden een weigering die de bedoelde toestemming overschaduwt, voeg de ontbrekende apparaat- of MFA-voorwaarde toe aan het beleid dat u bedoelde, of schrijf een smalle regel voor die ene resource in plaats van de gebruiker in een groep met tien andere te hijsen.
Een korte lus houdt de wijziging eerlijk:
- Reproduceer de weigering met het oorspronkelijke account en noteer de gebeurtenis-ID voordat u iets wijzigt.
- Wijzig één object, beleidsvolgorde, één voorwaarde of één groep, en noteer welke.
- Open een nieuwe sessie, bevestig dat de toestemming in het log verschijnt en dat de resource echt opent.
- Test een gebruiker die nog steeds geweigerd moet worden, zodat de reparatie het beleid niet per ongeluk verruimde.
Als de toestemming klopt en de resource opent toch niet, is het probleem naar routing of naamresolutie verschoven op het moment dat de autorisatie slaagde. Houd die twee fouten gescheiden en de volgende ticket kost minuten, geen middag.