Dodavanje korisnika u VPN grupu samo po sebi ne daje pristup
Članstvo u grupi jedan je uvjet, a ne dopuštenje. Pogledajte što je gateway stvarno upario, pročitajte zapis o prihvaćanju ili odbijanju i testirajte oba ishoda.
Stavili ste račun u pravu grupu, prijava je uspjela, a veza se i dalje odbija ili se uspostavi i ne stigne ni do čega korisnog. Uobičajena reakcija je dodavati korisnika u još grupa dok nešto ne popusti, i tako organizacije daju mnogo više nego što je tiket tražio. Članstvo u grupi jedan je ulaz u odluku o autorizaciji, nikad sama odluka: gateway prikupi nekoliko činjenica o sesiji, upari ih s uređenom politikom i tek onda odluči što sesija smije dirati. Ako je pao neki drugi uvjet, promjena grupe ne mijenja ništa osim vaše izloženosti.
Članstvo u grupi je uvjet, a ne dopuštenje
U RADIUS-u grupa dolazi kao atribut autorizacije, a atributi opisuju sesiju umjesto da je odobravaju. Poslužitelj odgovara s Access-Accept ili Access-Reject; pri prihvatu može dodati Filter-Id, Class ili tunelske atribute iz RFC 2868, a mrežna oprema na drugoj strani tumači ih kako je proizvođač odlučio. Ništa u protokolu ne preslikava grupu u puni pristup; to preslikavanje piše onaj koji je postavio politiku na gatewayu ili mrežnom pristupnom poslužitelju.
Zato se isto ime grupe ponaša različito na dva sustava. Microsoft NPS sastavlja mrežne politike od uvjeta, ograničenja i postavki i ocjenjuje ih zadanim redom. OpenVPN Access Server ima svoj model grupa i pravila pristupa, dok zajednički OpenVPN poslužitelj često sve pitanje prepušta client-connect skripti ili datoteci u client-config-dir.
Odluku donosi pravilo koje se uparilo, ne grupa koju ste očekivali
Većina strojeva staje na prvoj politici koja se upari ili na najkonkretnijoj. Ako politika 3 odbija a politika 7 dopušta, sesija može pasti a da nikad ne stigne do pravila koje bi je propustilo. Red je stvarna postavka na NPS-u i većini proizvoda za kontrolu mrežnog pristupa i pomiče se godinama.
Uvjeti koji idu uz grupu druga su polovica. Stanje uređaja, metoda autentifikacije, završen MFA, izvorna mreža, subjekt certifikata ili vremenski prozor mogu biti u istoj politici. Kad jedan nije ispunjen, politika se ne upari, stroj pada dalje i primjenjuje se zadano odbijanje. Sa stolice korisnika izgleda da je grupa ignorirana; sa stolice stroja grupa nije ni pitana.
Pojedinosti iz imenika stvaraju istu iluziju. Politika koja se uparuje po članstvu u Windows grupama čita SID-ove u korisničkom tokenu, a tamo se nabrajaju samo sigurnosne grupe, distribucijska grupa nikad se ne pojavi. Primarna grupa nosi se u svom polju, ne u nabrojanom popisu, pa politika vezana uz nju može tiho pasti.
Pročitajte zapis o prihvaćanju ili odbijanju prije nego dirnete grupu
Prvo jedno pitanje: je li zahtjev uopće stigao do faze autorizacije? Na NPS-u je odgovor u dnevniku događaja, gdje 6272 bilježi odobren pristup, 6273 odbijanje, a 6274 zahtjev koji je poslužitelj odbacio prije ocjene politike. Ta tri broja dijele problem na tri različite istrage, a samo jedna je o grupama.
| 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 |
Kad dnevnik nije dostupan, pitajte poslužitelj izravno i pročitajte što vraća. Odgovor bez Filter-Id i bez tunelskih atributa kaže da poslužitelj sesiju smatra običnom i da gateway primjenjuje vlastita pravila. Odgovor s atributima koje točka primjene ne implementira druga je greška: autorizacija je prošla, a uređaj je ignorirao rezultat.
radtest alice 'password' 10.0.0.5 0 testing123
Usporedite vraćene atribute s onima koje gateway dokumentira, ne s onim što ime grupe sugerira. Ta usporedba obično razdvoji problem politike od problema primjene.
Promjena grupe ne djeluje unatrag
Atributi autorizacije vraćaju se jednom, pri autentifikaciji sesije. Gateway ih čuva na sesiji i ne čita imenik ponovno za svaki paket, zato uspostavljena sesija nastavlja raditi nakon što nekoga uklonite iz grupe.
Da bi promjena stupila na snagu, treba nova odluka o autorizaciji, ne samo novi ključevi. Gdje poslužitelj podržava dinamičku autorizaciju RFC 5176, Disconnect-Request ili CoA-Request na UDP 3799 prisiljava sesiju na ponovnu ocjenu; inače odspojite klijenta i pustite ga da se ponovno poveže. Ponovno pregovaranje osvježava tunelske ključeve i obično ne dira rezultat autorizacije.
Popravite uvjet, ne grupu
Kad znate koja je politika proradila, popravak je obično malen: preuredite odbijanje koje zasjenjuje željeno dopuštenje, dodajte nedostajući uvjet za uređaj ili MFA u politiku koju ste mislili, ili napišite usko pravilo za jedan resurs umjesto da korisnika podignete u grupu koja nosi još deset.
Kratak ciklus čuva promjenu iskrenom:
- Reproducirajte odbijanje s izvornim računom i zapišite ID događaja prije nego bilo što promijenite.
- Promijenite jedan objekt, red politika, jedan uvjet ili jednu grupu, i zabilježite koji.
- Otvorite novu sesiju, potvrdite da se odobrenje vidi u dnevniku i da se resurs zaista otvara.
- Testirajte korisnika koji i dalje treba biti odbijen, da popravak nije slučajno proširio politiku.
Ako je odobrenje ispravno a resurs se ne otvara, problem se preselio na usmjeravanje ili razrješavanje imena u trenutku kad je autorizacija prošla. Držite te dvije greške odvojeno i sljedeći tiket traje minute, ne poslijepodne.