Cisco Secure Client bllokon VPN nga një sesion RDP
Klienti pranon fjalëkalimin dhe më pas refuzon të ndërtojë tunelin sepse sesioni erdhi përmes RDP. Kjo është politikë profili, jo dështim vërtetimi.
Hyrja ka sukses dhe tuneli prapë nuk ngrihet. Ky kombinim i huton njerëzit sepse e lexojnë si problem vërtetimi, dhe më pas kalojnë një pasdite duke rivendosur kredencialet që nuk ishin kurrë problemi. Një Cisco Secure Client mund të refuzojë të vendosë një VPN pikërisht sepse përpjekja erdhi nga një sesion Remote Desktop, dhe atë vendim e merr politika në anën e klientit.
Ku shfaqet kjo në rrjedhën e lidhjes
Kalo klientin nga lart. Profili ngarkohet, kredencialet mblidhen dhe vërtetimi përfundon. Më pas, përpara se të ndërtohet çdo tunel, klienti vlerëson cilësimet e sesionit dhe të vendosjes kundrejt mjedisit ku ndodhet.
Shkruaj tri gjëra në atë moment: mesazhin e saktë, versionin e klientit dhe emrin e profilit të shfaqur në klient. Këto tri e kthejnë një ankesë të paqartë në një kërkesë mbështetjeje mbi të cilën dikush mund të veprojë. Bëj një pamje ekrani të dialogut, sepse mesazhet e gjata priten në regjistër. Shëno edhe kohën, që administratori ta krahasojë me kryesuesin.
Cilësimi që vendos në të vërtetë
Politika Windows VPN Establishment është kontrolli përkatës dhe ka dy vlera të dokumentuara: vetëm përdorues lokalë, dhe lejo përdorues të largët. E dyta lejon vendosjen e një tuneli nga një sesion Remote Desktop në një konfigurim të mbështetur. E para është qëndrimi i parazgjedhur në shumë profile ndërmarrjesh.
Mos e ngatërro me Windows Logon Enforcement, të cilën udhëzuesi i profilit e dokumenton si politikë të veçantë për sesionet e hyrjes. Njëra rregullon se cili sesion mund të ndërtojë tunelin, tjetra rregullon sjelljen e njëkohshme ose para hyrjes. Ndryshimi i asaj të gabuar nuk jep asnjë efekt të dukshëm.
Lexo profilin që zbatohet në të vërtetë
Në një vendosje të menaxhuar klienti e merr profilin nga kryesuesi ose nga një vend i menaxhuar, dhe një kopje e redaktuar në disk shpesh nuk është ajo në fuqi. Prandaj një ndryshim lokal në XML mund të duket i saktë dhe të mos ndryshojë asgjë.
Pyet administratorin se çfarë profili dhe çfarë politike grupi merr pajisja, jo çfarë skedari ndodhet në laptop. Të dyja shpesh nuk përputhen pas një përditësimi versioni. Një kopje e vjetër në dosjen lokale hapet prapë në redaktor dhe duket prapë e saktë. Thjesht nuk është ajo që zbatoi klienti.
Rruga RDP pasi tuneli ngrihet
Lejimi i vendosjes nga distanca nuk garanton që sesioni yt Remote Desktop do të mbijetojë. Kur tuneli ndryshon rrugët ose rregullat lokale të aksesit, sesioni që të futi brenda mund të humbasë rrugën që e mban.
Planifiko një kanal rikuperimi përpara ndryshimit: akses në konsol, një rrugë administrimi jashtë brezit ose një procedurë e dokumentuar rilidhjeje. Vendosja e kësaj pas faktit zakonisht nënkupton një udhëtim te makina.
Mos përdor truqe për të vjedhur sesione, mjete alternative të kontrollit në distancë ose një fjalëkalim të shkruar në një skript për të anashkaluar politikën. Nëse organizata nuk e autorizon këtë rrjedhë pune, hapi i saktë është rruga e administrimit që ajo mbështet.
Çfarë t'i dërgosh administratorit
Jepi tekstin e mesazhit, versionin e klientit, emrin e profilit aktiv, llojin e sesionit përmes të cilit u lidhët, dhe nëse një përpjekje nga tastiera lokale sillet ndryshe. Shto vulën kohore.
Pikërisht krahasimi i fundit kursen kohë, sepse ndan një refuzim sipas politikës së sesionit nga një defekt i të gjithë pajisjes.
Verifiko pas një ndryshimi të miratuar
Pasi profili përditësohet, vendos një sesion të ri RDP dhe lidhu përsëri, pastaj kryej qëllimisht sekuencën e shkëputjes. Konfirmo që tuneli ngrihet, rruga e administrimit mbijeton dhe llogaria jote prapë mund të hyjë në desktop.
Pranimi në VPN, mbijetesa e sesionit dhe leja e hyrjes në Windows janë tri kontrolle të veçanta. Kalimi i njërës nuk thotë asgjë për dy të tjerat.