Konfigurera Per-Connection AD SSO för fleranvändarvärdar i Sophos Firewall

Flera användare arbetar på samma Remote Desktop Session Host, men Sophos Firewall ser bara en server-IP för alla anslutningar. Per-Connection AD SSO löser just detta specialfall för webbtrafik: Direct Web Proxy autentiserar varje HTTP- och HTTPS-anslutning separat med Kerberos eller NTLM.

Funktionen är inte begränsad till Windows RDS: även en Linux-server med flera användare kan använda denna anslutningsmodell, förutsatt att dess klienter stöder Direct Web Proxy och Kerberos eller NTLM. Detta exempel går igenom en Windows-RDS-pilot; Windows-kommandona och GPO-distributionen är inte en Linux-guide. Värdar utanför listan Multi-user hosts behåller sin tidigare konfigurerade IP-baserade autentisering.

Begränsningen är lika viktig som funktionen. Endast anslutningar som webbläsaren eller programmet uttryckligen skickar till proxyn får en användaridentitet. DNS, RDP, SMB och annan trafik utanför proxyn från samma server-IP förblir oautentiserad. Om även dessa protokoll måste styras per användare är SATC för Remote Desktop Services lämpligare.

⚠️ Så snart en IP-adress läggs till under Multi-user hosts använder den inte längre andra IP-baserade autentiseringsmetoder. STAS, Captive Portal, Clientless User och transparent AD SSO upphör att gälla för denna IP-adress. Testa därför först med exakt en pilotserver och dokumentera den befintliga autentiseringsvägen.

Per-Connection AD SSO i nio steg

1. Avgör om det verkligen bara är HTTP och HTTPS via en explicit proxy som ska behandlas per användare.
2. Kontrollera Active Directory, gruppimport, DNS, tid och brandväggens domänanslutning.
3. Förbered ett brandväggs-FQDN som kan lösas upp och ett matchande HTTP-SPN för Kerberos.
4. Bedöm först omfattning och säkerhetspåverkan; aktivera sedan AD SSO för den nödvändiga LAN-zonen under Administration > Device access och välj Apply. Begränsa Web proxy separat till pilotvärden med ett riktat ACL-undantag där det stöds; ett Accept-undantag begränsar inte en zonbehörighet. Om den nödvändiga behörigheten är oacceptabel, stoppa införandet och ta fram en stödd, avgränsad utformning.
5. Skapa RDS-servern som ett värdobjekt med exakt IP-adress.
6. Aktivera Per-Connection AD SSO för denna värd under Authentication > Web authentication.
7. Konfigurera webbläsare och proxykompatibla program med brandväggens FQDN och port 3128.
8. Placera en separat, loggad värdregel före konkurrerande användarregler och låt Match known users vara inaktiverat.
9. Kontrollera två parallella RDS-sessioner, olika resultat från webbpolicyer och trafik utanför proxyn separat.

Per-Connection AD SSO, STAS eller SATC?

Alla tre metoderna ger användarkontext, men löser olika uppgifter.

• STAS passar vanliga Windows-klienter när en klient-IP normalt tillhör exakt en användare. Brandväggen får en koppling mellan användare och IP-adress från Windows inloggningshändelser.
• Per-Connection AD SSO passar fleranvändarvärdar när endast HTTP- och HTTPS-anslutningar som uttryckligen skickas via proxyn behöver särskiljas. Ingen SATC-agent behövs på RDS-servern, men alla program måste använda Direct Web Proxy på ett tillförlitligt sätt.
• SATC passar Windows-RDS-system som stöds när även andra anslutningstyper från de enskilda användarsessionerna behöver en identitet. För detta krävs Sophos Server Protection på sessionsvärden. Den aktuella Sophos-guiden ger inget stöd för en ny Citrix-utrullning; befintliga Citrix-installationer bör stämmas av med Sophos Support före ändringar.

Klassisk STAS på Sophos Firewall kan inte skilja mellan flera användare bakom samma RDS-IP. Per-Connection AD SSO och SATC är därför inte bekvämare varianter av STAS, utan egna driftmodeller. Även SATC kopplar endast användarbaserade processer till användare; anslutningar som skapas av systemtjänster behöver fortfarande en egen regel utan Match known users. Om ett program inte stöder en explicit proxy eller om andra protokoll än webbprotokoll ska regleras per användare, stanna här och undersök SATC.

Exempel och värden som ska ersättas

Proceduren använder följande exempel:

• Fleranvändarvärd: RDS01
• IP-adress: 10.20.30.40
• Brandväggens FQDN och proxymål: fw01.corp.example
• Direct Web Proxy-port: 3128
• AD-grupper: RDS-Web-Standard och RDS-Web-Restricted
• ett pilotkonto per grupp med avsiktligt olika resultat från webbpolicyerna

10.20.30.40 ersätts med pilotserverns fasta IP-adress som är synlig för brandväggen. Inga andra system får också visas bakom denna adress via NAT. fw01.corp.example är ett dokumentationsnamn och måste ersättas med brandväggens verkliga FQDN som kan lösas upp internt. Värddelen bör vara högst 15 tecken lång och skrivas med små bokstäver, så att värdnamn, NetBIOS-namn, AD-datorobjekt och SPN stämmer överens.

Port 3128 är standard för Direct Web Proxy. Om en annan lyssningsport används i den egna miljön måste brandvägg, PAC-fil eller GPO, webbläsare och tester använda samma värde. Exempelgrupperna används bara för en tydlig acceptanskontroll; gruppnamn och webbpolicyer måste passa den egna behörighetsstrukturen.

Förbered förutsättningarna

Kontrollera Active Directory och domänanslutning

Brandväggen behöver en fungerande Active Directory-server, importerade grupper och en lyckad domänanslutning. Anslut Active Directory till Sophos Firewall förklarar LDAPS, sökbas, gruppimport och de allmänna förutsättningarna för AD SSO.

Om AD-servern ännu inte är konfigurerad väljer du typen Active Directory under Authentication > Servers > Add. Ange servernamn, en nåbar DC-IP eller DC-FQDN, NetBIOS-domän, AD-domän och sökbas för den egna miljön. För corp.example är sökbasen dc=corp,dc=example. Kryptera anslutningen med SSL/TLS på port 636 eller STARTTLS på port 389 och förbered certifikatkontrollen enligt den länkade AD-proceduren. Ange läs-/anslutningskontot med de rättigheter som beskrivs nedan, kör Test connection och spara med Save. Ersätt inte en AD-server som redan används enbart för piloten och ändra inte dess inloggningsuppgifter utan kontroll. Om domänen kräver strikt LDAP-kanalbindning eller LDAP-signering ska kompatibiliteten klarläggas enligt AD-proceduren före utrullningen; Sophos hjälp för AD-servern anger en begränsning för detta. Inaktivera inte något domänomfattande skyddskrav för att felsöka.

Vid gruppimport markeras automatiskt alla grupper i en organisationsenhet (OU) när den väljs. Attach to all the Groups tilldelar de valda gemensamma policyerna till varje grupp som guiden importerar. Kontrollera därför före slutförandet den grupplista som utökats genom OU-valet och dessa policyers omfattning; ta bara med de grupper som faktiskt behövs och de avsedda policytilldelningarna.

För piloten öppnar du Import för AD-servern under Authentication > Servers > Manage, börjar med Start i Import group wizard och väljer lämplig Base DN. För exempeldomänen corp.example är den dc=corp,dc=example; det är domändelarna som ska ersättas, inte LDAP-syntaxen. Välj RDS-Web-Standard och RDS-Web-Restricted, kontrollera den gemensamma policytilldelningen och sammanfattningen, slutför guiden och stäng med Close. Kontrollera därefter under Authentication > Groups att båda grupperna verkligen finns. En lyckad domänanslutning i sig importerar inte de policygrupper som behövs.

För vanliga LDAP-frågor räcker ett konto med läsrättigheter. Domänanslutningen och skapandet av SPN kräver däremot ett domänadministratörskonto eller ett konto med korrekt delegerade rättigheter. Det registrerade kontot måste även tillåta en senare återanslutning till domänen, eftersom HA, ytterligare AD-servrar eller uppgraderingar kan utlösa en sådan. Ett obegränsat domänadministratörskonto bör inte användas permanent för detta i onödan.

Välj den avsedda AD-servern under Authentication > Services > Firewall authentication methods och placera den i rätt ordning. Om det finns flera servrar kontrollerar brandväggen dem uppifrån och ned. Test connection på AD-servern bekräftar endast inloggningsuppgifter och nåbarhet, inte den senare Kerberos- eller NTLM-inloggningen i webbläsaren.

Välj Default group medvetet i samma område och spara med Apply. Om den AD-grupp som behövs inte är importerad kan en korrekt autentiserad användare hamna i standardgruppen i stället för att få önskad gruppolicy. Användare i en OU utan medlemskap i en kataloggrupp kan visas i Open group. Vid medlemskap i flera grupper kan den första matchande gruppen avgöra policyn; kontrollera därför inte bara importen utan även ordningen och den faktiska tilldelningen. Använd därför inte en standardgrupp med omfattande behörigheter som ersättning för en saknad import i piloten. Kontrollera den faktiska grupptilldelningen under Authentication > Users vid den första nya inloggningen; ett användarobjekt behöver inte vara synligt före denna inloggning.

Kontrollera FQDN, DNS, SPN och tid

Kerberos fungerar endast när klienterna använder brandväggens FQDN som proxymål. En proxy-IP-adress räcker inte för detta. På en Windows-pilotklient kan följande läsande kontroller användas:

Resolve-DnsName fw01.corp.example
setspn -Q HTTP/fw01.corp.example
w32tm /query /status

HTTP-SPN, utskrivet Service Principal Name, binder proxyns FQDN till brandväggens AD-datorobjekt. setspn -Q bör ge exakt en matchande koppling. Ingen träff eller flera träffar måste utredas före utrullningen.

DNS-suffixet som konfigurerats i värdnamnsfältet är inte automatiskt AD-suffixet: vid domänanslutningen bildar brandväggen AD-datornamnet och SPN från sitt NetBIOS-namn och AD-domänen. Om DNS-domänen och AD-domänen skiljer sig åt ska det FQDN som registrerats på AD-datorobjektet jämföras med det planerade proxymålet. Exemplet förutsätter ett matchande SPN för fw01.corp.example; att bara ange detta namn under Admin and user settings bevisar inte att det finns. Klarlägg först DNS och SPN gemensamt för det faktiska proxymålet och distribuera därefter proxykonfigurationen. Skapa inte ytterligare SPN på chans.

DNS-svaret måste peka på den avsedda brandväggen. Klient, domänkontrollant och brandvägg behöver dessutom en tid som uppfyller Kerberos krav. Kommandona ändrar ingenting. Korrigera inte SPN, domänanslutning eller tidskonfiguration på chans, utan fastställ först det faktiska felet.

Kartlägg proxystöd och undantag

Varje webbläsare och varje program vars webbtrafik ska få en användaridentitet måste använda den explicita proxyn och stödja Kerberos eller NTLM; i Windows-RDS-exemplet sker detta via integrerad Windows-autentisering. Kontrollera åtminstone följande före utrullningen:

• Webbläsare i varje RDS-session som stöds
• Program med egen HTTP-stack
• Windows- och programuppdateringar
• Tjänster som körs i systemkontext i stället för i en användarsession
• Mål som finns i PAC-filen eller listan för proxyundantag

Trafik som kringgår proxyn förblir utan användar-ID, vilket är förväntat. Planera en separat, strikt begränsad regel utan användarkoppling för nödvändiga maskinanslutningar. En bred Any-regel skulle försvaga säkerhetseffekten av användar- och webbpolicyerna.

Konfigurera Per-Connection AD SSO

1. Förbered brandväggens FQDN och AD SSO

Ange brandväggens avsedda FQDN under Administration > Admin and user settings och spara med Apply. Välj därefter alternativet Kerberos & NTLM vid If Active Directory (AD) SSO is configured under Authentication > Web authentication och spara även där med Apply. NTLM stöds tekniskt som reservmetod; Kerberos är snabbare och säkrare och bör fungera tillförlitligt i piloten. Eftersom varje proxyanslutning kan utlösa en autentisering bör även inloggningsfel, svarstider och belastningen på brandvägg och AD observeras under representativ trafik före en större utrullning. Dra inte slutsatser om någon fast belastningsmultiplikator eller garanterad användarkapacitet utifrån detta.

Om klientenheterna inte är korrekt konfigurerade för Kerberos eller om webbläsaren inte stöder Kerberos-autentisering används automatiskt NTLMv2 som reservmetod. Till skillnad från Kerberos behöver NTLMv2 inget FQDN som proxymål. Denna kompatibilitetsreserv garanterar dock inte en lyckad inloggning: autentiseringskanalerna som beskrivs nedan måste vara initierade, och den faktiska inloggningsvägen ska kontrolleras med pilotkontona.

Efter initieringen av AD SSO måste följande meddelanden om lyckat resultat visas under Authentication i Log Viewer:

• Kerberos authentication initialized successfully
• NTLM authentication channel established successfully

Brandväggen erbjuder metoderna först när båda kanalerna fungerar. Cannot initialize Kerberos authentication eller Cannot establish NTLM authentication channel är stoppsignaler, inte en uppmaning att starta om en tjänst på chans.

2. Begränsa åtkomsten i Device Access

Sophos kräver att AD SSO aktiveras för den nödvändiga LAN-zonen under Administration > Device access och tillämpas med Apply som förutsättning för Kerberos/NTLM. Bedöm först zonbehörighetens omfattning och säkerhetspåverkan; öppna inte hela LAN-zonen utan denna granskning. Om AD SSO är inaktiverat i alla zoner fungerar inte Kerberos/NTLM. Ett AD-SSO-ACL-undantag för enbart en värd ersätter inte denna förutsättning. Ett extra Accept-undantag kan inte heller begränsa en befintlig zonbehörighet. Om den nödvändiga behörigheten är oacceptabel, stoppa införandet och inhämta en stödd, avgränsad utformning för den installerade versionen från ACL-ansvarig eller Sophos Support. Begränsa separat åtkomsten till Web proxy från källan till pilotvärden med en riktad Local service ACL exception rule, där det stöds. Ett Accept-undantag begränsar inte en befintlig zonövergripande Web-proxybehörighet; den breda proxybehörigheten får inte vara kvar om åtkomsten verkligen ska begränsas till värden. Aktivera inga andra zoner eller tjänster i onödan. Hela upplägget förklaras i Device Access och Local Service ACL.

Åtkomst till webbproxyn har en viktig sidoeffekt: en tillåten värd kan nå brandväggens HTTP- och HTTPS-tjänster via proxyn, även om deras zon inte är tillåten i den vanliga Local Service-matrisen. Gör därför negativa tester av WebAdmin, User Portal och andra lokala mål från pilotvärden. Om denna exponering inte är acceptabel i det egna nätverket ska lösningen inte aktiveras i produktion.

Kontrollera den faktiska Web proxy listening port och de tillåtna målportarna under Web > General settings. Ändra standardvärdet 3128 endast om PAC-fil, GPO och alla hanterade program kan anpassas konsekvent.

3. Skapa fleranvändarvärden

Skapa ett nytt värdobjekt på följande sökväg:

Hosts and services > IP host > Add

För exemplet används följande värden:

1. Name: RDS01
2. IP version: IPv4
3. Type: IP
4. IP address: 10.20.30.40

Spara med Save och kontrollera att objektet innehåller exakt pilotens IP-adress innan det väljs i fleranvändarlistan.

Ange inte ett helt intervall eller ett undernät för det första testet. Annars kan många system samtidigt förlora sin tidigare IP-baserade autentisering. Flera värdar som godkänns senare kan efter lyckad individuell acceptanskontroll sammanföras kontrollerat i en värdgrupp.

4. Aktivera Per-Connection AD SSO

Gå till följande område:

Authentication > Web authentication > Authentication settings for direct web proxy

Gör sedan följande:

1. Aktivera Use per-connection AD SSO authentication for multi-user hosts.
2. Lägg till objektet RDS01 under Multi-user hosts med Add new item.
3. Spara med Apply.

Från detta ögonblick är STAS, Captive Portal, Clientless User och transparent AD SSO inte längre tillgängliga för 10.20.30.40. Genomför därför ändringen under ett underhållsfönster och använd inte en befintlig RDS-session som enda test.

Valfri API-mappning för automatisering

Den som vill automatisera detta GUI-steg hittar entiteten DirectWebProxyAuthentication i API-referensen för SFOS 22.0 och 23.0. Där kopplas omkopplaren och fleranvändarlistan till följande parametrar; denna mappning är inte en fullständig körbar begäran.

• DirectWebProxyAuthentication > PerConnectionAuth motsvarar på-/av-omkopplaren för Per-Connection AD SSO. Parametern är dokumenterad som en icke-obligatorisk SCALAR och tillåter endast Enable eller Disable. Skrivsättet med snedstreck i referensexemplet anger alternativ, inte ett tredje tillåtet värde.
• DirectWebProxyAuthentication > MultiUserHosts > Host beskriver listan med namn på fleranvändarvärdar, alltså i exemplet namnet på det tidigare skapade värdobjektet RDS01, inte dess IP-adress. Host är icke-obligatoriskt och dokumenterat som ARRAY med datatypen STRING. Flera värden tillåts, och enligt referensen ignoreras dubbletter. Referensen anger högst 1500 tecken, men förklarar inte om gränsen gäller per värde eller för hela listan.

Kolumnerna för standardvärden är tomma: det innebär varken att det finns ett dokumenterat standardvärde eller att det framgår vad som händer när fält utelämnas. Operationsavsnittet beskriver inte heller om en skickad lista kompletterar eller ersätter befintliga poster, eller hur poster tas bort. Tolka därför varken utelämnande eller en tom lista som en säker återställningsväg; det konkreta beteendet vid uppdatering och borttagning måste klarläggas för den build som används innan automatisering införs.

Statustabellen innehåller 200 och 500. Dessa API-poster bevisar varken HTTP-status eller lyckad användar- och policybehandling. Meddelandefälten hänvisar till JavaScript; det tillhandahållna operationsavsnittet innehåller inga ordagranna svarsmeddelanden.

Även vid en senare auktoriserad API-ändring gäller förutsättningarna ovan och den strikt avgränsade piloten med en enda värd. Spara först de faktiska inställningarna på ett säkert sätt och ha en oberoende administrationsåtkomst tillgänglig. Läs därefter ut omkopplarens läge och hela fleranvändarlistan igen från exakt den brandvägg som ändrats och jämför med det avsedda tillståndet; genomför sedan de positiva och negativa tester av proxy, användare, policyer, trafik utanför proxyn och lokala tjänster som beskrivs nedan. Ett accepterat konfigurationssvar ersätter inte denna acceptanskontroll. För återställning ska det sparade tidigare tillståndet återställas, utan att någon obestyrkt API-syntax för borttagning härleds ur detta.

5. Distribuera Direct Web Proxy

Ställ in webbläsarens eller systemets proxy via GPO, PAC-fil eller ett hanterat program till följande värde:

fw01.corp.example:3128

För Kerberos måste exakt det FQDN som matchar SPN användas. En IP-adress som proxymål, ett kortnamn som inte kan lösas upp eller ett annat alias leder ofta till NTLM som reservmetod eller en inloggningsfråga. Håll undantagslistorna medvetet små och dokumentera dem, eftersom varje anslutning som kringgår proxyn saknar Per-Connection-identitet.

Den allmänna konfigurationen av lyssnare, PAC, regler och återställning finns i Konfigurera Direct Web Proxy med en PAC-fil. Den här artikeln kompletterar endast upplägget med fleranvändarautentisering.

6. Placera en separat brandväggsregel

Skapa en separat, tydligt namngiven utgående regel för RDS01 under Rules and policies > Firewall rules. Den måste ligga före regler som omfattar samma värd med Match known users.

Välj IPv4 > Add firewall rule > New firewall rule för detta IPv4-exempel. Ange exempelvis RDS01_DirectProxy_Outbound som Rule name och Accept som Action. Namnet är valfritt; det bör tydliggöra värd och syfte. Kontrollera placeringen före konkurrerande användarregler utifrån hela regellistan, inte bara utifrån namnet.

De säkra ramarna:

• Source zones: den faktiska RDS-zonen, till exempel LAN
• Source networks and devices: endast RDS01
• Destination zones: WAN
• Destination networks: endast de mål som behövs eller ett medvetet val av Any
• Services: HTTP, HTTPS och en egen TCP-tjänst för 3128 eller den proxylyssningsport som faktiskt är konfigurerad; Any endast som ett medvetet val. Att bara välja lyssningsporten är inte ett fullständigt tjänsteurval för Direct Web Proxy.
• Log firewall traffic: aktiverat
• Match known users: inaktiverat
• Web filtering > Web policy: välj en förberedd användar- eller gruppberoende policy

Webbpolicyer kan skilja mellan användare och grupper i proxytrafiken, men får effekt först när de tilldelats brandväggsregeln. Denna åtskillnad hör hemma i webbpolicyn, inte i Match known users för denna värdregel. Kontrollera omkopplaren igen efter att webbpolicyn valts eller ändrats, eftersom ett användarberoende kan aktivera den på nytt.

Spara med Save, öppna regeln igen och kontrollera Match known users, loggning, webbpolicy och placering. Värdregeln tillåter den avsedda trafikvägen; webbpolicyn avgör vad användare och grupper får göra inom denna väg. En korrekt identifierad användare innebär därför inte automatiskt rätt behörighet.

Den allmänna AD-SSO-guiden beskriver även användarregler med Match known users aktiverat. Det är inte regelmodellen för den fleranvändar-IP som anges här: den specifika Per-Connection-guiden kräver uttryckligen en egen regel med denna omkopplare inaktiverad. Kopiera inte heller tjänstematchningen från en transparent HTTP-/HTTPS-regel: proxylyssningsporten beskriver vägen från klient till proxy, medan en separat anslutning från proxy till mål använder måltjänster som HTTP eller HTTPS. Bekräfta den faktiska Rule ID och rätt port i piloten med hjälp av loggarna. En IPv6-klient med ett IPv4-mål kan behöva två regler; detta IPv4-exempel är inte en fullständig dual-stack-guide för det.

Skapa en separat maskinregel för DNS, uppdateringar och andra nödvändiga anslutningar utanför proxyn. Lägg inte till någon generell WAN-till-LAN-regel; det exempel på inkommande trafik som Sophos visar behövs inte för normal RDS-webbåtkomst och skulle skapa onödig angreppsyta utan ett eget publiceringssyfte. Upplägg, ordning och loggning förklaras i Skapa brandväggsregler på rätt sätt.

Om det oberoende av proxyn finns ett motiverat behov av inkommande åtkomst till fleranvändarvärden ska Match known users vara inaktiverat även i dess egen regel. Begränsa källzon och tillåtna källvärdar, målzon och RDS01 samt de tjänster som faktiskt behövs, aktivera loggning och kontrollera placeringen före konkurrerande användarregler. Detta är inte en uppmaning att exponera RDP publikt; för normal webbåtkomst skapas ingen ny regel för inkommande trafik.

Genomför acceptanskontroll med två RDS-användare

Ett enda lyckat webbläsaranrop visar bara att någon form av proxytrafik fungerar. Den egentliga acceptanskontrollen kräver två parallella sessioner.

1. Tilldela två AD-pilotkonton till olika webbpolicygrupper.
2. Öppna två nya RDS-sessioner på RDS01.
3. Kontrollera den effektiva proxykonfigurationen i båda sessionerna.
4. Gör i varje session ett tillåtet HTTP- eller HTTPS-anrop och ett som avsiktligt behandlas olika.
5. Kontrollera att båda användarna visas under Current activities > Live users med Client Type Multi-host client.
6. Kontrollera användare och Log Comp för Kerberos eller NTLM under Log viewer > Authentication.
7. Jämför användare, policy, Rule ID, åtgärd och tidpunkt i webb- och brandväggsloggen.
8. Utför ett nödvändigt test utanför proxyn och bekräfta att trafiken inte felaktigt får en användaridentitet.
9. Kartlägg från pilotvärden vilka lokala HTTP- och HTTPS-tjänster på brandväggen som kan nås via proxyn. Om en tjänst som inte är tillåten enligt säkerhetsdesignen kan nås ska utrullningen stoppas och återupptas först med en verifierad ytterligare skyddsåtgärd.

En meningsfull jämförelse använder samma godkända testmål i båda sessionerna: ett konto i RDS-Web-Standard får öppna det, medan ett konto i RDS-Web-Restricted blockeras av den förberedda webbpolicyn. Dokumentera datum, tid, användare, käll-IP, Rule ID, policy och resultat. Öppna därefter ett kontrollmål som båda grupperna får använda. På så sätt skiljer man en avsiktlig gruppbegränsning från ett generellt proxy- eller DNS-avbrott. Testmålen hämtas från den egna godkända testlistan; blockera inte en produktionssida som används i verksamheten enbart för acceptanskontrollen.

Lägg till fler RDS-värdar först när båda användarna skiljs åt korrekt samtidigt, de avsedda webbpolicyresultaten uppnås och trafikvägen utanför proxyn är klarlagd. För allmän acceptanskontroll av regler finns hjälp i Testa Sophos Firewall-regler kontrollerat.

Felsökning

Proxyn går inte att nå

Kontrollera FQDN-upplösning, port, PAC-/GPO-resultat, källzon och tillstånden Web proxy samt AD SSO. Ett lyckat AD-servertest bevisar inte att proxyn kan nås. För SD-WAN-rutter måste proxyporten eller Any matcha tjänsteurvalet; brandväggen skapar själv den externa proxyanslutningen, och därför gäller inte alla klientegenskaper på samma sätt som för vanlig routad trafik.

Webbläsaren frågar efter inloggningsuppgifter eller använder NTLM

Kontrollera proxymål, DNS, HTTP-SPN, webbläsarzon och integrerad autentisering. Kerberos behöver ett matchande FQDN, inte brandväggens IP-adress. Att NTLM används som reservmetod är ett symtom som först bör förklaras, inte ett skäl att förebyggande rulla ut en lösning med enbart NTLM.

Båda sessionerna visas som samma användare

Kontrollera att båda webbläsarna verkligen använder den explicita proxyn och om ett program skapar anslutningar utanför respektive användarsession. Även en framförliggande proxy eller NAT kan förändra den avsedda anslutningsmodellen. I Live Users måste typen Multi-host client visas; en vanlig IP-baserad koppling är fel väg för denna värd.

Användaren är synlig, men webbpolicyn får ingen effekt

Kontrollera AD-grupp, Main Group, webbpolicyordning, brandväggsregel och loggpost tillsammans. Match known users måste förbli inaktiverat i den särskilda värdregeln. En synlig autentisering bevisar ännu inte att begäran använder den förväntade webbpolicyn eller Firewall Rule ID.

Om pilotanvändaren finns i Default group i stället för i den förväntade importerade AD-gruppen ska du först kontrollera Authentication > Groups, sökbas och gruppimport. Tilldela inte en bredare standardgruppspolicy för att dölja felet. Kontrollera efter en kontrollerad korrigering med en ny inloggning att tilldelningen och båda policytesterna stämmer.

Trafik som inte är webbtrafik visar ingen användare

Detta är förväntat beteende. Per-Connection AD SSO identifierar endast HTTP och HTTPS via Direct Web Proxy. För nödvändig maskintrafik gäller en regel utan användarkoppling. Om RDP, SMB, databastrafik eller annan trafik utanför proxyn måste särskiljas per session ska du byta till SATC.

SSO fungerar inte längre efter uppgradering eller HA-failover

AD SSO kan behöva en ny domänanslutning efter en uppgradering, vid användning av flera AD-servrar eller i HA. Det delegerade anslutningskontot måste därför förbli giltigt. Testa efter en kontrollerad failover med en ny proxyanslutning och båda pilotkontona; förutsätt inte att befintliga proxyanslutningar eller Kerberos-biljetter fortsätter utan avbrott. I varje HA-läge lagrar varje nod endast loggar för den trafik som den själv har hanterat. Kontrollera därför för en viss händelse den nod som var aktiv eller hanterade trafiken vid den tidpunkten.

Vid en uppgradering från SFOS 21.5 eller äldre direkt till SFOS 22.0 GA Build 411 kan även det kända problemet NC-176853 vara aktuellt: NTLM- och Kerberos-AD-SSO kan sluta fungera direkt efter uppgraderingen, så att identitetsbaserade policyer inte matchar. Sophos anger SFOS 22.0 MR1 Build 490 som versionen med korrigeringen. Den interna proceduren för KBA-000048429 beskriver diagnos och tillfällig lösning. Known Issues List nämner inte Per-Connection AD SSO separat; problemet är därför bara relevant om den underliggande AD-SSO-vägen slutar fungera efter just denna uppgradering. Spara firmwarebuild, tidpunkt och loggar, kontrollera KBA:n för den berörda builden och kringgå inte problemet med breda regler eller ett byte av autentiseringsmetod.

Läs relevanta loggar

Följande filer är relevanta i Advanced Shell:

cd /log
tail -n 200 nasm.log
tail -n 200 access_server.log
tail -n 200 awarrenhttp.log

nasm.log visar NTLM-, Kerberos- och eventuella KVNO-problem. access_server.log hjälper vid autentisering och auktorisering, och awarrenhttp.log vid webbproxyproblem. awarrenhttp_access.log skapas endast när debugloggning är tillfälligt aktiverad och hör inte till det normala första steget. Spara först tidsintervall, användare, mål, regel och befintliga loggar innan tjänster startas om eller debugloggningen utökas.

Återställning

En korrekt återställning återställer inte bara proxyn utan även den tidigare autentiseringsmodellen.

1. Dokumentera aktuell fleranvändarlista, Device Access-undantag, regler, webbpolicy och proxydistribution.
2. Ta bort RDS01 från Multi-user hosts och spara med Apply.
3. Återställ proxy-GPO, PAC-fil eller programkonfiguration kontrollerat.
4. Återställ tidigare STAS-, Clientless- eller Captive Portal-koppling endast om den var dokumenterad i förväg och lämplig för denna IP-adress.
5. Ta bort pilotens ACL-undantag eller tillfälliga zontillstånd för AD SSO och webbproxy efter kontroll av andra beroenden, eller återställ dem exakt till tidigare tillstånd.
6. Inaktivera eller ta bort särskilda värd- och maskinregler när ersättningsvägen har bekräftats.
7. Testa igen med nya webbläsar- och RDS-sessioner samt, vid HA, i båda driftrollerna.

Checklista

• Per-Connection AD SSO är endast avsett för explicit HTTP-/HTTPS-proxytrafik.
• Pilotvärden har en fast, unik IP-adress utan andra system bakom den.
• AD, grupper, domänanslutning, FQDN, DNS, SPN och tid har kontrollerats.
• AD SSO:s zonförutsättning och säkerhetspåverkan granskade; nödvändig LAN-zon aktiverad och Apply valt, Web-proxyåtkomst separat begränsad till pilotvärden utan bred proxybehörighet. Om zonbehörigheten är oacceptabel, stoppa införandet och inhämta en stödd, avgränsad utformning.
• Webbläsare och program använder fw01.corp.example:3128 eller de egna ersättningsvärdena.
• Den särskilda värdregeln har loggning aktiverad och Match known users inaktiverat.
• Trafik utanför proxyn är planerad som maskintrafik eller lösningen har ändrats till SATC.
• Två parallella användare, olika policyer och administrationsåtkomst har testats med både positiva och negativa tester.
• HA-failover och uppgraderingar har en dokumenterad procedur för återanslutning till domänen och omtestning.
• Återställning av fleranvändarlista, proxydistribution, Device Access, regler och tidigare autentisering är dokumenterad.

Vanliga frågor