شما یک اسکریپت client-connect اضافه می‌کنید که هر اتصالی را که در آن common_name با username تفاوت دارد رد می‌کند، و این مانند پیوندی میان یک گواهی و یک حساب به نظر می‌رسد. روی سروری که username-as-common-name در آن فعال است، این مقایسه تا زمان اجرای اسکریپت معنای خود را از دست داده است. هر دو مقدار همان رشته هستند، بنابراین آزمون برای گواهی‌ای که به شخصی کاملاً دیگر صادر شده هم قبول می‌شود.

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

آنچه به نظر می‌رسد مقایسه اثبات می‌کند

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

اینکه چنین باشد به یک گزینهٔ سرور بستگی دارد، و آن گزینه معمولاً به دلیلی نامرتبط روشن می‌شود، مثلاً ساده‌تر کردن نام‌گذاری فایل‌های پیکربندی برای هر کاربر.

username-as-common-name با نام چه می‌کند

وقتی username-as-common-name فعال است، OpenVPN پس از تأیید نام کاربری و گذرواژه، نام مشترک گواهی را با نام کاربری احرازشده جایگزین می‌کند. قلاب تأییدی که در طول آن بررسی اجرا می‌شود هنوز نام مشترک گواهی را دریافت می‌کند، چون جایگزینی هنوز رخ نداده است. همه‌چیز پس از آن، از جمله client-connect، نام کاربری را می‌بیند. پس فراخوانی بعدی یک هویت را دو بار دریافت می‌کند و نمی‌تواند آن را با گواهی ارائه‌شده مقایسه کند.

StageWhat common_name holds
Username and password verification hookThe certificate common name, for example bob-device
After the replacementThe authenticated account, alice
client-connect callbackThe account again, alice

یک اتصال نمونه را دنبال کنید: گواهی‌ای که برای bob-device صادر شده، ورود موفق به دایرکتوری با نام alice، و گزینهٔ فعال. مرحلهٔ تأیید هنوز می‌تواند دو رشتهٔ متفاوت ببیند. مرحلهٔ اتصال alice و alice را می‌بیند.

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

قاعده باید در مرحله‌ای اعمال شود که هویت گواهی و حساب را هم‌زمان می‌بیند

این کار در عمل یعنی قلاب تأیید نام کاربری و گذرواژه یا افزونه‌ای که همان‌جا بارگذاری می‌شود. افزونهٔ پشتیبانی‌شده‌ای که از قبل تأیید گذرواژه را انجام می‌دهد معمولاً جای درستی برای افزودن قاعدهٔ جفت‌سازی است، چون جایگزین کردن آن با مقایسهٔ نام‌ها، بررسی گذرواژه را کاملاً حذف می‌کند.

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

به یاد داشته باشید که این گزینه همچنین تغییر می‌دهد کدام پیکربندی برای هر کلاینت اعمال می‌شود، چون client-config-dir بر پایهٔ نام مشترک کلیدگذاری می‌شود.

جفت‌سازی را با دو اعتبارنامهٔ معتبر آزمایش کنید

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

مسیرهای گواهی غایب و گواهی نامعتبر را هم بررسی کنید و تأیید کنید سرور برای تنظیمات هر کلاینت از کدام هویت استفاده می‌کند. اگر تنها راه کار کردن مقایسه غیرفعال کردن username-as-common-name باشد، ابتدا هزینهٔ آن تغییر را حساب کنید، چون جست‌وجوی پیکربندی هر کلاینت را به نام گواهی بازمی‌گرداند.

مقالات مرتبط