Per-Connection AD SSO voor multi-userhosts op Sophos Firewall instellen

Meerdere gebruikers werken op dezelfde Remote Desktop Session Host, maar de Sophos Firewall ziet voor alle verbindingen slechts één server-IP. Per-Connection AD SSO lost precies deze bijzondere situatie voor webverkeer op: de Direct Web Proxy authenticeert elke HTTP- en HTTPS-verbinding afzonderlijk met Kerberos of NTLM.

De beperking is net zo belangrijk als de functie. Alleen verbindingen die de browser of toepassing uitdrukkelijk naar de proxy stuurt, krijgen een gebruikersidentiteit. DNS, RDP, SMB en ander non-proxyverkeer vanaf hetzelfde server-IP blijven niet-geverifieerd. Als ook deze protocollen per gebruiker moeten worden gecontroleerd, is SATC voor Remote Desktop Services geschikter.

⚠️ Zodra een IP-adres onder Multi-user hosts is opgenomen, gebruikt het geen andere IP-gebaseerde authenticatiemethoden meer. STAS, Captive Portal, Clientless User en transparante AD SSO vervallen voor dit IP-adres. Test daarom eerst met precies één pilotserver en documenteer het bestaande authenticatiepad.

Per-Connection AD SSO in negen stappen

Bepaal of werkelijk alleen HTTP en HTTPS via een expliciete proxy per gebruiker moeten worden verwerkt.
Controleer Active Directory, de groepsimport, DNS, tijd en de Domain Join van de firewall.
Bereid een oplosbare firewall-FQDN en een passende HTTP-SPN voor Kerberos voor.
Sta AD SSO en Web proxy alleen toe voor de benodigde bronzone of de pilot-host.
Maak voor de RDS-server een exact IP-hostobject aan.
Activeer onder Authentication > Web authentication Per-Connection AD SSO voor deze host.
Configureer browsers en toepassingen met proxyondersteuning voor de firewall-FQDN en poort 3128.
Plaats een eigen hostregel met logging vóór concurrerende gebruikersregels en laat Match known users uitgeschakeld.
Test afzonderlijk twee gelijktijdige RDS-sessies, verschillende Web Policy-resultaten en non-proxyverkeer.

Per-Connection AD SSO, STAS of SATC?

Alle drie de methoden leveren gebruikerscontext, maar lossen verschillende problemen op.

STAS past bij gewone Windows-clients wanneer een client-IP doorgaans aan precies één gebruiker toebehoort. De firewall ontvangt een koppeling tussen gebruiker en IP uit de Windows-aanmeldingsgebeurtenissen.
Per-Connection AD SSO past bij multi-userhosts wanneer alleen expliciet geproxiede HTTP- en HTTPS-verbindingen moeten worden onderscheiden. Op de RDS-server is geen SATC-agent nodig, maar alle toepassingen moeten de Direct Web Proxy betrouwbaar gebruiken.
SATC past bij RDS- of Citrix-systemen wanneer ook andere verbindingstypen uit de afzonderlijke gebruikerssessies een identiteit nodig hebben. Hiervoor is Sophos Server Protection op de Session Host vereist.

Klassieke STAS op Sophos Firewall kan meerdere gebruikers achter hetzelfde RDS-IP niet onderscheiden. Per-Connection AD SSO en SATC zijn daarom geen eenvoudigere varianten van STAS, maar afzonderlijke bedrijfsmodellen. Als een toepassing geen expliciete proxy ondersteunt of non-webprotocollen per gebruiker moeten worden geregeld, stop dan hier en beoordeel SATC.

Voorbeeld en aanpasbare waarden

De procedure gebruikt dit voorbeeld:

Multi-userhost: RDS01
IP-adres: 10.20.30.40
Firewall-FQDN en proxydoel: fw01.corp.example
Direct Web Proxy-poort: 3128
AD-groepen: RDS-Web-Standard en RDS-Web-Restricted
per groep één pilotaccount met bewust verschillende Web Policy-resultaten

Vervang 10.20.30.40 door het vaste IP-adres van de pilotserver zoals dat op de firewall zichtbaar is. Achter dit adres mogen niet ook andere systemen via NAT verschijnen. fw01.corp.example is een documentatienaam en moet worden vervangen door de echte, intern oplosbare firewall-FQDN. Het hostgedeelte mag bij voorkeur niet langer zijn dan 15 tekens en moet in kleine letters worden geschreven, zodat hostnaam, NetBIOS-naam, AD-computerobject en SPN bij elkaar passen.

Poort 3128 is de standaard voor de Direct Web Proxy. Als de eigen omgeving een andere Listening Port gebruikt, moeten firewall, PAC-bestand of GPO, browsers en tests dezelfde waarde gebruiken. De voorbeeldgroepen dienen alleen voor een begrijpelijke acceptatietest; groepsnamen en Web Policies moeten bij de eigen autorisatiestructuur passen.

Vereisten voorbereiden

Active Directory en Domain Join controleren

De firewall heeft een werkende Active Directory-server, geïmporteerde groepen en een geslaagde Domain Join nodig. Active Directory met Sophos Firewall verbinden behandelt LDAPS, zoekbasis, groepsimport en de algemene vereisten voor AD SSO.

Voor een gewone LDAP-query volstaat een account met leesrechten. Voor de Domain Join en het aanmaken van de SPN is daarentegen een Domain Admin-account of een account met correct gedelegeerde rechten nodig. Het opgeslagen account moet ook een latere rejoin toestaan, omdat HA, extra AD-servers of upgrades dit opnieuw kunnen activeren. Gebruik hiervoor niet onnodig permanent een onbeperkt Domain Admin-account.

Selecteer onder Authentication > Services > Firewall authentication methods de beoogde AD-server en plaats deze in de juiste volgorde. Bij meerdere servers controleert de firewall ze van boven naar beneden. Test connection bij de AD-server bevestigt alleen de aanmeldgegevens en bereikbaarheid, niet de latere Kerberos- of NTLM-aanmelding in de browser.

FQDN, DNS, SPN en tijd controleren

Kerberos werkt alleen wanneer de clients de firewall-FQDN als proxydoel gebruiken. Een proxy-IP-adres volstaat hiervoor niet. Op een Windows-pilotclient helpen deze alleen-lezen controles:

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

De HTTP-SPN, voluit Service Principal Name, koppelt de proxy-FQDN aan het AD-computerobject van de firewall. setspn -Q moet precies één passende koppeling opleveren. Geen resultaat of meerdere resultaten moeten vóór de uitrol worden opgelost.

Het DNS-antwoord moet naar de beoogde firewall verwijzen. Client, Domain Controller en firewall moeten bovendien een tijd gebruiken die geschikt is voor Kerberos. De opdrachten wijzigen niets. Pas SPN, Domain Join of tijdconfiguratie niet op goed geluk aan, maar toon eerst de werkelijke fout aan.

Proxyondersteuning en uitzonderingen inventariseren

Elke browser en toepassing waarvan het webverkeer een gebruiker moet krijgen, moet de expliciete proxy gebruiken en geïntegreerde Windows-authenticatie ondersteunen. Controleer vóór de uitrol ten minste:

browsers in elke ondersteunde RDS-sessie
toepassingen met een eigen HTTP-stack
Windows- en software-updates
services die in de systeemcontext in plaats van een gebruikerssessie draaien
doelen die in het PAC-bestand of de proxy-bypasslijst staan

Verkeer dat de proxy omzeilt, blijft zoals verwacht zonder gebruikers-ID. Plan voor noodzakelijke machineverbindingen een eigen, strikt begrensde regel zonder gebruikerskoppeling. Een brede Any-regel zou de beveiligingswerking van de gebruikers- en Web Policies verzwakken.

Per-Connection AD SSO configureren

1. Firewall-FQDN en AD SSO voorbereiden

Voer onder Administration > Admin and user settings de beoogde firewall-FQDN in. Kies daarna onder Authentication > Web authentication bij If Active Directory (AD) SSO is configured de optie Kerberos & NTLM. NTLM wordt technisch ondersteund als fallback, maar voor grotere installaties moet Kerberos betrouwbaar werken, omdat Per-Connection AD SSO veel extra authenticatieaanvragen kan veroorzaken.

Na de initialisatie van AD SSO moeten in de Log Viewer onder Authentication deze succesmeldingen verschijnen:

Kerberos authentication initialized successfully
NTLM authentication channel established successfully

De firewall biedt de methoden pas aan als beide kanalen werken. Cannot initialize Kerberos authentication of Cannot establish NTLM authentication channel zijn stopsignalen, geen verzoek om blind een service te herstarten.

2. Device Access strikt toestaan

Onder Administration > Device access moeten AD SSO en Web proxy voor het beoogde bronpad zijn toegestaan. Bij een vast pilot-IP is een gerichte Local service ACL exception rule doorgaans strikter dan toegang voor de hele LAN-zone. Een extra Accept-uitzondering beperkt een al actieve zonetoegang echter niet; voor een werkelijk strikt ontwerp moet de brede toegang uitgeschakeld blijven. Device Access en Local Service ACL behandelt de volledige configuratie.

Web Proxy-toegang heeft een belangrijke bijwerking: een toegestane host kan via de proxy HTTP- en HTTPS-services van de firewall bereiken, zelfs als zijn zone in de normale Local Service-matrix niet is toegestaan. Test daarom WebAdmin, User Portal en andere lokale doelen negatief vanaf de pilot-host. Als deze blootstelling in het eigen netwerk niet aanvaardbaar is, neem het ontwerp dan niet in productie.

Controleer onder Web > General settings de werkelijke Web proxy listening port en de toegestane doelpoorten. Wijzig de standaard 3128 alleen als het PAC-bestand, de GPO en alle beheerde toepassingen consequent kunnen worden aangepast.

3. Multi-userhost aanmaken

Maak via het volgende pad een nieuw hostobject aan:

Hosts and services > IP host > Add

Gebruik voor het voorbeeld deze waarden:

Name: RDS01
IP version: IPv4
Type: IP
IP address: 10.20.30.40

Voer voor de eerste test geen volledige range en geen subnet in. Anders kunnen veel systemen tegelijk hun bestaande IP-gebaseerde authenticatie verliezen. Na een geslaagde afzonderlijke acceptatietest kunnen meerdere vrijgegeven hosts gecontroleerd in een hostgroep worden samengebracht.

4. Per-Connection AD SSO activeren

Ga naar dit gedeelte:

Authentication > Web authentication > Authentication settings for direct web proxy

Vervolgens:

Activeer Use per-connection AD SSO authentication for multi-user hosts.
Voeg onder Multi-user hosts het object RDS01 toe.
Sla op met Apply.

Vanaf dit moment zijn STAS, Captive Portal, Clientless User en transparante AD SSO niet meer beschikbaar voor 10.20.30.40. Voer de wijziging daarom in een onderhoudsvenster uit en gebruik een bestaande RDS-sessie niet als enige test.

5. Direct Web Proxy distribueren

Stel de browser- of systeemproxy via GPO, PAC-bestand of beheerde toepassing in op deze waarde:

fw01.corp.example:3128

Voor Kerberos moet exact de FQDN worden gebruikt die bij de SPN past. Een IP-adres als proxydoel, een niet-oplosbare korte naam of een andere alias leidt vaak tot een NTLM-fallback of een aanmeldprompt. Houd bypassvermeldingen bewust beperkt en documenteer ze, omdat elke omzeilde verbinding geen Per-Connection-identiteit krijgt.

De algemene configuratie van listener, PAC-bestand, regel en rollback staat in Direct Web Proxy met een PAC-bestand instellen. Dit artikel voegt alleen de multi-userauthenticatie toe.

6. Eigen firewallregel positioneren

Maak onder Rules and policies > Firewall rules een eigen, duidelijk benoemde outboundregel voor RDS01. Deze moet vóór regels staan die dezelfde host met Match known users verwerken.

Het veilige kader:

Source zones: werkelijke RDS-zone, bijvoorbeeld LAN
Source networks and devices: alleen RDS01
Destination zones: WAN
Destination networks: alleen de benodigde doelen of bewust Any
Services: eigen TCP-service voor 3128 of de daadwerkelijk geconfigureerde proxy-Listening Port; Any alleen bewust
Log firewall traffic: actief
Match known users: uitgeschakeld
Web filtering > Web policy: de voorbereide gebruikers- of groepsafhankelijke Policy selecteren

Web Policies kunnen binnen het proxyverkeer gebruikers en groepen onderscheiden, maar werken pas wanneer ze aan de firewallregel zijn toegewezen. Deze differentiatie hoort in de Web Policy, niet in Match known users van deze hostregel. Controleer de schakelaar opnieuw nadat de Web Policy is geselecteerd of gewijzigd, omdat een gebruikersafhankelijkheid deze weer kan activeren.

Maak voor DNS, updates en andere noodzakelijke non-proxyverbindingen een afzonderlijke machineregel. Voeg geen algemene WAN-naar-LAN-regel toe; het inboundvoorbeeld van Sophos is niet nodig voor gewone RDS-webtoegang en zou zonder een eigen publicatiedoel een onnodig aanvalsoppervlak vormen. Firewallregels correct aanmaken behandelt de opbouw, volgorde en logging.

Testen met twee RDS-gebruikers

Eén geslaagde browseraanvraag bewijst alleen dat enig proxyverkeer werkt. Voor de werkelijke acceptatietest zijn twee gelijktijdige sessies nodig.

Wijs twee AD-pilotaccounts toe aan verschillende Web Policy-groepen.
Open twee nieuwe RDS-sessies op RDS01.
Controleer in beide sessies de effectieve proxyconfiguratie.
Start per sessie een toegestane en een bewust anders beoordeelde HTTP- of HTTPS-aanvraag.
Controleer onder Current activities > Live users beide gebruikers met Client Type Multi-host client.
Controleer onder Log viewer > Authentication de gebruiker en Log Comp voor Kerberos of NTLM.
Vergelijk in het web- en firewalllog gebruiker, Policy, Rule ID, actie en tijdstip.
Voer een noodzakelijke non-proxytest uit en bevestig dat deze niet ten onrechte een gebruikersidentiteit krijgt.
Inventariseer vanaf de pilot-host welke lokale HTTP- en HTTPS-services van de firewall via de proxy bereikbaar zijn. Als een service bereikbaar is die volgens het beveiligingsontwerp niet toegestaan is, stop dan de uitrol en ga pas verder met een aantoonbare extra beveiligingsmaatregel.

Voeg pas meer RDS-hosts toe wanneer beide gebruikers gelijktijdig correct worden onderscheiden, de bedoelde Web Policy-resultaten optreden en het non-proxypad duidelijk is. Sophos Firewall-regels gecontroleerd testen helpt bij de algemene acceptatietest van regels.

Problemen oplossen

De proxy is niet bereikbaar

Controleer de FQDN-resolutie, poort, PAC-/GPO-resultaat, bronzone en toegang voor Web proxy en AD SSO. Een geslaagde AD-servertest bewijst geen proxytoegang. Bij SD-WAN-routes moet de proxypoort of Any bij de servicematch passen; de firewall maakt de externe proxyverbinding zelf, waardoor niet alle clientkenmerken gelden zoals bij normaal gerouteerd verkeer.

De browser vraagt om aanmeldgegevens of gebruikt NTLM

Controleer het proxydoel, DNS, de HTTP-SPN, de browserzone en geïntegreerde authenticatie. Kerberos vereist de juiste FQDN, niet het firewall-IP. NTLM-fallback is een symptoom dat eerst moet worden verklaard, geen reden voor een preventieve NTLM-only-uitrol.

Beide sessies verschijnen als dezelfde gebruiker

Controleer of beide browsers werkelijk de expliciete proxy gebruiken en of een toepassing verbindingen buiten de betreffende gebruikerssessie opbouwt. Ook een upstreamproxy of NAT kan het gewenste verbindingsmodel veranderen. In Live Users moet het type Multi-host client verschijnen; een gewone IP-gebaseerde koppeling is voor deze host het verkeerde pad.

De gebruiker is zichtbaar, maar de Web Policy werkt niet

Controleer samen de AD-groep, Main Group, volgorde van de Web Policy, firewallregel en logvermelding. Match known users moet in de speciale hostregel uitgeschakeld blijven. Zichtbare authenticatie bewijst nog niet dat de aanvraag de verwachte Web Policy of Firewall Rule ID gebruikt.

Non-webverkeer toont geen gebruiker

Dat is verwacht gedrag. Per-Connection AD SSO identificeert alleen HTTP en HTTPS via de Direct Web Proxy. Voor noodzakelijk machineverkeer geldt een regel zonder gebruikerskoppeling. Als RDP, SMB, database- of ander non-proxyverkeer per sessie moet worden onderscheiden, schakel dan over op SATC.

SSO werkt niet meer na een upgrade of HA-failover

AD SSO kan na een upgrade, bij gebruik van meerdere AD-servers of in HA een nieuwe Domain Join nodig hebben. Het gedelegeerde joinaccount moet daarom geldig blijven. Test na een gecontroleerde failover met een nieuwe proxyverbinding en beide pilotaccounts; ga er niet van uit dat bestaande proxyverbindingen of Kerberos-tickets ononderbroken doorlopen. In elke HA-modus bewaart elke node alleen de logs van het verkeer dat deze zelf heeft verwerkt. Controleer voor een incident daarom de node die op dat moment actief was of het verkeer verwerkte.

Relevante logs lezen

In de Advanced Shell zijn deze bestanden relevant:

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

nasm.log toont NTLM-, Kerberos- en mogelijke KVNO-problemen. access_server.log helpt bij authenticatie en autorisatie, awarrenhttp.log bij de Web Proxy. awarrenhttp_access.log wordt alleen aangemaakt wanneer debug tijdelijk is geactiveerd en hoort niet bij de normale eerste stap. Leg vóór het herstarten van services of het uitbreiden van debug eerst het tijdvenster, de gebruiker, het doel, de regel en de bestaande logs vast.

Terugdraaien

Een nette terugkeer herstelt niet alleen de proxy, maar ook het eerdere authenticatiemodel.

Documenteer de huidige multi-userlijst, Device Access-uitzonderingen, regels, Web Policy en proxydistributie.
Verwijder RDS01 uit Multi-user hosts en sla op met Apply.
Draai de proxy-GPO, het PAC-bestand of de toepassingsconfiguratie gecontroleerd terug.
Herstel de eerdere STAS-, Clientless- of Captive Portal-koppeling alleen als deze vooraf was gedocumenteerd en voor dit IP-adres geschikt was.
Verwijder na controle van andere afhankelijkheden de pilot-ACL-uitzondering en tijdelijke AD SSO- en Web Proxy-zonetoegang, of zet ze exact terug naar de eerdere staat.
Schakel de speciale host- en machineregels uit of verwijder ze zodra het vervangende pad is bevestigd.
Test opnieuw met nieuwe browser- en RDS-sessies en, bij HA, op beide bedrijfsrollen.

Checklist

Per-Connection AD SSO is alleen bedoeld voor expliciet HTTP-/HTTPS-proxyverkeer.
De pilot-host heeft een vast, uniek IP-adres zonder andere systemen erachter.
AD, groepen, Domain Join, FQDN, DNS, SPN en tijd zijn gecontroleerd.
AD SSO en Web Proxy zijn alleen voor het benodigde bronpad toegestaan.
Browsers en toepassingen gebruiken fw01.corp.example:3128 of de eigen vervangende waarden.
De speciale hostregel heeft logging aan en Match known users uit.
Non-proxyverkeer is als machineverkeer gepland of het ontwerp is gewijzigd naar SATC.
Twee gelijktijdige gebruikers, verschillende Policies en beheerstoegang zijn positief en negatief getest.
Voor HA-failovers en upgrades bestaat een gedocumenteerde rejoin- en hertestprocedure.
Het terugdraaien van multi-userlijst, proxydistributie, Device Access, regels en eerdere authenticatie is gedocumenteerd.

Veelgestelde vragen

Kan Per-Connection AD SSO SATC vervangen?

Alleen wanneer uitsluitend HTTP en HTTPS via de Direct Web Proxy per gebruiker moeten worden beoordeeld. SATC kan alle ondersteunde verbindingstypen uit de RDS-gebruikerssessies koppelen en is daarom nodig als ook non-proxyverkeer een gebruikersidentiteit vereist.

Waarom moet Match known users uitgeschakeld zijn?

De speciale firewallregel moet eerst op basis van het IP-adres van de multi-userhost worden toegepast. Als Match known users actief is, kan de firewall het hostverkeer verwerken op basis van een bestaande IP-koppeling, vaak van een beheerder, en volgende regels overslaan. Voor dit ontwerp worden verschillen tussen gebruikers en groepen in de Web Policy beoordeeld.

Waarom gebruikt de browser NTLM in plaats van Kerberos?

Vaak komt het proxydoel niet overeen met de HTTP-SPN, wordt de firewall-FQDN niet correct opgelost of vertrouwt de browser het doel niet voor geïntegreerde authenticatie. Kerberos vereist de FQDN als proxydoel; met een IP-adres werkt het niet.

Krijgt RDP-, SMB- of DNS-verkeer ook een gebruikersidentiteit?

Nee. Per-Connection AD SSO geldt alleen voor HTTP- en HTTPS-verbindingen via de Direct Web Proxy. Het overige verkeer blijft niet-geverifieerd en heeft een passende machineregel of een andere methode zoals SATC nodig.