NetExtender уваходзіць, але доступу няма: SonicWall лакальны + LDAP
NetExtender падключаецца, але нішто не адказвае: аддзяліце аўтэнтыфікацыю SonicWall, сяброўства ў службе SSL VPN і дазволы доступу VPN для лакальных карыстальнікаў і карыстальнікаў LDAP.
Уваход паспяховы, тунель узнімаецца, і нішто за міжсеткавым экранам не адказвае. Гэты ўзор на SonicWall SSL VPN звычайна азначае, што ўліковы запіс прайшоў аўтэнтыфікацыю і спыніўся на адным з двух наступных дазволаў: допуску да службы SSL VPN або дазволу дасягнуць рэсурсу. Змешаныя лакальныя і LDAP-запісы пагаршаюць сітуацыю, бо два сховішчы дасягаюць гэтых дазволаў рознымі шляхамі. Сімптом аднолькавы з боку кліента, таму пласты трэба мэтанакіравана раздзяляць.
Сімптом і тры дазволы за ім
Паміж іменем карыстальніка і дасягальным серверам стаяць тры незалежныя рашэнні. Метад аўтэнтыфікацыі вырашае, ці будуць прыняты ўліковыя даныя і якім сховішчам. Сяброўства ў службе SSL VPN вырашае, ці можа гэтая асоба наогул карыстацца SSL VPN. Спіс доступу VPN вырашае, якія прыватныя прызначэнні сеанс можа дасягнуць. Праходжанне аднаго нічога не кажа пра наступныя два.
Карыстальнік, які аўтэнтыфікуецца, але не ўваходзіць у групу службы SSL VPN, бачыць злучэнне, якое ўстанаўліваецца і потым нічога не перадае, а журнал міжсеткавага экрана паказвае прыняты ўваход замест памылкі. Гэта выпадак, які варта хутка пазнаць, бо рашэнне — сяброўства ў групе, а не скід пароля.
Карыстальнік, які дапушчаны, але не мае рэсурсаў, бачыць сеанс, які падключаецца і нікуды карысна не маршрутызуе. Абодва выглядаюць як зламаны тунель з пункту гледжання службы падтрымкі, і абодва — гэта канфігурацыя, а не злучнасць.
Поле дамена — не каталог
NetExtender запытвае дамен, і гэтае поле не з'яўляецца базай пошуку для Active Directory. У стандартнай канфігурацыі поле павінна быць роўным дамену карыстальніка SSL VPN, які наладжаны на міжсеткавым экране, і дакументаванае значэнне па змаўчанні для яго LocalDomain. Параўнанне адрознівае вялікія і малыя літары, таму значэнне, уведзенае з іншым рэгістрам, не праходзіць, нават калі ўліковы запіс правільны.
Калі наладжана раздзяленне аўтэнтыфікацыі, назвы раздзелаў выбіраюць знешні кантэкст аўтэнтыфікацыі, а наладжанае значэнне па змаўчанні захоўвае сваю ролю. У абодвух варыянтах метка дамена на баку кліента не перадаецца ў LDAP або RADIUS як частка імені карыстальніка, таму яна не можа кіраваць пошукам у каталозе.
Трымайце тры радкі асобна ў нататках: суфікс DNS кампаніі, базу пошуку LDAP і метку дамена NetExtender. Яны выглядаюць падобна, і ніводзін не замяняе іншы. Капіруйце значэнне аператара для гэтай устаноўкі, а не значэнне з паведамлення на форуме пра іншую версію прашыўкі.
Допуск і доступ да рэсурсаў — асобныя дазволы
Лакальныя ўліковыя запісы патрабуюць сяброўства ў групе службы SSL VPN, перш чым служба іх прыме. Запісы каталога дасягаюць той жа групы праз падтрымліваемы працэс супастаўлення груп, гэта значыць сувязь групы LDAP трэба наладзіць і потым праверыць як эфектыўнае сяброўства, а не меркаваць з боку каталога.
Доступ да рэсурсаў ідзе далей, у раздзеле доступ VPN для карыстальніка або групы. Дайце канкрэтныя падсеткі і службы, якія патрэбныя ролі, і супрацьстойце спакусе даць усю LAN, бо патрэбна адна праграма. Маршруты сеансу, правілы доступу і дазволы службы прызначэння павінны ўсе адпавядаць гэтаму аб'ёму.
| Layer | What it decides | Where it is set |
|---|---|---|
| Authentication | Whether the credential is accepted, and by which store | Authentication method and directory configuration |
| Admission | Whether the identity may use the SSL VPN | SSL VPN service group membership |
| Resource | Which destinations the session may reach | VPN Access on the user or group |
Маршрут на кліенце робіць прызначэнне даступным для выбару і не дае на яго дазволу. Сяброўства ў групе SSL VPN таксама не робіць уліковы запіс адміністратарам міжсеткавага экрана, і не варта ставіцца да яго як да агульнай выдачи прывілеяў.
Дзве асобы, па чатыры праверкі
Тэстуйце з адным лакальным запісам і адным запісам каталога, абодва вузка аўтарызаваныя і абодва задокументаваныя як тэставыя. Для кожнага запішыце крыніцу аўтэнтыфікацыі, якая прыняла ўваход, эфектыўныя групы, прызначаны доступ да рэсурсаў і адну дазволеную аперацыю праграмы. Чатыры праверкі, два сховішчы і пісьмовы вынік для кожнай камбінацыі.
Затым праверце адмоўныя выпадкі: рэсурс, да якога запіс не павінен дасягаць, і запіс, які трэба адразу адхіліць. Дызайн, які даказвае толькі станоўчы шлях, схільны пакідаць адчыненым другі ўваход, асабліва калі тое ж кароткае імя карыстальніка існуе ў абодвух сховішчах. Адключыце запіс каталога і пераканайцеся, што лакальны не працягвае ціха працаваць.
Пераглядзіце дублікаты імёнаў як частку ўкаранення, а не пасля інцыдэнту. Адзін і той жа чалавек у двух сховішчах адначасова і зручнасць падтрымкі, і праблема аўдыту, а міжсеткавы экран ахвотна аўтэнтыфікуе той, які вы наладзілі.
Трымайце шлях аднаўлення вузкім
Захоўвайце палітыку MFA для кожнага класа запісаў, замест таго каб вызваляць ад яе лакальныя запісы. Калі лакальныя запісы даюць зацверджаны шлях аднаўлення на выпадак збою каталога, абмяжуйце гэты шлях названымі адміністратарамі і весціце яго свядома, бо лакальны аварыйны запіс для кожнага супрацоўніка — другая сістэма аўтэнтыфікацыі з больш слабым наглядам.
Запішыце дамен кліента, крыніцу аўтэнтыфікацыі і эфектыўны доступ у адзін запіс. Наступны адміністратар зможа тады ўзнавіць працоўны дызайн змешаных запісаў, замест таго каб перабіраць радкі даменаў, пакуль уваход не ўдасца.