Kasutaja lisamine VPN-gruppi ei anna iseenesest juurdepääsu
Grupiliikmelisus on üks tingimus, mitte luba. Vaadake, mida lüüs tegelikult sobitas, lugege vastuvõtu või keeldumise kirjet ja katsetage mõlemat tulemust.
Pistsite konto õigesse gruppi, sisselogimine õnnestus ja ühendus lükatakse ikkagi tagasi või see luuakse ega jõua kuhugi kasulikku. Tavaline reaktsioon on lisada kasutajat järjest rohkematesse gruppidesse, kuni miski järele annab, ja nii annavad organisatsioonid palju rohkem kui pilet palus. Grupiliikmelisus on autoriseerimisotsuse üks sisend, mitte kunagi otsus ise: lüüs kogub sessiooni kohta paar fakti, sobitab need järjestatud poliitikaga ja alles siis otsustab, mida sessioon puutuda tohib. Kui ebaõnnestus mõni muu tingimus, ei muuda grupi muutmine midagi peale teie kokkupuute.
Grupiliikmelisus on tingimus, mitte luba
RADIUSes saabub grupp autoriseerimisatribuudina ning atribuudid kirjeldavad sessiooni, selle asemel et seda lubada. Server vastab Access-Accept või Access-Reject; vastuvõtul võib see lisada Filter-Id, Class või RFC 2868 tunneliatribuudid, ja teises otsas olev võrguseade tõlgendab neid tootja otsuse järgi. Protokollis ei vasta miski grupile täielikku juurdepääsu; selle vastavuse kirjutab see, kes seadistas poliitika lüüsil või võrgu juurdepääsuseveril, ja see võib olla kitsas nagu üks host.
Seepärast käitub sama grupinimi kahes süsteemis erinevalt. Microsoft NPS koostab võrgupoliitikad tingimustest, piirangutest ja seadetest ning hindab neid etteantud järjekorras. OpenVPN Access Serveril on oma grupi- ja juurdepääsureeglite mudel, samas kui kogukonna OpenVPN server annab kogu küsimuse sageli üle client-connect skriptile või client-config-dir failile. Igaüks tarbib gruppi; ükski ei jaga teise prioriteediloogikat.
Otsustab reegel, mis sobis, mitte grupp, mida ootasite
Enamik mootoreid peatub esimesel sobival poliitikal või kõige spetsiifilisemal. Kui poliitika 3 keeldub ja poliitika 7 lubab, võib sessioon ebaõnnestuda jõudmata kunagi reeglini, mis oleks selle läbi lasknud. Järjekord on tegelik seade NPSis ja enamikus võrgu juurdepääsukontrolli toodetes ning nihkub aastate jooksul.
Grupiga kaasas käivad tingimused on teine pool. Seadme seisund, autentimismeetod, lõpetatud MFA, lähtevõrk, sertifikaadi subjekt või ajaline aken võivad olla samas poliitikas. Kui üks neist on täitmata, poliitika ei sobi, mootor kukub läbi ja kehtib vaikimisi keeldumine. Kasutaja istmelt näib, et gruppi eiratakse; mootori istmelt ei küsitud gruppi üldse.
Kataloogi detailid tekitavad sama illusiooni. Windowsi grupiliikmelisuse järgi sobituv poliitika loeb kasutaja tokenis olevaid SIDe, ja seal loetletakse ainult turvagruppe, turustusgrupp ei ilmuta kunagi. Esmane grupp kantakse eraldi väljal, mitte loendis, seega sellele kinnitatud poliitika võib vaikselt ebaõnnestuda.
Lugege vastuvõtu või keeldumise kirjet enne, kui gruppi puutute
Küsige kõigepealt üht asja: kas päring jõudis üldse autoriseerimisetappi? NPSis on vastus sündmustelogis, kus 6272 märgib antud juurdepääsu, 6273 keeldumise ja 6274 päringu, mille server enne poliitika hindamist kõrvale heitis. Need kolm numbrit jagavad probleemi kolmeks eri uurimiseks ja ainult üks neist puudutab gruppe.
| 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 |
Kui logi käepärast pole, küsige serverilt otse ja lugege, mida see tagastab. Vastus ilma Filter-Id ja tunneliatribuutideta ütleb, et server peab sessiooni tavaliseks ja lüüs rakendab oma reegleid. Vastus atribuutidega, mida jõustamispunkt ei rakenda, on teine viga: autoriseerimine läks läbi ja seade eiras tulemust.
radtest alice 'password' 10.0.0.5 0 testing123Võrrelge tagastatud atribuute nendega, mida lüüs dokumenteerib, mitte sellega, mida grupinimi vihjab. See võrdlus eraldab tavaliselt poliitikaprobleemi jõustamisprobleemist.
Grupi muudatus ei mõju tagasiulatuvalt
Autoriseerimisatribuudid tagastatakse üks kord, sessiooni autentimisel. Lüüs hoiab neid sessioonil ega loe kataloogi iga paketi jaoks uuesti, seepärast töötab olemasolev sessioon edasi ka pärast seda, kui keegi grupist eemaldada, ja uus võib ebaõnnestuda, kuni vana veel töötab.
Muudatuse jõustumiseks on vaja uut autoriseerimisotsust, mitte ainult uusi võtmeid. Kui server toetab RFC 5176 dünaamilist autoriseerimist, sunnib Disconnect-Request või CoA-Request UDP 3799 juurde sessiooni uuesti hindama; muidu katkestage klient ja laske tal uuesti ühenduda. Ümberläbirääkimine uuendab tunnelivõtmed ja jätab autoriseerimistulemuse tavaliselt puutumata.
Parandage tingimust, mitte gruppi
Kui teate, milline poliitika rakendus, on parandus tavaliselt väike: järjestage ümber keeld, mis varjutab soovitud loa, lisage puuduv seadme- või MFA-tingimus poliitikale, mida mõtlesite, või kirjutage kitsas reegel ühele ressursile, selle asemel et tõsta kasutaja gruppi, mis kannab veel kümmet.
Lühike tsükkel hoiab muudatuse ausana:
- Korrake keeldumine algse kontoga ja kirjutage sündmuse ID üles enne, kui midagi muudate.
- Muutke ühte objekti, poliitikate järjekorda, üht tingimust või üht gruppi, ja märkige millist.
- Avage uus sessioon, kinnitage, et luba ilmub logisse ja et ressurss tõesti avaneb.
- Testige kasutajat, keda peaks ikka keelduma, et parandus ei laiendanud poliitikat kogemata.
Kui luba on õige ja ressurss ei avane, on probleem liikunud marsruutimisse või nimede lahendamisse hetkel, mil autoriseerimine läbis. Hoidke need kaks viga lahus ja järgmine pilet võtab minuteid, mitte pärastlõunat.