Groeplidmaatskap gee nie self toegang nie

Jy sit die rekening in die regte groep, die aanmelding slaag, en die verbinding word steeds geweier of bereik niks bruikbaars. Die gewone reaksie is om by meer groepe te voeg tot iets werk, en so word baie meer regte toegeken as wat die kaartjie gevra het. Groeplidmaatskap is een inset vir die magtigingsbesluit, nooit die besluit self nie: die gateway versamel feite oor die sessie, pas dit op geordende beleid toe en besluit eers dan wat die sessie mag raak. As n ander voorwaarde gefaal het, verander die groep niks behalwe jou blootstelling.

Groeplidmaatskap is n voorwaarde, nie n reg nie

In RADIUS kom die groep as n magtiging-eienskap, en eienskappe beskryf die sessie eerder as om dit toe te ken. Die bediener antwoord met Access-Accept of Access-Reject; by aanvaarding kan dit Filter-Id, Class of die tonnel-eienskappe van RFC 2868 byvoeg, wat die toerusting aan die ander kant volgens sy verskaffer interpreteer. Niks in die protokol beeld n groep na volle toegang af nie; daardie afbeelding skryf wie die beleid op die gateway of die netwerktoegang-bediener opstel, en dit kan so smal soos een gasheer wees.

Daarom gedra n identiese groepsnaam hom anders op twee stelsels. Microsoft NPS stel netwerkbeleide uit voorwaardes, beperkings en instellings saam en evalueer dit in n bepaalde volgorde. OpenVPN Access Server het sy eie groep- en toegangsreelmodel, terwyl n gemeenskapsbediener die vraag dikwels aan n client-connect-skrip of client-config-dir-leer delegeer. Elkeen gebruik n groep; nie een deel n ander se voorranglogika nie.

Die reël wat pas, besluit, nie die groep wat jy verwag het nie

Die meeste enjins stop by die eerste beleid wat pas of by die mees spesifieke een. As beleid 3 weier en beleid 7 toelaat, kan n sessie misluk sonder om ooit die reël te bereik wat dit sou deurlaat. Ordening is n werklike instelling op NPS en die meeste netwerktoegangbeheerprodukte, en dit verskuif oor jare: iemand skuif n weier-beleid na bo vir n onverwante voorval, en n groep wat verlede kwartaal gewerk het, werk nie meer nie.

Voorwaardes wat saam met die groep loop, is die ander helfte. Toestelpostuur, magtigingsmetode, MFA-voltooiing, bronnetwerk, sertifikaatonderwerp of n tydvenster kan almal in dieselfde beleid sit. Wanneer een daarvan nie nagekom word nie, pas die beleid nie, die enjin val deur en n verstek-weier geld. Vanuit die gebruiker se stoel lyk dit of die groep geignoreer word; vanuit die enjin se stoel is die groep nooit geraadpleeg nie.

Gidsgegewens skep dieselfde illusie. n Beleid wat op Windows-groepslidmaatskap pas, lees die SID-e in die token, en net sekuriteitsgroepe word gelys, nooit n verspreidingsgroep nie. n Primere groep word in sy eie veld gedra, nie in die gelysde lys nie, so n beleid wat daarop vasgepen is, kan stilweg misluk. Hernoemde groepe en kruisdomein-SID-e voeg vertaalstappe by wat stilweg misluk wanneer n vertroue eenrigting is.

Lees die aanvaardings- of weieringsrekord voordat jy aan n groep raak

Vra eers een vraag: het die versoek die magtigingstadium enigsins bereik? Op NPS staan die antwoord in die gebeurtenislog, waar 6272 toegang verleen, 6273 weiering en 6274 n weggegooide versoek aanteken. Daardie drie nommers verdeel die probleem in drie ondersoeke, en net een gaan oor groepe.

Wanneer die log buite bereik is, ondervra die bediener direk en lees wat dit teruggee. n Antwoord sonder Filter-Id en sonder tonnel-eienskappe se die bediener beskou die sessie as gewoon en die gateway pas sy eie reels toe. n Antwoord met eienskappe wat die handhawingspunt nie implementeer nie, is n ander fout: magtiging het geslaag en die toestel het die resultaat geignoreer.

radtest alice 'password' 10.0.0.5 0 testing123

Vergelyk die teruggegewe eienskappe met die wat die gateway dokumenteer, nie met wat die groepsnaam voorstel nie. Daardie vergelyking skei gewoonlik n beleidsprobleem van n handhawingsprobleem voordat iemand n groep wysig.

n Groepswysiging werk nie terug nie

Magtiging-eienskappe word een keer teruggegee, wanneer die sessie geauthentiseer word. Die gateway stoor dit op die sessie en lees nie die gids vir elke pakkie weer nie, en dis waarom n bestaande sessie bly werk nadat jy iemand uit n groep verwyder het, en waarom n nuwe sessie kan misluk terwyl n ou een nog loop.

Om n wysiging te laat geld, het jy n nuwe magtigingsbesluit nodig, nie net nuwe sleutels nie. Waar die bediener RFC 5176 dinamiese magtiging ondersteun, dwing n Disconnect-Request of CoA-Request na UDP 3799 die sessie om herbewoordeel te word; anders ontkoppel die klient en laat hom weer koppel. Heronderhandeling vernuwe die tonnelsleutels en laat die magtigingsresultaat gewoonlik onaangeraak, wat teenstrydige toetsresultate gee.

Maak die voorwaarde reg, nie die groep nie

Sodra jy weet watter beleid gepas het, is die herstel gewoonlik klein: herrangskik n weier wat die bedoelde toelating oorskadu, voeg die ontbrekende toestel- of MFA-voorwaarde by die beleid wat jy bedoel het, of skryf n smal reel vir die een hulpbron eerder as om die gebruiker in n groep te promoveer wat tien ander saamdra. Lidmaatskap verbreed om n kaartjie te sluit, is die duur weergawe, en dis hoe n ondersteuningskortpad n staande uitsondering word.

n Kort lus hou die wysiging eerlik:

• Herproduseer die weiering met die oorspronklike rekening en skryf die gebeurtenis-ID neer voordat jy iets verander.
• Verander een objek, hetsy n beleidsorde, een voorwaarde of een groep, en teken aan watter een.
• Maak n nuwe sessie oop, bevestig die toekenning verskyn in die log, en bevestig die hulpbron open werklik.
• Toets n gebruiker wat steeds geweier moet word, sodat die herstel nie die beleid per ongeluk verbreed het nie.

As die toekenning korrek is en die hulpbron nog steeds nie oopgaan nie, het die probleem na roetering of naamoplossing verskuif die oomblik toe magtiging geslaag het. Hou daardie twee foute uitmekaar en die volgende kaartjie neem minute eerder as n middag.