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.

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 endast HTTP och HTTPS via en explicit proxy ska behandlas per användare.
2. Kontrollera Active Directory, gruppimport, DNS, tid och brandväggens Domain Join.
3. Förbered ett upplösningsbart FQDN för brandväggen och ett passande HTTP-SPN för Kerberos.
4. Tillåt AD SSO och Web proxy endast för den nödvändiga källzonen eller pilotvärden.
5. Skapa ett exakt IP-värdobjekt för RDS-servern.
6. Aktivera Per-Connection AD SSO för värden under Authentication > Web authentication.
7. Konfigurera webbläsare och proxykompatibla program med brandväggens FQDN och port 3128.
8. Placera en egen loggad värdregel före konkurrerande användarregler och låt Match known users vara inaktiverat.
9. Testa två parallella RDS-sessioner, olika Web Policy-resultat och trafik utanför proxyn var för sig.

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 från Windows inloggningshändelser.
• Per-Connection AD SSO passar fleranvändarvärdar när endast explicit proxade HTTP- och HTTPS-anslutningar 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 RDS- eller Citrix-system när även andra anslutningstyper från de enskilda användarsessionerna behöver en identitet. Då krävs Sophos Server Protection på Session Host.

Klassisk STAS i Sophos Firewall kan inte skilja flera användare bakom samma RDS-IP. Per-Connection AD SSO och SATC är därför inte bekvämare varianter av STAS, utan separata driftmodeller. Om ett program inte stöder en explicit proxy eller om andra protokoll än webbprotokoll ska styras per användare bör arbetet stoppas här och SATC utvärderas.

Exempel och utbytbara värden

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
• port för Direct Web Proxy: 3128
• AD-grupper: RDS-Web-Standard och RDS-Web-Restricted
• ett pilotkonto per grupp med avsiktligt olika Web Policy-resultat

Ersätt 10.20.30.40 med pilotserverns fasta IP-adress så som brandväggen ser den. Inga andra system får visas bakom denna adress via NAT. fw01.corp.example är ett dokumentationsnamn och måste ersättas med brandväggens verkliga, internt upplösningsbara FQDN. Värddelen bör vara högst 15 tecken 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 den egna miljön använder en annan Listening Port måste brandväggen, PAC-filen eller GPO:n, webbläsarna och testerna använda samma värde. Exempelgrupperna används endast för ett tydligt acceptanstest; gruppnamn och Web Policies måste anpassas till den egna behörighetsstrukturen.

Förbereda förutsättningarna

Kontrollera Active Directory och Domain Join

Brandväggen behöver en fungerande Active Directory-server, importerade grupper och en lyckad Domain Join. Ansluta Active Directory till Sophos Firewall beskriver LDAPS, sökbas, gruppimport och de allmänna kraven för AD SSO.

För en vanlig LDAP-fråga räcker ett konto med läsbehörighet. Domain Join och skapandet av SPN kräver däremot ett Domain Admin-konto eller ett konto med korrekt delegerade rättigheter. Det sparade kontot måste även tillåta en senare rejoin, eftersom HA, ytterligare AD-servrar eller uppgraderingar kan utlösa den igen. Ett obegränsat Domain Admin-konto bör inte användas permanent 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.

Kontrollera FQDN, DNS, SPN och tid

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

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

HTTP-SPN, utskrivet Service Principal Name, kopplar proxyns FQDN till brandväggens AD-datorobjekt. setspn -Q ska ge exakt en passande koppling. Inget resultat eller flera resultat måste utredas före utrullningen.

DNS-svaret måste peka på den avsedda brandväggen. Klient, Domain Controller och brandvägg behöver dessutom en tid som är kompatibel med Kerberos. Kommandona ändrar ingenting. Ändra inte SPN, Domain Join eller tidskonfiguration på misstanke, utan belägg först det faktiska felet.

Inventera proxystöd och undantag

Varje webbläsare och program vars webbtrafik ska få en användare måste använda den explicita proxyn och stödja integrerad Windows-autentisering. Kontrollera minst 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 över proxyundantag

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

Konfigurera Per-Connection AD SSO

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

Ange brandväggens avsedda FQDN under Administration > Admin and user settings. Välj sedan Kerberos & NTLM vid If Active Directory (AD) SSO is configured under Authentication > Web authentication. NTLM stöds tekniskt som fallback, men i större installationer bör Kerberos fungera tillförlitligt eftersom Per-Connection AD SSO kan generera många ytterligare autentiseringsförfrågningar.

Efter initieringen av AD SSO ska följande lyckade meddelanden visas i Log Viewer under Authentication:

• Kerberos authentication initialized successfully
• NTLM authentication channel established successfully

Brandväggen erbjuder inte metoderna förrän 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 utan diagnos.

2. Begränsa Device Access noggrant

Under Administration > Device access måste AD SSO och Web proxy vara tillåtna för den avsedda källvägen. För en fast pilot-IP är en riktad Local service ACL exception rule oftast mer begränsad än en tillåtelse för hela LAN-zonen. Ett ytterligare Accept-undantag begränsar dock inte en zonåtkomst som redan är aktiv; i en verkligt strikt design måste den breda tillåtelsen förbli inaktiverad. Device Access och Local Service ACL beskriver hela konfigurationen.

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

Kontrollera faktisk Web proxy listening port och tillåtna målportar under Web > General settings. Ändra standardvärdet 3128 endast om PAC-filen, GPO:n och alla hanterade program kan anpassas konsekvent.

3. Skapa fleranvändarvärden

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

Hosts and services > IP host > Add

Exemplet använder följande värden:

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

Ange inte ett helt intervall eller ett subnät i det första testet. Annars kan många system samtidigt förlora sin tidigare IP-baserade autentisering. Efter ett lyckat individuellt acceptanstest kan flera godkända värdar kontrollerat samlas 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.
3. Spara med Apply.

Från och med nu ä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 i ett underhållsfönster och använd inte en befintlig RDS-session som enda test.

5. Distribuera Direct Web Proxy

Ställ in webbläsar- eller systemproxyn via GPO, PAC-fil eller hanterat program till följande värde:

fw01.corp.example:3128

Kerberos kräver exakt det FQDN som motsvarar SPN. En IP-adress som proxymål, en kortform som inte kan lösas upp eller ett annat alias leder ofta till NTLM-fallback eller en fråga efter inloggningsuppgifter. Håll avsiktligt antalet bypassposter lågt och dokumentera dem, eftersom varje kringgången anslutning saknar Per-Connection-identitet.

Den allmänna konfigurationen av listener, PAC-fil, regel och återställning beskrivs i Konfigurera Direct Web Proxy med en PAC-fil. Den här artikeln lägger endast till fleranvändarautentiseringen.

6. Placera en egen brandväggsregel

Skapa en egen, 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.

Säker konfiguration:

• Source zones: faktisk RDS-zon, till exempel LAN
• Source networks and devices: endast RDS01
• Destination zones: WAN
• Destination networks: endast nödvändiga mål eller medvetet Any
• Services: en egen TCP-tjänst för 3128 eller den faktiskt konfigurerade proxy-Listening Port; Any endast medvetet
• Log firewall traffic: aktivt
• Match known users: inaktiverat
• Web filtering > Web policy: välj förberedd användar- eller gruppberoende Policy

Web Policies kan skilja mellan användare och grupper i proxytrafiken, men börjar inte gälla förrän de har tilldelats brandväggsregeln. Denna åtskillnad hör hemma i Web Policy, inte i Match known users i denna värdregel. Kontrollera reglaget igen när Web Policy har valts eller ändrats, eftersom ett användarberoende kan aktivera det på nytt.

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

Testa med två RDS-användare

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

1. Tilldela två AD-pilotkonton till olika Web Policy-grupper.
2. Öppna två nya RDS-sessioner på RDS01.
3. Kontrollera den effektiva proxykonfigurationen i båda sessionerna.
4. Starta ett tillåtet och ett avsiktligt annorlunda bedömt HTTP- eller HTTPS-anrop i varje session.
5. Kontrollera båda användarna med Client Type Multi-host client under Current activities > Live users.
6. Kontrollera användaren 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. Starta ett nödvändigt test utanför proxyn och bekräfta att det 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 endast fortsätta med en verifierad ytterligare skyddsåtgärd.

Lägg inte till fler RDS-värdar förrän båda användarna särskiljs korrekt samtidigt, avsedda Web Policy-resultat uppstår och vägen utanför proxyn är klarlagd. Testa Sophos Firewall-regler kontrollerat hjälper vid det allmänna acceptanstestet av regler.

Felsökning

Proxyn går inte att nå

Kontrollera FQDN-upplösning, port, resultatet från PAC/GPO, källzon och tillåtelserna Web proxy och AD SSO. Ett lyckat AD-servertest bevisar inte proxyåtkomst. Vid SD-WAN-rutter måste proxyporten eller Any matcha tjänstekriteriet; brandväggen skapar själv den externa proxyanslutningen och därför gäller inte alla klientegenskaper på samma sätt som för normal routad trafik.

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

Kontrollera proxymål, DNS, HTTP-SPN, webbläsarzon och integrerad autentisering. Kerberos kräver rätt FQDN, inte brandväggens IP-adress. NTLM-fallback är ett symptom som först måste förklaras, inte ett skäl till en förebyggande utrullning med enbart NTLM.

Båda sessionerna visas som samma användare

Kontrollera om båda webbläsarna verkligen använder den explicita proxyn och om något program skapar anslutningar utanför respektive användarsession. Även en uppströmsproxy eller NAT kan ä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 syns, men Web Policy tillämpas inte

Kontrollera AD-grupp, Main Group, ordning för Web Policy, brandväggsregel och loggpost tillsammans. Match known users måste förbli inaktiverat i den särskilda värdregeln. Synlig autentisering bevisar ännu inte att anropet använder förväntad Web Policy eller Firewall Rule ID.

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, databas- eller annan trafik utanför proxyn måste särskiljas per session ska SATC användas.

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

AD SSO kan behöva en ny Domain Join efter en uppgradering, vid användning av flera AD-servrar eller i HA. Det delegerade joinkontot måste därför förbli giltigt. Testa efter en kontrollerad failover med en ny proxyanslutning och båda pilotkontona; anta inte att befintliga proxyanslutningar eller Kerberos-biljetter fortsätter utan avbrott. I alla HA-lägen sparar varje nod endast loggarna för den trafik som den själv har behandlat. Kontrollera därför den nod som var aktiv eller behandlade trafiken vid den aktuella tidpunkten.

Läsa 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 problem med NTLM, Kerberos och eventuellt KVNO. access_server.log hjälper vid autentisering och auktorisering, awarrenhttp.log vid Web Proxy. awarrenhttp_access.log skapas endast när felsökning tillfälligt har aktiverats och hör inte till det normala första steget. Säkra först tidsfönster, användare, mål, regel och befintliga loggar innan tjänster startas om eller felsökningen utökas.

Återställning

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

1. Dokumentera aktuell fleranvändarlista, Device Access-undantag, regler, Web Policy 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 och lämplig för denna IP-adress.
5. Ta efter kontroll av andra beroenden bort pilotens ACL-undantag och tillfälliga zontillåtelser för AD SSO och Web Proxy, eller återställ dem exakt till föregående tillstånd.
6. Inaktivera eller ta bort de särskilda värd- och maskinreglerna så snart ersättningsvägen har bekräftats.
7. Testa igen med nya webbläsar- och RDS-sessioner och, 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 och entydig IP-adress utan andra system bakom.
• AD, grupper, Domain Join, FQDN, DNS, SPN och tid har kontrollerats.
• AD SSO och Web Proxy är endast tillåtna för den nödvändiga källvägen.
• Webbläsare och program använder fw01.corp.example:3128 eller miljöns egna ersättningsvärden.
• Den särskilda värdregeln har loggning aktiverad och Match known users inaktiverat.
• Trafik utanför proxyn är planerad som maskintrafik eller så har designen ändrats till SATC.
• Två samtidiga användare, olika Policies och hanteringsåtkomst har testats positivt och negativt.
• HA-failover och uppgraderingar har en dokumenterad procedur för rejoin och omtest.
• Återställning av fleranvändarlista, proxydistribution, Device Access, regler och tidigare autentisering är dokumenterad.

Vanliga frågor