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-ի ուղեցույցը վկայականների ձևանմուշների կառավարման վերաբերյալ ընդգրկում է ձևանմուշների վահանակը, թույլտվությունները և հրապարակման առանձին քայլը։