Å leggje ein brukar til ei VPN-gruppe gir ikkje tilgang i seg sjølv
Gruppemedlemskap er éin føresetnad, ikkje eit løyve. Sjå kva gatewayen faktisk jamførte, les motteke- eller avvist-posten, og prøv begge utfalla.
Kontoen står i rett gruppe, innlogginga lukkast, men tilkoplinga vert avvist eller når ingenting nyttig. Fleire grupper gir meir enn saka bad om. Gruppemedlemskap er eitt innspel, ikkje avgjerda: gatewayen jamfører fakta mot ordna policy og avgjer først då. Fell ein annan føresetnad, endrar gruppa berre eksponeringa.
Gruppemedlemskap er ein føresetnad, ikkje eit løyve
I RADIUS er gruppa eit autorisasjonsattributt som skildrar økta, ikkje løyver henne. Tenaren svarar Access-Accept eller Access-Reject, og kan leggje ved Filter-Id, Class eller tunnelattributtar frå RFC 2868; utstyret tolkar dei som produsenten vil. Ingenting kartlegg gruppa til full tilgang; den kartlegginga skriv den som sette policyen.
Difor verkar same gruppenamn ulikt på to system. Microsoft NPS byggjer policyar av føresetnader, avgrensingar og innstillingar og vurderer dei i fast rekkjefølgje. OpenVPN Access Server har eigen modell, og samfunnstenarar overlèt ofte alt til client-connect eller client-config-dir.
Regelen som passa avgjer, ikkje gruppa du venta
Dei fleste motora stoggar ved første treff eller den mest spesifikke. Avviser policy 3 og tillèt policy 7, kan økta feile før ho når regelen som slapp henne gjennom. Rekkjefølgja er ei reell innstilling og flyttar seg over år.
Føresetnadene rundt gruppa er andre halvdel: einingstilstand, autentiseringsmetode, MFA, kjeldenett, sertifikatsubjekt eller tidsvindauge. Manglar éin, passar ikkje policyen, og standardavvising gjeld. Brukaren ser ei gruppe som vert ignorert; motoren spurde aldri.
Katalogdetaljar lurer på same vis. Policy på Windows-grupper les SID-ar i tokenet, der berre tryggingsgrupper er lista. Primærgruppa ligg i eige felt, så policy fest til henne kan feile stille.
Les motteke- eller avvist-posten før du rører ei gruppe
Spør først: nådde førespurnaden autorisasjonsfasen? På NPS står 6272 for gitt tilgang, 6273 for avvising og 6274 for ein førespurnad kasta før policyvurdering. Tala deler problemet i tre granskingar; berre éi gjeld grupper.
| 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 |
Er loggen utilgjengeleg, spør tenaren og les svaret. Utan Filter-Id og tunnelattributtar ser tenaren økta som ordinær og gatewayen nyttar eigne reglar. Attributtar handhevinga ikkje implementerer er ein annan feil: autorisasjonen gjekk gjennom og eininga ignorerte han.
radtest alice 'password' 10.0.0.5 0 testing123
Samanlikn attributtane med dei gatewayen dokumenterer, ikkje med gruppenamnet. Det skil policyproblem frå handhevingsproblem.
Ei gruppeendring verkar ikkje bakover
Attributtane vert returnerte éin gong ved autentisering. Gatewayen lagrar dei på økta og les ikkje katalogen per pakke, så ei etablert økt held fram etter at nokon vert fjerna frå gruppa.
Endringa krev ei ny autorisasjonsavgjerd, ikkje berre nye nøklar. Støttar tenaren RFC 5176, tvingar Disconnect-Request eller CoA-Request til UDP 3799 ny vurdering; elles kople frå og til på nytt. Nye forhandlingar fornyar berre tunnelnøklane.
Rett føresetnaden, ikkje gruppa
Når du veit kva policy som slo til, er reparasjonen liten: omorganiser avvisinga som skuggar løyvet, legg til manglande eining- eller MFA-føresetnad, eller skriv ei smal regel for éin ressurs i staden for å lyfte brukaren inn i ei gruppe med ti andre.
Ei kort løkke held endringa ærleg:
- Gjenskap avvisinga med originalkontoen og noter hendings-ID før du endrar noko.
- Endre eitt objekt, policyrekkjefølgje, éin føresetnad eller éi gruppe, og noter kva.
- Opne ny økt, stadfest at løyvet synest i loggen og at ressursen opnar.
- Test ein brukar som framleis skal avvisast, så reparasjonen ikkje utvida policyen.
Er løyvet rett og ressursen framleis stengd, har problemet flytta seg til ruting eller namneoppslag då autorisasjonen gjekk gjennom. Hald feila skilde, og neste sak tek minutt, ikkje ein ettermiddag.