Cisco Secure Client-ը արգելափակում է VPN-ը RDP նստաշրջանից

Մուտքը հաջողվում է, բայց թունելը այդպես էլ չի բարձրանում։ Այս համակցությունը շփոթեցնում է մարդկանց, քանի որ նրանք դա կարդում են որպես նույնականացման խնդիր, ապա կես օր ծախսում են վերականգնելով հավատարմագրեր, որոնք երբեք խնդիրը չեն եղել։ Cisco Secure Client-ը կարող է հրաժարվել VPN կառուցելուց հենց այն պատճառով, որ փորձը եկել է Remote Desktop նստաշրջանից, և այդ որոշումը կայացնում է քաղաքականությունը հաճախորդի կողմում։

Որտեղ է դա երևում միացման հոսքում

Անցեք հաճախորդով վերևից։ Պրոֆիլը բեռնվում է, հավատարմագրերը հավաքվում են, նույնականացումը ավարտվում է։ Այնուհետև, մինչև որևէ թունել կառուցելը, հաճախորդը գնահատում է իր նստաշրջանի և կառուցման կարգավորումները այն միջավայրի նկատմամբ, որտեղ գտնվում է։

Այդ պահին գրի առեք երեք բան՝ հաղորդագրության ճշգրիտ տեքստը, հաճախորդի տարբերակը և հաճախորդում ցուցադրվող պրոֆիլի անունը։ Այս երեքը անորոշ բողոքը վերածում են աջակցության հարցման, որի վրա ինչ-որ մեկը կարող է գործել։ Լուսանկարեք երկխոսության պատուհանը, քանի որ երկար հաղորդագրությունները կրճատվում են մատյանում։ Նշեք նաև ժամը, որպեսզի ադմինիստրատորը կարողանա համեմատել այն գլխավոր սերվերի հետ։

Կարգավորումը, որն իրականում որոշում է

Windows VPN Establishment քաղաքականությունը համապատասխան կառավարումն է, և այն ունի երկու փաստաթղթավորված արժեք՝ միայն տեղական օգտատերեր, և թույլատրել հեռավոր օգտատերերին։ Երկրորդը թույլատրում է թունել կառուցել Remote Desktop նստաշրջանից աջակցվող կազմաձևում։ Առաջինը լռելյայն դիրքորոշումն է շատ ձեռնարկային պրոֆիլներում։

Չշփոթեք այն Windows Logon Enforcement-ի հետ, որը պրոֆիլի ուղեցույցը փաստաթղթավորում է որպես առանձին քաղաքականություն մուտքի նստաշրջանների մասին։ Մեկը կարգավորում է, թե որ նստաշրջանը կարող է կառուցել թունելը, մյուսը՝ միաժամանակյա կամ մուտքից առաջ վարքը։ Սխալը փոխելը տեսանելի ազդեցություն չի տալիս։

Կարդացեք այն պրոֆիլը, որն իրականում կիրառված է

Կառավարվող տեղակայման դեպքում հաճախորդը ստանում է իր պրոֆիլը գլխավոր սերվերից կամ կառավարվող վայրից, և սկավառակի վրա խմբագրված պատճենը հաճախ այն չէ, որն ուժի մեջ է։ Այդ պատճառով տեղական XML փոփոխությունը կարող է ճիշտ թվալ և ոչինչ չփոխել։

Հարցրեք ադմինիստրատորին, թե սարքը որ պրոֆիլն ու որ խմբային քաղաքականությունն է ստանում, ոչ թե թե որ ֆայլն է նոութբուքում։ Տարբերակի թարմացումից հետո այս երկուսը հաճախ չեն համընկնում։ Տեղական պանակի հնացած պատճենը դեռ բացվում է խմբագրիչում և դեռ ճիշտ է թվում։ Պարզապես այն չէ, ինչ կիրառել է հաճախորդը։

RDP ուղին թունելի բարձրանալուց հետո

Հեռավոր կառուցման թույլտվությունը չի երաշխավորում, որ ձեր Remote Desktop նստաշրջանը կպահպանվի։ Երբ թունելը փոխում է երթուղիներ կամ տեղական հասանելիության կանոններ, ձեզ ներս բերած նստաշրջանը կարող է կորցնել այն պահող ուղին։

Փոփոխությունից առաջ պլանավորեք վերականգնման ուղի՝ կոնսոլի հասանելիություն, ժապավենից դուրս կառավարման ուղի կամ փաստաթղթավորված վերամիացման ընթացակարգ։ Դա հետագայում որոշելը սովորաբար նշանակում է ուղևորություն դեպի մեքենան։

Քաղաքականությունը շրջանցելու համար մի օգտագործեք նստաշրջան գողանալու հնարքներ, այլընտրանքային հեռակառավարման գործիքներ կամ սկրիպտում գրված գաղտնաբառ։ Եթե կազմակերպությունը չի լիազորում այս աշխատանքային հոսքը, ճիշտ քայլը իր աջակցած կառավարման ուղին է։

Ինչ ուղարկել ադմինիստրատորին

Տվեք նրանց հաղորդագրության տեքստը, հաճախորդի տարբերակը, ակտիվ պրոֆիլի անունը, նստաշրջանի տեսակը, որով միացել եք, և արդյոք տեղական կոնսոլի փորձն այլ կերպ է վարվում։ Ավելացրեք ժամանակի դրոշմանիշը։

Հենց վերջին համեմատությունն է խնայում ժամանակը, քանի որ այն առանձնացնում է նստաշրջանի քաղաքականության մերժումը սարքի ամբողջական խափանումից։

Ստուգեք հաստատված փոփոխությունից հետո

Պրոֆիլը թարմացնելուց հետո ստեղծեք նոր RDP նստաշրջան և նորից միացեք, ապա դիտավորյալ անցեք անջատման հաջորդականությունը։ Հաստատեք, որ թունելը բարձրանում է, կառավարման ուղին պահպանվում է, և ձեր հաշիվը դեռ կարող է մուտք գործել աշխատասեղան։

VPN ընդունումը, նստաշրջանի պահպանումը և Windows մուտքի թույլտվությունը երեք առանձին ստուգումներ են։ Մեկն անցնելը ոչինչ չի ասում մյուս երկուսի մասին։