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 functie is niet beperkt tot Windows RDS: ook een multi-user-Linux-server kan dit verbindingsmodel gebruiken, mits de clients de Direct Web Proxy en Kerberos of NTLM ondersteunen. Dit voorbeeld behandelt een Windows-RDS-pilot; de Windows-opdrachten en GPO-distributie vormen geen Linux-handleiding. Hosts buiten de lijst Multi-user hosts behouden hun eerder geconfigureerde IP-gebaseerde authenticatie.

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

1. Bepaal of werkelijk alleen HTTP en HTTPS via een expliciete proxy per gebruiker moeten worden verwerkt.
2. Controleer Active Directory, de groepsimport, DNS, de tijd en de Domain Join van de firewall.
3. Bereid een oplosbare firewall-FQDN en een bijpassende HTTP-SPN voor Kerberos voor.
4. Beoordeel eerst de reikwijdte en beveiligingsimpact; schakel daarna AD SSO in voor de vereiste LAN-zone onder Administration > Device access en kies Apply. Beperk Web proxy afzonderlijk tot de pilothost met een gerichte ACL-uitzondering, indien ondersteund; een Accept-uitzondering beperkt geen zonetoestemming. Is de vereiste toestemming onacceptabel, stop dan de uitrol en verkrijg een ondersteund, afgebakend ontwerp.
5. Maak voor de RDS-server een IP-hostobject met het exacte IP-adres aan.
6. Activeer onder Authentication > Web authentication Per-Connection AD SSO voor deze host.
7. Configureer browsers en toepassingen die een proxy ondersteunen voor de firewall-FQDN en poort 3128.
8. Plaats een aparte hostregel met logging vóór concurrerende gebruikersregels en laat Match known users uitgeschakeld.
9. Controleer twee parallelle RDS-sessies, verschillende Web Policy-resultaten en non-proxyverkeer afzonderlijk.

Per-Connection AD SSO, STAS of SATC?

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

• STAS is geschikt voor gewone Windows-clients waarbij een client-IP doorgaans bij precies één gebruiker hoort. De firewall ontvangt een gebruiker-IP-koppeling uit de Windows-aanmeldingsgebeurtenissen.
• Per-Connection AD SSO is geschikt voor multi-userhosts als alleen HTTP- en HTTPS-verbindingen die expliciet via de proxy lopen, van elkaar moeten worden onderscheiden. Op de RDS-server is geen SATC-agent nodig, maar alle toepassingen moeten de Direct Web Proxy wel betrouwbaar gebruiken.
• SATC is geschikt voor ondersteunde Windows-RDS-systemen als ook andere verbindingstypen uit de afzonderlijke gebruikerssessies een identiteit nodig hebben. Hiervoor is Sophos Server Protection op de Session Host vereist. De huidige Sophos-handleiding onderbouwt geen nieuwe Citrix-uitrol; stem wijzigingen aan bestaande Citrix-installaties vooraf af met Sophos Support.

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 werkingsmodellen. Ook SATC koppelt alleen gebruikersgebonden processen; verbindingen die door systeemdiensten worden aangemaakt, hebben nog steeds een eigen regel zonder Match known users nodig. Als een toepassing geen expliciete proxy ondersteunt of als non-webprotocollen per gebruiker moeten worden geregeld, stop dan hier en onderzoek SATC.

Voorbeeld en vervangbare 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
• één pilotaccount per groep 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 moet maximaal 15 tekens lang zijn en in kleine letters worden geschreven, zodat de hostnaam, NetBIOS-naam, het AD-computerobject en de SPN bij elkaar passen.

Poort 3128 is de standaard voor de Direct Web Proxy. Als in de eigen omgeving een andere Listening Port wordt gebruikt, moeten de firewall, het PAC-bestand of de GPO, de browsers en de tests dezelfde waarde gebruiken. De voorbeeldgroepen dienen alleen voor een duidelijke acceptatietest; groepsnamen en Web Policies moeten aansluiten op de eigen rechtenstructuur.

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, de zoekbasis, groepsimport en de algemene AD-SSO-vereisten.

Als de AD-server nog niet is ingesteld, selecteer dan onder Authentication > Servers > Add het type Active Directory. Voer de servernaam, het bereikbare DC-IP of de DC-FQDN, het NetBIOS-domein, het AD-domein en de zoekbasis van de eigen omgeving in. Voor corp.example is de zoekbasis dc=corp,dc=example. Versleutel de verbinding met SSL/TLS op poort 636 of STARTTLS op poort 389 en bereid de certificaatcontrole voor volgens de gekoppelde AD-procedure. Voer het lees-/join-account met de hieronder beschreven rechten in, voer Test connection uit en sla op met Save. Vervang een al gebruikte AD-server niet uitsluitend voor de pilot en wijzig de toegangsgegevens niet zonder controle. Als het domein strikte LDAP-kanaalbinding of LDAP-ondertekening afdwingt, controleer dan vóór de uitrol de compatibiliteit aan de hand van de AD-procedure; de Sophos-help voor AD-servers vermeldt hiervoor een beperking. Schakel geen domeinbrede beveiligingseis uit om problemen op te lossen.

Bij de groepsimport selecteert een organisatie-eenheid (OU) automatisch alle groepen die deze bevat. Attach to all the Groups wijst de geselecteerde gemeenschappelijke policies toe aan elke groep die door de wizard wordt geïmporteerd. Controleer daarom vóór het afronden de groepslijst die door de OU-selectie is uitgebreid en het toepassingsbereik van deze policies; neem alleen de daadwerkelijk benodigde groepen en bedoelde policytoewijzingen over.

Open voor de pilot onder Authentication > Servers > Manage bij de AD-server Import, begin in de Import group wizard met Start en selecteer de juiste Base DN. Voor het voorbeelddomein corp.example is deze dc=corp,dc=example; vervang de domeinonderdelen, niet de LDAP-syntaxis. Selecteer RDS-Web-Standard en RDS-Web-Restricted, controleer de gemeenschappelijke policytoewijzing en de samenvatting, rond de wizard af en sluit deze met Close. Controleer daarna onder Authentication > Groups of beide groepen daadwerkelijk aanwezig zijn. Een geslaagde Domain Join op zichzelf importeert de benodigde policygroepen niet.

Voor gewone LDAP-query’s 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 deze opnieuw kunnen activeren. Gebruik hiervoor niet onnodig permanent een onbeperkt Domain Admin-account.

Selecteer onder Authentication > Services > Firewall authentication methods de bedoelde AD-server en zet 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 toegangsgegevens en bereikbaarheid, niet de latere Kerberos- of NTLM-aanmelding in de browser.

Kies in hetzelfde gedeelte bewust de Default group en sla op met Apply. Als de benodigde AD-groep niet is geïmporteerd, kan een succesvol geauthenticeerde gebruiker in de standaardgroep terechtkomen in plaats van de gewenste groepspolicy te krijgen. Gebruikers in een OU zonder lidmaatschap van een directorygroep kunnen in de Open group verschijnen. Bij meerdere groepslidmaatschappen kan de eerste passende groep de policy bepalen; controleer daarom niet alleen de import, maar ook de volgorde en de daadwerkelijke koppeling. Gebruik voor de pilot dus geen standaardgroep met ruime rechten als vervanging voor een ontbrekende import. Controleer bij de eerste nieuwe aanmelding onder Authentication > Users de daadwerkelijke groepskoppeling; een gebruikersobject hoeft niet al vóór deze aanmelding zichtbaar te zijn.

FQDN, DNS, SPN en tijd controleren

Kerberos werkt alleen als de clients de firewall-FQDN als proxydoel gebruiken. Een proxy-IP-adres volstaat daarvoor niet. Op een Windows-pilotclient helpen deze controles, die alleen gegevens uitlezen:

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 onderzocht.

Het DNS-achtervoegsel dat in het Hostname-veld is geconfigureerd, is niet automatisch het AD-achtervoegsel: bij de Domain Join vormt de firewall de AD-computernaam en de SPN op basis van de NetBIOS-naam en het AD-domein. Als het DNS-domein en het AD-domein verschillen, vergelijk dan de op het AD-computerobject geregistreerde FQDN met het geplande proxydoel. Het voorbeeld gaat uit van een passende SPN voor fw01.corp.example; alleen het invoeren van deze naam onder Admin and user settings bewijst dat niet. Controleer eerst DNS en SPN samen voor het daadwerkelijke proxydoel en distribueer daarna de proxyconfiguratie. Maak niet op goed geluk extra SPN’s aan.

Het DNS-antwoord moet bij de bedoelde firewall passen. Daarnaast moeten de client, Domain Controller en firewall een tijdinstelling hebben die geschikt is voor Kerberos. De opdrachten wijzigen niets. Pas de SPN, Domain Join of tijdconfiguratie niet op goed geluk aan, maar toon eerst de daadwerkelijke fout aan.

Proxyondersteuning en uitzonderingen inventariseren

Elke browser en toepassing waarvan het webverkeer een gebruiker toegewezen moet krijgen, moet de expliciete proxy gebruiken en Kerberos of NTLM ondersteunen; in het Windows-RDS-voorbeeld gebeurt dit via geïntegreerde Windows-authenticatie. Controleer vóór de uitrol minimaal:

• Browsers in elke ondersteunde RDS-sessie
• Toepassingen met een eigen HTTP-stack
• Windows- en software-updates
• Diensten die in de systeemcontext draaien in plaats van in een gebruikerssessie
• 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 aparte, strikt beperkte 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 bedoelde firewall-FQDN in en sla op met Apply. Selecteer daarna onder Authentication > Web authentication bij If Active Directory (AD) SSO is configured de optie Kerberos & NTLM en sla eveneens op met Apply. NTLM wordt technisch ondersteund als fallback; Kerberos is sneller en veiliger en moet in de pilot betrouwbaar functioneren. Omdat elke proxyverbinding een authenticatie kan activeren, moet je vóór een grotere uitrol ook aanmeldingsfouten, responstijden en de belasting van de firewall en AD bij representatief verkeer monitoren. Leid hieruit geen vaste belastingsfactor of gegarandeerde gebruikerscapaciteit af.

Als de eindapparaten niet correct voor Kerberos zijn geconfigureerd of de browser geen Kerberos-authenticatie ondersteunt, wordt automatisch NTLMv2 als fallback gebruikt. Anders dan Kerberos heeft NTLMv2 geen FQDN als proxydoel nodig. Deze compatibiliteitsfallback garandeert echter geen geslaagde aanmelding: de hieronder beschreven authenticatiekanalen moeten zijn geïnitialiseerd en het daadwerkelijke aanmeldingspad moet met de pilotaccounts worden gecontroleerd.

In de Log Viewer moeten onder Authentication na de AD-SSO-initialisatie 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 signalen om te stoppen, geen aanleiding om blind een service opnieuw te starten.

2. Device Access beperkt toestaan

Sophos vereist dat AD SSO voor de benodigde LAN-zone onder Administration > Device access wordt ingeschakeld en met Apply wordt toegepast als voorwaarde voor Kerberos/NTLM. Beoordeel vooraf de reikwijdte van de zonetoestemming en de beveiligingsimpact; stel niet zonder die beoordeling de hele LAN-zone open. Als AD SSO in alle zones uitstaat, werken Kerberos/NTLM niet. Een AD-SSO-ACL-uitzondering voor alleen een host vervangt deze voorwaarde niet. Een extra Accept-uitzondering beperkt evenmin een bestaande zonetoestemming. Is de vereiste toestemming onacceptabel, stop dan de uitrol en verkrijg bij de ACL-beheerder of Sophos Support een ondersteund, afgebakend ontwerp voor de geïnstalleerde build. Beperk afzonderlijk de bereikbaarheid van Web proxy vanuit de bron tot de pilothost met een gerichte Local service ACL exception rule, indien ondersteund. Een Accept-uitzondering beperkt geen bestaande zonebrede Web-proxytoestemming; die brede proxytoestemming mag niet actief blijven voor werkelijk hostgebonden toegang. Schakel geen onnodige andere zones of diensten in. De volledige inrichting wordt uitgelegd in Device Access en Local Service ACL.

Web Proxy-toegang heeft een belangrijk neveneffect: een toegestane host kan HTTP- en HTTPS-diensten van de firewall via de proxy bereiken, zelfs als hun zone in de gewone Local Service-matrix niet is toegestaan. Voer daarom met de pilothost negatieve tests uit voor WebAdmin, User Portal en andere lokale doelen. Als deze blootstelling in het eigen netwerk niet acceptabel is, activeer het ontwerp dan niet in productie.

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

3. Multi-userhost aanmaken

Maak onder het volgende pad een nieuw hostobject aan:

Hosts and services > IP host > Add

Voor het voorbeeld worden deze waarden gebruikt:

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

Sla op met Save en controleer of het object het exacte pilot-IP bevat voordat je het in de multi-userlijst selecteert.

Voer voor de eerste test geen volledig bereik en geen subnet in. Anders kunnen veel systemen tegelijk hun bestaande IP-gebaseerde authenticatie verliezen. Meerdere hosts die later worden goedgekeurd, kunnen na een geslaagde afzonderlijke acceptatietest gecontroleerd in een hostgroep worden samengevoegd.

4. Per-Connection AD SSO activeren

Ga naar dit gedeelte:

Authentication > Web authentication > Authentication settings for direct web proxy

Daarna:

1. Activeer Use per-connection AD SSO authentication for multi-user hosts.
2. Voeg onder Multi-user hosts met Add new item het object RDS01 toe.
3. 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.

Optionele API-koppeling voor automatisering

Wie deze GUI-stap wil automatiseren, vindt in de API-referentie voor SFOS 22.0 en 23.0 de entiteit DirectWebProxyAuthentication. Deze koppelt de schakelaar en de multi-userlijst als volgt aan API-parameters; deze koppeling is geen volledig uitvoerbaar verzoek.

• DirectWebProxyAuthentication > PerConnectionAuth komt overeen met de aan-/uitschakelaar voor Per-Connection AD SSO. De parameter is gedocumenteerd als een niet-verplichte SCALAR en staat uitsluitend Enable of Disable toe. De schrijfwijze met een schuine streep in het referentievoorbeeld geeft alternatieven aan, geen derde toegestane waarde.
• DirectWebProxyAuthentication > MultiUserHosts > Host beschrijft de lijst met multi-userhostnamen, in dit voorbeeld dus de naam van het eerder aangemaakte hostobject RDS01, niet het IP-adres ervan. Host is niet verplicht en is gedocumenteerd als een ARRAY met datatype STRING. Meerdere waarden zijn toegestaan; dubbele waarden worden volgens de referentie genegeerd. De referentie vermeldt een maximum van 1500 tekens, maar legt niet uit of deze limiet per waarde of voor de volledige lijst geldt.

De Default-kolommen zijn leeg: hieruit volgt noch een gedocumenteerde standaardwaarde, noch een uitspraak over het effect van weggelaten velden. Het gedeelte over de bewerking beschrijft evenmin of een aangeleverde lijst bestaande vermeldingen aanvult of vervangt, en hoe vermeldingen worden verwijderd. Beschouw daarom noch het weglaten van velden, noch een lege lijst als een veilige manier om terug te keren naar de vorige toestand; vóór automatisering moet voor de gebruikte build duidelijk zijn hoe updates en verwijderingen precies werken.

De statustabel bevat 200 en 500. Een operatiestatus bevestigt niet de HTTP-status of dat gebruikers en policies succesvol zijn verwerkt. De meldingsvelden verwijzen naar JavaScript; het beschikbare gedeelte over de bewerking bevat geen letterlijke antwoordmeldingen.

Ook bij een latere geautoriseerde API-wijziging blijven de bovenstaande vereisten en de strikt afgebakende pilot met één host gelden. Leg vooraf de daadwerkelijke instellingen veilig vast en houd een onafhankelijke beheertoegang beschikbaar. Lees daarna de schakelaar en de volledige multi-userlijst opnieuw uit op precies de firewall waarop de wijziging is uitgevoerd en vergelijk deze met de beoogde toestand; voer vervolgens de hieronder beschreven positieve en negatieve tests voor de proxy, gebruikers, policies, non-proxyverkeer en lokale diensten uit. Een geaccepteerd configuratieantwoord vervangt deze acceptatietest niet. Herstel voor de rollback de veilig vastgelegde vorige toestand, zonder daaruit een niet-onderbouwde API-syntaxis voor verwijdering af te leiden.

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 NTLM-fallback of een aanmeldingsprompt. Houd bypassvermeldingen bewust beperkt en documenteer ze, omdat elke verbinding die de proxy omzeilt geen Per-Connection-identiteit krijgt.

De algemene configuratie van de listener, PAC, regels en rollback staat in Direct Web Proxy met PAC-bestand instellen. Dit artikel vult die inrichting alleen aan met multi-userauthenticatie.

6. Een aparte firewallregel op de juiste plaats zetten

Maak onder Rules and policies > Firewall rules een aparte, duidelijk benoemde uitgaande regel voor RDS01 aan. Deze moet vóór regels staan die dezelfde host met Match known users afhandelen.

Selecteer voor dit IPv4-voorbeeld IPv4 > Add firewall rule > New firewall rule. Stel als Rule name bijvoorbeeld RDS01_DirectProxy_Outbound in en als Action Accept. De naam is vrij te kiezen; deze moet de host en het doel herkenbaar maken. Controleer de positie vóór concurrerende gebruikersregels aan de hand van de volledige regellijst, niet alleen op basis van de naam.

Het veilige kader:

• Source zones: daadwerkelijke RDS-zone, bijvoorbeeld LAN
• Source networks and devices: alleen RDS01
• Destination zones: WAN
• Destination networks: alleen de benodigde doelen of bewust Any
• Services: HTTP, HTTPS en een eigen TCP-service voor 3128 of de daadwerkelijk geconfigureerde proxy-Listening-Port; gebruik Any alleen bewust. Alleen de Listening Port selecteren is geen volledige serviceselectie voor de Direct Web Proxy.
• Log firewall traffic: ingeschakeld
• Match known users: uitgeschakeld
• Web filtering > Web policy: selecteer de voorbereide gebruikers- of groepsafhankelijke policy

Web Policies kunnen gebruikers en groepen binnen het proxyverkeer onderscheiden, maar werken pas als ze aan de firewallregel zijn gekoppeld. Dit onderscheid hoort in de Web Policy, niet in Match known users van deze hostregel. Controleer de schakelaar opnieuw nadat je de Web Policy hebt geselecteerd of gewijzigd, omdat een gebruikersafhankelijkheid deze weer kan inschakelen.

Sla op met Save, open de regel opnieuw en controleer Match known users, logging, Web Policy en positie. De hostregel staat het bedoelde verkeerspad toe; de Web Policy bepaalt binnen dat pad de toegang voor gebruikers en groepen. Een correct herkende identiteit betekent daarom niet automatisch de juiste rechten.

De algemene AD-SSO-handleiding beschrijft ook gebruikersregels waarbij Match known users is ingeschakeld. Dat is niet het regelmodel voor het hier ingevoerde multi-user-IP: de specifieke Per-Connection-handleiding vereist uitdrukkelijk een aparte regel met deze schakelaar uitgeschakeld. Neem ook de servicematch niet over uit een transparante HTTP-/HTTPS-regel: de proxy-Listening-Port beschrijft het pad van client naar proxy, terwijl een aparte verbinding van proxy naar doel doelservices zoals HTTP of HTTPS gebruikt. Bevestig in de pilot de daadwerkelijke Rule ID en de juiste poort aan de hand van de logs. Een IPv6-client met een IPv4-doel kan twee regels nodig hebben; dit IPv4-voorbeeld is daarvoor geen volledige dual-stackhandleiding.

Maak voor DNS, updates en andere noodzakelijke non-proxyverbindingen een aparte machineregel aan. Voeg geen algemene WAN-naar-LAN-regel toe; het door Sophos getoonde inkomende voorbeeld is niet nodig voor normale RDS-webtoegang en zou zonder een eigen publicatiedoel onnodig aanvalsoppervlak creëren. Inrichting, volgorde en logging worden uitgelegd in Firewallregels correct aanmaken.

Als er onafhankelijk van de proxy een onderbouwde behoefte aan inkomende toegang tot de multi-userhost bestaat, moet ook voor de eigen regel daarvan Match known users uitgeschakeld zijn. Beperk de bronzone en toegestane bronhosts, de doelzone en RDS01 en de daadwerkelijk benodigde services, schakel logging in en controleer de positie vóór concurrerende gebruikersregels. Dit is geen aansporing om RDP openbaar beschikbaar te maken; voor normale webtoegang wordt geen nieuwe inkomende regel aangemaakt.

Acceptatietest met twee RDS-gebruikers

Eén geslaagde browseraanroep bewijst alleen dat er proxyverkeer werkt. Voor de daadwerkelijke acceptatietest zijn twee parallelle sessies nodig.

1. Koppel twee AD-pilotaccounts aan verschillende Web Policy-groepen.
2. Open twee nieuwe RDS-sessies op RDS01.
3. Controleer in beide sessies de effectieve proxyconfiguratie.
4. Voer in elke sessie één toegestane HTTP- of HTTPS-aanroep uit en één aanroep die bewust verschillend wordt beoordeeld.
5. Controleer onder Current activities > Live users beide gebruikers met Client Type Multi-host client.
6. Controleer onder Log viewer > Authentication de gebruikers en Log Comp voor Kerberos of NTLM.
7. Vergelijk in het web- en firewalllog de gebruiker, policy, Rule ID, actie en het tijdstip.
8. Voer een noodzakelijke non-proxytest uit en bevestig dat deze niet ten onrechte een gebruikersidentiteit krijgt.
9. Leg vanaf de pilothost vast welke lokale HTTP- en HTTPS-diensten van de firewall via de proxy bereikbaar zijn. Als een dienst bereikbaar is die volgens het beveiligingsontwerp niet toegankelijk mag zijn, stop dan de uitrol en ga pas verder met een aantoonbare aanvullende beveiligingsmaatregel.

Een zinvolle vergelijking gebruikt in beide sessies hetzelfde goedgekeurde testdoel: een account in RDS-Web-Standard mag het openen, terwijl een account in RDS-Web-Restricted door de voorbereide Web Policy wordt geblokkeerd. Leg datum, tijd, gebruiker, bron-IP, Rule ID, policy en resultaat vast. Open daarna een controledoel dat beide groepen mogen gebruiken. Zo onderscheid je een bedoelde groepsbeperking van een algemene proxy- of DNS-storing. De testdoelen komen uit de eigen goedgekeurde testlijst; blokkeer niet uitsluitend voor de acceptatietest een zakelijke website die in productie wordt gebruikt.

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

Problemen oplossen

De proxy is niet bereikbaar

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

De browser vraagt om aanmeldingsgegevens of gebruikt NTLM

Controleer het proxydoel, DNS, de HTTP-SPN, browserzone en geïntegreerde authenticatie. Kerberos heeft de juiste FQDN nodig, 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 daadwerkelijk de expliciete proxy gebruiken en of een toepassing verbindingen buiten de betreffende gebruikerssessie aanmaakt. Ook een voorliggende proxy 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 wordt niet toegepast

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

Als de pilotgebruiker in de Default group staat in plaats van in de verwachte geïmporteerde AD-groep, controleer dan eerst Authentication > Groups, de zoekbasis en de groepsimport. Ken geen ruimere standaardgroepspolicy toe om de fout te verbergen. Controleer na een gecontroleerde correctie met een nieuwe aanmelding of de koppeling en beide policytests kloppen.

Non-webverkeer toont geen gebruiker

Dit 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, stap dan over op SATC.

Na een upgrade of HA-failover werkt SSO niet meer

AD SSO kan na een upgrade, bij het gebruik van meerdere AD-servers of in HA een nieuwe Domain Join nodig hebben. Het gedelegeerde join-account 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 zonder onderbreking blijven werken. In elke HA-modus slaat elke node alleen de logs op van het verkeer dat deze zelf heeft verwerkt. Controleer voor een gebeurtenis daarom de node die op dat moment actief was of het verkeer verwerkte.

Bij een upgrade van SFOS 21.5 of ouder rechtstreeks naar SFOS 22.0 GA Build 411 kan daarnaast Known Issue NC-176853 van toepassing zijn: NTLM- en Kerberos-AD-SSO kunnen direct na de upgrade uitvallen, waardoor identiteitsgebaseerde policies niet matchen. Sophos vermeldt SFOS 22.0 MR1 Build 490 als versie met de oplossing. De interne procedure voor KBA-000048429 beschrijft de diagnose en workaround. De Known Issues List vermeldt Per-Connection AD SSO niet afzonderlijk; deze bevinding is daarom alleen relevant als het onderliggende AD-SSO-pad na precies deze upgrade uitvalt. Bewaar de firmwarebuild, het tijdstip en de logs, controleer de KBA voor de betreffende build en overbrug het probleem niet met brede regels of een wijziging van de authenticatiemethode.

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 als debug tijdelijk is ingeschakeld en hoort niet bij de normale eerste stap. Leg vóór het opnieuw starten van services of het uitbreiden van debug eerst het tijdvenster, de gebruiker, het doel, de regel en de bestaande logs vast.

Rollback

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

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

Checklist

• Per-Connection AD SSO is alleen bedoeld voor expliciet HTTP-/HTTPS-proxyverkeer.
• De pilothost heeft een vast, uniek IP zonder andere systemen erachter.
• AD, groepen, Domain Join, FQDN, DNS, SPN en tijd zijn gecontroleerd.
• AD-SSO-zonevoorwaarde en beveiligingsimpact beoordeeld; vereiste LAN-zone ingeschakeld en Apply toegepast, Web-proxytoegang afzonderlijk beperkt tot de pilothost zonder brede proxytoestemming. Is de zonetoestemming onacceptabel, stop dan de uitrol en verkrijg een ondersteund, afgebakend ontwerp.
• Browsers en toepassingen gebruiken fw01.corp.example:3128 of de eigen vervangende waarden.
• Bij de speciale hostregel is logging ingeschakeld en Match known users uitgeschakeld.
• Non-proxyverkeer is gepland als machineverkeer of het ontwerp is gewijzigd naar SATC.
• Twee parallelle gebruikers, verschillende policies en beheertoegang zijn positief en negatief getest.
• Voor HA-failover en upgrades is een procedure voor rejoin en opnieuw testen gedocumenteerd.
• De rollback van de multi-userlijst, proxydistributie, Device Access, regels en eerdere authenticatie is gedocumenteerd.

Veelgestelde vragen