Afegir un usuari a un grup VPN no concedeix accés per si sol

Heu posat el compte al grup correcte, l inici de sessió ha funcionat i la connexió encara es refusa, o bé es connecta i no arriba a res d útil. La reacció habitual és afegir l usuari a més grups fins que alguna cosa cedeixi, i així les organitzacions atorguen molt més del que demanava el tiquet. La pertinença a un grup és una entrada a la decisió d autorització, mai la decisió mateixa: la passarel·la recull unes quantes dades de la sessió, les emparella amb una política ordenada i només llavors decideix a què pot tocar la sessió. Si ha fallat una altra condició, canviar el grup no canvia res excepte la vostra exposició.

La pertinença a un grup és una condició, no un permís

A RADIUS el grup arriba com un atribut d autorització, i els atributs descriuen la sessió en lloc de concedir-la. El servidor respon amb Access-Accept o Access-Reject; en acceptar pot adjuntar Filter-Id, Class o els atributs de túnel de RFC 2868, i l equip de xarxa de l altre extrem els interpreta com decideixi el fabricant. Res del protocol no mapifica un grup a accés complet; aquest mapatge l escriu qui configura la política a la passarel·la o al servidor d accés de xarxa, i pot ser tan estret com un sol amfitrió.

Per això un mateix nom de grup es comporta diferent en dos sistemes. Microsoft NPS munta polítiques de xarxa amb condicions, restriccions i paràmetres i les avalua en un ordre configurat. OpenVPN Access Server té el seu propi model de grups i regles d accés, mentre que un servidor OpenVPN comunitari sovint delega tota la qüestió a un script client-connect o a un fitxer de client-config-dir. Cadascun consumeix un grup; cap no comparteix la lògica de precedència de l altre.

Decideix la regla que ha emparellat, no el grup que esperàveu

La majoria de motors s aturen a la primera política que emparella o a la més específica. Si la política 3 denega i la política 7 permet, la sessió pot fallar sense arribar mai a la regla que l hauria deixat passar. L ordre és un paràmetre real a NPS i a la majoria de productes de control d accés a la xarxa, i es desplaça amb els anys.

Les condicions que acompanyen el grup són l altra meitat. La postura del dispositiu, el mètode d autenticació, l MFA completat, la xarxa d origen, el subjecte del certificat o una finestra horària poden ser a la mateixa política. Quan una no es compleix, la política no emparella, el motor cau i s aplica la denegació per defecte. Des del seient de l usuari sembla que el grup s ignora; des del seient del motor el grup no s ha consultat mai.

Els detalls del directori produeixen la mateixa il·lusió. Una política que emparella per pertinença a grups de Windows llegeix els SID del testimoni de l usuari, i allà només s enumeren grups de seguretat: un grup de distribució no hi apareix mai. El grup primari es porta al seu propi camp, no a la llista enumerada, així que una política fixada a aquest grup pot fallar en silenci.

Llegiu el registre d acceptació o denegació abans de tocar cap grup

Primer una pregunta: la petició ha arribat a l etapa d autorització? A NPS la resposta ja és al registre d esdeveniments, on 6272 registra accés concedit, 6273 una denegació i 6274 una petició que el servidor va descartar abans d avaluar la política. Aquests tres números divideixen el problema en tres investigacions diferents, i només una va de grups.

Quan el registre no és a l abast, pregunteu directament al servidor i llegiu què retorna. Una resposta sense Filter-Id ni atributs de túnel diu que el servidor considera la sessió corrent i que la passarel·la aplica regles pròpies. Una resposta amb atributs que el punt d aplicació no implementa és una altra falla: l autorització ha passat i el dispositiu ha ignorat el resultat.

radtest alice 'password' 10.0.0.5 0 testing123

Compareu els atributs retornats amb els que documenta la passarel·la, no amb el que suggereix el nom del grup. Aquesta comparació sol separar un problema de política d un problema d aplicació.

Un canvi de grup no és retroactiu

Els atributs d autorització es retornen una vegada, quan s autentica la sessió. La passarel·la els desa a la sessió i no rellegeix el directori per a cada paquet, i per això una sessió establerta continua funcionant després de treure algú d un grup, i una de nova pot fallar mentre la vella encara corre.

Perquè el canvi tingui efecte cal una nova decisió d autorització, no només claus noves. On el servidor admet autorització dinàmica RFC 5176, una Disconnect-Request o CoA-Request a UDP 3799 força la reavaluació de la sessió; si no, desconnecteu el client i deixeu que es torni a connectar. La renegociació refresca les claus del túnel i normalment deixa intacte el resultat d autorització.

Arregleu la condició, no el grup

Quan sabeu quina política ha saltat, la reparació sol ser petita: reordeneu una denegació que eclipsa el permís volgut, afegiu la condició de dispositiu o MFA que falta a la política que volíeu emparellar, o escriviu una regla estreta per a aquest recurs en lloc de promoure l usuari a un grup que en porta deu més.

Un bucle curt manté el canvi honest:

• Reproduïu la denegació amb el compte original i apunteu l ID d esdeveniment abans de canviar res.
• Canvieu un sol objecte, l ordre de polítiques, una condició o un grup, i anoteu quin.
• Obriu una sessió nova, confirmeu que la concessió apareix al registre i que el recurs s obre de debò.
• Proveu un usuari que encara ha de ser refusat, perquè l arranjament no hagi eixamplat la política per accident.

Si la concessió és correcta i el recurs no s obre, el problema s ha mogut a encaminament o resolució de noms en el moment que l autorització ha passat. Manteniu les dues falles separades i el proper tiquet costarà minuts, no una tarda.