اتصال مجدد به VPN ویندوز بدون گذاشتن رمز عبور در وظیفه

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

کنش وظیفه چه چیزی را خوانا باقی می‌گذارد

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

schtasks /query /tn "VPN Reconnect" /xml
cmdkey /list

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

کلید از پیش به اشتراک گذاشته‌شده ذخیره‌شده واقعاً چه می‌خرد

Add-VpnConnection -L2tpPsk کلید را در ورودی دفترچه تلفن اتصال می‌نویسد نه در یک وظیفه. این سطح مواجهه کوچک‌تری از کنش وظیفه است. با این حال رازی قابل بازیابی است، زیرا مدیر روی ماشین می‌تواند دفترچه تلفن را بخواند.

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

اعتبارنامه‌های Winlogon راز را حذف می‌کنند و وابستگی اضافه می‌کنند

-UseWinlogonCredential مسیر دیگری را در پیش می‌گیرد. اتصال احراز هویت می‌کند با MSCHAPv2 در برابر اعتبارنامه‌های کاربر واردشده. برای آن حساب چیز اضافه‌ای ذخیره نمی‌شود.

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

احراز هویت با گواهی مقیاس می‌پذیرد زیرا چیزی ذخیره نمی‌شود

جایی که سرور EAP-TLS را پشتیبانی می‌کند، گواهی ماشین راز مشترک را کاملاً حذف می‌کند و ابطال در لایه گواهی رخ می‌دهد. وظیفه‌ای که به صورت SYSTEM اجرا می‌شود می‌تواند آن گواهی را بدون ورود تعاملی ارائه دهد. پیش از ساختن بر آن تأیید کنید که سرور احراز هویت با گواهی را می‌پذیرد. طرحی که به روشی پشتیبانی‌نشده وابسته است برنامه است نه راه‌حل. سپس تصمیم بگیرید کلید خصوصی کجا زندگی می‌کند: انبار ماشین برای هویت دستگاه، انبار کاربر برای یک شخص.

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

پیش از چرخش بعدی مصنوعات را بررسی کنید

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

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