Cisco Secure Client blokkeert VPN vanuit een RDP-sessie

De aanmelding lukt en de tunnel komt toch niet op. Die combinatie verwart mensen omdat ze het lezen als een authenticatieprobleem, en vervolgens een middag besteden aan het resetten van inloggegevens die nooit de oorzaak waren. Een Cisco Secure Client kan weigeren een VPN op te zetten juist omdat de poging uit een Remote Desktop-sessie kwam, en die beslissing wordt genomen door beleid aan de clientzijde.

Waar dit in de verbindingsstroom verschijnt

Loop de client van bovenaf door. Het profiel wordt geladen, inloggegevens worden verzameld en de authenticatie rondt af. Daarna, voordat er een tunnel wordt gebouwd, beoordeelt de client zijn sessie- en opbouwinstellingen tegen de omgeving waarin hij zich bevindt.

Noteer op dat moment drie dingen: het exacte bericht, de clientversie en de profielnaam die in de client wordt getoond. Die drie maken van een vage klacht een supportverzoek waar iemand iets mee kan. Maak een schermafbeelding van het dialoogvenster, want lange berichten worden in het log afgekapt. Noteer ook de tijd, zodat de beheerder die kan vergelijken met de headend.

De instelling die het echt beslist

Het beleid Windows VPN Establishment is de relevante controle, en het heeft twee gedocumenteerde waarden: alleen lokale gebruikers, en externe gebruikers toestaan. De tweede staat het opbouwen van een tunnel vanuit een Remote Desktop-sessie toe in een ondersteunde configuratie. De eerste is de standaardhouding in veel bedrijfsprofielen.

Verwar het niet met Windows Logon Enforcement, dat de profielhandleiding documenteert als een apart beleid over aanmeldingssessies. Het ene bepaalt welke sessie de tunnel mag bouwen, het andere bepaalt gelijktijdig gedrag of gedrag vóór aanmelding. De verkeerde aanpassen heeft geen zichtbaar effect.

Lees het profiel dat daadwerkelijk wordt toegepast

In een beheerde uitrol ontvangt de client zijn profiel van de headend of van een beheerde locatie, en een op schijf bewerkte kopie is vaak niet de geldende. Daarom kan een lokale XML-wijziging correct lijken en niets veranderen.

Vraag de beheerder welk profiel en welk groepsbeleid het apparaat ontvangt, in plaats van welk bestand er op de laptop staat. Die twee zijn het na een versie-upgrade vaak oneens. Een verouderde kopie in de lokale map opent nog steeds in de editor en ziet er nog steeds correct uit. Het is alleen niet wat de client heeft toegepast.

Het RDP-pad nadat de tunnel omhoog komt

Extern opbouwen toestaan garandeert niet dat je Remote Desktop-sessie overleeft. Wanneer de tunnel routes of lokale toegangsregels wijzigt, kan de sessie die je binnenbracht het pad verliezen dat haar in stand houdt.

Plan een herstelkanaal vóór de wijziging: consoletoegang, een out-of-band-beheerpad of een gedocumenteerde herverbindingsprocedure. Dat achteraf beslissen betekent meestal een reis naar de machine.

Gebruik geen trucs om sessies te stelen, alternatieve tools voor extern beheer of een wachtwoord dat in een script is geschreven om het beleid te omzeilen. Als de organisatie deze werkwijze niet autoriseert, is de juiste stap het beheerpad dat zij wel ondersteunt.

Wat je naar de beheerder stuurt

Geef hun de berichttekst, de clientversie, de naam van het actieve profiel, het sessietype waarover je verbonden was, en of een poging vanaf de lokale console zich anders gedraagt. Voeg de tijdstempel toe.

Juist die laatste vergelijking bespaart tijd, omdat ze een weigering op grond van sessiebeleid scheidt van een storing op het hele apparaat.

Controleer na een goedgekeurde wijziging

Zodra het profiel is bijgewerkt, breng je een nieuwe RDP-sessie tot stand en verbind je opnieuw, en doorloop daarna bewust de verbreeksessie. Bevestig dat de tunnel omhoog komt, het beheerpad overleeft en je account nog steeds op het bureaublad kan aanmelden.

VPN-toelating, sessiebehoud en Windows-aanmeldingsrechten zijn drie afzonderlijke controles. Er één halen zegt niets over de andere twee.