Adăugarea unui utilizator într-un grup VPN nu acordă acces de la sine
Apartenența la grup este o condiție, nu o permisiune. Uitați-vă ce a comparat de fapt gateway-ul, citiți înregistrarea de acceptare sau refuz și testați ambele rezultate.
Contul este în grupul corect, autentificarea a reușit, iar conexiunea este totuși refuzată sau nu ajunge la nimic util. Reflexul obișnuit este să adaugi utilizatorul în mai multe grupuri până cedează ceva, și astfel organizațiile acordă mult mai mult decât a cerut tichetul. Apartenența este o intrare în decizia de autorizare, niciodată decizia: gateway-ul adună fapte despre sesiune, le compară cu o politică ordonată și abia apoi decide. Dacă altă condiție a eșuat, schimbarea grupului schimbă doar expunerea.
Apartenența la grup este o condiție, nu o permisiune
În RADIUS grupul vine ca atribut de autorizare, iar atributele descriu sesiunea în loc să o permită. Serverul răspunde cu Access-Accept sau Access-Reject; la acceptare poate atașa Filter-Id, Class sau atributele de tunel din RFC 2868, iar echipamentul din cealaltă parte le interpretează cum a decis producătorul. Nimic din protocol nu mapează un grup la acces complet; acea mapare o scrie cine a configurat politica.
De aceea același nume de grup se comportă diferit pe două sisteme. Microsoft NPS compune politici de rețea din condiții, restricții și setări și le evaluează într-o ordine definită. OpenVPN Access Server are propriul model de grupuri și reguli, iar un server OpenVPN comunitar deleagă adesea totul unui script client-connect sau unui fișier client-config-dir.
Decide regula care s-a potrivit, nu grupul așteptat
Majoritatea motoarelor se opresc la prima politică potrivită sau la cea mai specifică. Dacă politica 3 refuză și politica 7 permite, sesiunea poate eșua fără să ajungă la regula care ar fi lăsat-o să treacă. Ordinea este o setare reală în NPS și în majoritatea produselor de control al accesului.
Condițiile care însoțesc grupul sunt cealaltă jumătate: starea dispozitivului, metoda de autentificare, MFA finalizat, rețeaua sursă, subiectul certificatului sau o fereastră orară. Dacă una lipsește, politica nu se potrivește, motorul cade și se aplică refuzul implicit.
Detaliile directorului creează aceeași iluzie. O politică pe apartenența la grupuri Windows citește SID-urile din token, unde sunt listate doar grupuri de securitate; un grup de distribuție nu apare niciodată. Grupul primar stă într-un câmp propriu, așa că o politică legată de el poate eșua în silențiu.
Citiți înregistrarea de acceptare sau refuz înainte de a atinge un grup
Întrebați mai întâi un lucru: a ajuns cererea la etapa de autorizare? În NPS răspunsul este în jurnalul de evenimente, unde 6272 notează accesul acordat, 6273 refuzul, iar 6274 o cerere eliminată înainte de evaluarea politicii. Cele trei numere împart problema în trei investigații, iar doar una este despre grupuri.
| 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 |
Când jurnalul nu este accesibil, întrebați serverul direct și citiți ce returnează. Un răspuns fără Filter-Id și fără atribute de tunel înseamnă că serverul consideră sesiunea obișnuită și gateway-ul aplică reguli proprii. Un răspuns cu atribute pe care punctul de aplicare nu le implementează este altă defecțiune: autorizarea a trecut și dispozitivul a ignorat rezultatul.
radtest alice 'password' 10.0.0.5 0 testing123Comparați atributele returnate cu cele documentate de gateway, nu cu ce sugerează numele grupului. Acea comparație separă de obicei o problemă de politică de una de aplicare.
O schimbare de grup nu este retroactivă
Atributele de autorizare sunt returnate o dată, la autentificarea sesiunii. Gateway-ul le păstrează pe sesiune și nu recitește directorul pentru fiecare pachet, de aceea o sesiune stabilită continuă după ce scoți pe cineva din grup.
Pentru ca schimbarea să producă efect este nevoie de o nouă decizie de autorizare, nu doar de chei noi. Unde serverul acceptă RFC 5176, un Disconnect-Request sau CoA-Request către UDP 3799 forțează reevaluarea; altfel deconectați clientul și lăsați-l să revină.
Reparați condiția, nu grupul
Când știți ce politică a acționat, reparația este de obicei mică: reordonați un refuz care umbrește permisiunea dorită, adăugați condiția de dispozitiv sau MFA lipsă, sau scrieți o regulă îngustă pentru resursa respectivă în loc să promovați utilizatorul într-un grup cu alte zece.
O buclă scurtă ține schimbarea onestă:
- Reproduceți refuzul cu contul original și notați ID-ul evenimentului înainte de a schimba ceva.
- Schimbați un singur obiect, ordinea politicilor, o condiție sau un grup, și notați care.
- Deschideți o sesiune nouă, confirmați că permisiunea apare în jurnal și că resursa se deschide cu adevărat.
- Testați un utilizator care trebuie încă refuzat, ca reparația să nu fi lărgit politica.
Dacă permisiunea este corectă și resursa nu se deschide, problema s-a mutat la rutare sau rezolvarea numelor în momentul în care autorizarea a trecut. Țineți cele două defecțiuni separate și următorul tichet durează minute.