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 за секој клас сметки наместо да ги изземате локалните сметки од неа. Ако локалните сметки нудат одобрена патека за враќање при прекин на директориумот, ограничете ја таа патека на именувани администратори и водете ја намерно, бидејќи локална итна сметка за секој вработен е втор систем за автентикација со послаб надзор.
Запишете го доменот на клиентот, изворот на автентикација и ефективниот пристап во истиот запис. Следниот администратор тогаш може да репродуцира функционален дизајн на мешани сметки наместо да проба низи домени додека најавувањето не успее.