Du åbner Macen, og GlobalProtect er allerede forbundet, eller det forbinder igen hver gang, du logger ind. Intet i appen spørger dig først. Den indstilling, der forårsager dette, ligger i portalmens agentkonfiguration, ikke på din brugerkonto, og den gemmes ikke i en fil, du er ment at redigere. Det, du ser, er forbindelsesmetoden user-logon, der gør sit arbejde.

Når du ved, hvilken metode der er tildelt, ved du, hvad du kan ændre, og hvad du skal anmode om.

Symptomet peger på politik

Portalmens agentkonfiguration afgør, hvornår GlobalProtect forbinder, og de to metoder, du vælger imellem, er On-Demand, som venter på dig, og User-logon (Always On), som forbinder efter login. En portal kan også tilbyde Pre-logon (Always On) på understøttede administrerede enheder, hvilket er uden for rækkevidde på en Mac, du selv logger ind på. En maskine, der forbinder af sig selv, er næsten altid på user-logon. Appens egne indstillinger kan vise tilstanden, men de ejer den ikke, og derfor overlever et fjernet flueben i klienten ikke den næste politikopdatering. Portalen sender metoden, når du forbinder, og igen ved hver opdatering, så en ændring på klientsiden er midlertidig af design.

Politik vinder, hver gang.

De to metoder, side om side

On-Demand, som appen måske stadig kalder manual, betyder, at du klikker forbind, og intet forbinder før det. User-logon betyder, at tunnelen kommer op, efter du godkender dig over for Macen, hvilket de fleste administrerede flåder ønsker, fordi det fjerner vinduet, hvor nogen surfer ubeskyttet. Afvejningen er præcis det symptom, du lagde mærke til: tunnelen findes, før du besluttede, at du ville have den. Ingen af metoderne ændrer, hvad tunnelen må nå; de afgør kun, hvornår den kommer op.

Hvis dit arbejde kræver en On-Demand-forbindelse, er det en anmodning om politikændring, ikke en ændring af indstillinger.

Hvis målet er en midlertidig afbrydelse

Nogle udrulninger viser en Disconnect-kontrol i appen, og Palo Alto Networks dokumenterer den i Mac Disconnect-vejledningen til appversion 6.0 og nyere. Den vises kun, når agentkonfigurationen tillader det. Den konfiguration kan også kræve en årsag, en adgangskode eller en ticket til helpdesk, og den kan begrænse, hvor længe eller hvor ofte du forbliver afbrudt.

Gennemfør det flow i stedet for at stoppe tjenesten. At stoppe den ligner en afbrydelse og opfører sig som en politikforseelse.

Afbrydelse af en håndhævet tunnel sætter også din trafik tilbage på den almindelige netværksvej, hvilket er værd at huske, mens du fejlretter en loginportal.

Hvad redigering af launch agent ødelægger

Den sædvanlige omvej er at redigere launch agentens RunAtLoad- eller KeepAlive-nøgler, eller en privat portalindstilling, for at forhindre appen i at starte. Det kan se ud, som om det virker indtil den næste politikopdatering eller appopdatering. Derefter er appen og dens administrerede politik uenige, hvilket giver en tilstand, som support ikke kan ræsonnere om. Det efterlader også maskinen i en konfiguration, som organisationen aldrig har godkendt.

At skjule et opstartsvindue er igen en anden anmodning, og den har sin egen understøttede grænsefladeindstilling.

Hvad du præcist skal bede om

Bed om On-Demand ved navn, eller et godkendt Disconnect-flow med dets betingelser, eller en understøttet måde at undertrykke loginvinduet. Vage anmodninger besvares med den forkerte, og så er du tilbage ved at redigere plists. Nævn også den appversion, du kører, fordi Disconnect-kontrollen kun er dokumenteret fra 6.0 og frem.

Hvis Disconnect-muligheden mangler, eller appen straks forbinder igen, så tag den tildelte agentkonfiguration med til IT og spørg, hvilken metode der gælder for din gruppe.

Relaterede artikler