آن کادر انتخاب در صفحه ورود مثل یک ترجیح مشتری به نظر می‌رسد، اما روی یک دستگاه مدیریت‌شده غالباً به‌جای آن یک تصمیم خط‌مشی است. کنترل به‌خاطرسپاری Viscosity وقتی استقرار ذخیره‌سازی را مجاز می‌داند، اعتبارنامه را در جاکلیدی macOS ذخیره می‌کند. افسانه این است که کادر انتخاب همیشه در اختیار شماست. در عمل سه چیز جداگانه می‌تواند آن را مسدود کند و تنها یکی از آن‌ها به رمز عبور مربوط است.

کادر انتخاب واقعاً چه چیزی ذخیره می‌کند

انتخاب گزینه به‌خاطرسپاری از مشتری می‌خواهد مقدار را برای همان یک اتصال و حساب نگه دارد. مورد در جاکلیدی قرار می‌گیرد و ورودهای بعدی آن را از طریق درخواست پشتیبانی‌شده و نه از طریق یک ترجیح پنهان دوباره استفاده می‌کنند. چیزی در خود فایل اتصال نوشته نمی‌شود. همین جداسازی دلیل آن است که حذف مورد در آینده یک درخواست تولید می‌کند و نه یک نمایه خراب.

مقدار ذخیره‌شده ورودی‌ای برای احراز هویتی است که سرور به‌هرحال انجام می‌داد. چیزی را که دروازه می‌خواهد تغییر نمی‌دهد، از عامل دوم عبور نمی‌کند و کد یک‌بارمصرف را به رازی قابل استفاده مجدد تبدیل نمی‌کند. چیزی که کوتاه می‌کند تایپ است، نه خط‌مشی‌ای که استقرار روی آن حساب اعمال می‌کند.

چرا ممکن است کنترل غایب باشد

مدیر می‌تواند ذخیره اعتبارنامه را برای یک نصب مدیریت‌شده غیرفعال کند و SparkLabs کنترل به‌خاطرسپاری را همراه با رفتار جاکلیدی آن در راهنمای ذخیره اعتبارنامه مستند می‌کند. وقتی کادر انتخاب غایب است، خراب نیست و جست‌وجوی یک فرمان ترجیحات که آن را نادیده بگیرد پاسخ اشتباه است.

به‌جای آن از مالک بپرسید کدام گردش‌کار پشتیبانی‌شده اعمال می‌شود. استقراری که ذخیره‌سازی را ممنوع می‌کند معمولاً دلیلی دارد و دلیل غالباً این است که حساب مشترک است، دستگاه مورد اعتماد نیست یا اعتبارنامه قرار است طبق برنامه منقضی شود. دور زدن تنظیم، یک کنترل عمدی را به حادثه تبدیل می‌کند و حادثه معمولاً با ممیزی شخص دیگری ضمیمه می‌رسد.

در یک نصب مدیریت‌نشده، کنترل غایب یک پرسش پشتیبانی با شماره نسخه است. نسخه نصب‌شده مشتری و آنچه درخواست واقعاً نشان می‌دهد را بفرستید، نه حدس درباره پیش‌فرض‌های پنهان.

سه درخواست که یک درخواست نیستند

کد یک‌بارمصرف رمز عبور نیست، رمز عبور مجوز جاکلیدی نیست و رد سرور هیچ‌یک از این سه نیست. اشتباه گرفتن آن‌ها خرابی‌هایی تولید می‌کند که مثل اعتبارنامه اشتباه خوانده می‌شوند، در حالی که مشکل واقعی یک فیلد، یک گفت‌وگو یا یک مسیر است.

گفت‌وگوی جاکلیدی طبق طراحی محلی است. می‌پرسد آیا این برنامه می‌تواند این مورد را روی این دستگاه بخواند و تأیید آن چیزی به سرور VPN نمی‌گوید.

به همین دلیل رد کردن گفت‌وگو خرابی سمت مشتری تولید می‌کند که سرور هرگز آن را نمی‌بیند، در حالی که رمز عبور اشتباه رد سمت سرور تولید می‌کند که مشتری فقط می‌تواند آن را گزارش کند. پیش از پاسخ دادن گفت‌وگو را بخوانید و بررسی کنید که برنامه درخواست‌کننده همان مشتری مورد انتظار است و نه یک نصب‌کننده یا یک فرایند کمکی. این تمایز بیشترین اهمیت را روی دستگاه‌های مشترک دارد، جایی که ممکن است بیش از یک حساب به مورد دسترسی داشته باشد.

عامل دوم بیرون از همه این‌ها می‌ایستد. ذخیره رمز عبور کد را ذخیره نمی‌کند و استقراری که کد را می‌خواهد همچنان آن را در هر اتصال می‌خواهد. آن مرحله را هنگام آزمایش قابل مشاهده نگه دارید، زیرا جریانی که بی‌صدا از آن می‌گذرد جریانی نیست که پیکربندی کرده‌اید.

بازیابی یک اعتبارنامه بدون بازنشانی بقیه

اگر احراز هویت پس از تغییر رمز عبور شکست خورد، به‌جای ویرایش دستی جاکلیدی از مسیر مستند درخواست مجدد و به‌روزرسانی مشتری برای همان یک اتصال استفاده کنید. پیش از جایگزینی هر چیزی پیام را بخوانید، زیرا مهلت تمام‌شده، رد گواهی یا مسیر غایب با بازنویسی یک رمز عبور ذخیره‌شده ترمیم نمی‌شود. انجام مکرر آن بیشتر شما را به نادیده گرفتن خطایی که مشتری نشان می‌دهد عادت می‌دهد. اعتبارنامه متأثر را به‌روزرسانی کنید، سپس دوباره متصل شوید و ببینید کدام درخواست ظاهر می‌شود.

بازنشانی کامل جاکلیدی که انجمن‌های پشتیبانی پیشنهاد می‌کنند تغییری بسیار بزرگ‌تر از مشکل است. رمز عبور ذخیره‌شده یک اتصال هیچ ارتباطی با گواهی اتصال دیگر ندارد و پاک کردن همه چیز یک مورد کهنه را به یک بعدازظهر ثبت‌نام دوباره تبدیل می‌کند.

با قطع و اتصال دوباره از طریق کنترل‌های عادی تمام کنید و تأیید کنید که حساب موردنظر استفاده می‌شود و حذف مورد ذخیره‌شده درخواست تولید می‌کند و نه خرابی. استفاده مجدد قابل پیش‌بینی با یک روش روشن برای به‌روزرسانی یا حذف اعتبارنامه نتیجه‌ای است که ارزش آزمایش دارد.

مقالات مرتبط