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