Cisco Secure Client Always-On: distribuera profilen först

Inställningar på enhetens sida kan inte få en oregistrerad laptop att bete sig som en hanterad slutpunkt, och de flesta Always-On-utrullningar fastnar i den luckan. Cisco Secure Client tillämpar policyn genom profilen som ligger på maskinen, så leveransen av den profilen är en del av tillämpningsplanen och inte en detalj i den. Arbeta igenom de fem stegen nedan i ordning och stanna vid det första som inte håller, eftersom ett senare steg inte kan kompensera för en tidigare lucka.

Steg ett: avgör om regeln börjar före inloggning

Always-On upprättar tunneln efter att användaren loggat in, och leverantörens dokumentation säger klart att den inte upprättar någon anslutning när ingen loggar in. Om kravet är en tunnel som finns före Windows inloggningsskärm är detta fel funktion och ingen profiljustering ändrar det. Att distribuera profilen i förväg förvandlar inte beteendet efter inloggning till beteende före inloggning.

Skriv ner kravet som ett av fyra olika beteenden och testa sedan varje för sig. En enda lyckad anslutning visar bara det vanliga fallet, och de övriga tre är där supportärendena kommer ifrån. Markera vilken rad ditt krav faktiskt behöver, eftersom ett team som bara behöver beteendet efter inloggning kan hoppa över argumentet om före inloggning. Tabellen är en acceptanslista, inte en önskelista.

Om kravet bara är den andra raden gäller resten av sidan fortfarande, men acceptanstestet är billigare.

Steg två: bekräfta att profilen redan finns på slutpunkten

Tillämpningen läser en lokal profil, så den första frågan är om filen finns innan användaren ens ansluter. En profil som laddas ner vid den första lyckade anslutningen levereras för sent för en maskin som måste skyddas från första inloggningen. Skicka med den i installationsprogrammet eller i slutpunktshanteringen och behandla filens närvaro som en byggkontroll, inte som en förhoppning.

Get-Service vpnagent | Select-Object Status, StartType
Get-ChildItem 'C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile'
Get-Content 'C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile\profile.xml' | Select-String -Pattern AlwaysOn

Äldre AnyConnect-installationer behåller samma fil i en mapp med annat namn, så bekräfta sökvägen för den klientversion du distribuerar i stället för att kopiera en sökväg från en gammal runbook. Tjänsten måste köra och vara inställd på att starta automatiskt, eftersom en stoppad agent är en slutpunkt utan tillämpning oavsett vad profilen säger.

Om profilen saknas, stanna här. Att justera felpolicyn eller listan över betrodda nätverk för en maskin utan profil är arbete på en väg som aldrig körs.

Steg tre: välj felbeteendet medvetet

Vad som händer när tunneln inte kan komma upp är ett separat beslut från om tunneln startar automatiskt. Policyn för anslutningsfel avgör om slutpunkten får använda internet medan upprättandet fortsätter att misslyckas, och de två inställningarna blandas ofta ihop eftersom båda ligger nära Always-On-alternativen. Välj en med avsikt och skriv ner skälet.

Att blockera all anslutning låter strängt och skapar sin egen incidentklass: en användare på ett nätverk där gatewayen inte går att nå kan inte hämta den åtgärd som skulle återställa tjänsten. Att tillåta internetåtkomst håller maskinen användbar och försvagar garantin att trafiken skyddas. Båda svaren kan vara rätt, men inget av dem är ett standardvärde du bör upptäcka under ett avbrott.

Beteendet vid nya försök hör till samma beslut. En klient som försöker i evighet döljer en trasig gateway från övervakningen, medan en klient som ger upp efter ett försök ser trasig ut för användaren. Bestäm hur länge slutpunkten ska fortsätta försöka innan felpolicyn tar över, och testa den tiden i stället för att anta den.

Steg fyra: definiera vad som räknas som betrott

Identifiering av betrodda nätverk använder kriterierna i klientprofilen, till exempel konfigurerade DNS-domäner eller betrodda DNS-servrar, för att avgöra att slutpunkten redan är på ett nätverk där tunneln är onödig. Den listan är hela policyn, så en tom eller ärvd lista gör funktionen antingen overksam eller oförutsägbar.

Ersätt inte det med ett antagande om Windows-brandväggens nätverkskategori. En maskin kan vara på ett domänmärkt nätverk och ändå stå någonstans du inte litar på, och en maskin med offentlig profil kan stå inne i din egen byggnad. Identifieringskriterierna bör beskriva dina nätverk direkt, inte en ersättning för dem.

Testa övergången åt båda hållen, inklusive fallet där slutpunkten flyttas från ett betrott till ett obetrodd nätverk medan en session är öppen. Frånkopplingen och återanslutningen är separata händelser, och en policy som bara hanterar den första lämnar ett fönster där tunneln saknas.

Steg fem: gör slutpunktspolicyn svår att ångra

Tillämpningen på slutpunkten är bara så stark som slutpunktens egna kontroller. Lokala administratörsrättigheter låter en användare stoppa agenttjänsten, byta ut profilen eller avinstallera klienten, och en profilmapp som vanliga användare kan skriva i är en policy som vem som helst kan redigera. Båda är problem med slutpunktshantering som VPN-headenden inte kan lösa åt dig. Fråga skrivbordsteamet vilket av de två villkoren som gäller innan du lovar tillämpning, och skriv svaret i utrullningsplanen.

Bestäm låsningsnivån med återställningsvägen i sikte. En profil som hindrar användaren från att nå internet och samtidigt hindrar hen från att reparera klienten förvandlar ett supportärende till ett platsbesök, så behåll en dokumenterad återställningsväg som inte är beroende av att tunneln är uppe.

Behåll valideringen av gatewaycertifikatet på och distribuera profilen bara via en kanal du litar på. En låst klient som accepterar en profil från en oväntad källa har flyttat förtroendegränsen i stället för att upprätthålla den.