Проектиране на шаблони в AD CS за ролите на VPN шлюз и клиенти

Корпоративен 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 за управление на шаблони за сертификати покрива конзолата за шаблони, разрешенията и отделната стъпка на публикуване.