Lietotāja pievienošana VPN grupai pati par sevi nedod piekļuvi
Grupas dalība ir viens nosacījums, ne atļauja. Apskatiet, ko vārteja faktiski saskaņoja, izlasiet pieņemšanas vai noraidīšanas ierakstu un pārbaudiet abus iznākumus.
Konts ir pareizajā grupā, pieteikšanās izdevās, bet savienojums joprojām tiek noraidīts vai arī neaizsniedz neko lietderīgu. Ierastā reakcija ir pievienot lietotāju vairākām grupām, līdz kaut kas piekāpjas, un tā organizācijas piešķir daudz vairāk, nekā prasīja biļete. Grupas dalība ir viena autorizācijas lēmuma ievade, nekad pats lēmums: vārteja savāc faktus par sesiju, saskaņo tos ar sakārtotu politiku un tikai pēc tam izlemj, kam sesija drīkst pieskarties. Ja neizdevās cits nosacījums, grupas maiņa maina tikai jūsu pakļautību.
Grupas dalība ir nosacījums, ne atļauja
RADIUS grupа nāk kā autorizācijas atribūts, un atribūti apraksta sesiju, nevis to atļauj. Serveris atbild ar Access-Accept vai Access-Reject; pieņemot tas var pievienot Filter-Id, Class vai RFC 2868 tuneļa atribūtus, un tīkla iekārta otrā pusē tos interpretē tā, kā nolēmis ražotājs. Protokolā nekas nepārveido grupu pilnīgā piekļuvē; šo atbilstību raksta tas, kurš iestatīja politiku uz vārtejas vai tīkla piekļuves servera.
Tāpēc viens un tas pats grupas nosaukums divās sistēmās uzvedas atšķirīgi. Microsoft NPS veido tīkla politikas no nosacījumiem, ierobežojumiem un iestatījumiem un vērtē tās noteiktā kārtībā. OpenVPN Access Server ir savs grupu un piekļuves noteikumu modelis, bet kopienas OpenVPN serveris bieži visu jautājumu nodod client-connect skriptam vai client-config-dir failam.
Lemj noteikums, kas saskaņojās, nevis grupa, ko gaidījāt
Lielākā daļa dzinēju apstājas pie pirmās atbilstošās politikas vai pie visspecifiskākās. Ja politika 3 noraida un politika 7 atļauj, sesija var neizdoties, tā arī nesasniedzot noteikumu, kas to būtu laidis cauri. Kārtība ir reāls iestatījums NPS un lielākajā daļā tīkla piekļuves kontroles produktu, un gadu gaitā tā mainās.
Nosacījumi, kas iet kopā ar grupu, ir otrā puse. Ierīces stāvoklis, autentifikācijas metode, pabeigts MFA, avota tīkls, sertifikāta subjekts vai laika logs var būt tajā pašā politikā. Ja kāds nav izpildīts, politika nesaskan, dzinējs nokrīt un tiek piemērots noklusējuma noraidījums. No lietotāja vietas izskatās, ka grupa tiek ignorēta; no dzinēja vietas grupa nemaz netika jautāta.
Kataloga detaļas rada to pašu ilūziju. Politika, kas saskaņo Windows grupas dalību, lasa SID žetonā, un tur tiek uzskaitītas tikai drošības grupas, sadales grupa nekad neparādās. Primārā grupa tiek turēta atsevišķā laukā, nevis sarakstā, tāpēc politika, kas pie tās piesaistīta, var klusi neizdoties.
Izlasiet pieņemšanas vai noraidīšanas ierakstu pirms aiztiekat grupu
Vispirms viens jautājums: vai pieprasījums vispār sasniedza autorizācijas posmu? NPS atbilde ir notikumu žurnālā, kur 6272 atzīmē piešķirto piekļuvi, 6273 noraidījumu, bet 6274 pieprasījumu, ko serveris izmeta pirms politikas novērtēšanas. Šie trīs skaitļi sadala problēmu trīs dažādās izmeklēšanās, un tikai viena ir par grupām.
| 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 žurnāls nav pieejams, jautājiet serverim tieši un lasiet atbildi. Atbilde bez Filter-Id un bez tuneļa atribūtiem nozīmē, ka serveris sesiju uzskata par parastu un vārteja piemēro savus noteikumus. Atbilde ar atribūtiem, ko izpildes punkts neievieš, ir cita kļūda: autorizācija izgāja, un ierīce ignorēja rezultātu.
radtest alice 'password' 10.0.0.5 0 testing123Salīdziniet atgrieztos atribūtus ar tiem, ko vārteja dokumentē, nevis ar to, ko liecina grupas nosaukums. Šis salīdzinājums parasti atdala politikas problēmu no izpildes problēmas.
Grupas maiņa nedarbojas atpakaļejoši
Autorizācijas atribūti tiek atgriezti vienreiz, sesijas autentifikācijas laikā. Vārteja tos glabā sesijā un nelasa katalogu no jauna katram paketei, tāpēc jau izveidota sesija turpina darboties arī pēc tam, kad kāds tiek izņemts no grupas.
Lai izmaiņas stātos spēkā, vajadzīgs jauns autorizācijas lēmums, nevis tikai jaunas atslēgas. Ja serveris atbalsta RFC 5176 dinamisko autorizāciju, Disconnect-Request vai CoA-Request uz UDP 3799 piespiež sesiju pārvērtēt; pretējā gadījumā atvienojiet klientu un ļaujiet tam pievienoties no jauna. Atkārtotas sarunas atjauno tuneļa atslēgas un parasti atstāj autorizācijas rezultātu.
Labojiet nosacījumu, nevis grupu
Kad zināt, kura politika iedarbojās, labojums parasti ir mazs: pārkārtojiet noraidījumu, kas aizsedz vēlamo atļauju, pievienojiet trūkstošo ierīces vai MFA nosacījumu paredzētajai politikai, vai uzrakstiet šauru noteikumu vienam resursam, tā vietā lai celtu lietotāju grupā ar desmit citiem.
Īss cikls notur izmaiņas godīgas:
- Atkārtojiet noraidījumu ar sākotnējo kontu un pierakstiet notikuma ID pirms kaut ko maināt.
- Mainiet vienu objektu, politiku kārtību, vienu nosacījumu vai vienu grupu, un pierakstiet, kuru.
- Atveriet jaunu sesiju, apstipriniet, ka atļauja parādās žurnālā un resurss tiešām atveras.
- Pārbaudiet lietotāju, kuram joprojām jābūt noraidītam, lai labojums nejauši nepaplašinātu politiku.
Ja atļauja ir pareiza un resurss tomēr neataras, problēma ir pārgājusi uz maršrutēšanu vai nosaukumu atrisināšanu tajā brīdī, kad autorizācija izgāja. Turiet abas kļūdas atsevišķi, un nākamā biļete prasīs minūtes, nevis pēcpusdienu.