طراحی قالب‌های AD CS برای نقش‌های دروازه VPN و کلاینت
یک قالب تنها زمانی هویت‌های متعدد صادر می‌کند که با نقش طرف مقابل بخواند. هدف و منبع نام را برای هر نقش تعیین کنید، آن را روی CA منتشر کنید و یک پایلوت ثبت‌نام کنید.
یک CA سازمانی می‌تواند هر گواهی‌ای را که VPN نیاز دارد صادر کند بدون آنکه هرگز خودش دروازه باشد. کار طراحی این است که تصمیم بگیرید هر طرف باید چه چیزی را اثبات کند و سپس کدام قالب می‌تواند اعتبارنامه‌ای صادر کند که دقیقاً همان را اثبات می‌کند. من با یک جدول نقش شروع می‌کنم، به‌جای ویرایش یک قالب در جای خود آن را تکثیر می‌کنم، منبع موضوع را برای هر نقش تثبیت می‌کنم، نتیجه را روی CA صادرکننده منتشر می‌کنم و پیش از آنکه کسی آن را خودکار کند یک پایلوت ثبت‌نام می‌کنم. هر گام زیر جایی است که یک CA سالم هنوز گواهی‌ای تولید می‌کند که VPN آن را رد خواهد کرد.
پیش از باز کردن کنسول قالب‌ها جدول نقش را بنویسید
دو نقش، دو هدف. دروازه هویت یک سرویس را اثبات می‌کند، پس گواهی آن به Server Authentication (1.3.6.1.5.5.7.3.1)، کاربرد کلید برای امضای دیجیتال و رمزگذاری کلید، و نام میزبانی که کلاینت‌ها به آن وصل می‌شوند در نام جایگزین موضوع نیاز دارد. کلاینت‌هایی که با گواهی احراز هویت می‌کنند به Client Authentication (1.3.6.1.5.5.7.3.2) و هویتی نیاز دارند که با آنچه دروازه در بررسی طرف مقابل انتظار دارد بخواند. گواهی کاربر و گواهی رایانه قابل تبادل نیستند، چون در مخزن‌های متفاوتی زندگی می‌کنند و فرایندهای متفاوتی از آن‌ها استفاده می‌کنند.
برای هر نقش چهار ستون بنویسید: هویتی که باید ظاهر شود، هدف، مصرف‌کننده کلید، و اینکه آیا کلید می‌تواند از دستگاه خارج شود. همان جدول بعداً هر کادر را تعیین می‌کند و همان چیزی است که به بازبین می‌دهید. احراز هویت کلاینت با گذرواژه شاخه‌ای جداست: اگر دروازه کاربران را با اعتبارنامه احراز هویت می‌کند، توزیع گواهی کلاینت کار اضافه می‌کند بدون آنکه اثباتی اضافه کند.
به‌جای ویرایش یک قالب مشترک، قالبی را تکثیر کنید
از قالبی با هدف تقریباً درست شروع کنید، مانند RAS and IAS Server برای دروازه یا Computer برای دستگاه‌های عضو دامنه، سپس آن را تکثیر کنید و به نسخه نامی بدهید که بگوید برای چه کاری است. گسترده‌کردن قالبی که سرویس‌های دیگر از آن استفاده می‌کنند همان تغییری است که شش هفته بعد چیز نامرتبطی را می‌شکند. روی نسخه، خط‌مشی‌های برنامه را بر اساس هدف جدول نقش تنظیم کنید، کاربرد کلید را با آن سازگار نگه دارید، الگوریتم و طول کلیدی را که دروازه‌هایتان می‌پذیرند انتخاب کنید و کلید خصوصی را غیرقابل‌صدور علامت بزنید مگر آنکه دستگاهی برای جابه‌جایی به صدور آن نیاز داشته باشد.
اعتبار و تمدید هم به قالب تعلق دارند. عمر کوتاه لغو کردنش آسان‌تر و اداره‌اش سخت‌تر است؛ عمر بلند کار ثبت‌نام را کم می‌کند و مدت در معرض بودن کلید لو‌رفته را طولانی می‌کند. عددی انتخاب کنید که بتوانید از آن دفاع کنید و توجه داشته باشید که اعتبار خود CA و دوره تمدید قالب می‌توانند نتیجه را کوتاه‌تر کنند.
تصمیم بگیرید موضوع از کجا می‌آید
برای رایانه یا کاربر دامنه، موضوع را از اطلاعات دایرکتوری بسازید تا درخواست‌دهنده نتواند نام را تایپ کند. برای دروازه‌ای که عضو دامنه نیست، یا دستگاهی که هویتش بیرون از AD تعیین می‌شود، قالب به‌جای آن به مسیر درخواست کنترل‌شده نیاز دارد. فعال‌کردن موضوع و نام‌های جایگزینِ ارائه‌شده توسط درخواست‌دهنده تصمیم واقعی است: مجوزی برای اینکه هر ثبت‌نام‌شده‌ای هر نامی را ادعا کند نیست، و خط‌مشی سمت CA هنوز باید بگوید چه کسی می‌تواند درخواست کند و چه شاهدی لازم است.
Windows IKEv2 اینجا سخت‌گیر است. گواهی دروازه با نامی که کلاینت پیکربندی کرده تطبیق داده می‌شود، پس نام DNS باید همان‌جایی باشد که کلاینت آن را جست‌وجو می‌کند، معمولاً یک ورودی dNSName در نام جایگزین موضوع. خاموش‌کردن بررسی نام یا بررسی هدف برای اینکه گواهی ناهماهنگ کار کند، همان بررسی‌ای را حذف می‌کند که ناهماهنگی را در محیط عملیاتی می‌گرفت.
قالب را منتشر کنید، سپس مجوزها را محدود کنید
ساختن شیء قالب در AD DS و انتشار آن روی CA صادرکننده دو عملیات جداست که با کنسول‌های متفاوت انجام می‌شود. نسخه را از کنسول Certification Authority زیر Certificate Templates منتشر کنید، سپس از خط فرمان بررسی کنید که CA اکنون آن را ارائه می‌دهد:
certutil -CATemplates
certutil -TCAInfoمجوزها بعد می‌آیند. به گروه‌هایی که باید آن را درخواست کنند Read و Enroll بدهید و نه بیشتر، دسترسی خواندن خود CA را دست‌نخورده نگه دارید و Autoenroll را فقط جایی بدهید که ثبت‌نام خودکار مورد نظر است و خط‌مشی استقرار که آن را کار می‌اندازد پشتیبانی‌اش می‌کند. یک کادر در قالب به‌تنهایی چیزی را ثبت‌نام نمی‌کند، و قالب منتشرشده بدون مجوز ثبت‌نام دروازه‌ای می‌سازد که گواهی را فهرست می‌کند و بعد درخواست را رد می‌کند.
یک پایلوت را در مصرف‌کننده واقعی ثبت‌نام کنید
گواهی را در همان بافتاری درخواست کنید که از آن استفاده خواهد کرد، سپس به‌جای اعتماد به نام فایل، آنچه برگشته را بررسی کنید. گواهی کاربر در مخزن کاربر جاری و گواهی رایانه در مخزن رایانه محلی می‌نشیند و MMC هر دو را نشان می‌دهد، به همین دلیل ثبت‌نامی که “کار کرد” می‌تواند هنوز برای سرویس VPN نامرئی باشد.
certlm.msc
certutil -dump vpn-gateway.cerخروجی را برای موضوع، نام‌های جایگزین، کاربرد توسعه‌یافته کلید و زنجیره بخوانید. برای دروازه‌ای که Windows نیست، درخواست را از طریق گردش‌کار پشتیبانی‌شده ارسال کنید نه با فرض اینکه ثبت‌نام خودکار دامنه به آن می‌رسد، و تأیید کنید که قالب صادرشده همانی است که مصرف‌کننده همراه کلید خصوصی متناظرش وارد می‌کند. در پایان، اعتماد و مجوزدهی را جدا نگه دارید: VPN هنوز باید تصمیم بگیرد کدام کاربران یا دستگاه‌ها به کدام منابع می‌رسند، و ابطال تنها وقتی دسترسی را برمی‌دارد که دروازه اصلاً ابطال را بررسی کند. راهنمای Microsoft برای مدیریت قالب‌های گواهی کنسول قالب‌ها، مجوزها و گام انتشار جداگانه را پوشش می‌دهد.