Að bæta notanda í VPN-hóp veitir ekki aðgang eitt og sér
Hópaaðild er eitt skilyrði, ekki leyfi. Skoðaðu hvað gáttin bar í raun saman, lestu samþykktar- eða synjunarfærsluna og prófaðu bæði útkomin.
Þú settir reikninginn í réttan hóp, innskráningin tókst, og tengingunni er samt hafnað eða hún nær engu gagnlegu. Venjulega viðbragðið er að bæta notandanum í fleiri hópa þar til eitthvað lætur undan, og þannig veitir fyrirtækið miklu meira en miðinn bað um. Hópaaðild er eitt inntak í heimildarákvörðunina, aldrei ákvörðunin sjálf: gáttin safnar fáum staðreyndum um lotuna, ber þær saman við skipulögð stefnur og ákveður svo hvað lotan má snerta. Ef annað skilyrði brást breytir hópurinn engu nema áhættu þinni.
Hópaaðild er skilyrði, ekki leyfi
Í RADIUS kemur hópurinn sem heimildareiginleiki, og eiginleikar lýsa lotunni í stað þess að leyfa hana. Þjónninn svarar með Access-Accept eða Access-Reject; við samþykkt getur hann bætt við Filter-Id, Class eða göngueiginleikum RFC 2868, og netbúnaðurinn hinum megin túlkar þá eins og framleiðandinn ákvað. Ekkert í samskiptareglunum varpar hóp yfir í fullan aðgang; þá vörpun skrifar sá sem stillti stefnuna á gáttinni eða netaðgangsþjóninum.
Þess vegna hegðar sami hópnefni sér öðruvísi á tveimur kerfum. Microsoft NPS setur saman netstefnur úr skilyrðum, takmörkunum og stillingum og metur þær í ákveðinni röð. OpenVPN Access Server hefur sitt eigið líkan af hópum og aðgangsreglum, en samfélagsútgáfa OpenVPN-þjóns felur oft öllu málinu á client-connect skriftu eða client-config-dir skrá.
Það er reglan sem passaði sem ræður, ekki hópurinn sem þú bjóst við
Flestar vélar stöðva á fyrstu stefnunni sem passar eða þeirri sértækustu. Ef stefna 3 hafnar og stefna 7 leyfir getur lotan mistekist án þess að ná reglunni sem hefði hleypt henni í gegn. Röðin er raunveruleg stilling á NPS og flestum netaðgangsstýringum og færist til með árunum.
Skilyrðin sem fylgja hópnum eru hinn helmingurinn. Staða tækisins, auðkenningaraðferð, lokið MFA, upprunanet, viðfang skírteinis eða tímarammi geta verið í sömu stefnu. Ef eitt er óuppfyllt passar stefnan ekki, vélin fellur í gegn og sjálfgefin synjun gildir. Frá sæti notandans virðist hópurinn hunsaður; frá sæti vélarinnar var hópurinn aldrei spurður.
Smáatriði í skránni skapa sömu blekkingu. Stefna sem passar við Windows-hópaaðild les SID í tóken notandans, og þar eru aðeins öryggishópar taldir, dreifihópur birtist aldrei. Aðalhópurinn er borinn í eigin reit, ekki á listanum, svo stefna sem er fest við hann getur mistekist hljóðlaust.
Lestu samþykktar- eða synjunarfærsluna áður en þú snertir hóp
Spyrðu fyrst eins: náði beiðnin yfirhöfuð heimildarstiginu? Á NPS er svarið í atburðaskránni, þar sem 6272 skráir veittan aðgang, 6273 synjun og 6274 beiðni sem þjónninn henti áður en stefnan var metin. Þessar þrjár tölur skipta vandamálinu í þrjár rannsóknir, og aðeins ein snýr að hópum.
| 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 |
Þegar skráin er ekki aðgengileg skaltu spyrja þjóninn beint og lesa svarið. Svar án Filter-Id og án göngueiginleika þýðir að þjónninn telur lotuna venjulega og gáttin beitir eigin reglum. Svar með eiginleikum sem framfylgdarpunkturinn útfærir ekki er önnur bilun: heimildin fór í gegn og tækið hunsaði niðurstöðuna.
radtest alice 'password' 10.0.0.5 0 testing123Berðu eiginleikana sem komu til baka saman við þá sem gáttin skjalfestir, ekki það sem hópnefnið bendir á. Sá samanburður aðskilur venjulega stefnuvandamál frá framfylgdarvandamáli.
Hópbreyting hefur ekki afturvirk áhrif
Heimildareiginleikar koma til baka einu sinni, þegar lotan er auðkennd. Gáttin geymir þá á lotunni og les skrána ekki aftur fyrir hverja pakkann, þess vegna heldur lota sem er komin áfram að virka eftir að einhver er tekinn úr hópi, og ný getur mistekist.
Til að breytingin gildi þarf nýja heimildarákvörðun, ekki bara nýja lykla. Þar sem þjónninn styður RFC 5176 virka heimild, þvingar Disconnect-Request eða CoA-Request á UDP 3799 endurmat lotunnar; annars skaltu aftengja biðlarann og leyfa honum að tengjast aftur. Endursamningur endurnýjar göngulykla og lætur heimildarniðurstöðuna yfirleitt óbreytta.
Lagaðu skilyrðið, ekki hópinn
Þegar þú veist hvaða stefna virkaði er viðgerðin yfirleitt lítil: endurraðaðu synjun sem skyggir á tilætlað leyfi, bættu vantaði tækja- eða MFA-skilyrði við stefnuna sem þú meintir, eða skrifaðu þrönga reglu fyrir eina tilföng í stað þess að lyfta notandanum í hóp sem ber tíu aðra.
Stutt lykkja heldur breytingunni heiðarlegri:
- Endurgerðu synjunina með upprunalega reikningnum og skrifaðu niður atburðar-ID áður en þú breytir nokkru.
- Breyttu einum hlut, stefnuröð, einu skilyrði eða einum hóp, og skráðu hvaða.
- Opnaðu nýja lotu, staðfestu að leyfið sjáist í skránni og að tilfangið opnist í raun.
- Prófaðu notanda sem á enn að hafna, svo viðgerðin hafi ekki víkkað stefnuna fyrir slysni.
Ef leyfið er rétt og tilfangið opnast samt ekki, hefur vandamálið flust yfir í leiðsögn eða nafnaleysingu á þeirri stundu sem heimildin fór í gegn. Haltu bilununum tveimur aðskildum og næsti miði tekur mínútur, ekki síðdegi.