NetExtender tizimga kiradi, lekin kirish yo'q: SonicWall mahalliy + LDAP
NetExtender ulanadi, lekin hech narsa javob bermaydi: SonicWall autentifikatsiyasi, SSL VPN xizmatiga a'zolik va mahalliy hamda LDAP foydalanuvchilari uchun VPN kirish ruxsatlarini ajratib ko'ring.
Tizimga kirish muvaffaqiyatli bo'ladi, tunnel ko'tariladi va xavfsizlik devori orqasidagi hech narsa javob bermaydi. SonicWall SSL VPN dagi bunday holat odatda hisob autentifikatsiyadan o'tganini va keyingi ikkita ruxsatdan birida to'xtaganini bildiradi: SSL VPN xizmatiga qabul qilinish yoki resursga yetib borish ruxsati. Aralash mahalliy va LDAP hisoblari vaziyatni yomonlashtiradi, chunki ikki ombor bu ruxsatlarga turli yo'llar bilan erishadi. Alomat mijoz tomondan bir xil, shuning uchun qatlamlarni ataylab ajratish kerak.
Alomat va uning orqasidagi uchta ruxsat
Foydalanuvchi nomi va yetib boriladigan server o'rtasida uchta mustaqil qaror turadi. Autentifikatsiya usuli hisob ma'lumotlari qabul qilinishini va qaysi ombor tomonidan qabul qilinishini hal qiladi. SSL VPN xizmatiga a'zolik bu shaxsning umuman SSL VPN dan foydalana olishini hal qiladi. VPN kirish ro'yxati sessiya qaysi xususiy manzillarga yetib borishini hal qiladi. Bittasidan o'tish keyingi ikkitasi haqida hech narsa demaydi.
Autentifikatsiyadan o'tgan, lekin SSL VPN xizmat guruhida bo'lmagan foydalanuvchi o'rnatiladigan va keyin hech narsa tashimaydigan ulanishni ko'radi, xavfsizlik devori jurnali esa xato o'rniga qabul qilingan kirishni ko'rsatadi. Bu tez tanib olinishi kerak bo'lgan holat, chunki yechim guruhga a'zolik, parolni tiklash emas.
Qabul qilingan, lekin resurslari bo'lmagan foydalanuvchi ulanadigan va foydali hech qayerga yo'naltirmaydigan sessiyani ko'radi. Ikkalasi ham yordam stolidan buzilgan tunnel kabi ko'rinadi va ikkalasi ham ulanish emas, konfiguratsiya.
Domen maydoni katalog emas
NetExtender domen so'raydi va bu maydon Active Directory uchun qidiruv bazasi emas. Standart tuzilmada maydon xavfsizlik devori sozlagan SSL VPN foydalanuvchi domeniga teng bo'lishi kerak va buning uchun hujjatlashtirilgan standart qiymat LocalDomain. Taqqoslash katta-kichik harflarni farqlaydi, shuning uchun boshqa harf kattaligida kiritilgan qiymat hisob to'g'ri bo'lsa ham muvaffaqiyatsiz bo'ladi.
Autentifikatsiya bo'linishi sozlangan bo'lsa, bo'linma nomlari tashqi autentifikatsiya kontekstini tanlaydi va sozlangan standart o'z rolini saqlaydi. Ikkala tuzilmada ham mijoz tomonidagi domen yorlig'i foydalanuvchi nomining bir qismi sifatida LDAP yoki RADIUS ga uzatilmaydi, shuning uchun u katalog qidiruvini boshqara olmaydi.
Uchta satrni yozuvlaringizda alohida saqlang: kompaniyaning DNS qo'shimchasi, LDAP qidiruv bazasi va NetExtender domen yorlig'i. Ular bir-biriga o'xshaydi va hech biri boshqasini almashtirmaydi. Ushbu o'rnatish uchun operatorning qiymatini ko'chiring, boshqa proshivka versiyasi haqidagi forum xabaridagi qiymatni emas.
Qabul va resursga kirish alohida ruxsatlardir
Mahalliy hisoblar xizmat ularni qabul qilishidan oldin SSL VPN xizmat guruhiga a'zo bo'lishi kerak. Katalog hisoblari qo'llab-quvvatlanadigan guruh xaritalash ish oqimi orqali o'sha guruhga erishadi, ya'ni LDAP guruh munosabati sozlanishi va keyin katalog tomonidan taxmin qilinmasdan, samarali a'zolik sifatida tekshirilishi kerak.
Resursga kirish keyin keladi, foydalanuvchi yoki guruhdagi VPN kirish ostida. Rolga kerak bo'lgan aniq pastki tarmoqlar va xizmatlarni bering va bitta dastur kerakligi uchun butun LAN ni berish qisqa yo'liga qarshi turing. Sessiya yo'llari, kirish qoidalari va manzil xizmati ruxsatlari bu qamrovga mos bo'lishi kerak.
| 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 |
Mijozdagi yo'l manzilni tanlanadigan qiladi va unga ruxsat bermaydi. SSL VPN guruhiga a'zolik ham hisobni xavfsizlik devori administratoriga aylantirmaydi va uni umumiy imtiyoz berish sifatida ko'rib chiqmaslik kerak.
Ikki shaxs, har biriga to'rtta tekshiruv
Bitta mahalliy hisob va bitta katalog hisobi bilan sinab ko'ring, ikkalasi ham tor vakolatli va ikkalasi ham sinov hisobi sifatida hujjatlashtirilgan. Har biri uchun kirishni qabul qilgan autentifikatsiya manbasini, samarali guruhlarni, tayinlangan resurs kirishini va ruxsat etilgan bitta dastur amalini qayd eting. To'rtta tekshiruv, ikki ombor va har bir kombinatsiya uchun yozma natija.
Keyin salbiy holatlarni sinab ko'ring: hisob yetib bormasligi kerak bo'lgan resurs va darhol rad etilishi kerak bo'lgan hisob. Faqat ijobiy yo'lni isbotlaydigan dizayn, ayniqsa bir xil qisqa foydalanuvchi nomi ikkala omborda mavjud bo'lsa, ikkinchi kirishni ochiq qoldirishga moyil. Katalog hisobini o'chiring va mahalliy hisob jimgina ishlashda davom etmasligini tasdiqlang.
Takroriy nomlarni hodisadan keyin emas, joriy etishning bir qismi sifatida ko'rib chiqing. Bir odamning ikki omborda bo'lishi bir vaqtning o'zida ham qo'llab-quvvatlash qulayligi, ham audit muammosidir va xavfsizlik devori siz sozlagan variantni mamnuniyat bilan autentifikatsiya qiladi.
Tiklash yo'lini tor tuting
Mahalliy hisoblarni undan ozod qilish o'rniga har bir hisob sinfi uchun MFA siyosatini saqlang. Agar mahalliy hisoblar katalog uzilishi uchun tasdiqlangan tiklash yo'lini taqdim etsa, bu yo'lni nomlangan administratorlar bilan cheklang va uni ataylab boshqaring, chunki har bir xodim uchun mahalliy favqulodda hisob zaifroq nazoratga ega ikkinchi autentifikatsiya tizimidir.
Mijoz domenini, autentifikatsiya manbasini va samarali kirishni bir xil yozuvga yozing. Keyingi administrator kirish muvaffaqiyatli bo'lguncha domen satrlarini sinab ko'rish o'rniga ishlaydigan aralash hisob dizaynini takrorlay oladi.