Додавањето корисник во VPN група само по себе не дава пристап
Членството во група е еден услов, а не дозвола. Погледнете што портата навистина спореди, прочитајте го записот за прифаќање или одбивање и тестирајте ги двата исхода.
Сметката е во вистинската група, најавувањето успеа, а врската сè уште се одбива или се воспоставува и не стигнува до ништо корисно. Обичната реакција е да се додаде корисникот во повеќе групи додека нешто не попушти, и така организациите даваат многу повеќе отколку што бара тикетот. Членството во група е еден влез во одлуката за авторизација, никогаш самата одлука: портата собира факти за сесијата, ги споредува со подредена политика и дури потоа одлучува. Ако пропаднал друг услов, менувањето на групата менува само вашата изложеност.
Членството во група е услов, а не дозвола
Во RADIUS групата доаѓа како атрибут за авторизација, а атрибутите ја опишуваат сесијата наместо да ја дозволуваат. Серверот одговара со Access-Accept или Access-Reject; при прифаќање може да додаде Filter-Id, Class или тунелските атрибути од RFC 2868, а мрежната опрема од другата страна ги толкува како што одлучил производителот. Ништо во протоколот не пресликува група во целосен пристап; тоа пресликување го пишува оној што ја поставил политиката на портата или мрежниот пристапен сервер.
Затоа истото име на група се однесува различно на два система. Microsoft NPS составува мрежни политики од услови, ограничувања и поставки и ги оценува по определен ред. OpenVPN Access Server има свој модел на групи и правила за пристап, додека заедничкиот OpenVPN сервер често сето прашање го препушта на client-connect скрипта или на client-config-dir датотека.
Одлучува правилото што се совпаднало, не групата што сте ја очекувале
Повеќето машини застануваат на првата политика што се совпаѓа или на најконкретната. Ако политиката 3 одбива, а политиката 7 дозволува, сесијата може да пропадне без никогаш да стигне до правилото што би ја пропуштило. Редот е вистинска поставка на NPS и на повеќето производи за контрола на мрежниот пристап.
Условите што одат со групата се другата половина. Состојбата на уредот, методот на автентикација, завршената MFA, изворната мрежа, субјектот на сертификатот или временскиот прозорец може да бидат во истата политика. Ако еден не е исполнет, политиката не се совпаѓа, машината паѓа и се применува стандардното одбивање.
Деталите од директориумот ја создаваат истата илузија. Политиката што се совпаѓа по членство во Windows групи ги чита SID во токенот, а таму се наведени само безбедносни групи, дистрибутивна група никогаш не се појавува. Примарната група се носи во свое поле, не во списокот, па политиката врзана за неа може тивко да пропадне.
Прочитајте го записот за прифаќање или одбивање пред да допрете група
Прво едно прашање: дали барањето воопшто стигна до фазата на авторизација? На NPS одговорот е во дневникот на настани, каде 6272 запишува дозволен пристап, 6273 одбивање, а 6274 барање што серверот го отфрлил пред оценување на политиката. Тие три броја го делат проблемот на три различни истраги, а само една е за групи.
| 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 |
Кога дневникот не е достапен, прашајте го серверот директно и прочитајте што враќа. Одговор без Filter-Id и без тунелски атрибути значи дека серверот сесијата ја смета за обична и портата применува свои правила. Одговор со атрибути што точката за спроведување не ги применува е друга грешка: авторизацијата помина, а уредот го игнорираше резултатот.
radtest alice 'password' 10.0.0.5 0 testing123
Споредете ги вратените атрибути со оние што портата ги документира, не со она што го сугерира името на групата. Таа споредба обично го дели проблемот со политиката од проблемот со спроведувањето.
Промената на група не делува наназад
Атрибутите за авторизација се враќаат еднаш, при автентикација на сесијата. Портата ги чува на сесијата и не го препрочитува директориумот за секој пакет, затоа воспоставената сесија продолжува да работи и откако некој ќе биде отстранет од група.
За промената да стапи на сила треба нова одлука за авторизација, не само нови клучеви. Каде серверот поддржува RFC 5176 динамична авторизација, Disconnect-Request или CoA-Request на UDP 3799 присилува повторна оценка; инаку исклучете го клиентот и оставете го повторно да се поврзе. Преговарањето ги освежува тунелските клучеви и обично не го чепка резултатот.
Поправете го условот, не групата
Кога знаете која политика делувала, поправката обично е мала: преуредете одбивање што го засенува посакуваното дозволување, додајте го условот за уред или MFA во политиката што ја мислевте, или напишете тесно правило за еден ресурс наместо да го подигнете корисникот во група со уште десет.
Краток циклус ја чува промената искрена:
- Репродуцирајте го одбивањето со првобитната сметка и запишете го ID на настанот пред да смените нешто.
- Сменете еден објект, ред на политики, еден услов или една група, и запишете која.
- Отворете нова сесија, потврдете дека дозволувањето се гледа во дневникот и дека ресурсот навистина се отвора.
- Тестирајте корисник што треба сè уште да биде одбиен, за поправката да не ја прошири политиката случајно.
Ако дозволувањето е точно, а ресурсот не се отвора, проблемот се преселил на рутирање или разрешување имиња во моментот кога авторизацијата помина. Држете ги двете грешки одвоени и следниот тикет ќе трае минути, не попладне.