Kontrollera User-ID-gränsen och VPN-portalnedladdningar

Om en användare kan logga in på VPN Portal men inte ladda ned någon .ovpn-konfiguration beror det ofta på SSL VPN-behörigheten, MFA eller webbläsaren. I stora miljöer eller miljöer som har vuxit under många år kan det dock finnas en mindre uppenbar orsak: Sophos Firewalls interna User ID.

Sophos Firewall stöder högst 65 535 User ID, som delas mellan användare och grupper. Det går att kontrollera direkt i WebAdmin om en viss användare berörs. Enligt Sophos Firewall-dokumentationen autentiseras användare med ett ID över 65535 inte längre och kan därför bland annat misslyckas med att ladda ned .ovpn-filen.

Den här artikeln visar hur du verifierar felbilden och rensar användarhanteringen utan att förhastat radera produktionskonton, grupper eller MFA-tilldelningar.

När User-ID-gränsen bör misstänkas

Gränsen är inte ett typiskt fel i små miljöer. Den blir relevant när många lokala konton, externa användare eller importerade grupper har skapats på brandväggen under flera år.

Följande kombination är särskilt misstänkt:

• Inloggningen på VPN Portal fungerar, men .ovpn-filen saknas eller går inte att ladda ned.
• Endast enskilda användare berörs, trots att gruppen och Remote Access-policyn är identiska.
• Nyare användare misslyckas medan äldre konton fortsätter att fungera.
• Det finns väldigt många gamla objekt under Authentication > Users eller Authentication > Groups.
• Testkonton, tidigare medarbetare eller kataloggrupper som inte längre behövs har aldrig rensats bort.

Om alla användare berörs eller om inloggningen misslyckas redan före portalen bör du först kontrollera autentiseringsservern, MFA, Device Access och Remote Access-policyn. Om tunneln upprättas men ingen trafik därefter flödar ligger problemet troligare i brandväggsregler, routing, DNS, NAT eller returvägen.

Vad det interna User ID-numret betyder

Det User ID som avses här är en intern numerisk tilldelning i brandväggen. Det är varken ett Active Directory-SID, ett Microsoft Entra Object ID eller funktionen Synchronized user ID authentication.

Fyra egenskaper är viktiga för felsökningen:

• Användare och grupper delar samma intervall med högst 65535 ID-nummer.
• Användare kan visserligen skapas utöver denna gräns, men brandväggen kan inte längre autentisera dem om de får ett högre ID.
• Användare från externa autentiseringsservrar visas ofta under Authentication > Users först efter att de för första gången har loggat in på en brandväggstjänst som User Portal eller VPN Portal.
• Sophos rekommenderar att användare och grupper som inte längre behövs eller är inaktiva raderas regelbundet så att deras ID-nummer kan återanvändas.

Antalet synliga användare bevisar därför inte i sig att gränsen har nåtts. Även grupper använder ID-nummer, och numreringen kan innehålla luckor. Det avgörande är det ID som faktiskt har tilldelats den berörda användaren.

Kontrollera en användares User ID

Det konkreta ID-numret visas i WebAdmin:

1. Öppna Authentication > Users.
2. Välj Show additional properties.
3. Leta efter den berörda användaren i kolumnen User ID som nu visas.
4. Jämför användarens ID med en fungerande användare i samma grupp och Remote Access-policy.

Tolkningen är entydig:

• User ID till och med 65535: Den dokumenterade gränsen har inte överskridits för användaren. Fortsätt med normal felsökning av VPN, portal och autentisering.
• User ID över 65535: Användarobjektet ligger utanför det intervall som stöds. Planera en rensning och testa därefter användaren igen under kontrollerade former.
• Användaren saknas i listan: Den externa användaren har kanske aldrig loggat in på en brandväggstjänst. Kontrollera först den faktiska inloggningsvägen.

⚠️ Många användarobjekt är bara en indikation. Först kolumnen User ID visar om den konkreta användaren överskrider gränsen.

Kontrollera beroenden före radering

Att rensa användare och grupper är ett administrativt ingrepp. Ett objekt kan fortfarande behövas för Remote Access, regler eller autentisering även om det vid första anblicken verkar gammalt.

Kontrollera följande före radering:

• Remote Access: Är användaren eller gruppen tillåten i en SSL VPN- eller IPsec-policy?
• Brandväggsregler: Används objektet som användarkriterium?
• Portaler: Är User Portal eller VPN Portal kopplad till gruppen?
• MFA: Har användaren en OTP- eller tokentilldelning?
• Grupplogik: Är objektet en produktionsanvändares primärgrupp eller ytterligare gruppmedlemskap?
• Katalogkälla: Kommer objektet att skapas igen vid nästa inloggning eller gruppimport?

Före en större rensning bör en aktuell säkerhetskopia finnas. En dokumenterad lista över de objekt som ska tas bort är dessutom bättre än en massradering baserad på ålder eller namn.

Rensa användare och grupper kontrollerat

Rensa Active Directory-användare

Sophos beskriver ett tydligt arbetsflöde för AD-användare som inte längre behövs:

1. Ta först bort användaren som inte längre behövs i Active Directory.
2. Öppna Authentication > Users.
3. Kör Purge AD users för att lokalt ta bort poster för AD-användare som inte längre finns.
4. Kontrollera i ett HA-kluster att processen har slutförts som förväntat. Sophos utför raderingen på Primary och Auxiliary Device.

Purge AD users ersätter inte korrekt behörighetshantering i Active Directory. Om en användare finns kvar där kan posten skapas på nytt i brandväggen vid en senare inloggning.

Rensa lokala användare och importerade grupper

Lokala testkonton och grupper som inte längre behövs tas bort specifikt under Authentication > Users respektive Authentication > Groups. Arbeta i små och spårbara steg:

1. Identifiera objekt som inte längre behövs och dokumentera deras beroenden.
2. Radera först tydligt inaktuella testkonton och oanvända grupper.
3. Kontrollera användarlistan och produktionsinloggningar efter varje mindre rensningssteg.
4. Begränsa omfattande gruppimporter under Authentication > Servers till de VPN-, portal- och regelgrupper som faktiskt behövs.

Om den berörda produktionsanvändaren själv har ett ID över 65535 bör användarposten inte raderas blint. Först måste tillräckligt många oanvända ID-nummer frigöras och alla beroenden till grupper, policyer och MFA dokumenteras. Sophos beskriver återanvändning av frigjorda ID-nummer, men inte någon automatisk omnumrering av ett redan befintligt användarobjekt. Om det höga ID-numret består eller om det är oklart hur posten kan skapas på nytt på ett säkert sätt är ett ärende hos Sophos Support lämpligare än att upprepade gånger radera produktionsidentiteter.

Testa efter rensningen

Rensningen är inte klar förrän det ursprungliga felet bevisligen har försvunnit:

1. Logga in den berörda användaren på VPN Portal igen.
2. Kontrollera tilldelat User ID under Authentication > Users > Show additional properties.
3. Ladda ned .ovpn-konfigurationen igen.
4. Om nedladdningen fungerar importerar du profilen i Sophos Connect eller den klient som används och testar anslutningen.
5. Om nedladdningen fortfarande misslyckas kontrollerar du de vanliga orsakerna för portal och Remote Access.

För SSL VPN-konfigurationen och klientflödet kan du använda Konfigurera Sophos Connect på Sophos Firewall och Konfigurera Sophos SSL VPN med Sophos Connect på Windows.

Andra orsaker till misslyckade nedladdningar

Portalnedladdningar kan misslyckas även om användarens User ID ligger inom det intervall som stöds. Då är framför allt följande punkter relevanta:

• Användaren eller primärgruppen är inte tillåten i rätt SSL VPN-policy.
• VPN Portal kan inte nås från källzonen under Administration > Device access.
• MFA eller OTP misslyckas.
• Portalcertifikatet är inte betrott.
• Webbläsaren eller Endpoint-skyddet blockerar nedladdningen.
• För Entra ID SSO stämmer inte den importerade gruppen, Allowed users and groups, UPN eller Redirect-konfigurationen.

Vid Entra-inloggningsfel kan du använda Konfigurera Microsoft Entra ID SSO för Sophos Connect och VPN Portal. För att härda och styra portalernas åtkomst passar Device Access och Local Service ACL på Sophos Firewall.

Förebygg User-ID-problem i driften

I större miljöer bör användarhygien vara en del av brandväggsdriften:

• Importera endast kataloggrupper som faktiskt behövs för VPN, portaler, regler eller användarpolicyer.
• Ta regelbundet bort tidigare lokala användare och projektkonton.
• Kontrollera efter katalogomstruktureringar vilka gamla användar- och gruppobjekt som finns kvar i brandväggen.
• Kontrollera kolumnen User ID tidigt vid ovanliga portalfel i stället för att omedelbart konfigurera om VPN eller certifikat.
• Dokumentera produktionsgrupper, primärgrupper och MFA-beroenden så att en senare rensning kan utföras kontrollerat.

Brandväggen bör endast känna till de identiteter som den verkligen behöver för policyer, portaler, Remote Access och rapportering. Den ersätter inte en korrekt identitetslivscykel i katalogtjänsten.

FAQ