Sophos Firewall: eDirectory migreren vóór SFOS 23

SFOS 23.0 ondersteunt de native eDirectory-authenticatieserver niet meer. Daarom is een migratie naar een ondersteund authenticatietype vereist voordat naar SFOS 23.0 of hoger wordt geüpgraded. Als er een eDirectory-serverconfiguratie op de firewall achterblijft, mislukt de firmware-upgrade. Een gevalideerd doelpad is dus een upgradevoorwaarde; alleen een back-up van de oude configuratie maken is geen vervanging voor de migratie.

Een bestaande eDirectory-serverconfiguratie activeert een waarschuwing in het Control center en een banner onder Authentication > Servers. Back-ups en configuratie-imports mogen zo’n configuratie bevatten, maar bij het herstellen of importeren wordt deze niet gemigreerd.

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 de niet meer benodigde native eDirectory-serverconfiguratie en het eerdere eDirectory-STAS-pad, 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 native SFOS 22-verbinding documenteren

Novell eDirectory is een X.500-compatibele directoryservice. Het native servertype eDirectory werkt nog in SFOS 22.0 MR2, maar door de SFOS 23-grens is het niet geschikt als nieuw doelontwerp. Leg daarom vóór de migratie de bestaande verbinding volledig vast.

Open onder Authentication > Servers de bestaande eDirectory-server en documenteer ten minste het volgende:

Server name, IP-adres van de server en poort
Bind DN als volledige Distinguished Name in LDAP-syntaxis en de eigenaar van het bijbehorende Password
Connection security: Simple verstuurt inloggegevens onversleuteld; gebruik in productie SSL/TLS of STARTTLS
de status van Validate server certificate en een eventueel geselecteerd Client certificate
Base DN als startpunt voor het zoeken naar gebruikers; Get base DN kan de door de server aangeboden waarde ophalen
het resultaat van Test connection, een echte gebruikersaanmelding en de resulterende groep

Een bestaand Simple-pad is een securitybevinding, maar wordt niet midden in de migratie blind omgezet. DNS, certificaatnaam, CA-vertrouwen en de geplande TLS-poort moeten eerst werken. Test connection bevestigt alleen verbinding en inloggegevens. Leg ook selectie en volgorde onder Authentication > Services vast en test een echte service. Bind-wachtwoorden en andere geheimen horen niet in screenshots of migratiedocumentatie.

Het tweede verouderde pad is eDirectory-compatibele STAS voor transparante gebruikersherkenning. In SFOS 22 gebruikt STAS Novell eDirectory als Domain Type onder General > Monitored Domains en de modus EDIRECTORY onder STA Agent. Verwar dit pad niet met versleutelde LDAP-authenticatie: secure LDAP-poort 636 wordt niet ondersteund voor de Novell eDirectory-configuratie van STAS. Het als NCL-1392 geregistreerde gedrag vermeldt geen getroffen of gecorrigeerde versies en geen workaround. STAS voor Sophos Firewall beschrijft de ondersteunde planning, vervanging en end-to-endvalidatie van dit identiteitspad.

Neem daarom ook de STAS-servers, collectorgroepen, bewaakte netwerken en op de firewall geregistreerde collectors op in de migratie-inventaris. Een generieke LDAP-server kan gebruikersauthenticatie vervangen, maar niet dit transparante STAS-identiteitspad. Er is een afzonderlijke, gevalideerde methode nodig voordat het oude STAS-pad buiten gebruik wordt gesteld.

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: de generieke LDAP-server controleert de aanmelding, maar neemt de transparante gebruikersherkenning van het eerdere eDirectory-STAS-pad niet over. Gebruikers die eerder automatisch werden herkend, hebben daarom een afzonderlijk gepland 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. Als meerdere servers zijn geselecteerd, stuurt de firewall aanvragen in de getoonde volgorde door. Per authenticatiemethode kunnen maximaal 20 authenticatieservers worden geselecteerd; plan de oude en nieuwe server voor parallel gebruik binnen deze limiet. 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 en bewijst niet dat het nieuwe identiteitspad werkt. Een terugval na de firmware-upgrade moet bovendien de door Sophos ondersteunde procedures voor firmwareterugval en herstel volgen. Valideer daarom het eDirectory-terugvalpad vóór de upgrade in plaats van alleen op het back-upbestand te vertrouwen.

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 de niet meer benodigde native eDirectory-serverconfiguratie en stel het eerdere eDirectory-STAS-pad buiten gebruik. Een nieuw aangemaakte generieke LDAP server die dezelfde directory bevraagt, blijft bestaan.
Controleer onder Authentication > Servers, Authentication > Services, in de STAS-configuratie en in de inventaris of geen enkele productieservice nog afhankelijk is van het native eDirectory-pad.
Maak een nieuwe versleutelde back-up van de opgeschoonde configuratie.
Leg de exacte doelversie en build vast en toets die aan de hier beschreven migratiegrenzen en de algemene procedure Sophos Firewall-firmware-update: voorbereiding en best practices. Start de upgrade pas daarna.

De native eDirectory-authenticatieserver vervalt met SFOS 23; eerst is een migratie naar een ondersteund authenticatietype vereist. Goedkeuring voor de productie-upgrade moet altijd bij de exacte doelversie en build passen.

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: generieke LDAP controleert de aanmelding, maar vervangt het eerdere eDirectory-STAS-identiteitspad niet. Migreer en test transparante herkenning afzonderlijk.
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 wordt als enige eDirectory-terugval beschouwd: een back-upbestand migreert het identiteitspad niet en vervangt geen ondersteunde firmwareterugval. Documenteer en valideer de terugval volledig vóór de upgrade.