Sophos Firewall: eDirectory migreren vóór SFOS 23

SFOS 23.0 ondersteunt de native eDirectory-authenticatieserver niet meer. Als er een native eDirectory-serverconfiguratie op de firewall achterblijft, mislukt de firmware-upgrade naar SFOS 23.0 of hoger. Vóór de upgrade moet daarom een ondersteunde authenticatieserver werken en moet de native eDirectory-server- en SSO-configuratie volledig zijn verwijderd.

In SFOS 22.0 MR2 werkt eDirectory nog. Gebruik deze periode voor een gecontroleerde parallelle werking: voeg de nieuwe bron toe, controleer gebruikers en groepen met echte accounts, schakel de authenticatieservices gecontroleerd om en verwijder eDirectory pas wanneer de terugval niet meer nodig is. Gekoppelde Entra ID SSO-services worden daarbij gezamenlijk behandeld. Het MR2-overzicht plaatst de overige wijzigingen van deze versie in hun context.

Korte procedure

Inventariseer alle eDirectory-afhankelijkheden in servers, groepen, services, regels, VPN en SSO.
Bereid een actuele back-up, een lokale beheerder en een gedocumenteerde consoletoegang voor.
Kies afhankelijk van het gebruik generieke LDAP, Active Directory, RADIUS of Microsoft Entra ID SSO als doel.
Voeg de nieuwe authenticatieserver parallel toe en controleer de verbinding, gebruikers en groepen.
Wijs groepen en policies bewust toe aan de nieuwe bron.
Schakel de services onder Authentication > Services gecontroleerd om en test ze met echte accounts; behandel gekoppelde Entra ID SSO-services gezamenlijk.
Verwijder pas na de volledige acceptatie alle native eDirectory-server- en SSO-configuraties, maak opnieuw een back-up en start de upgrade naar SFOS 23.

Dit is bewust geen omschakeling met één knop. De firewall gebruikt authenticatieservers per service en in een vastgelegde volgorde. Bovendien zijn rechten vaak gekoppeld aan groepen die na de omschakeling wel dezelfde naam kunnen hebben, maar niet automatisch dezelfde toewijzing en werking hebben.

Wat momenteel van eDirectory afhankelijk is

Vóór de eerste wijziging moet duidelijk zijn waar eDirectory daadwerkelijk wordt gebruikt. Neem minimaal de volgende onderdelen op in de inventaris:

Onder Authentication > Servers staan de eDirectory-servers en eventueel meerdere directorydoelen.
Onder Authentication > Services wordt per service bepaald welke servers in welke volgorde worden bevraagd.
Onder Authentication > Groups kunnen groepspolicies, Default Group en groepsvolgorde de effectieve rechten van een gebruiker bepalen. Bij Active Directory komen daar Main Group en andere groepslidmaatschappen bij.
Firewallregels, Web- en Application-policies en Traffic Shaping kunnen naar gebruikers of groepen verwijzen.
VPN Portal, SSL VPN, Remote Access IPsec, User Portal en Captive Portal hebben eigen authenticatie- en autorisatiepaden.
MFA en beheerderaanmeldingen kunnen afhankelijk zijn van groepen en de authenticatievolgorde.
Gebruikersgebaseerde rapporten en transparante gebruikersherkenning vereisen nog steeds een betrouwbare koppeling tussen gebruiker en verbinding.

Een screenshot van de huidige server-, service- en groepsvolgorde is vaak nuttiger dan alleen een lijst met namen. Noteer daarnaast voor elke belangrijke groep minimaal één positieve en één negatieve testgebruiker. Zo kan later niet alleen worden gecontroleerd wie toegang krijgt, maar ook wie correct wordt geweigerd.

De juiste doelmethode kiezen

Er bestaat geen universele één-op-één-vervanging voor elke eDirectory-omgeving. Een organisatie kan de bestaande directory via LDAP blijven gebruiken, identiteiten naar een andere directory migreren of afhankelijk van de service meerdere authenticatiemethoden combineren.

Bestaande eDirectory via generieke LDAP

Als eDirectory zelf blijft bestaan, kan Sophos Firewall deze via het ondersteunde servertype LDAP server bevragen voor gebruikersaanmeldingen. Dit pad wijzigt de directorystructuur niet automatisch, maar vereist wel een nieuwe LDAP-configuratie met een passende Base DN en passende aanmeldings- en groepsattributen.

De beperking is belangrijk: native eDirectory SSO is vanaf SFOS 23 niet meer beschikbaar. De generieke LDAP-server controleert de aanmelding, maar neemt de transparante gebruikersherkenning niet over. Gebruikers die eerder automatisch werden herkend, hebben daarom een nieuw SSO- of aanmeldingsproces nodig. De volledige veldbeschrijving staat in Een generieke LDAP-server met Sophos Firewall verbinden.

Active Directory

Active Directory past wanneer de gebruikers al in een Windows-domein aanwezig zijn of bewust daarheen worden gemigreerd. Importeer dan de groepen, controleer Main Group en policies opnieuw en bouw de gewenste transparante gebruikersherkenning afzonderlijk op. Active Directory met Sophos Firewall verbinden behandelt LDAPS, groepsimport en de servicetests.

STAS meldt Windows-domeinaanmeldingen transparant bij de firewall, maar converteert de bestaande eDirectory SSO-configuratie niet. Als dit identiteitspad nodig is, plan het dan met STAS voor Sophos Firewall als afzonderlijke migratie.

RADIUS

RADIUS is geschikt wanneer er al een centrale authenticatieservice of MFA-gateway bestaat. De RADIUS-server moet de informatie leveren die de firewall voor de betreffende service nodig heeft; een directorygroepsmodel wordt niet automatisch overgenomen. De MFA-methode moet bij de service passen: VPN Portal ondersteunt bijvoorbeeld geen challenge-gebaseerde RADIUS-MFA. Shared Secret, groepsattribuut, time-outs en verdere beperkingen worden behandeld in Een Sophos Firewall RADIUS-server instellen.

Microsoft Entra ID SSO

Microsoft Entra ID SSO kan geschikt zijn voor gedocumenteerde portal-, beheerder- en Remote Access-scenario’s. Het is echter geen algemene vervanging voor elke gebruikersnaam-wachtwoordaanvraag en biedt geen transparante LAN-gebruikersherkenning. Bij Remote Access moeten samenhangende services worden gecoördineerd: VPN Portal en SSL VPN gebruiken dezelfde Entra-server; bij een provisioningbestand geldt dit bovendien voor IPsec. Redirect URIs, groepen, Conditional Access en de ondersteunde services worden beschreven in Microsoft Entra ID SSO voor Sophos Connect en VPN Portal.

De doelarchitectuur mag gemengd zijn. LDAP kan bijvoorbeeld voorlopig gebruikers uit de bestaande eDirectory authenticeren, terwijl Remote Access later gericht naar RADIUS of Entra ID SSO wordt omgeschakeld. Doorslaggevend is dat elke gebruikte service een getest doelpad heeft voordat eDirectory wordt verwijderd.

Beveiligen vóór de eerste wijziging

Zorg vóór de cutover dat de volgende onderdelen beschikbaar zijn:

Een actuele, versleutelde Sophos Firewall-back-up.
Een lokale beheerder van wie de aanmelding niet afhankelijk is van eDirectory of de nieuwe externe bron. Onder Authentication > Services moet Local bij Administrator authentication methods geselecteerd blijven.
Een gedocumenteerde console- of andere noodtoegang tot de firewall.
Screenshots of een schriftelijke inventaris van de server-, service- en groepsvolgorde.
Minimaal één testaccount per belangrijke groep en een account dat geen toegang mag krijgen.
Een onderhoudsvenster, een verantwoordelijke beslisser en een duidelijk terugvalcriterium.

Schakel de WebAdmin-toegang als laatste om. Controleer vooraf of Local geselecteerd blijft en of de lokale aanmelding in een privébrowservenster werkt. Zo blijft er een onafhankelijke toegang beschikbaar als de nieuwe externe authenticatie of de groepsresolutie niet werkt zoals verwacht.

Doelserver parallel opbouwen

Voeg de nieuwe server eerst aanvullend toe. Tijdens de initiële serverconfiguratie blijft de bestaande eDirectory-selectie ongewijzigd; pas voor de pilottest wordt precies één beheersbare authenticatiemethode gewijzigd.

Voorbeeld: eDirectory als generieke LDAP-server koppelen

Onder Authentication > Servers > Add kan een pilotconfiguratie er bijvoorbeeld als volgt uitzien:

Server type: LDAP server
Server name: EDIR-LDAP-PILOT
Server IP/domain: edir01.example.net
Version: 3
Connection security: SSL/TLS
Port: 636
Bind DN: cn=sfos-bind,ou=service,o=Example
Base DN: ou=users,o=Example
Authentication attribute: bijvoorbeeld uid, na controle van het gebruikersobject
Group name attribute: bijvoorbeeld groupMembership, na controle van het gebruikersobject
Validate server certificate: ingeschakeld nadat de uitgevende CA op de firewall als vertrouwd is ingesteld

edir01.example.net, Bind DN en Base DN zijn voorbeeldwaarden en moeten bij de eigen directorystructuur passen. Als certificaatvalidatie is ingeschakeld, moet de geconfigureerde FQDN overeenkomen met het servercertificaat en door de firewall kunnen worden omgezet. Het bindaccount heeft alleen leesrechten nodig voor het vereiste deel van de directory.

Welke aanmeldings- en groepsattributen passen, wordt bepaald door het werkelijke gebruikersobject. In een eDirectory-omgeving kunnen bijvoorbeeld cn of uid voor de aanmelding en groupMembership voor groepen relevant zijn. Dit zijn te controleren kandidaten en geen universele voorschriften.

Vanaf een Linux-beheersysteem kan een gebruikersobject alleen-lezen worden gecontroleerd:

LDAPTLS_CACERT='/secure/path/edir-ca.pem' \
ldapsearch -LLL -x \
  -H 'ldaps://edir01.example.net:636' \
  -D 'cn=sfos-bind,ou=service,o=Example' -W \
  -b 'ou=users,o=Example' -s sub \
  '(|(cn=max.muster)(uid=max.muster))' \
  dn objectClass cn uid mail groupMembership

Deze opdracht hoort niet in de Advanced Shell van Sophos Firewall. -W vraagt interactief om het bindwachtwoord, zodat dit niet in de shellgeschiedenis terechtkomt. Het pad bij LDAPTLS_CACERT, de FQDN, de DN’s, het filter en de opgevraagde attributen moeten aan de eigen omgeving worden aangepast. Als de lokale OpenLDAP-client de CA al via de Trust Store of ldap.conf vertrouwt, kan LDAPTLS_CACERT worden weggelaten. Anders verwijst de variabele naar een leesbare CA-bundle in PEM-formaat.

Een mogelijke uitvoer kan er als volgt uitzien:

dn: cn=Max Muster,ou=users,o=Example
cn: Max Muster
uid: max.muster
mail: max.muster@example.net
groupMembership: cn=VPN-Mitarbeitende,ou=groups,o=Example

Dit is een leesvoorbeeld en geen beloofd eDirectory-schema. Als groupMembership ontbreekt of de directory andere waarden levert, bepaal dan het werkelijke attribuut en pas de firewallconfiguratie daarop aan. Controleer daarna afzonderlijk Test connection, een echte gebruikersaanmelding en de resulterende groep.

Groepen en policies opnieuw toewijzen

Een geslaagde aanmelding is niet voldoende als de gebruiker daarna in de verkeerde groep terechtkomt. Stel dat de bestaande groep VPN-Mitarbeitende SSL VPN mag gebruiken en via een gebruikersregel interne applicaties kan bereiken. Na de omschakeling moeten minimaal de volgende vragen worden beantwoord:

Verschijnt de testgebruiker onder Authentication > Users met de verwachte effectieve groep? Controleer bij Active Directory Main Group en andere lidmaatschappen afzonderlijk.
Is de nieuwe groep aanwezig en correct gerangschikt onder Authentication > Groups?
Verwijst de SSL VPN- of IPsec-configuratie naar de nieuwe effectieve groep?
Komt de gebruiker nog steeds overeen met de bedoelde firewallregel en niet met een algemenere regel?
Wordt de gewenste MFA-policy nog steeds toegepast?

Dezelfde zichtbare groepsnamen uit twee bronnen garanderen niet hetzelfde lidmaatschap of dezelfde effectieve groepsprioriteit. Bij Active Directory kunnen groepsvolgorde en Main Group invloed hebben op VPN, MFA en andere policies. De basisprincipes staan in MFA voor Sophos Firewall activeren.

Service voor service omschakelen

Onder Authentication > Services worden authenticatieservers per service geselecteerd. Daarom wordt niet alles tegelijk omgeschakeld. Gekoppelde Entra ID SSO-services worden echter als één samenhangend pad gepland en gezamenlijk geaccepteerd.

Kies eerst een beheersbare service en een pilotgebruiker.
Selecteer de nieuwe server voor deze service en leg de positie in de servervolgorde bewust vast.
Pas de wijziging toe en test zowel een correcte als een opzettelijk onjuiste aanmelding.
Controleer gebruiker, groep, logvermelding en de daadwerkelijk toegepaste policy.
Schakel pas daarna de volgende service om.

Begin met een bewust gekozen, goed beheersbare pilotservice. Daarna volgen de daadwerkelijk gebruikte onderdelen, zoals Firewall authentication methods, User portal authentication methods, VPN portal authentication methods, SSL VPN authentication methods en Remote Access IPsec. Bij Entra ID SSO worden de hierboven beschreven gekoppelde Remote Access-services gecoördineerd omgeschakeld. Vanwege het risico op buitensluiting volgen Administrator authentication methods als laatste. Het overzicht van Sophos Firewall-portals legt uit welke portals afzonderlijk functioneren en bereikbaar moeten zijn.

Als dezelfde gebruikersnaam op de oude en nieuwe server bestaat, kan de servervolgorde een onjuiste groepstoewijzing verhullen. Selecteer voor een gecontroleerde test bij de gekozen pilotservice tijdelijk alleen de nieuwe server. De echte aanmelding en Authentication > Users laten daarna zien of de nieuwe bron de gebruiker met de verwachte groep levert.

Met echte verbindingen accepteren

Test connection bevestigt de bereikbaarheid en inloggegevens van de server. De controle is echter pas afgerond wanneer de echte service en de daaraan gekoppelde autorisatie werken.

De acceptatie moet voor elke relevante groep minimaal het volgende aantonen:

Een bevoegde gebruiker kan zich aanmelden bij de bedoelde portal of VPN-service.
Een niet-bevoegde gebruiker wordt geweigerd of krijgt alleen de bedoelde beperkte policy.
Onder Authentication > Users kloppen gebruiker en groep.
De Log Viewer toont een begrijpelijke authenticatiegebeurtenis.
Firewall-, Web- en VPN-policies komen overeen met de verwachte regel.
Interne doelen zijn via het bedoelde verkeerspad bereikbaar.
MFA en beheerdersrollen gedragen zich zoals gepland.

Met Firewall Rule Testing en Log Viewer kan worden gecontroleerd welke Rule ID voor een gebruiker en diens verkeer van toepassing is. Transparante gebruikersherkenning of SSO wordt afzonderlijk getest; een geslaagde LDAP-aanmelding bevestigt dit pad niet.

Terugval tijdens de pilotfase

Zolang de firewall nog SFOS 22.0 MR2 gebruikt en eDirectory niet is verwijderd, blijft de oude configuratie beschikbaar als gecontroleerde terugval. Als een pilot mislukt, worden alle daarvoor gewijzigde waarden teruggezet: serverselectie en volgorde onder Authentication > Services, Default Group en groepsvolgorde, en de betrokken VPN-leden, MFA- en policyverwijzingen. Controleer daarna de aanmelding, groep en policy opnieuw.

De back-up beschermt de firewallconfiguratie, maar is geen automatische identiteitsmigratie. Back-up en configuratie-import converteren of migreren de eDirectory-configuratie die ze bevatten niet. Een dergelijke back-up is daarom na de upgrade geen functionerende eDirectory-terugval.

eDirectory verwijderen en SFOS 23 vrijgeven

Verwijder eDirectory pas na een vooraf vastgelegde observatieperiode. In deze periode moeten elk productief gebruikt aanmeldingspad, elke belangrijke groep, de gebruikte VPN-verbindingen en de beheerprocedures onder realistische omstandigheden minimaal één keer foutloos via de nieuwe bron hebben gewerkt; onopgeloste authenticatie-, groeps- of policyfouten verhinderen de vrijgave voor verwijdering.

Ter afsluiting:

Controleer of eDirectory in geen enkele authenticatiemethode meer is geselecteerd.
Vergelijk groeps-, VPN-, policy-, MFA-, beheerder- en SSO-afhankelijkheden opnieuw met de inventaris.
Verwijder alle native eDirectory-server- en eDirectory SSO-configuraties van de firewall. Een nieuw aangemaakte generieke LDAP server die dezelfde directory bevraagt, blijft bestaan.
Controleer onder Authentication > Servers, Authentication > Services en in de inventaris of er geen native eDirectory-configuratie of -afhankelijkheid meer over is.
Maak een nieuwe versleutelde back-up van de opgeschoonde configuratie.
Controleer de algemene procedure Sophos Firewall-firmware-update: voorbereiding en best practices en de actuele SFOS 23 Release Notes, upgrade-informatie en Known Issues. Start de upgrade pas daarna.

Sophos bevestigt dat de upgrade mislukt wanneer er een native eDirectory-serverconfiguratie aanwezig is en dat deze vóór SFOS 23 moet worden verwijderd. Controleer vóór de productie-upgrade ook de definitieve SFOS 23 Release Notes, upgrade-informatie en Known Issues op verdere details.

Typische struikelblokken

Test connection is geslaagd, maar de gebruiker komt in de verkeerde groep terecht: controleer Base DN, het aanmeldings- en groepsattribuut op het echte gebruikersobject en de groepsvolgorde.
De pilot lijkt te werken, maar kan nog eDirectory gebruiken: selecteer bij de gecontroleerde pilotservice tijdelijk alleen de nieuwe server en controleer daarna gebruiker, groep en policy.
User Portal werkt, maar VPN niet: controleer de authenticatiemethode en autorisatiegroep afzonderlijk voor elke portal en VPN-service.
LDAP-aanmelding werkt, maar transparante herkenning niet: native eDirectory SSO is vanaf SFOS 23 niet meer beschikbaar. Generieke LDAP controleert de aanmelding, maar neemt de transparante gebruikersherkenning niet over.
Na de groepswijziging geldt een andere firewallregel: vergelijk de effectieve groep, groepsvolgorde en directe gebruikers- of groepsverwijzingen in de policies. Controleer bij Active Directory bovendien Main Group en andere lidmaatschappen.
De back-up is gepland als latere eDirectory-terugval: onder SFOS 23 wordt de opgenomen eDirectory-configuratie niet gemigreerd; de terugval moet vóór de upgrade werken.