Добавянето на потребител към 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-овете в токена на потребителя, а там се изброяват само групи за сигурност — група за разпространение никога не се появява. Основната група на потребителя се носи в отделно поле, а не в изброения списък, така че политика, вързана към тази група, може да се провали безшумно. Преименуваните групи и 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 към политиката, която сте имали предвид, или напишете тясно правило за конкретния ресурс, вместо да вдигате потребителя в група, която носи още десет. Разширяването на членството, за да се затвори заявка, е скъпата версия на същата поправка и така един бърз ход от поддръжката се превръща в постоянно изключение, което никой не преглежда.
Кратък цикъл държи промяната честна:
- Възпроизведете отказа с оригиналния акаунт и запишете номера на събитието, преди да промените каквото и да е.
- Променете един обект — ред на политика, едно условие или една група — и запишете кой.
- Отворете нова сесия, потвърдете, че разрешението се появява в журнала, и потвърдете, че ресурсът наистина се отваря.
- Тествайте потребител, който все още трябва да бъде отказан, за да не е разширила поправката политиката случайно.
Ако разрешението е правилно, а ресурсът все още не се отваря, проблемът се премести в маршрутизацията или в разрешаването на имена в момента, в който авторизацията мина. Дръжте тези две повреди разделени и следващата заявка ще отнеме минути, вместо цял следобед.