Sophos Firewall: migrera eDirectory före SFOS 23

SFOS 23.0 stöder inte längre den inbyggda autentiseringsservern eDirectory. Därför krävs migrering till en autentiseringstyp som stöds före uppgradering till SFOS 23.0 eller senare. Om en eDirectory-serverkonfiguration finns kvar på brandväggen misslyckas firmwareuppgraderingen. En verifierad målväg är alltså en förutsättning för uppgraderingen; enbart en backup av den gamla konfigurationen ersätter inte migreringen.

En befintlig eDirectory-serverkonfiguration utlöser ett larm i Control center och en banner under Authentication > Servers. Backuper och konfigurationsimporter kan innehålla en sådan konfiguration, men den migreras inte när den återställs eller importeras.

I SFOS 22.0 MR2 fungerar eDirectory fortfarande. Den tiden bör användas för en kontrollerad parallelldrift: lägg till den nya källan, kontrollera användare och grupper med verkliga konton, ställ om autentiseringstjänsterna kontrollerat och ta inte bort eDirectory förrän återställningsmöjligheten inte längre behövs. Kopplade Entra ID SSO-tjänster hanteras tillsammans. Översikten över MR2 sätter in de övriga ändringarna i versionen i sitt sammanhang.

Snabböversikt

Kartlägg alla eDirectory-beroenden i servrar, grupper, tjänster, regler, VPN och SSO.
Förbered en aktuell backup, en lokal administratör och dokumenterad konsolåtkomst.
Välj generisk LDAP, Active Directory, RADIUS eller Microsoft Entra ID SSO som mål beroende på användningsområde.
Lägg till den nya autentiseringsservern parallellt och kontrollera anslutning, användare och grupper.
Mappa medvetet grupper och policyer till den nya källan.
Ställ om tjänsterna kontrollerat under Authentication > Services och testa dem med verkliga konton; hantera kopplade Entra ID SSO-tjänster tillsammans.
Ta först efter fullständig verifiering bort den inbyggda eDirectory-serverkonfiguration och tidigare eDirectory-STAS-väg som inte längre behövs, skapa en ny backup och starta uppgraderingen till SFOS 23.

Det här är avsiktligt inte en övergång som görs med en enda omkopplare. Brandväggen använder autentiseringsservrar per tjänst och i en fastställd ordning. Dessutom är behörigheter ofta knutna till grupper som kan ha samma namn efter övergången, men inte automatiskt samma tilldelning och verkan.

Vad som i dag är beroende av eDirectory

Före den första ändringen måste det vara tydligt var eDirectory faktiskt används. Inventeringen bör minst omfatta följande områden:

Under Authentication > Servers finns eDirectory-servrarna och eventuellt flera katalogmål.
Under Authentication > Services anges för varje tjänst vilka servrar som tillfrågas och i vilken ordning.
Under Authentication > Groups kan gruppolicyer, Default Group och gruppordningen avgöra en användares faktiska behörigheter. Med Active Directory tillkommer Main Group och övriga medlemskap.
Brandväggsregler, Web- och Application-policyer samt Traffic Shaping kan referera till användare eller grupper.
VPN Portal, SSL VPN, Remote Access IPsec, User Portal och Captive Portal har egna inloggnings- och behörighetsvägar.
MFA och administrativa inloggningar kan bero på grupper och autentiseringsordningen.
Användarbaserade rapporter och transparent användaridentifiering kräver fortfarande en tillförlitlig koppling mellan användare och anslutning.

En skärmbild av den nuvarande server-, tjänste- och gruppordningen är ofta mer användbar än en ren namnlista. För varje viktig grupp bör man dessutom notera minst en positiv och en negativ testanvändare. Då går det senare att kontrollera inte bara vem som får åtkomst, utan också vem som avvisas korrekt.

Kartlägg XML-automatisering och äldre dokumentation om eDirectory-operationer

Inventeringen ska även omfatta skript, integrationer och Postman-samlingar som använder den inbyggda XML-API-typen EdirServer eller bygger på de äldre anvisningarna för att lägga till, redigera eller ta bort en eDirectory-server. För varje jobb dokumenteras ansvariga, utlösare respektive schema, brandväggsversion och build, det serverobjekt som anropas, läs- eller skrivoperation samt beroende tjänster. Kontrollera även sparade mallar och återställningsjobb som körs sällan; hemligheter ska ligga kvar i det skyddade hemlighetslagret och får inte kopieras till inventeringen.

XML-API-katalogen för SFOS 22 innehåller den inbyggda eDirectory-posten samt dokumentationen för operationerna Add eDirectory server / Edit eDirectory server och Delete eDirectory server. Dessa poster saknas i SFOS 23-katalogen. Detta är belägg i dokumentationen, inte ett bevis som vi har testat för att en API-operation har tagits bort vid körning och inte heller ett löfte om en viss felkod. Äldre dokument eller sparade samlingar utgör därför inget godkännande för att fortsätta skicka sådana begäranden till SFOS 23. Posterna för generiska LDAP-servrar finns kvar i katalogen. En generisk LDAP server som stöds tas inte bort bara för att den frågar samma katalog.

De berörda jobben ställs om till den valda måltyp som stöds, inte genom att enbart byta namn på EdirServer i en gammal payload:

Kontrollera i API help för den installerade builden om och hur målobjektet och den operation som behövs stöds. Objekttaggar, attribut, explicit skrivoperation och transport måste passa detta. Guiden Kontrollera API-åtkomst och granska XML-begäranden säkert förklarar tillåtna källor, kontobehörigheter, versionsgränser och svarskontroll. Om stödet fortfarande är oklart ska jobbet inte köras i produktion; klarlägg frågan med supporten.
Dokumentera målobjekt samt grupp- och tjänstetilldelning för ersättningsjobbet. Pausa de gamla skrivjobben före den kontrollerade pilotkörningen så att de varken utlöser dubbla ändringar eller återskapar en inbyggd serverkonfiguration som redan har tagits bort. Förvara säkerhetskopierade mallar, scheman och konfigurationsläget för återställningsvägen skyddat.
Testa under underhållsfönstret först en ofarlig läsfråga som stöds och därefter endast den godkända lilla ändringen. Jämför XML-svaret och statusen med det faktiska objektet i WebAdmin och med Audit Trail; enbart ett lyckat HTTP-anrop räcker inte. Testa dessutom inloggning, faktisk grupp och berörda policyer med verkliga konton. Aktivera ersättningsjobbet först efter denna verifiering och övervaka dess nästa ordinarie körningar.
Vid oväntade ändringar av objekt, grupper eller policyer ska ersättningsjobbet pausas och de loggade ändringarna återtas kontrollerat. Godkänn det gamla jobbet för körning igen endast på den SFOS 22-väg som fortfarande stöds, med befintlig inbyggd konfiguration och en verifierad återställningsväg; starta det inte som en nödlösning på SFOS 23. Efter firmwareuppgraderingen gäller de gränser för firmwareåterställning och restore som stöds och beskrivs längre ned. Innan borttagningen och uppgraderingen godkänns måste inventeringen bekräfta att inget produktionsjobb längre är beroende av den inbyggda EdirServer-vägen eller dess äldre dokumentation om operationer.

Dokumentera den inbyggda SFOS 22-anslutningen

Novell eDirectory är en X.500-kompatibel katalogtjänst. Den inbyggda servertypen eDirectory fungerar fortfarande i SFOS 22.0 MR2, men gränsen i SFOS 23 gör den olämplig som ny målarkitektur. Dokumentera i stället den befintliga anslutningen fullständigt före migreringen.

Öppna den befintliga eDirectory-servern under Authentication > Servers och dokumentera minst följande:

Server name, serverns IP-adress och port
Bind DN som ett fullständigt Distinguished Name i LDAP-syntax samt ägaren av tillhörande Password
Connection security: Simple skickar inloggningsuppgifter okrypterat; använd SSL/TLS eller STARTTLS i produktion
status för Validate server certificate och eventuellt valt Client certificate
Base DN som startpunkt för användarsökningen; Get base DN kan hämta det värde som servern erbjuder
resultatet av Test connection, en riktig användarinloggning och den resulterande gruppen

En befintlig Simple-väg är ett säkerhetsproblem, men ska inte ändras blint mitt under migreringen. DNS, certifikatnamn, CA-förtroende och avsedd TLS-port måste fungera först. Test connection bekräftar bara anslutning och inloggningsuppgifter. Dokumentera också val och ordning under Authentication > Services och testa en riktig tjänst. Bind-lösenord och andra hemligheter hör inte hemma i skärmbilder eller migreringsdokumentation.

Den andra äldre vägen är eDirectory-kompatibel STAS för transparent användaridentifiering. I SFOS 22 använder STAS Novell eDirectory som Domain Type under General > Monitored Domains och läget EDIRECTORY under STA Agent. Blanda inte ihop denna väg med krypterad LDAP-autentisering: säker LDAP-port 636 stöds inte för STAS-konfigurationen med Novell eDirectory. Beteendet som registrerats som NCL-1392 anger varken berörda eller korrigerade versioner och inte heller någon tillfällig lösning. STAS för Sophos Firewall beskriver den stödda planeringen, ersättningen och fullständiga verifieringen av denna identitetsväg.

Migreringsinventeringen måste därför även omfatta STAS-servrar, collector-grupper, övervakade nätverk och collectors som registrerats på brandväggen. En generisk LDAP-server kan ersätta användarautentisering, men inte denna transparenta STAS-identitetsväg. En separat verifierad metod krävs innan den äldre STAS-vägen tas ur drift.

Välj en lämplig målmetod

Det finns ingen universell 1:1-ersättning för varje eDirectory-miljö. Ett företag kan fortsätta använda den befintliga katalogen via LDAP, migrera identiteter till en annan katalog eller kombinera flera autentiseringsmetoder beroende på tjänst.

Fortsätt använda eDirectory via generisk LDAP

Om själva eDirectory ska finnas kvar kan Sophos Firewall fråga katalogen vid användarinloggningar via den servertyp som stöds, LDAP server. Den här metoden ändrar inte katalogträdet automatiskt, men kräver en ny LDAP-konfiguration med lämplig Base DN samt rätt inloggnings- och gruppattribut.

Begränsningen är viktig: den generiska LDAP-servern kontrollerar inloggningen men ger inte den transparenta användaridentifiering som den tidigare eDirectory-STAS-vägen gav. Användare som tidigare identifierades automatiskt behöver därför ett separat planerat SSO- eller inloggningsflöde. En fullständig beskrivning av fälten finns i Ansluta en generisk LDAP-server till Sophos Firewall.

Active Directory

Active Directory passar när användarna redan finns i en Windows-domän eller medvetet migreras dit. Då måste grupper importeras, Main Group och policyer kontrolleras på nytt och eventuell transparent användaridentifiering konfigureras separat. Ansluta Active Directory till Sophos Firewall beskriver LDAPS, gruppimport och tjänstetester.

STAS rapporterar Windows-domäninloggningar transparent till brandväggen, men konverterar inte den tidigare eDirectory-SSO-konfigurationen. Den som behöver den här identitetsvägen planerar den som en separat migrering med hjälp av STAS för Sophos Firewall.

RADIUS

RADIUS passar när det redan finns en central autentiseringstjänst eller en MFA-gateway. RADIUS-servern måste ge brandväggen den information som krävs för respektive tjänst; en katalogs gruppmodell överförs inte automatiskt. MFA-metoden måste passa tjänsten: VPN Portal stöder till exempel inte utmaningsbaserad RADIUS-MFA. Shared Secret, gruppattribut, tidsgränser och andra begränsningar beskrivs i Konfigurera en RADIUS-server på Sophos Firewall.

Microsoft Entra ID SSO

Microsoft Entra ID SSO kan vara lämpligt för dokumenterade scenarier med portaler, administratörer och Remote Access. Det är dock ingen allmän ersättning för varje fråga med användarnamn och lösenord och ger ingen transparent identifiering av LAN-användare. För Remote Access måste kopplade tjänster samordnas: VPN Portal och SSL VPN använder samma Entra-server; med en provisioneringsfil gäller detta även IPsec. Redirect URIs, grupper, Conditional Access och de tjänster som stöds beskrivs i Microsoft Entra ID SSO för Sophos Connect och VPN Portal.

Målarkitekturen kan vara blandad. LDAP kan till exempel inledningsvis autentisera användare från det befintliga eDirectory, medan Remote Access senare migreras specifikt till RADIUS eller Entra ID SSO. Det avgörande är att varje tjänst som används har en testad målväg innan eDirectory tas bort.

Säkra miljön före den första ändringen

Före övergången bör följande finnas på plats:

En aktuell, krypterad backup av Sophos Firewall.
En lokal administratör vars inloggning inte är beroende av eDirectory eller den nya externa källan. Under Authentication > Services måste Local fortfarande vara valt i Administrator authentication methods.
Dokumenterad konsolåtkomst eller annan nödåtkomst till brandväggen.
Skärmbilder eller en skriftlig inventering av server-, tjänste- och gruppordningen.
Minst ett testkonto per viktig grupp samt ett konto som inte ska få åtkomst.
Ett underhållsfönster, en ansvarig beslutsfattare och ett tydligt återställningskriterium.

WebAdmin-åtkomsten ställs om sist. Kontrollera först att Local fortfarande är valt och att den lokala inloggningen fungerar i ett privat webbläsarfönster. Då finns en oberoende åtkomstväg kvar om den nya externa autentiseringen eller gruppmatchningen inte fungerar som förväntat.

Bygg upp målservern parallellt

Den nya servern läggs först till som en extra server. Under den inledande serverkonfigurationen förblir det befintliga eDirectory-valet oförändrat; först för pilottestet ändras exakt en autentiseringsmetod som är enkel att kontrollera.

Exempel: anslut eDirectory som en generisk LDAP-server

Under Authentication > Servers > Add kan en pilotkonfiguration exempelvis se ut så här:

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: till exempel uid, efter kontroll av användarobjektet
Group name attribute: till exempel groupMembership, efter kontroll av användarobjektet
Validate server certificate: aktiverat efter att brandväggen har konfigurerats att lita på den utfärdande CA:n

edir01.example.net, Bind DN och Base DN är exempelvärden och måste anpassas till det egna katalogträdet. När certifikatvalidering är aktiverad måste det konfigurerade FQDN-namnet motsvara servercertifikatet och kunna lösas upp av brandväggen. Bindkontot behöver endast läsbehörighet till den del av katalogen som krävs.

Vilka inloggnings- och gruppattribut som passar avgörs av det verkliga användarobjektet. I en eDirectory-miljö kan exempelvis cn eller uid vara relevanta för inloggning och groupMembership för grupper. Det är värden som ska verifieras, inte universella inställningar.

Från ett Linux-administrationssystem kan ett användarobjekt kontrolleras med skrivskyddad åtkomst:

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

Kommandot ska inte köras i Advanced Shell på Sophos Firewall. -W frågar interaktivt efter bindlösenordet så att det inte sparas i skalhistoriken. Sökvägen i LDAPTLS_CACERT, FQDN-namnet, DN-värdena, filtret och de efterfrågade attributen måste anpassas till den egna miljön. Om den lokala OpenLDAP-klienten redan litar på CA:n via sitt betrodda certifikatarkiv eller ldap.conf kan LDAPTLS_CACERT utelämnas. I annat fall måste variabeln peka på ett läsbart PEM-CA-paket.

En möjlig utdata kan se ut så här:

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

Detta är ett läsexempel, inte ett garanterat eDirectory-schema. Om groupMembership saknas eller katalogen returnerar andra värden måste det faktiska attributet fastställas och brandväggskonfigurationen anpassas därefter. Kontrollera sedan Test connection, en verklig användarinloggning och den resulterande gruppen separat.

Mappa grupper och policyer på nytt

En lyckad inloggning räcker inte om användaren därefter hamnar i fel grupp. Anta att den tidigare gruppen VPN-Mitarbeitende får använda SSL VPN och når interna applikationer via en användarbaserad regel. Efter övergången måste minst följande frågor besvaras:

Visas testanvändaren under Authentication > Users med den förväntade faktiska gruppen? Med Active Directory kontrolleras Main Group och övriga medlemskap separat.
Finns den nya gruppen under Authentication > Groups och har den rätt placering?
Refererar SSL VPN- eller IPsec-konfigurationen till den nya faktiska gruppen?
Matchar användaren fortfarande den avsedda brandväggsregeln och inte en mer allmän regel?
Tillämpas fortfarande den önskade MFA-policyn?

Samma synliga gruppnamn från två källor garanterar varken samma medlemskap eller samma faktiska gruppprioritet. Med Active Directory kan gruppordningen och Main Group påverka VPN, MFA och andra policyer. Grunderna beskrivs i Aktivera MFA för Sophos Firewall.

Ställ om en tjänst i taget

Under Authentication > Services väljs autentiseringsservrar per tjänst. När flera servrar är valda vidarebefordrar brandväggen begäranden i den ordning som visas. Högst 20 autentiseringsservrar kan väljas per autentiseringsmetod; planera in den gamla och den nya servern inom denna gräns under parallelldriften. Därför ska inte allt ställas om samtidigt. Kopplade Entra ID SSO-tjänster planeras och verifieras dock som en sammanhängande väg.

Välj först en tjänst som är enkel att kontrollera och en pilotanvändare.
Välj den nya servern för denna tjänst och fastställ medvetet dess position i serverordningen.
Tillämpa ändringen och testa en korrekt samt en avsiktligt felaktig inloggning.
Kontrollera användare, grupp, loggpost och den policy som faktiskt tillämpades.
Ställ först därefter om nästa tjänst.

Börja med en medvetet vald pilottjänst som är enkel att kontrollera. Därefter följer de områden som faktiskt används, till exempel Firewall authentication methods, User portal authentication methods, VPN portal authentication methods, SSL VPN authentication methods och Remote Access IPsec. Med Entra ID SSO ställs de kopplade Remote Access-tjänster som beskrivs ovan om samordnat. På grund av risken för utelåsning ställs Administrator authentication methods om sist. Översikten över Sophos Firewall-portaler förklarar vilka portaler som fungerar separat och måste vara nåbara.

Om samma användarnamn finns på den gamla och den nya servern kan serverordningen dölja en felaktig gruppmappning. För ett kontrollerat test kan man tillfälligt välja endast den nya servern för den valda pilottjänsten. Den verkliga inloggningen och Authentication > Users visar då om den nya källan levererar användaren med den förväntade gruppen.

Verifiera med verkliga anslutningar

Test connection bekräftar att servern kan nås och att inloggningsuppgifterna är korrekta. Verifieringen är dock inte klar förrän den verkliga tjänsten och den tillhörande behörigheten fungerar.

För varje relevant grupp bör verifieringen minst visa följande:

En behörig användare kan logga in på den avsedda portalen eller VPN-tjänsten.
En obehörig användare avvisas eller får endast den avsedda begränsade policyn.
Under Authentication > Users är användare och grupp korrekta.
Log Viewer visar en begriplig autentiseringshändelse.
Brandväggs-, Web- och VPN-policyerna matchar den förväntade regeln.
Interna mål kan nås via den avsedda trafikvägen.
MFA och administrativa roller fungerar som planerat.

Med Firewall Rule Testing och Log Viewer går det att kontrollera vilket Rule ID som tillämpas för en användare och dennes trafik. Transparent användaridentifiering respektive SSO testas separat; en lyckad LDAP-inloggning bekräftar inte den vägen.

Återställning under pilotfasen

Så länge brandväggen fortfarande använder SFOS 22.0 MR2 och eDirectory inte har tagits bort finns den gamla konfigurationen kvar som en kontrollerad återställningsmöjlighet. Om ett pilottest misslyckas återställs alla värden som ändrades för testet: serverval och ordning under Authentication > Services, Default Group och gruppordningen samt berörda VPN-medlemmar, MFA-referenser och policyreferenser. Därefter kontrolleras inloggning, grupp och policy på nytt.

Backupen skyddar brandväggskonfigurationen men är ingen automatisk identitetsmigrering och bevisar inte att den nya identitetsvägen fungerar. En återställning efter firmwareuppgraderingen måste dessutom följa de procedurer för firmwareåterställning och restore som Sophos stöder. Verifiera därför eDirectory-återställningsvägen före uppgraderingen i stället för att enbart förlita dig på backupfilen.

Ta bort eDirectory och godkänn uppgraderingen till SFOS 23

eDirectory tas bort först efter en observationsperiod som har definierats i förväg. Under denna tid måste varje produktionsanvänd inloggningsväg, varje viktig grupp, de VPN-anslutningar som används och de administrativa processerna ha fungerat felfritt minst en gång via den nya källan under realistiska förhållanden. Oklara fel i autentisering, grupper eller policyer förhindrar ett godkännande av borttagningen.

Avslutningsvis:

Kontrollera att eDirectory inte längre är valt i någon autentiseringsmetod.
Jämför på nytt beroenden för grupper, VPN, policyer, MFA, administratörer och SSO med inventeringen.
Ta bort den inbyggda eDirectory-serverkonfiguration som inte längre behövs och ta den tidigare eDirectory-STAS-vägen ur drift. En nyskapad generisk LDAP server som frågar samma katalog finns kvar.
Verifiera under Authentication > Servers, Authentication > Services, i STAS-konfigurationen och i inventeringen att ingen produktionstjänst fortfarande är beroende av den inbyggda eDirectory-vägen.
Skapa en ny krypterad backup av den rensade konfigurationen.
Dokumentera exakt målversion och build och jämför dem med migreringsgränserna som beskrivs här samt den allmänna guiden Uppdatering av firmware för Sophos Firewall: förberedelser och bästa praxis. Starta först därefter uppgraderingen.

Den inbyggda autentiseringsservern eDirectory upphör i SFOS 23; först krävs migrering till en autentiseringstyp som stöds. Godkännandet för produktionsuppgraderingen måste alltid motsvara exakt målversion och build.

Vanliga fallgropar

Test connection lyckas, men användaren hamnar i fel grupp: kontrollera Base DN, inloggnings- och gruppattributen i det verkliga användarobjektet samt gruppordningen.
Pilottestet verkar fungera, men kan fortfarande använda eDirectory: välj tillfälligt endast den nya servern för den kontrollerade pilottjänsten och kontrollera därefter användare, grupp och policy.
User Portal fungerar, men VPN gör det inte: kontrollera autentiseringsmetoden och behörighetsgruppen separat för varje portal och VPN-tjänst.
LDAP-inloggningen fungerar, men inte den transparenta identifieringen: generisk LDAP kontrollerar inloggningen men ersätter inte den tidigare eDirectory-STAS-identitetsvägen. Migrera och testa den transparenta identifieringen separat.
Efter gruppövergången matchas en annan brandväggsregel: jämför den faktiska gruppen, gruppordningen och direkta användar- eller gruppreferenser i policyerna. Med Active Directory ska även Main Group och övriga medlemskap kontrolleras.
Backupen behandlas som den enda återställningsvägen för eDirectory: en backupfil migrerar inte identitetsvägen och ersätter inte en firmwareåterställning som stöds. Dokumentera och verifiera hela återställningen före uppgraderingen.