Ha egy felhasználót VPN-csoporthoz adunk, az önmagában nem ad hozzáférést

A fiók a megfelelő csoportban van, a bejelentkezés sikerült, a kapcsolatot mégis elutasítják, vagy létrejön és nem ér el semmi hasznosat. A szokásos reakció, hogy újabb csoportokba tesszük a felhasználót, amíg valami enged, és így a szervezetek sokkal többet adnak, mint amit a jegy kért. A csoporttagság egyetlen bemenet a jogosítási döntéshez, soha nem maga a döntés: az átjáró összegyűjt néhány tényt a munkamenetről, összeveti őket rendezett szabályzattal, és csak utána dönti el, mihez nyúlhat a munkamenet. Ha más feltétel bukott meg, a csoport módosítása semmit nem változtat a kitettségén kívül.

A csoporttagság feltétel, nem engedély

A RADIUS-ban a csoport jogosítási attribútumként érkezik, az attribútumok pedig leírják a munkamenetet, nem engedélyezik. A kiszolgáló Access-Accept vagy Access-Reject választ ad; elfogadáskor hozzáfűzhet Filter-Id-t, Class-t vagy az RFC 2868 szerinti alagút-attribútumokat, és a túloldali hálózati eszköz a gyártó döntése szerint értelmezi őket. A protokollban semmi nem képez le egy csoportot teljes hozzáférésre; ezt a leképezést az írja, aki a szabályzatot az átjárón vagy a hálózati hozzáférési kiszolgálón beállította.

Ezért viselkedik ugyanaz a csoportnév másképp két rendszeren. A Microsoft NPS feltételekből, korlátozásokból és beállításokból állítja össze a hálózati szabályzatokat, és meghatározott sorrendben értékeli őket. Az OpenVPN Access Servernek saját csoport- és hozzáférésiszabály-modellje van, a közösségi OpenVPN-kiszolgáló pedig gyakran az egész kérdést egy client-connect szkriptre vagy egy client-config-dir fájlra bízza.

A nap egyező szabály dönt, nem a várt csoport

A legtöbb motor az első egyező szabályzatnál vagy a legkonkrétabbnál áll meg. Ha a 3. szabályzat elutasít, a 7. pedig engedélyez, a munkamenet meghiúsulhat anélkül, hogy valaha elérné a továbbengedő szabályt. A sorrend valódi beállítás az NPS-en és a legtöbb hálózati hozzáférés-vezérlő terméken, és évek alatt elcsúszik.

A csoporttal együtt járó feltételek a másik fele. Az eszköz állapota, a hitelesítési módszer, a befejezett MFA, a forráshálózat, a tanúsítvány tárgya vagy egy időablak ugyanabban a szabályzatban lehet. Ha egyik nem teljesül, a szabályzat nem egyezik, a motor továbblép, és az alapértelmezett elutasítás érvényesül. A felhasználó helyéről úgy tűnik, mintha a csoportot figyelmen kívül hagynák; a motor helyéről a csoportot meg sem kérdezték.

A címtár részletei ugyanezt a látszatot keltik. A Windows-csoporttagságra illesztő szabályzat a felhasználó tokenjében lévő SID-okat olvassa, ott pedig csak biztonsági csoportok szerepelnek, terjesztési csoport soha nem jelenik meg. Az elsődleges csoport saját mezőjében utazik, nem a listában, ezért a rá rögzített szabályzat csendben meghiúsulhat.

Olvassa el az elfogadási vagy elutasítási rekordot, mielőtt csoporthoz nyúl

Először egy kérdés: eljutott-e a kérés egyáltalán a jogosítási szakaszba? Az NPS-en a válasz az eseménynaplóban van, ahol a 6272 megadott hozzáférést, a 6273 elutasítást, a 6274 pedig egy kérést rögzít, amelyet a kiszolgáló a szabályzat értékelése előtt eldobott. Ez a három szám három különböző vizsgálatra bontja a problémát, és csak az egyik szól csoportokról.

Ha a napló nem érhető el, kérdezze közvetlenül a kiszolgálót, és olvassa el a választ. A Filter-Id és alagút-attribútumok nélküli válasz azt jelenti, hogy a kiszolgáló a munkamenetet szokásosnak tartja, és az átjáró saját szabályait alkalmazza. A végrehajtási pont által nem támogatott attribútumokat tartalmazó válasz más hiba: a jogosítás átment, és az eszköz figyelmen kívül hagyta az eredményt.

radtest alice 'password' 10.0.0.5 0 testing123

Hasonlítsa a visszakapott attribútumokat azokhoz, amelyeket az átjáró dokumentál, ne ahhoz, amit a csoportnév sugall. Ez az összevetés általában elválasztja a szabályzatproblémát a végrehajtási problémától.

A csoportváltás nem visszamenőleges

A jogosítási attribútumok egyszer kerülnek visszaadásra, a munkamenet hitelesítésekor. Az átjáró a munkameneten tárolja őket, és nem olvassa újra a címtárat minden csomagnál, ezért a létrejött munkamenet tovább működik, miután valakit kivesz egy csoportból.

Ahhoz, hogy a változás érvényesüljön, új jogosítási döntés kell, nem csak friss kulcsok. Ahol a kiszolgáló támogatja az RFC 5176 dinamikus jogosítást, a UDP 3799-re küldött Disconnect-Request vagy CoA-Request újraértékelésre kényszeríti a munkamenetet; egyébként bontsa a kapcsolatot, és hagyja újracsatlakozni. Az újratárgyalás frissíti az alagút kulcsait, és rendszerint érintetlenül hagyja a jogosítási eredményt.

A feltételt javítsa, ne a csoportot

Ha tudja, melyik szabályzat lépett, a javítás rendszerint kicsi: rendezze át az elutasítást, amely elfedni a kívánt engedélyt, adja hozzá a hiányzó eszköz- vagy MFA-feltételt a szándékolt szabályzathoz, vagy írjon szűk szabályt az egy erőforrásra, ahelyett hogy a felhasználót tíz másikat hordozó csoportba emelné.

Rövid ciklus tartja őszintén a változást:

• Reprodukálja az elutasítást az eredeti fiókkal, és jegyezze fel az eseményazonosítót, mielőtt bármit módosít.
• Módosítson egy objektumot, szabályzatsorrendet, egy feltételt vagy egy csoportot, és jegyezze fel, melyiket.
• Nyisson új munkamenetet, erősítse meg, hogy az engedély megjelenik a naplóban, és hogy az erőforrás valóban megnyílik.
• Teszteljen egy felhasználót, akit még el kell utasítani, hogy a javítás ne szélesítse a szabályzatot véletlenül.

Ha az engedély helyes, és az erőforrás mégsem nyílik meg, a probléma átkerült az útválasztásra vagy a névfeloldásra abban a pillanatban, amikor a jogosítás átment. Tartsa külön a két hibát, és a következő jegy percekbe kerül, nem egy délutánba.