Azure VPN Client 3.4 kobler fra hver time: påloggingsfrekvens

Én bruker kobler til, jobber, og blir deretter koblet fra én gang i timen med en melding om at autentiseringen mot Microsoft Entra er utløpt. Det går an å koble til på nytt, og syklusen gjentar seg som på en stoppeklokke. På en point-to-site-gateway der ingenting er rullet ut, peker mønsteret på påloggingsinformasjonen og ikke på tunnelen. Azure VPN Client 3.4.0 begynte å håndheve påloggingsfrekvensen i betinget tilgang under en etablert økt, en policy som tidligere klienter bare vurderte ved pålogging.

Gå gjennom de seks kontrollene nedenfor i rekkefølge. Hver av dem bekrefter eller utelukker tidsplanen, og å stoppe for tidlig er hvordan en gateway blir bygget på nytt uten grunn.

Trinn 1: les den nøyaktige meldingen

Formuleringen skiller lagene. En melding om at Entra-autentiseringen utløper er en påstand om tokenet; en tunnel- eller sikkerhetsforeningsfeil er det ikke. Skriv også ned medgått tid, målt fra tilkobling til frakobling og ikke fra starten av arbeidsdagen.

Hvis brukeren kan koble til igjen umiddelbart og gatewayen fortsatt viser en sunn tunnel, ser du på tokenutløp og ikke en død peer.

Trinn 2: finn klientversjonen

Les versjonen i appen, ikke i utrullingsposten. Endringen kom med 3.4.0, så 3.3.1 og eldre holder en etablert tunnel i live uavhengig av policyen. Én ikke-administrert bærbar med eldre build oppfører seg perfekt mens resten av teamet faller hver time: det er den typen splittelse som sender folk tilbake til gatewayen. Versjonen er en egenskap ved klienten, og gatewayen aner ikke hvilken build som er tilkoblet.

Oppdater først én testenhet og følg med på klokken. En enhet som begynner å falle på policyintervallet etter oppdateringen, bekrefter mekanismen uten å røre produksjonspolicyen.

Trinn 3: finn ut hvor policyen bor

Påloggingsfrekvens er en innstilling for betinget tilgang i policyen som retter seg mot bedriftsappen Azure VPN. Den finnes ikke på VPN-gatewayressursen, ikke i point-to-site-konfigurasjonen og ikke i klientprofilen. Søk etter Azure VPN-appen i policylisten og les øktkontrollene.

To policyer kan gjelde for én bruker, og den strengeste vinner, så en verdi du aldri har satt kan være den som gjelder. Kontroller både en leietakeromfattende basispolicy og den appspesifikke. Rapportens omfang betyr også noe: en policy som utelukker en gruppe, gir en populasjon med annen atferd og uten åpenbar forklaring.

Trinn 4: regn etter

Frakoblingen skjer én time etter verdien for påloggingsfrekvens, i atferden Microsoft dokumenterer for denne klienten, så en frekvens på sju timer gir omtrent åtte timer med tilkobling. Den forskyvningen er grunnen til at en verdi valgt for en åtte timers arbeidsdag ser ødelagt ut om ettermiddagen, mens en test på ni timer ser bra ut. Gjør klagen om til tall før du endrer noe: tilkoblingstid, frakoblingstid, forskjell og deretter sammenligning med policyverdien pluss én time.

Hvis forskjellen ikke stemmer med den summen, er tidsplanhypotesen feil, og du bør slutte å justere policyen.

Trinn 5: skill en tidsplan fra en rekey

IPsec-rekey, død-peer-deteksjon og inaktive tidsavbrudd gir uregelmessige brudd knyttet til trafikkvolum eller stillhet, ikke til en stoppeklokke. En bruker som faller midt i en overføring, og en som faller etter en inaktiv lunsj, beskriver forskjellige mekanismer. Spør hva brukeren gjorde i minuttet før frakoblingen.

Sertifikatproblemer ser annerledes ut igjen: klienten klarer ikke å koble til i stedet for å miste en fungerende økt, og feilen er umiddelbar. En MFA-forespørsel som aldri fullføres, viser seg som en henging, ikke som et rent timelig brudd etterfulgt av en vellykket gjenoppkobling.

Trinn 6: rull ut uten overraskelser

Kunngjør klientoppdateringen før den når brukerne via butikken, fordi atferdsendringen leveres med klienten. Velg frekvensen ut fra kravet: en verdi som dekker arbeidsdagen for brukbarhet, eller en kort verdi hvis en tapt bærbar raskt må miste tilgang. Noter hvilket krav som vant, siden samme innstilling gir både beskyttelsen og klagen. Bekreft deretter valget på en enhet med den nye builden i stedet for å ekstrapolere fra en pilot med den gamle.

Oppbevar meldingen, versjonen, policyverdien og det målte intervallet i ett notat. Den posten besvarer neste rapport på et minutt i stedet for med en gjenoppbygging.