مهاجرت بک‌اند احراز هویت VPN بدون استفاده مجدد از هش‌های قدیمی
جابه‌جایی هویت‌های VPN یک برش است، نه رونوشت: زنجیره احراز هویت را ترسیم کنید، یک گروه آزمایشی را منتقل کنید، تغییرات اعتبارنامه‌ها را بیازمایید و بازیابی‌ای برنامه‌ریزی کنید که بازنشانی آن را باطل نمی‌کند.
نام‌های کاربری در دایرکتوری جدید ظاهر می‌شوند، مهاجرت پایان‌یافته اعلام می‌شود و ورودها همچنان شکست می‌خورند. دروازه هنوز به مسیر احراز هویت پشتیبانی‌شده و نتیجه مجوزدهی درست نیاز دارد و هیچ‌کدام از دایرکتوری‌ای که اکنون حساب‌ها را دارد برنمی‌آید. جابه‌جایی بک‌اند یک برش با چرخه عمر است، نه کار رونوشت. نشانه زیر همانی است که معمولاً تفاوت را آشکار می‌کند.
نشانه: حساب‌ها هستند، نشست‌ها نیستند
دایرکتوری جدید هر نام کاربری را دارد، یک اتصال آزمایشی موفق می‌شود و کلاینت VPN همچنان خطای احراز هویت برمی‌گرداند. این ترکیب یعنی هویت وجود دارد، اما مسیر بررسی‌ای که دروازه استفاده می‌کند به آن نمی‌رسد یا با روشی می‌رسد که نمی‌تواند برآورده کند. هر دو پیکربندی‌اند و دو مسئله متفاوت‌اند.
اولی سیم‌کشی است: دروازه به بک‌اندی اشاره می‌کند که پاسخ نمی‌دهد، از راز مشترکی استفاده می‌کند که طرف مقابل انتظارش را ندارد، یا ویژگی‌ای می‌خواهد که سرویس جدید برنمی‌گرداند. دومی رمزنگاری است: روش به راز اصلی نیاز دارد و مخزن جدید فقط هش آن را نگه می‌دارد. متن خطا در هر دو حالت شبیه است، از این رو این دو یک مسئله تلقی می‌شوند.
جدا کردن این دو پیش از دست زدن به حساب‌ها یک هفته صرفه‌جویی می‌کند. یکی پرسش مسیریابی و اعتماد است، دیگری تصمیم درباره بازنشانی اعتبارنامه‌ها، و آمیختن‌شان تغییراتی می‌سازد که هیچ‌کس نمی‌تواند به چیزی نسبت دهد.
پیش از جابه‌جایی هر کس، زنجیره را ترسیم کنید
برای هر نمایه کلاینت شش چیز بنویسید: روش احراز هویت بیرونی، هر روش درونی، هویت سروری که کلاینت انتظار دارد، رابط میان دروازه و بک‌اند، ویژگی‌ای که دروازه به عضویت گروه نگاشت می‌کند و سیاست منابعی که از آن برمی‌آید. خواندن‌شان به ترتیب نشان می‌دهد کدام حلقه صاحب ندارد. هر بند مسئولی دارد و برش در همان‌جایی شکست می‌خورد که کسی بررسی نکرده است.
| Link | Question it answers |
|---|---|
| Client profile | Which method and server name does the client use? |
| Inner method | Is there a second authentication step? |
| Server identity | Which certificate or name must the client accept? |
| Gateway to backend | Which protocol, port and shared secret? |
| Attribute mapping | Which returned value becomes group membership? |
| Resource policy | What the resulting session may reach |
ورود معمولی به دایرکتوری تقریباً هیچ‌چیز از آن زنجیره را نمی‌پیماید. ثابت می‌کند حساب وجود دارد و گذرواژه کار می‌کند، یعنی همان بخشی که هرگز محل تردید نبود.
هش‌ها میان روش‌ها سفر نمی‌کنند
سازگاری اعتبارنامه‌ها باید یک بار بررسی شود، پیش از آنکه هیچ گروهی جابه‌جا شود. FreeRADIUS جداسازی را روشن مستند می‌کند: بررسی CHAP که سرور خود انجام می‌دهد به گذرواژه واقعی نیاز دارد و MS-CHAP همان گذرواژه یا مواد NT مناسب را می‌پذیرد. هشی که برای هدف دیگری ساخته شده با هیچ‌یک از دو حالت جور درنمی‌آید، هر قدر هم قوی باشد.
تفاوت در این است که چه کسی اثبات را محاسبه می‌کند. روشی که با پیوند به دایرکتوری بررسی می‌کند می‌گذارد دایرکتوری آنچه را می‌تواند بررسی کند. روشی که با بازمحاسبه پاسخ چالش بررسی می‌کند خود راز را نیاز دارد، چون سرور باید همان محاسبه را انجام دهد.
آنجا که مواد نیست، گزینه‌های صادقانه بازنشانی پشتیبانی‌شده، ثبت‌نام دوباره، سرویس بررسی بیرونی یا تغییر روش است. برون‌بر موقت گذرواژه‌های بازیابی‌پذیر در آن فهرست نیست. مخزنی از اعتبارنامه‌ها به متن روشن در آشفته‌ترین هفته پروژه می‌سازد و معمولاً از مهاجرت جان به در می‌برد.
گروه آزمایشی، سپس تغییرات چرخه عمر
گروه کوچکی از هویت‌های تأییدشده را با کلاینت واقعی جابه‌جا کنید و چهار چیز را بیازمایید: ورود تازه، اعتبارنامه عمداً نادرست، منابعی که نشست می‌تواند به آن‌ها برسد و منابعی که نباید. هویت سروری را هم که کلاینت پذیرفته بررسی کنید، چون ناسازگاری نام گواهی تا کسی گزارش کلاینت را نخواند نامرئی است.
سپس تغییراتی را تمرین کنید که استقرار واقعاً به آن‌ها وابسته است. گذرواژه‌ای را عوض کنید، گواهی را تمدید یا دوباره ثبت کنید و دسترسی یک حساب آزمایشی را بردارید. پس از هر یک تأیید کنید کدام تأییدکننده درخواست را پردازش کرده، چون نشستی که پیش از برش ساخته شده ممکن است کار کند و چیزی درباره ورود بعدی ثابت نمی‌کند.
تحویل نمایه را از تعویض هویت جدا کنید. هر گروه به نمایه مقصودش، وضعیت اعتبارنامه یا ثبت‌نامش، سرویس احراز هویتی که باید به کار ببرد و یک تماس پشتیبانی نیاز دارد و هیچ‌یک از این سوابق نباید راز داشته باشد.
اگر مسیرهای قدیمی و جدید هم‌زمان وجود دارند، آن‌ها را با تاریخ پایان محدود کنید. بازگشت خودکار می‌تواند حسابی را با اعتبارنامه قدیمی وارد کند پس از آنکه مالک جدید دسترسی را برداشته، و این یک پسرفت امنیتی به‌ظاهر دسترس‌پذیری است.
بازگشت نمی‌تواند اعتبارنامه را بازگرداند
وارونه کردن برش دایرکتوری را دقیقاً همان‌گونه که اکنون هست باقی می‌گذارد. گذرواژه بازنشانی‌شده بازنشانی‌شده می‌ماند، گواهی باطل‌شده باطل می‌ماند و قالب اعتبارنامه تغییریافته تغییرکرده می‌ماند. این‌ها رویدادهایی در دایرکتوری‌اند و دروازه هرگز منبعشان نبوده است. بازیابی باید برای هر رویداد تعریف شود و هیچ بخشی از آن نمی‌تواند به بازسازی راز از هشی ناسازگار وابسته باشد.
مسیر مدیریتی‌ای نگه دارید که از اتصال در حال مهاجرت استفاده نکند. وقتی احراز هویت جدید شکست می‌خورد، گروه را متوقف کنید و از مسیر بازیابی مستندش استفاده کنید، نه اینکه برای رسیدن به مهلت احراز هویت را برای همه تضعیف کنید.
پس از پوشش گروه‌ها، اعتبارنامه‌ها، نمایه‌ها و روابط اعتماد قدیمی بک‌اند را از راه مالکانشان کنار بگذارید. تأیید کنید که مسیر قدیمی دیگر کاربران را راه نمی‌دهد و نگاشت هویت به سیاست بدون راز را که پشتیبانی هنوز لازم دارد نگه دارید. مهاجرت وقتی کامل است که چرخه عمر جدید کار کند و هیچ‌کس دیگر از مسیر قدیمی وارد نشود، نه وقتی فهرست حساب‌ها کامل به نظر برسد.