Přidání uživatele do skupiny VPN samo o sobě přístup nedá
Členství ve skupině je jedna podmínka, ne oprávnění. Podívejte se, co brána skutečně porovnala, přečtěte si záznam o přijetí nebo odmítnutí a otestujte oba výsledky.
Účet je ve správné skupině, přihlášení prošlo, a spojení je přesto odmítnuto, nebo se naváže a nedostane se k ničemu užitečnému. Běžná reakce je přidávat uživatele do dalších skupin, dokud něco nepovolí, a tak organizace udělují mnohem víc práv, než žádal tiket. Členství ve skupině je jeden vstup do rozhodnutí o autorizaci, nikdy rozhodnutí samo: brána posbírá několik faktů o relaci, porovná je s uspořádanou politikou a teprve pak rozhodne, na co relace smí dosáhnout. Pokud selhala jiná podmínka, změna skupiny nezmění nic kromě vaší expozice.
Členství ve skupině je podmínka, ne oprávnění
V RADIUS přichází skupina jako autorizační atribut a atributy relaci popisují, místo aby ji povolovaly. Server odpovídá Access-Accept nebo Access-Reject; při přijetí může přiložit Filter-Id, Class nebo tunelové atributy z RFC 2868 a síťové zařízení na druhé straně je vykládá podle rozhodnutí výrobce. Nic v protokolu nepřevádí skupinu na plný přístup; toto mapování píše ten, kdo nastavil politiku na bráně nebo na serveru síťového přístupu, a může být úzké jako jediný hostitel.
Proto se stejný název skupiny chová na dvou systémech jinak. Microsoft NPS skládá síťové politiky z podmínek, omezení a nastavení a vyhodnocuje je v daném pořadí. OpenVPN Access Server má vlastní model skupin a pravidel přístupu, zatímco komunitní server OpenVPN často celou otázku předává skriptu client-connect nebo souboru v client-config-dir. Každý spotřebovává skupinu; žádný nesdílí logiku priorit druhého.
Rozhoduje pravidlo, které se shodovalo, ne skupina, kterou jste čekali
Většina strojů se zastaví u první shodné politiky nebo u nejkonkrétnější. Pokud politika 3 odmítá a politika 7 povoluje, relace může selhat, aniž by se kdy dostala k pravidlu, které by ji pustilo. Pořadí je skutečné nastavení na NPS a většině produktů pro řízení síťového přístupu a během let se posouvá.
Podmínky, které jdou se skupinou, jsou druhá polovina. Stav zařízení, metoda ověření, dokončené MFA, zdrojová síť, subjekt certifikátu nebo časové okno mohou být ve stejné politice. Když jedna z nich není splněna, politika se neshoduje, stroj propadne a platí výchozí odmítnutí. Z pohledu uživatele to vypadá, že se skupina ignoruje; z pohledu stroje se skupina vůbec neptala.
Detaily z adresáře vytvářejí stejnou iluzi. Politika, která porovnává členství ve skupinách Windows, čte SID v tokenu uživatele, a tam se vypisují jen skupiny zabezpečení, distribuční skupina se nikdy neobjeví. Primární skupina se nese ve vlastním poli, ne v seznamu, takže politika na ni navázaná může tiše selhat.
Přečtěte si záznam o přijetí nebo odmítnutí, než se skupiny dotknete
Nejprve jedna otázka: dostal se požadavek vůbec do fáze autorizace? Na NPS je odpověď v protokolu událostí, kde 6272 zaznamenává povolený přístup, 6273 odmítnutí a 6274 požadavek, který server zahodil před vyhodnocením politiky. Ta tři čísla dělí problém na tři různá vyšetřování a jen jedno z nich je o skupinách.
| 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 |
Když je protokol nedostupný, zeptejte se serveru přímo a přečtěte, co vrací. Odpověď bez Filter-Id a bez tunelových atributů říká, že server považuje relaci za běžnou a brána uplatňuje vlastní pravidla. Odpověď s atributy, které vynucovací bod neimplementuje, je jiná závada: autorizace prošla a zařízení výsledek ignorovalo.
radtest alice 'password' 10.0.0.5 0 testing123Porovnejte vrácené atributy s těmi, které brána dokumentuje, ne s tím, co naznačuje název skupiny. Toto srovnání obvykle oddělí problém politiky od problému vynucení.
Změna skupiny neplatí zpětně
Autorizační atributy se vracejí jednou, při ověření relace. Brána je uchovává u relace a nečte adresář znovu pro každý paket, proto zavedená relace běží dál poté, co někoho odeberete ze skupiny, a nová může selhat, dokud stará ještě žije.
Aby se změna projevila, potřebujete nové rozhodnutí o autorizaci, ne jen nové klíče. Kde server podporuje dynamickou autorizaci RFC 5176, vynutí Disconnect-Request nebo CoA-Request na UDP 3799 nové vyhodnocení relace; jinak klienta odpojte a nechte ho připojit znovu. Opětovné vyjednání obnoví tunelové klíče a výsledek autorizace obvykle nechá nedotčený.
Opravte podmínku, ne skupinu
Když víte, která politika zabrala, je oprava obvykle malá: přeřaďte odmítnutí, které zastiňuje zamýšlené povolení, doplňte chybějící podmínku zařízení nebo MFA do politiky, kterou jste mysleli, nebo napište úzké pravidlo pro jeden zdroj, místo abyste uživatele povýšili do skupiny s deseti dalšími.
Krátká smyčka drží změnu poctivou:
- Reprodukujte odmítnutí s původním účtem a zapište ID události, než cokoli změníte.
- Změňte jeden objekt, pořadí politik, jednu podmínku nebo jednu skupinu, a poznamenejte kterou.
- Otevřete novou relaci, potvrďte, že se povolení objeví v protokolu, a že se zdroj skutečně otevře.
- Otestujte uživatele, který má být stále odmítán, aby oprava politiku omylem nerozšířila.
Pokud je povolení správné a zdroj se přesto neotevře, problém se přesunul na směrování nebo překlad jmen v okamžiku, kdy autorizace prošla. Držte ty dvě závady oddělené a další tiket zabere minuty, ne odpoledne.