Konfigurera TACACS+ för administratörer på Sophos Firewall

Med TACACS+ kan inloggningen för namngivna administratörer på Sophos Firewall verifieras mot en central server. Det förenklar lösenordsregler och avveckling, men gör inte automatiskt brandväggen till en helt TACACS+-styrd nätverksenhet: själva tilldelningen av Device access profile förblir lokal i SFOS.

Det säkra arbetsflödet separerar därför tre nivåer: anslutning och autentiseringsuppgifter till TACACS+-servern, lyckad inloggning på avsedd SFOS-tjänst och den lokala administratörsrollen på brandväggen. Test connection bekräftar endast serveranslutning och användaruppgifter, inte efterföljande åtkomst till WebAdmin.

Viktigt: Före omställningen måste det lokala superadministratörskontot admin, en andra fungerande hanteringsväg och en öppen lokal administratörssession finnas tillgängliga. TACACS+ aktiveras inte som enda metod förrän pilotinloggning, negativt test och återställningsväg fungerar.

TACACS+ i tio steg

1. Testa lokal admin, MFA eller återställningsväg och hanteringsåtkomst med godkänt resultat.
2. Dokumentera TACACS+-server, brandväggens källadress, TCP-port och pilotkonto; lagra Shared Secret endast i det godkända hemlighetslagret, inte i driftsättningsärendet.
3. Tillåt TACACS+-vägen endast över ett betrott hanteringsnät eller en skyddad tunnel.
4. Skapa en TACACS+ server under Authentication > Servers > Add.
5. Kontrollera autentiseringsuppgifter och nåbarhet med Test connection och spara därefter.
6. Autentisera pilotanvändaren externt en gång via en redan godkänd brandväggstjänst så att användarobjektet skapas.
7. Gör under Authentication > Users pilotanvändaren kontrollerat till administratör och tilldela en minimal Device Access-profil.
8. Lägg till TACACS+ under Authentication > Services > Administrator authentication methods, ange ordningen och behåll Local som ett medvetet reservalternativ.
9. Testa WebAdmin positivt i ett privat webbläsarfönster och negativt med en obehörig användare.
10. Lägg först därefter till fler administratörer, kontrollera loggarna och testa ett avbrott i TACACS+-vägen kontrollerat.

Vad SFOS styr med TACACS+

Sophos Firewall använder den konfigurerade TACACS+-servern som autentiseringsmetod för valda tjänster. SFOS 22-hjälpen anger uttryckligen PAP och CHAP för TACACS+ i protokollmatrisen för VPN (IPsec/dial-in/L2TP/PPTP) authentication methods. Det innebär inte att WebAdmin har ett valbart PAP- eller CHAP-alternativ; för administratörer väljs server och ordning under Administrator authentication methods.

Den aktuella SFOS 22-hjälpen dokumenterar inte att ett TACACS+-attribut automatiskt överförs till en Sophos-administratörsprofil. En användare från en extern server visas som standardanvändare vid sin första inloggning och får administratörsbehörighet först efter lokal tilldelning. Microsoft Entra ID SSO är ett uttryckligen dokumenterat undantag med roll- eller gruppmappning.

Inte heller TACACS+-protokollets allmänna stöd för Authorization och Accounting innebär dokumenterad SFOS Command Authorization. För denna runbook gäller därför:

• TACACS+ verifierar den externa identiteten och lösenordet.
• SFOS fastställer användartyp och Device Access-profil lokalt.
• configuration-audit.log förblir beviset för konfigurationsändringar på brandväggen.
• Enbart en TACACS+-behörighet ger ingen användare åtkomst till WebAdmin.

För lokal rollplanering passar konfigurera Sophos Firewall-administratörer och profiler säkert.

Exempel och förutsättningar

Exempelkonfigurationen använder:

• Server name: TACACS-HQ
• Server IP: 10.20.30.15
• Port: 49
• Pilotanvändare: fw-noc-pilot
• Device Access-profil: NOC-ReadOnly
• Hanteringsnät: 10.20.40.0/24

10.20.30.15 och 10.20.40.0/24 är privata exempelvärden och ersätts med den riktiga serveradressen och det godkända hanteringsnätet. TCP 49 är den TACACS+-serverport som IANA har tilldelat, men porten som anges i SFOS måste fortfarande exakt motsvara motparten. Shared Secret dokumenteras inte i skärmbilder, ärenden eller detta exempel.

Före konfigurationen måste följande vara klarlagt:

• TACACS+-servern känner brandväggens faktiska källadress som klient eller Network Access Server.
• Routing och brandväggsväg mellan brandvägg och server fungerar i båda riktningarna.
• Pilotkontot är aktivt på TACACS+-servern och godkänt för den avsedda autentiseringstypen.
• En separat Device Access-profil med None, Read-only och endast nödvändigt Read-write är förberedd.
• WebAdmin är endast nåbart från det avsedda hanteringsnätet.
• Det lokala admin-kontot fungerar oberoende av TACACS+.
• Säkerhetskopia, underhållsfönster och återställningsväg är dokumenterade.

Skapa den minimala profilen under Profiles > Device access > Add. Ställ varje menyområde på None, Read-only eller Read-write; Expand ger finare behörigheter för undermenyer. NOC-ReadOnly är bara ett exempelnamn. Det är den sparade behörighetsmatrisen som gäller och som senare tilldelas användaren med User type Administrator.

Det aktuella SFOS-formuläret dokumenterar IP-adress, port och Shared Secret för TACACS+, men ingen TLS-inställning. RFC 8907 beskriver det klassiska TACACS+-paketskyddet som obfuskering utan modern integritet, sekretess eller skydd mot återuppspelning. Servervägen ska därför gå i ett separat betrott hanteringsnät eller en skyddad tunnel, aldrig oskyddat över internet. Om endast en osäker transportväg finns tillgänglig stoppas produktionssättningen.

Skapa TACACS+-servern på brandväggen

Menysökväg:

Authentication > Servers > Add

Arbetsgång:

1. Ställ in Server type på TACACS+ server.
2. Ange ett tydligt Server name, till exempel TACACS-HQ.
3. Ange rätt Server IP och den Port som är konfigurerad på servern.
4. Ange samma Shared secret som på TACACS+-motparten. Denna sträng är det gemensamma lösenordet mellan brandväggen som klient och servern, inte pilotanvändarens lösenord.
5. Använd det godkända pilotkontot för Test connection.
6. Spara endast när testet lyckas.

Anslutningstestet kontrollerar användarens autentiseringsuppgifter och anslutningen till servern. Det bevisar inte isolerat att Shared Secret är korrekt, att användaren redan har en administratörsprofil, att WebAdmin är nåbart från användarens nät eller att en verklig administratörsinloggning fungerar.

Om testet misslyckas kontrolleras först server-IP, route, port, Shared Secret, klientdefinition och serverlogg. Autentiseringsmetoder eller administratörsroller ändras inte på måfå.

XML-API-automatisering: tolka konfigurationssvar efter SFOS-version

Klargör dokumentationskonflikten före skrivåtgärder: XML-exemplen för SFOS 22 och 23 visar AuthenticationServer/TACACSServer/Port med 49 och AuthenticationServer/TACACSServer/ServerAddress. Parametertabellerna anger däremot AuthenticationPort med standardvärdet 1812 och ServerIP. Detta är en motsägelse mellan exempel och tabell, inte ett bevis för utbytbara taggalias eller ett faktiskt använt TACACS+-standardvärde.

Kontrollera API-referensen för den installerade builden och serverns sparade tillstånd före varje godkänd skrivåtgärd. Om schemat fortfarande är oklart ska det först klargöras med Sophos Support; härled inte en kopieringsfärdig XML-begäran från dessa uppgifter. TCP-porten måste fortfarande exakt motsvara TACACS+-motparten. Använd inte 1812 utan verifiering och ändra inte servern för att anpassa den till tabellen. Läs tillbaka och jämför det sparade objektet efter en ändring; pilotinloggningen och det lokala reservalternativet krävs fortfarande.

Parametertabellerna för SFOS 22 och 23 anger även följande obligatoriska fält och inmatningsgränser:

Dessa uppgifter beskriver endast dokumentationen, inte verifierat beteende vid körning. Kontrollera även gränserna mot referensen för den installerade builden före en godkänd ändring. Korta aldrig ned ett befintligt Shared Secret och ändra det inte enbart för att passa denna tabell. Stoppa ändringen vid en avvikelse och klargör med Sophos Support hur arbetet ska fortsätta.

Om TACACS+-servrar läggs till eller ändras via XML API måste svarshanteringen anpassas till SFOS-versionen. API-dokumentationen skiljer mellan följande status-/identifierarpar för Add TACACS+ server och Edit TACACS+ server:

• SFOS 22 – Add: 200/TacacsAddSuccess, 500/TacacsAddFail, 502/TacacsRecordExists, 503/TacacsAddFailDetail.
• SFOS 22 – Edit: 200/TacacsUpdateSuccess, 500/TacacsUpdateFail, 502/TacacsUpdateFailDetail.
• SFOS 23 – Add: 200/CPSuccessConfig, 400/CPInvalidRequestBody, 401/CPUnauthorized, 403/CPForbidden, 409/CPResourceConflict, 500/CPInternalServerError.
• SFOS 23 – Edit: 200/CPSuccessConfig, 400/CPInvalidRequestBody, 401/CPUnauthorized, 403/CPForbidden, 404/CPRecordNotFound, 500/CPInternalServerError.

Talen är dokumenterade statusvärden för konfigurationsåtgärden, inte uppgifter om HTTP-transportstatus. Namnen efter / är råa JavaScript-identifierare under Message, inte upplösta meddelandetexter. För SFOS 23 får automatiseringen inte återanvända de gamla 502/503-kopplingarna oförändrade. Det är inte heller verifierat att 409/CPResourceConflict enbart anger en duplicerad serverpost.

Innan man beslutar att upprepa en skrivåtgärd rekommenderas att läsa tillbaka det sparade serverobjektet och jämföra det med den avsedda konfigurationen. Statuslistan garanterar varken att upprepning är säker eller några särskilda regler för nya försök. Ett konfigurationsresultat ersätter varken Test connection eller en verklig WebAdmin-verifiering med en lokalt tilldelad minimal profil och ett tillgängligt nödkonto. Denna åtskillnad beskriver det dokumenterade API-kontraktet, inte ett utfört produkttest.

XML Delete: kontrollera mål och resultat separat. Den separata operationen Delete TACACS+ server identifierar enligt referensen för SFOS 22 och 23 den sparade servern via ServerName, inte via en antagen IP-selektor. Delete-tabellen anger endast detta fält: högst 50 tecken, inget komma, UTF-8 tillåtet. Att fältet där är markerat som valfritt innebär inte ett godkännande för en bred radering eller en radering utan ett entydigt mål. Före den godkända operationen läses den exakt namngivna servern tillbaka, jämförs med raderingsuppdraget och kontrolleras för att se om den fortfarande används av någon autentiseringsmetod eller annan funktion. Så länge beroenden finns kvar eller målet är oklart utförs ingen radering. Det fungerande lokala reservalternativet och den öppna lokala administratörssessionen behålls. Därefter läses samma mål tillbaka igen och det kontrolleras att exakt den godkända posten har tagits bort.

För Delete dokumenterar versionerna separata status-/identifierarpar:

• SFOS 22 – Delete: 200/TacacsDeleteSuccess, 500/TacacsDeleteFailed.
• SFOS 23 – Delete: 200/CPSuccessConfig, 500/CPInternalServerError.

Även här är talen dokumenterade statusvärden för konfigurationsåtgärden, inte HTTP-transportstatus. Namnen är oupplösta JavaScript-identifierare under Message, inte observerade meddelanden vid körning. De båda Delete-sidorna innehåller inget exempel på ett XML-envelope; därför konstrueras ingen Delete-begäran utifrån Add-/Edit-strukturen. Referensen för den installerade builden och kontrollen av det exakta målet före och efter operationen förblir avgörande. Denna tolkning av dokumentationen gör inte anspråk på att något raderingstest har utförts eller att det finns säkra regler för nya försök.

Gör den externa användaren säkert till administratör

Användare från externa servrar blir synliga under Authentication > Users efter att de har loggat in framgångsrikt på en brandväggstjänst för första gången. För piloten används en tjänst som redan är godkänd för ändamålet, till exempel User Portal eller VPN Portal. Om ingen sådan väg finns skapas inte en bred WAN-behörighet enbart för att lägga upp användaren.

Arbetsflödet förblir snävt:

1. Tillåt den valda portal- eller autentiseringstjänsten endast från hanteringsnätet.
2. Lägg till TACACS+ för just denna autentiseringsmetod utan att ta bort befintliga reservmetoder.
3. Logga in pilotanvändaren en gång med godkänt resultat.
4. Kontrollera under Authentication > Users att det externa användarobjektet har skapats.
5. Öppna användaren och ställ in User type på Administrator.
6. Tilldela den förberedda profilen, till exempel NOC-ReadOnly.
7. Återställ tillfälliga portal- eller metodbehörigheter som inte längre behövs till det dokumenterade tidigare tillståndet.

En extern användare får inte i förebyggande syfte den fullständiga profilen Administrator. Först testas en läsande eller snävt begränsad roll. Skrivbehörighet ges endast till konton vars arbetsuppgift faktiskt kräver den.

Ändra Administrator authentication methods

Menysökväg:

Authentication > Services > Administrator authentication methods

TACACS+ läggs till i listan över valda servrar. Högst 20 servrar kan väljas per autentiseringsmetod. Om flera servrar finns vidarebefordrar SFOS begäran i den ordning som visas. Antal och ordning är därför delar av säkerhetsdesignen.

För piloten:

1. Lägg till TACACS+ i den valda listan.
2. Flytta servern till den planerade positionen.
3. Behåll Local som ett medvetet reservalternativ för namngivna lokala administratörer.
4. Använd Apply.
5. Låt den befintliga admin-sessionen vara öppen.

Administrator authentication methods gäller uttryckligen inte för den lokala superadministratören admin. Det kontot förblir den oberoende nödvägen och skyddas separat med ett starkt lösenord, MFA och begränsad nätverksåtkomst.

Set authentication methods same as firewall kopplar administratörsinloggningen till metoderna för brandväggsautentisering. Alternativet används endast när denna koppling verkligen är avsedd och dokumenterad. För en tydlig administratörspilot är en uttrycklig lista enklare att testa och återställa.

Verifiera WebAdmin och rolleffekten

WebAdmin använder HTTPS-port 4444 som standard; en avvikande port visas under Administration > Admin and user settings. Före negativa tester kontrolleras även Block login där: efter tillräckligt många misslyckade försök blockerar SFOS käll-IP:n för alla tjänster, WebAdmin, CLI, VPN Portal och User Portal. Kontrollerna med en obehörig användare och med ett felaktigt lösenord är separata negativa tester. Före varje försök tas hänsyn till spärrtröskeln, observationsperioden och redan ackumulerade misslyckade försök; testerna utförs inte direkt efter varandra om det skulle kunna leda till att spärrtröskeln nås. En andra hanteringskälla eller konsolen förblir tillgänglig. En misslyckad CAPTCHA räknas enligt Sophos inte som ett misslyckat inloggningsförsök.

En godkänd verifiering testar inte bara lösenordsdialogen:

1. Den lokala admin-sessionen förblir öppen.
2. Piloten loggar in i ett privat webbläsarfönster via avsedd WebAdmin-FQDN.
3. Den tilldelade profilen kontrolleras: förväntade menyer visas och otillåtna områden saknas.
4. Med Read-only får en kontrollerad ändring inte kunna sparas.
5. För en avsedd skrivroll används en ofarlig teständring med dokumenterad återställning.
6. En giltig TACACS+-användare utan lokal administratörsroll får inte kunna öppna WebAdmin.
7. Ett felaktigt lösenord måste avvisas.
8. Lokal admin måste fortfarande kunna logga in i ett andra privat fönster.
9. TACACS+-serverloggen, Log Viewer och configuration-audit.log korreleras tidsmässigt.

WebAdmin-nåbarhet styrs separat under Administration > Device access eller med en snäv Local Service ACL Exception. TACACS+ och MFA motiverar inte en bred WAN-behörighet. Den säkra nätverksvägen beskrivs i Device Access och Local Service ACL.

Kontrollera loggar och HA

I Log viewer filtreras på pilotanvändare, käll-IP och testtidpunkt. För djupare analys är följande relevant:

• access_server.log för autentisering, auktorisering och Accounting på SFOS
• configuration-audit.log för ändringar, administratör och tidpunkt
• syslog.log för systemhändelser på kernelnivå; kontrollera systemhändelser och administratörsutlösta händelser i Log viewer
• TACACS+-serverloggen för klientadress, användare, metod och resultat

I ett HA-kluster förutsätts inte att en befintlig WebAdmin-session överlever en failover utan avbrott. Efter ett planerat rollbyte utförs en ny inloggning och på TACACS+-servern kontrolleras vilken källadress brandväggen faktiskt använder. Om servern tillåter klienter baserat på källadressen måste alla adresser som förekommer i den verkliga HA-vägen vara medvetet godkända.

Loggar finns på den node som bearbetade händelsen. I ett HA-fall med oklar tidpunkt kontrolleras därför båda nodes eller en konsoliderad utvärdering.

Avgränsa fel efter symptom

Test connection misslyckas

Kontrollera server-IP, route, TCP-port, Shared Secret, klientdefinition och serverstatus. En paketinsamling kan visa om brandväggen når servern och vilken Source-IP anslutningen använder. Utan svar eller med en oväntad Source-IP fortsätter arbetet inte med användarroller.

Test connection lyckas, men WebAdmin avvisar användaren

Det stämmer med att en lokal administratörsprofil saknas. Kontrollera under Authentication > Users att användaren finns, att User type: Administrator är inställt och att rätt Device Access-profil är tilldelad. Kontrollera därefter ordningen under Administrator authentication methods och WebAdmin-ACL:n.

Servern godkänner lösenordet, men fel profil används

TACACS+ tilldelar inte automatiskt den lokala Sophos-profilen i detta SFOS-arbetsflöde. Kontrollera användarobjektet och profilen på brandväggen. Hitta inte på serverattribut och tilldela inte en fullständig administratörsprofil som ett snabbt test.

Inloggningen fungerar bara fram till HA-failover

Kontrollera den faktiska Source-IP:n för den nya inloggningen på TACACS+-servern. Kontrollera därefter route, port, klientdefinition och Shared Secret för den aktiva vägen. En gammal webbläsarsession är inget bevis på framgång; en ny session används.

Alla externa administratörsinloggningar misslyckas

Logga in med lokal admin, kontrollera serverstatus och metodordning och ta vid behov bort TACACS+ från administratörslistan kontrollerat. Utöka inte Device Access-behörigheten till Any och starta inte om autentiseringstjänsten som första åtgärd.

För metodövergripande diagnos passar felsök Sophos Firewall-autentisering systematiskt.

Avveckling och återställning

Vid avveckling spärras användaren först på TACACS+-servern. Därefter kontrolleras på brandväggen om en befintlig session fortfarande är aktiv och om det lokala externa användarobjektet fortfarande har en administratörsprofil. En spärr på servern behandlas inte som en garanti för att varje befintlig WebAdmin-session avslutas omedelbart.

Efter det negativa testet tas den lokala administratörsprofilen bort eller så inaktiveras användaren. Gransknings- och serverloggar dokumenteras med ärende och tidpunkt. Superadministratörskontot admin ingår inte i detta normala avvecklingsflöde.

Återställning efter en misslyckad pilot:

1. Logga in med den öppna lokala administratörssessionen.
2. Ta bort TACACS+ från Administrator authentication methods eller återställ den dokumenterade tidigare positionen.
3. Återställ tillfälliga portal- och Device Access-behörigheter till tidigare tillstånd.
4. Ta bort den lokala administratörsrollen från pilotanvändaren eller inaktivera användaren.
5. Testa en ny lokal administratörsinloggning och den normala autentiseringsvägen.
6. Ta först därefter bort TACACS+-serverposten, förutsatt att ingen annan funktion använder den.

Checklista

• lokal admin, MFA och återställningsväg testade
• brandväggens faktiska källadress känd på TACACS+-servern
• TCP-port och Shared Secret överensstämmer
• servervägen ligger i ett betrott eller skyddat nät
• Test connection godkänt utan att feltolkas som WebAdmin-bevis
• pilotanvändaren synlig som externt användarobjekt
• User type: Administrator och minimal profil lokalt tilldelade
• Local behållet som medvetet reservalternativ
• positiva och negativa WebAdmin-tester godkända
• WebAdmin endast nåbart från avsett hanteringsnät
• access_server.log, serverlogg och Audit Trail korrelerade
• HA eller failover testad med en ny inloggning
• avveckling och återställning dokumenterade

Vanliga frågor