GlobalProtect på Mac ansluter vid inloggning: så ändrar du det

Du öppnar Macen och GlobalProtect är redan anslutet, eller så ansluter det igen varje gång du loggar in. Inget i appen frågar dig först. Inställningen som orsakar detta, ligger i portalens agentkonfiguration, inte i ditt användarkonto, och den lagras inte i en fil som du ska redigera. Det du ser är anslutningsmetoden user-logon som gör sitt jobb.

Att veta vilken metod som är tilldelad säger dig vad du kan ändra och vad du måste begära.

Symtomet pekar på policy

Portalens agentkonfiguration avgör när GlobalProtect ansluter, och de två metoderna du väljer mellan är On-Demand, som väntar på dig, och User-logon (Always On), som ansluter efter inloggning. En portal kan också erbjuda Pre-logon (Always On) på hanterade enheter som stöds, vilket ligger utanför ramen på en Mac som du loggar in på själv. En maskin som ansluter av sig själv kör nästan alltid på user-logon. Appens egna inställningar kan visa statusen, men de äger den inte, och därför överlever inte en bortkryssad ruta i klienten nästa policyuppdatering. Portalen skickar metoden när du ansluter och igen vid varje uppdatering, så en ändring på klientsidan är tillfällig av design.

Policyn vinner, varje gång.

De två metoderna, sida vid sida

On-Demand, som appen kanske fortfarande kallar manuell, innebär att du klickar på anslut och inget ansluter före det. User-logon innebär att tunneln kommer upp efter att du autentiserat dig mot Macen, vilket de flesta hanterade flottor vill, eftersom det tar bort fönstret där någon surfar oskyddat. Avvägningen är precis det symtom du märkte: tunneln finns innan du bestämt att du vill ha den. Ingen av metoderna ändrar vad tunneln får nå; de avgör bara när den kommer upp.

Om ditt arbete behöver en On-Demand-anslutning är det en begäran om policyändring, inte en inställningsändring.

Om målet är en tillfällig frånkoppling

Vissa utrullningar visar en Disconnect-kontroll i appen, och Palo Alto Networks dokumenterar den i Mac Disconnect-guiden för appversion 6.0 och senare. Den visas bara när agentkonfigurationen tillåter det. Den konfigurationen kan också kräva en anledning, en åtkomstkod eller en biljett till helpdesk, och den kan begränsa hur länge eller hur ofta du är frånkopplad.

Slutför det flödet i stället för att stoppa tjänsten. Att stoppa den ser ut som en frånkoppling och beter sig som en policyöverträdelse.

Att koppla från en påtvingad tunnel sätter också tillbaka din trafik på den vanliga nätverksvägen, vilket är värt att komma ihåg när du felsöker en inloggningsportal.

Vad redigering av launch agent förstör

Den vanliga vägen runt är att redigera launch agentens RunAtLoad- eller KeepAlive-nycklar, eller en privat portalinställning, för att hindra appen från att starta. Det kan se ut att fungera till nästa policyuppdatering eller appuppdatering. Då är appen och dess hanterade policy oense, vilket ger ett tillstånd som supporten inte kan resonera om. Det lämnar också maskinen i en konfiguration som organisationen aldrig har godkänt.

Att dölja ett startfönster är återigen en annan begäran, och det har sin egen stödda gränssnittsinställning.

Vad du ska begära, exakt

Begär On-Demand vid namn, eller ett godkänt Disconnect-flöde med dess villkor, eller ett stött sätt att undertrycka inloggningsfönstret. Vaga förfrågningar besvaras med den felaktiga, och då är du tillbaka vid redigering av plists. Nämn också vilken appversion du kör, eftersom Disconnect-kontrollen först dokumenteras från 6.0.

Om Disconnect-alternativet saknas eller appen ansluter igen direkt, ta med den tilldelade agentkonfigurationen till IT och fråga vilken metod som gäller för din grupp.