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 را برای هر کلاس حساب حفظ کنید، به جای اینکه حساب‌های محلی را از آن معاف کنید. اگر حساب‌های محلی مسیر بازیابی تأییدشده‌ای برای قطعی دایرکتوری فراهم می‌کنند، آن مسیر را به مدیران نام‌برده محدود کنید و آگاهانه اداره کنید، چون حساب اضطراری محلی برای هر کارمند یک سیستم احراز هویت دوم با نظارت ضعیف‌تر است.
دامنه کلاینت، منبع احراز هویت و دسترسی مؤثر را در یک رکورد بنویسید. مدیر بعدی آنگاه می‌تواند طرحی کارآمد از حساب‌های مختلط را بازتولید کند، به جای اینکه رشته‌های دامنه را امتحان کند تا ورود موفق شود.