Sophos Firewall: migrera eDirectory före SFOS 23

SFOS 23.0 stöder inte längre den inbyggda autentiseringsservern eDirectory. Om en inbyggd eDirectory-serverkonfiguration finns kvar på brandväggen misslyckas firmwareuppgraderingen till SFOS 23.0 eller senare. Före uppgraderingen måste därför en autentiseringsserver som stöds fungera och de inbyggda eDirectory-server- och eDirectory-SSO-konfigurationerna vara helt borttagna.

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 alla inbyggda eDirectory-server- och eDirectory-SSO-konfigurationer, 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.

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: inbyggd eDirectory-SSO är inte tillgänglig från och med SFOS 23. Den generiska LDAP-servern kontrollerar inloggningen men ger inte transparent användaridentifiering. Användare som tidigare identifierades automatiskt behöver därför ett nytt 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. 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. Backup och konfigurationsimport konverterar eller migrerar inte den eDirectory-konfiguration som ingår. En sådan backup är därför ingen fungerande återställningsväg för eDirectory efter uppgraderingen.

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 alla inbyggda eDirectory-server- och eDirectory-SSO-konfigurationer från brandväggen. En nyskapad generisk LDAP server som frågar samma katalog finns kvar.
Verifiera under Authentication > Servers, Authentication > Services och i inventeringen att ingen inbyggd eDirectory-konfiguration eller något beroende finns kvar.
Skapa en ny krypterad backup av den rensade konfigurationen.
Kontrollera den allmänna guiden Uppdatering av firmware för Sophos Firewall: förberedelser och bästa praxis samt aktuell information om versioner, uppgraderingar och Known Issues för SFOS 23. Starta först därefter uppgraderingen.

Uppgraderingsfelet när det finns en inbyggd eDirectory-serverkonfiguration och kravet på att ta bort den före SFOS 23 har bekräftats av Sophos. Före produktionsuppgraderingen ska även den slutliga informationen om versioner, uppgraderingar och Known Issues för SFOS 23 kontrolleras för ytterligare detaljer.

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: inbyggd eDirectory-SSO är inte tillgänglig från SFOS 23. Generisk LDAP kontrollerar inloggningen men ger ingen transparent användaridentifiering.
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 planeras som en senare återställningsväg för eDirectory: på SFOS 23 migreras inte den ingående eDirectory-konfigurationen; återställningsvägen måste fungera före uppgraderingen.