Cisco Secure Client blokkeer VPN vanaf 'n RDP-sessie

Die aanmelding slaag en die tonnel kom steeds nie op nie. Daardie kombinasie verwar mense, want hulle lees dit as 'n verifikasieprobleem en spandeer dan 'n middag daaraan om geloofsbriewe te herstel wat nooit die probleem was nie. 'n Cisco Secure Client kan weier om 'n VPN te bou juis omdat die poging van 'n Remote Desktop-sessie gekom het, en daardie besluit word deur beleid aan die kliëntkant geneem.

Waar dit in die verbindingsvloei verskyn

Gaan die kliënt van bo af deur. Die profiel laai, geloofsbriewe word ingesamel en verifikasie voltooi. Dan, voordat enige tonnel gebou word, evalueer die kliënt sy sessie- en vestigingsinstellings teen die omgewing waarin hy hom bevind.

Skryf drie dinge op daardie oomblik neer: die presiese boodskap, die kliëntweergawe en die profielnaam wat in die kliënt gewys word. Daardie drie verander 'n vae klag in 'n ondersteuningsversoek waarop iemand kan reageer. Neem 'n skermskoot van die dialoog, want lang boodskappe word in die log afgekap. Let ook op die tyd, sodat die administrateur dit teen die hoofkant kan pas.

Die instelling wat dit eintlik bepaal

Die Windows VPN Establishment-beleid is die betrokke beheer, en dit het twee gedokumenteerde waardes: slegs plaaslike gebruikers, en laat afgeleë gebruikers toe. Die tweede laat die bou van 'n tonnel vanaf 'n Remote Desktop-sessie in 'n ondersteunde opset toe. Die eerste is die verstekhouding in baie ondernemingsprofiele.

Moenie dit met Windows Logon Enforcement verwar nie, wat die profielgids as 'n aparte beleid oor aanmeldingsessies dokumenteer. Die een bepaal watter sessie die tonnel mag bou, die ander bepaal gelyktydige of voor-aanmelding-gedrag. Om die verkeerde een te verander het geen sigbare uitwerking nie.

Lees die profiel wat werklik toegepas word

In 'n bestuurde ontplooiing kry die kliënt sy profiel van die hoofkant of 'n bestuurde ligging, en 'n kopie wat op die skyf geredigeer is, is dikwels nie die een wat geld nie. Daarom kan 'n plaaslike XML-verandering korrek lyk en niks verander nie.

Vra die administrateur watter profiel en groepsbeleid die toestel ontvang, eerder as watter lêer op die skootrekenaar bestaan. Die twee stem dikwels nie ooreen ná 'n weergawe-opgradering nie. 'n Verouderde kopie in die plaaslike vouer open steeds in die redigeerder en lyk steeds korrek. Dit is bloot nie wat die kliënt toegepas het nie.

Die RDP-pad nadat die tonnel opgekom het

Om afgeleë vestiging toe te laat waarborg nie dat jou Remote Desktop-sessie oorleef nie. Wanneer die tonnel roetes of plaaslike toegangsreëls verander, kan die sessie wat jou ingebring het die pad verloor wat dit onderhou.

Beplan 'n herstelkanaal voor die verandering: konsoltoegang, 'n buiteband-bestuurspad of 'n gedokumenteerde herverbindingsprosedure. Om dit agterna te besluit beteken gewoonlik 'n reis na die masjien.

Moenie truuks gebruik om sessies te steel, alternatiewe afstandbeheergereedskap of 'n wagwoord wat in 'n script geskryf is om die beleid te omseil nie. As die organisasie nie hierdie werkwyse magtig nie, is die korrekte stap die administrasiepad wat dit wel ondersteun.

Wat om aan die administrateur te stuur

Gee hulle die boodskapteks, kliëntweergawe, die aktiewe profielnaam, die sessietipe waaroor jy gekonnekteer het, en of 'n plaaslike konsolpoging anders optree. Voeg die tydstempel by.

Daardie laaste vergelyking is die een wat tyd spaar, want dit skei 'n sessiebeleid-weiering van 'n toestelwye fout.

Verifieer ná 'n goedgekeurde verandering

Sodra die profiel opgedateer is, vestig 'n vars RDP-sessie en konnekteer weer, en oefen dan die ontkoppelreeks doelbewus. Bevestig die tonnel kom op, die bestuurspad oorleef en jou rekening kan steeds by die lessenaar aanmeld.

VPN-toelating, sessie-oorlewing en Windows-aanmeldregte is drie aparte kontroles. Om een te slaag sê niks oor die ander twee nie.