Konfigurera Synchronized User ID Authentication på Sophos Firewall

Synchronized User ID Authentication kopplar inloggningen på en hanterad endpoint till Sophos Firewall. Sophos Endpoint överför identiteten via Security Heartbeat. I AD-förloppet för SFOS 22 validerar brandväggen domänanvändaren via Active Directory; SFOS 23-hjälpen beskriver dessutom Microsoft Entra ID med identifiering via UPN och hämtning av grupper. Användare som har kopplats korrekt visas under Current activities > Live users.

Metoden passar hanterade arbetsstationer där Sophos Endpoint och Security Heartbeat redan fungerar. Den kräver ingen extra autentiseringsagent på klienten eller servern. Sophos Endpoint är däremot fortfarande ett krav.

⚠️ SFOS 22-hjälpen bekräftar det äldre AD-förloppet för Windows 10 och utesluter andra katalogtjänster. Detta gäller inte generellt för SFOS 23: där dokumenteras ett separat Entra ID-förlopp. Lokala användare och enheter med Server Protection är fortfarande undantagna. SFOS 23-sidan anger ingen specifik operativsystemsversion; dra inte slutsatsen att ytterligare operativsystem stöds utifrån detta eller en lyckad pilot.

SFOS 23: Entra-identitet via Security Heartbeat

Denna gren beskriver inloggningen på endpointen, inte den interaktiva SSO-inloggningen på VPN Portal eller WebAdmin. Entra-integrationen måste redan vara korrekt konfigurerad. Den gemensamma grundkonfigurationen för Entra beskriver app, behörigheter, autentiseringsserver och gruppimport; själva VPN-inloggningen är inte en förutsättning för denna heartbeat-pilot. För administratörsåtkomst gäller separat Entra ID för WebAdmin.

Minimikrav och identifiering

Kontrollera dessa förutsättningar före piloten:

• Brandväggen kör den avsedda SFOS 23-builden, är ansluten till Sophos Central respektive Sophos Fusion och har en fungerande Security Heartbeat. De licensuppgifter som behållits nedan kommer uttryckligen från SFOS 22-hjälpen; de belägger inget nytt eller ändrat licenskrav för SFOS 23. Kontrollera licensrätten för den version som faktiskt används separat.
• Sophos Endpoint 2025.1 eller senare är installerat på den hanterade pilotklienten. SFOS 23-hjälpen kräver Endpoint på domänanslutna enheter; dra inte slutsatsen att valfria anslutningsmodeller eller operativsystem därmed stöds.
• Användarkontot använder samma e-postadress i Sophos Central/Fusion, på brandväggen och i den konfigurerade katalogen. Den inloggade Entra-användaren måste kunna kopplas entydigt.
• Microsoft Entra ID har konfigurerats korrekt som autentiseringsserver på brandväggen. Kontrollera Entra-servern och Test connection under Authentication > Servers; kontrollera tidssynkronisering, nåbarhet, appbehörigheter och gruppimport enligt den länkade grundkonfigurationen.
• Endpoint överför den inloggade Entra-användarens giltiga UPN via heartbeat. Från och med Endpoint 2025.1 överförs inloggningsnamn, domännamn och UPN; äldre versioner skickar inget UPN. Utan UPN kan brandväggen inte koppla heartbeat till någon Entra-användare. Ett grönt heartbeat räcker därför inte ensamt.

⚠️ Synkronisera inte användare i en och samma domän samtidigt via AD och Entra ID. Entra-förutsättningarna utesluter denna kombination. Tolka inte en befintlig AD-väg som en automatisk migrering: klargör först vilken katalog som ansvarar för användarna och hur återgången ska ske; stoppa piloten om dubbelkopplingen inte är utredd.

Entra-förloppet består av fem steg:

1. Användaren loggar in med sitt Entra ID-konto på enheten som skyddas av Sophos Endpoint.
2. Endpoint skickar identitetsinformationen till brandväggen via Security Heartbeat.
3. Brandväggen identifierar Entra-användaren utifrån användarens UPN. Till skillnad från AD-grenen används här inte sAMAccountName som kopplingsnyckel för Entra.
4. Brandväggen hämtar Entra-gruppmedlemskapen och aktiverar användaren med passande användar- och grupppolicyer samt motsvarande Synchronized Security-policyer.
5. Användaren visas under Current activities > Live users. Brandväggen använder eller delar inga lösenord i detta förlopp.

Validera Entra-piloten och behörighetskontrollen

Som dokumentationsexempel används anna.muster@example.com, klient-IP 10.20.30.101, Entra-pilotgruppen SFOS-Internet-Users och regeln LAN_User_Internet. Ersätt UPN, IP och grupp med värdena för den egna piloten. Begränsa medvetet gruppen till de testanvändare som behövs; namnet ensamt bevisar varken medlemskap eller behörighet.

1. Dokumentera tidigare tillstånd för katalogkoppling, användar- och gruppobjekt, regler och HA-noder samt en oberoende administrativ åtkomstväg. Använd en godkänd testklient och testkonton; spärra eller ta inte bort produktionskonton.
2. Importera den Entra-grupp som behövs enligt grundkonfigurationen och välj den i en snävt avgränsad, loggad regel under Rules and policies > Firewall rules med Match known users och Users or groups. Begränsa källa, destination och tjänster till piloten; pilotregeln som beskrivs längre ned visar fälten.
3. Logga ut piloten helt och logga in på nytt med Entra-kontot. Kontrollera heartbeat och Current activities > Live users tillsammans: förväntad användare, klient-IP och Client Type: Heartbeat måste stämma med testinloggningen. Dokumentera den identitet som faktiskt visas; förutsätt inte ett visst visningsnamn.
4. Skapa ett nytt tillåtet testflöde och jämför användare, källa, destination, tjänst, åtgärd, tidpunkt och Firewall Rule ID i Log viewer. Först rätt flöde bevisar regelns effekt; en post under Live users bevisar inte ensam gruppbehörigheten.
5. Kontrollera samma destinationsväg med en separat testanvändare utanför pilotgruppen. Denna användare får inte ges åtkomst genom pilotgruppens regel. En annan tillåten regel kan fortfarande gälla: dokumentera dess Rule ID i stället för att förvänta dig en generell blockering.
6. Validera saknat eller ogiltigt UPN, ett obefintligt eller inaktivt Entra-testkonto och bristande nåbarhet från brandväggen till Entra som negativa testfall. Skapa störningar endast i en isolerad, godkänd testmiljö, inte genom spärrar för hela tenanten eller globala nätverksblockeringar. Utan en sådan miljö ska testfallen dokumenteras som öppna, inte som framgångsrikt testade. Förvänta dig ingen Entra-koppling om UPN saknas; utlova inget visst felmeddelande eller omedelbar utloggning av befintliga sessioner vid konto- eller nåbarhetsfel.
7. Testa förlust av heartbeat samt viloläge och väckning kontrollerat. Om heartbeat saknas loggas den synkroniserade användaren ut; andra autentiseringsmetoder kan fortfarande gälla och trafiken kan avbrytas fram till nästa inloggning. Följande kontrollkedja för heartbeat gäller även här.

Entra-användaren saknas eller har fel grupp

Vid grönt heartbeat utan passande identitet ska du först kontrollera Endpoint-versionen och det UPN som faktiskt rapporteras. Kontrollera därefter att Entra-kontot finns och är aktivt, att brandväggstjänsterna når Entra och att Entra-konfigurationen har slutförts korrekt. Kör Test connection igen under Authentication > Servers. Ett lyckat anslutningstest bevisar ensamt varken endpointens UPN eller gruppbehörigheten.

Om identiteten är synlig men gruppen eller regeln är fel ska Entra-medlemskap, importerad brandväggsgrupp, användarkoppling och regelordning jämföras. Spara det berörda flödet med Rule ID och tidpunkt. Bredda inte regler, ta inte bort användarobjekt och starta inte om tjänster i förebyggande syfte. För en eskalering ska SFOS-build, Endpoint-version, anonymiserat UPN, heartbeatstatus, klient-IP, tidsfönster och behandlande HA-nod sparas tillsammans med loggarna som anges nedan.

HA och återgång för Entra-piloten

Även SFOS 23-hjälpen beskriver Synchronized User ID som aktiverat som standard och kräver aktivering eller avaktivering på båda HA-enheterna. Tillståndsändringen sparas inte i säkerhetskopian. De bevarade shellkommandona längre ned dokumenteras även i SFOS 23; de växlar hela funktionen, inte bara Entra. En sådan tjänsteomstart är därför inte en harmlös återgång för piloten.

Testa failover endast i ett godkänt underhållsfönster med oberoende administrativ åtkomst. Validera heartbeat, ny Entra-inloggning, Live users, gruppregel och ett nytt testflöde igen på den nod som därefter behandlar trafiken. Förutsätt inte att användartillstånd eller sessioner tas över utan avbrott; de SFOS 22-korrigeringar som anges nedan är ingen ny garanti för failover i SFOS 23.

För återgången ska du först återställa pilotregeln och pilotkopplingarna till deras dokumenterade tidigare tillstånd och kontrollera den tidigare autentiseringsvägen med en ny inloggning och verklig trafik. Ta inte bort eller avaktivera globalt Entra-app, server, behörigheter och grupper som delas med VPN, Portal eller WebAdmin som en del av teststädningen. Om även det globala tillståndet för Synchronized User ID ändrades under underhållsfönstret ska det avsedda tillståndet uttryckligen återställas på båda noderna och kontrolleras separat efter en återställning från säkerhetskopia. Aktivera en AD-återgång först när Entra-synkroniseringen för samma domän har avslutats kontrollerat.

Följande AD-steg och exempel behålls som en separat, äldre SFOS 22-väg. Identifieringen via AD beskrivs även i SFOS 23-hjälpen, men ersätter där inte Entra-kontrollen.

SFOS 22 med AD: Synchronized User ID i åtta steg

1. Välj en Windows 10-domänklient med Sophos Endpoint som pilot.
2. Kontrollera Sophos Fusion (tidigare Sophos Central), Security Heartbeat och brandväggslicensen.
3. Anslut Active Directory som autentiseringsserver till brandväggen.
4. Jämför UPN-domän, sAMAccountName, e-postadress och användarprofil mellan AD, Sophos Fusion och brandväggen.
5. Förbered en snävt avgränsad och loggad användarregel för en pilotgrupp.
6. Logga in på nytt i Windows på piloten och bekräfta ett grönt heartbeat.
7. Kontrollera användare, IP-adress och Client Type under Current activities > Live users samt den verkliga trafiken i Log Viewer.
8. Testa förlust av heartbeat, HA-beteende och en kontrollerad återgång innan fler endpoints läggs till.

När Synchronized User ID passar

Synchronized User ID är inte en allmän ersättning för alla Sophos autentiseringsmetoder. Den bevarade SFOS 22-AD-vägen passar när en hanterad Windows 10-endpoint normalt tillhör exakt en AD-användare och Sophos Endpoint redan skickar ett Security Heartbeat. För Entra-användare under SFOS 23 gäller förutsättningarna och valideringen i den separata grenen ovan.

Andra driftmodeller kräver andra metoder:

• STAS på Sophos Firewall kopplar Windows-inloggningar från domänkontrollanter, STA Agent och Collector till en klient-IP.
• SATC för Remote Desktop Services skiljer flera sessioner bakom samma RDS- eller Citrix-IP.
• Per-Connection AD SSO skiljer HTTP- och HTTPS-anslutningar från flera användare via Direct Web Proxy.
• Captive Portal eller Client Authentication Agent passar när en interaktiv inloggning krävs.

Tvinga inte in ett server- eller terminalserverscenario i Synchronized User ID. Sophos anger uttryckligen att Server Protection inte stöds. Om flera användare delar samma IP eller om andra anslutningar än webbtrafik måste kopplas per session passar SATC bättre.

Om Synchronized User ID och STAS är konfigurerade samtidigt använder autentiseringsservern enligt Sophos den metod vars inloggningsbegäran kommer först. Behandla inte denna samexistens som en fast prioritet. Avgränsa piloten entydigt och kontrollera Client Type vid varje validering.

Så fungerar AD-kopplingen

Förloppet består av fyra separata nivåer:

1. Användaren loggar in på Windows-domänklienten.
2. Sophos Endpoint skickar domänanvändaren till brandväggen via Security Heartbeat.
3. Brandväggen läser domänen från UPN och användarnamnet från sAMAccountName.
4. Brandväggen validerar användaren mot rätt Active Directory-server och aktiverar användaren för användarbaserade regler.

Funktionen autentiserar inte lokala Windows-användare och ersätter inte en AD-anslutning. Om UPN-domänen, katalogservern eller användarprofilen inte stämmer överens kan en grön endpoint fortfarande sakna en användbar användaridentitet.

Sophos Firewall delar eller använder ingen lösenordsinformation i detta förlopp. Heartbeat överför domän- och användaruppgifterna som krävs för kopplingen, medan valideringen sker på den konfigurerade AD-servern.

AD-exempel och utbytbara värden

Förloppet använder följande dokumentationsvärden:

• Brandvägg: fw01.example.com
• AD-domän och UPN-suffix: example.com
• Windows-klient: WS-101
• Klient-IP: 10.20.30.101
• Användarnamn: anna.muster
• UPN: anna.muster@example.com
• sAMAccountName: anna.muster
• AD-grupp: SFOS-Internet-Users
• Pilotregel: LAN_User_Internet

example.com, WS-101, 10.20.30.101, användaren och gruppen är exempel och ska ersättas med de verkliga värdena. Objektnamnet är inte avgörande. Sophos Fusion, Windows, Active Directory och brandväggen måste entydigt koppla samma användare.

Förbered förutsättningarna

Kontrollera Sophos Fusion och Security Heartbeat

Brandväggen måste vara ansluten till Sophos Fusion och ha en giltig Network Protection-prenumeration. Piloten behöver Sophos Central Endpoint Protection med en utvärderingslicens eller fullständig licens. Dessa licenskrav kommer från SFOS 22-hjälpen för Security Heartbeat; registrering och baslinjen för heartbeat beskrivs i Anslut Sophos Firewall till Sophos Fusion.

Under System > Sophos Fusion måste registrering och Security Heartbeat vara aktiva. Piloten ska visas med en rimlig status i Control Center och Sophos Fusion. Upprätta först denna baslinje och kontrollera därefter identitetskopplingen.

Enligt SFOS 22-hjälpen för Security Heartbeat utbyter endpoint och brandvägg heartbeat-data via en krypterad TLS-anslutning till 52.5.76.173 på TCP 8347. Grön status betyder att Sophos-skyddet fungerar korrekt och att ingen aktiv eller inaktiv skadlig kod eller PUA har upptäckts. Det bevisar ännu inte att AD har validerat användaren. Vid anslutningsproblem ska transport, Fusion-tenant och endpointcertifikat kontrolleras separat från användarkopplingen.

Synchronized User ID är aktiverat som standard. Det finns därför ingen vanlig WebAdmin-inställning som först måste aktiveras för piloten. Shellkommandona längre ned används endast för kontrollerad avaktivering eller återaktivering.

Jämför Active Directory och användarattribut (AD-vägen)

Under Authentication > Servers måste en lämplig Active Directory-server finnas och vara nåbar. Anslut Active Directory till Sophos Firewall beskriver LDAPS, sökbas, gruppimport och serverordning.

Gå därefter till Authentication > Services > Firewall authentication methods och flytta AD-servern till Selected authentication server. SFOS 22-hjälpen för Authentication Services bekräftar att minst en server måste vara vald; om flera är valda behandlar brandväggen dem i den ordning som visas. Att bara lägga till servern under Servers räcker inte för brandväggsautentisering.

Åtminstone följande värden måste stämma överens för piloten:

• Domänen i UPN motsvarar domänen för den AD-server som brandväggen använder.
• sAMAccountName är unikt i Active Directory och kan hittas av brandväggen.
• Användarprofil och e-postadress stämmer överens mellan AD, Sophos Fusion och brandväggens lokala användarpost.
• Den nödvändiga AD-gruppen är importerad och kopplad till rätt användarprofil i brandväggen.

Ett avvikande UPN-suffix, dubbla sAMAccountName-värden i olämpliga sökområden eller en AD-server som inte matchar är stoppsignaler. Kompensera inte med en bredare användarregel.

Förbered pilotregeln

Klicka under Rules and policies > Firewall rules på Add firewall rule > New firewall rule och skapa en snävt avgränsad regel för pilotgruppen, eller använd en befintlig användarregel på ett kontrollerat sätt. Aktivera Match known users i avsnittet för användaridentitet innan du väljer Users or groups:

• Source zones: faktisk klientzon
• Source networks and devices: pilotnät eller ett snävare källintervall
• Users or groups: SFOS-Internet-Users
• Destination zones: endast den nödvändiga destinationsvägen
• Services: endast tjänsterna som behövs för testet
• Log firewall traffic: aktiverat

Regelordning, loggning och det negativa testet är viktigare än en bred tillåtelseregel. Skapa Sophos Firewall-regler korrekt beskriver konfigurationen.

Logga in och validera AD-piloten

1. Logga ut den befintliga användaren helt från pilotklienten.
2. Logga in på nytt i Windows som anna.muster@example.com.
3. Kontrollera ett grönt heartbeat i Sophos Fusion och på brandväggen.
4. Sök efter anna.muster och 10.20.30.101 under Current activities > Live users.
5. Bekräfta att användare, IP-adress och Client Type: Heartbeat visas.
6. Starta ett tillåtet trafiktest via LAN_User_Internet.
7. Öppna Log viewer uppe till höger, välj brandväggsmodulen och jämför användarnamn, källa, destination, tjänst, Firewall Rule ID, åtgärd och tid.
8. Utför ett negativt test med en användare utanför pilotgruppen.

En post under Live users bevisar endast identitetskopplingen. Endast det loggade testflödet bevisar att rätt användarregel också tillämpas. Om trafikloggen bara visar IP-adressen eller flödet träffar en annan Rule ID ska regeln inte breddas. Kontrollera kopplingen och ordningen.

Testa medvetet förlust av heartbeat

Om Security Heartbeat saknas eller försvinner vid övergång mellan viloläge och väckning loggar brandväggen ut användaren som identifierats via Synchronized User ID. Andra konfigurerade autentiseringsmetoder kan fortfarande gälla, men användarbaserad trafik kan avbrytas fram till nästa inloggning.

För ett kontrollerat test:

1. Dokumentera först den aktiva användaren, IP-adressen, heartbeatstatusen och regeln.
2. Försätt piloten i viloläge och väck den igen.
3. Kontrollera heartbeatstatus och Live users på nytt.
4. Starta ett nytt trafiktest och bekräfta den användare och Rule ID som faktiskt används.
5. Kontrollera endpoint, sökväg och loggar vid avvikelser i stället för att förebyggande avaktivera Synchronized User ID globalt.

Ett Missing Heartbeat betyder inte automatiskt skadlig kod. Felsök Missing Heartbeat-varningar systematiskt beskriver hela diagnosvägen.

Tolka versionsinformationen för SFOS 22 och kända begränsningar

Vid valideringen är installerad Maintenance Release viktig, inte bara ”SFOS 22”. Den här aktuella artikeln om Synchronized User ID dokumenterar själv de två konkreta NC-påståendena. Kontrollen före uppgradering till SFOS 22 ansvarar här endast för kontroll av version och build, godkänd uppgraderingsväg och ändringsförberedelser. Produktkorrigeringarna är: MR1 Build 490 åtgärdar fördröjd internetåtkomst efter manuellt utlöst HA-failover med heartbeat-autentisering (NC-165361); MR2 Build 546 åtgärdar felaktiga Missing Heartbeat-rapporter när två endpoints delar samma dockningsstation eller USB-gränssnitt (NC-176012). Om något av symptomen uppstår på en äldre 22.0-build ska den exakta builden först dokumenteras och en godkänd uppdateringsväg bedömas.

Runbooken för felsökning av Missing Heartbeat behandlar också NC-147863: vid SSL VPN split tunneling till en extern brandvägg kan en ny VPN-adapter avbryta heartbeat-anslutningen. Användaren förlorar då heartbeat-autentiseringen och kan hamna i en anslutnings- och frånkopplingsloop. Om piloten omfattar detta scenario ska det testas separat. Som lösning anger Sophos att Match known users ska inaktiveras i den lokala brandväggens VPN-regel eller att Captive Portal ska användas för autentisering. Begränsa först ändringen till den berörda VPN-regeln och dokumentera effekten och återgången.

Avgränsa fel systematiskt

Endpointen visas inte med ett grönt heartbeat

Kontrollera först Fusion-registrering, endpointlicens, Network Protection-licens, brandväggskoppling, DNS, tid och nätverksväg. Utan fungerande Security Heartbeat kan Synchronized User ID inte överföra en identitet.

Användaren saknas under Live users

För AD-vägen ska Windows-inloggning, UPN, sAMAccountName, AD-server, sökområde och användarprofil kontrolleras tillsammans. Ett grönt heartbeat bekräftar endpointanslutningen, inte automatiskt en lyckad AD-validering. För Entra-användare under SFOS 23 ska du i stället använda kontrollen av UPN, konto och nåbarhet i Entra-grenen.

Fel användare eller fel grupp

För AD ska UPN-domän, AD-sökområde, importerad grupp, Main Group och lokala användarobjekt jämföras. För Entra under SFOS 23 gäller dessutom Entra-medlemskapet och UPN-kopplingen i den separata grenen. Ta inte bort användarobjekt innan beroenden till VPN, Portal, regler, kvoter och rapportering har kontrollerats.

Användaren är synlig men regeln gäller inte

Kontrollera källzon, källnät, användare eller grupp, tjänst, destination och regelordning. I Log Viewer måste det verkliga flödet visa förväntad Firewall Rule ID. En synlig identitet bekräftar inte ensam behörigheten.

Server eller obekräftad Windows-version

Server Protection stöds inte för någon av vägarna. SFOS 22-hjälpen nämner uttryckligen Windows 10 för AD; SFOS 23-sidan anger ingen specifik operativsystemsversion. Dra inte slutsatsen att andra operativsystem, anslutningsmodeller eller okända endpointtyper är godkända för produktion utifrån att dokumentationen finns tillgänglig eller hur en enskild pilot beter sig.

Läs relevanta loggar

Dessa kontroller ändrar inget och är användbara i Advanced Shell:

cd /log
tail -n 200 heartbeatd.log
tail -n 200 access_server.log
tail -n 200 hbtrust.log

heartbeatd.log visar heartbeat-händelser, access_server.log hjälper vid autentisering och behörighetskontroll och hbtrust.log vid förtroenderelationen till Sophos Fusion. En enda logg är inte ett fullständigt bevis. Spara tidsfönster, användare, endpoint, IP, Rule ID och berörd HA-nod tillsammans. Sophos Firewall-loggfiler och tjänster beskriver fler loggvägar.

Om det fortfarande är oklart om katalogen, metoden, den lokala användarposten eller regeln brister ger Felsök autentiseringsfel systematiskt en metodövergripande diagnosordning.

Avaktivera funktionen kontrollerat

⚠️ Följande kommandon ändrar autentiseringstillståndet och startar om access_server. Dokumentera först aktiva användare, berörda regler, en alternativ åtkomstmetod och återgången. I HA måste båda noderna hanteras medvetet.

De officiella instruktionerna för SFOS 22 och SFOS 23 anger dessa kommandon för bestående avaktivering:

touch /content/no_userid
service access_server:restart -ds nosync

Denna variant avaktiverar funktionen endast till nästa omstart av brandväggen:

touch /tmp/no_userid
service access_server:restart -ds nosync

Ta bort den bestående filen och starta om tjänsten för att aktivera funktionen igen:

rm /content/no_userid
service access_server:restart -ds nosync

Kontrollera efter varje ändring en ny Windows-inloggning, Live users, den verkliga trafiken och loggarna. Det avaktiverade tillståndet sparas inte i konfigurationssäkerhetskopior. Efter en återställning ska det avsedda tillståndet kontrolleras igen och vid behov ställas in på båda HA-noderna.

HA, säkerhetskopior och drift

I ett HA-kluster aktiveras eller avaktiveras Synchronized User ID på båda enheterna. Varje nod lagrar endast loggar för trafik och händelser som den själv behandlar. Vid en incident ska därför noden som var aktiv eller behandlade trafiken vid tidpunkten kontrolleras.

Ett kontrollerat HA-test kräver en ny Windows-inloggning och ett nytt trafikflöde. Förutsätt inte att användartillstånd eller aktiva sessioner fortsätter utan avbrott. Efter failover ska minst heartbeat, Live users, användarregeln och loggarna valideras på nytt.

Tillståndet för /content/no_userid ingår inte i en säkerhetskopia. Detta undantag måste dokumenteras uttryckligen i driftrutiner, återställningstester och RMA-processen.

Återställning

1. Dokumentera aktuellt tillstånd för heartbeat, användare, regel och HA.
2. Avaktivera pilotregeln eller återställ dess dokumenterade tidigare tillstånd.
3. Återställ det dokumenterade tidigare tillståndet kontrollerat endast om funktionens globala tillstånd ändrades under testet. För en avsedd återaktivering efter bestående avaktivering ska /content/no_userid tas bort och access_server startas om; aktivera inte generellt en funktion som tidigare var avaktiverad. Enligt Sophos upphör den tillfälliga varianten vid nästa omstart av brandväggen. Starta inte om enbart för teststädning utanför ett godkänt underhållsfönster.
4. Upprätta samma avsedda tillstånd på båda HA-noderna.
5. Logga in på nytt i Windows på piloten och kontrollera heartbeat och Live users.
6. Testa användarregeln och den alternativa autentiseringsvägen på nytt med verklig trafik.
7. Ta först därefter bort tillfälliga testobjekt eller pilottilldelningar.

Checklista för SFOS 22-AD-vägen

• Piloten är en Windows 10-domänklient med stöd och Sophos Endpoint.
• Brandväggen, endpointen och Security Heartbeat är synliga i Sophos Fusion.
• Network Protection- och endpointlicenserna är giltiga.
• AD-server, UPN-domän, sAMAccountName, e-postadress och användarprofil stämmer överens.
• Pilotgruppen är importerad och användarregeln är snävt avgränsad och loggad.
• Live users visar förväntad användare och rätt klient-IP.
• Den verkliga trafiken träffar förväntad Firewall Rule ID.
• Förlust av heartbeat och viloläge eller väckning har testats kontrollerat.
• HA-noder, loggar, återställningsbegränsning och återgång är dokumenterade.
• Synchronized User ID har inte överutnyttjats som ersättning för SATC, STAS eller andra katalogtjänster.

Vanliga frågor