Anslut en generisk LDAP-server till Sophos Firewall

Sophos Firewall kan autentisera användare via servertypen LDAP server utifrån katalogattribut och gruppmedlemskap. I praktiken krävs fyra steg: förbered en lokal grupp, anslut LDAP-servern, välj den under Authentication > Services för önskad tjänst och kontrollera inloggning och behörighet med riktiga testkonton.

OpenLDAP, 389 Directory Server eller FreeIPA är typiska kandidater för en generisk LDAP-anslutning, men är inte utbytbara produkter. Attribut, returnerade gruppvärden och kontons utgångsdatum varierar beroende på schemat. Denna guide ger därför ett generaliserbart exempel; värdena måste kontrolleras på det verkliga användarobjektet. Google Secure LDAP beskrivs nedan som en egen variant, dokumenterad av Sophos.

För Windows Active Directory med LDAPS, gruppimport eller AD SSO passar Anslut Active Directory till Sophos Firewall bättre. RADIUS via Microsoft NPS eller en MFA-gateway behandlas i Konfigurera en RADIUS-server på Sophos Firewall. Om du behöver byta ut den inbyggda eDirectory-servertypen före SFOS 23, kan du hitta hela migreringsprocessen på Migrera eDirectory före SFOS 23.

Förbered värden och återställningsväg

Du behöver:

WebAdmin-åtkomst till Sophos Firewall;
LDAP-servern måste kunna nås från brandväggen via den port som är konfigurerad på servern;
ett bindningskonto med läsrättigheter till det nödvändiga katalogområdet;
Bind DN och Base DN, till exempel cn=svc-sophos,ou=service,dc=example,dc=net och ou=people,dc=example,dc=net;
attributen för inloggning, visningsnamn, e-postadress, grupp och, om tillämpligt, kontots utgångsdatum;
vid certifikatvalidering, ett servernamn som kan slås upp och en lämplig CA-förtroendekedja.

De vanliga startvärdena är port 389 för STARTTLS och 636 för SSL/TLS. De är inte en fast SFOS-standard: en katalog kan använda en annan port, som måste matcha Connection security och serverkonfigurationen.

⚠️ Bindningskontot kräver inga administrativa skrivbehörigheter. Begränsa dess läsrättigheter till underträdet och de attribut som brandväggen behöver för användarförfrågningar.

Innan du gör ändringar under Authentication > Services, dokumentera de valda servrarna, deras ordningsföljd och arvsalternativ för varje påverkad metod. Under Firewall authentication methods, anteckna även den tidigare Default group. Detta gör att du kan ångra ändringen utan att förhastat ta bort nya objekt. Ha under ändringarna en lokal administratörsinloggning tillgänglig för återställning som du har testat i förväg.

Skilj mellan Bind DN, Base DN och attribut

Ett DN går från det specifika objektet till katalogroten. cn=svc-sophos,ou=service,dc=example,dc=net anger bindningskontot i exemplet. Base DN anger däremot startpunkten för användarsökningen, såsom ou=people,dc=example,dc=net.

En bas-DN som är för smal hittar inte alla användare du behöver. En onödigt bred sökbas kan bromsa sökningar och inkludera oönskade objekt. Append base DN lägger till bas-DN till en ofullständig bindnings-DN vid bindningen; om DN redan är fullständigt lämnas alternativet vanligtvis avstängt. Beteendet hos den LDAP-server som används är avgörande.

Attributen kommer också från katalogschemat. uid, cn, mail och memberOf är exempel, inte universella standardvärden. Sophos rekommenderar memberOf som Group name attribute, men använder GID i sitt eget allmänna konfigurationsexempel. Därför måste returvärde, lokal gruppmappning och medlemskap i flera grupper kontrolleras med riktiga testanvändare.

Välj kryptering och certifikat

Plaintext skickar användarnas inloggningsuppgifter okrypterat och är inte en bra produktionskonfiguration. SSL/TLS krypterar anslutningen från början; STARTTLS uppgraderar en initialt okrypterad LDAP-anslutning till TLS.

För Validate server certificate måste du under Server IP/domain ange namnet i servercertifikatet, och brandväggen måste kunna slå upp det. Sophos hänvisar till det som CNAME i SFOS-22-hjälpen, medan samma fältbeskrivning på andra ställen bara nämner en server-IP. Certifikatnamnet är därför det säkra valet för en kontrollerad TLS-utbyggnad. Om brandväggen inte kan slå upp namnet kan en post skapas under Network > DNS > DNS host entry. TTL, omvänd DNS-uppslagning och test av DNS-resolvern förklaras i Konfigurera DNS-värdposter på Sophos Firewall.

Validate server certificate kontrollerar certifikatet för den fjärranslutna LDAP-servern. Det valfria fältet Client certificate anger ett certifikat som brandväggen använder för att upprätta en säker anslutning till LDAP-tjänsten; Google Secure LDAP kräver uttryckligen certifikatet som genereras av Google. Vid TLS-fel ska du först åtgärda problem med namn, DNS, tid, giltighet och förtroendekedja i stället för att stänga av servercertifikatkontrollen som första steg.

Konfigurera LDAP-grupp och server

Förbered lokal grupp

Öppna Authentication > Groups och välj Add.
Ange ett unikt Group name, till exempel LDAP-Benutzer.
Välj Group type för den avsedda inloggningsmetoden. Normal kräver användarinloggning; Clientless styr åtkomst baserat på en IP-adress.
Ställ in nödvändiga policyer för användare, fjärråtkomst och inloggning och spara med Save.

Välj medvetet de gränser som behövs för Surfing quota och Access time. Sophos använder Unlimited internet access och Allowed all the time i sitt utbildningsexempel; detta är exempelpolicyer, inte ett krav för LDAP. För en begränsad åtkomst under pilotfasen passar den användningstid som faktiskt behövs och det tillåtna tidsfönstret bättre. Låt övriga fält stå kvar på standardvärdet endast om det passar den egna åtkomstpolicyn.

Gruppen kommer senare att användas som Default group. Den tillåter eller blockerar inte trafik på egen hand; detta avgörs av gruppens policyer och reglerna för respektive tjänst. För användarpolicyer och VPN för fjärråtkomst, med undantag för SSL VPN, har användarspecifika inställningar företräde framför grupppolicyer. Denna företrädesregel gäller inte för SSL VPN för fjärråtkomst: en användare kan komma åt resurserna i alla full- och split-tunnel-policyer som gäller för användaren eller dennes grupper. En mer restriktiv användarpolicy upphäver därför inte automatiskt bredare SSL-VPN-behörigheter som tilldelats via grupper. Detta innebär inte någon allmän garanti för att alla LDAP-scheman hanterar medlemskap i flera grupper på samma sätt; gruppmappningen och de resurser som faktiskt kan nås måste kontrolleras under pilotfasen. Den kompletta grupplogiken med pilotfas, användarspecifika undantag och huvudgrupp beskrivs i Hantera användargrupper säkert på Sophos Firewall.

Skapa anslutningen och konfigurera bindningen

Öppna Authentication > Servers och välj Add.
För Server type, välj LDAP server.
Ange ett unikt Server name, till exempel LDAP-Firma.
Ange serverns IP-adress eller domännamn under Server IP/domain. För Validate server certificate, använd namnet från servercertifikatet som brandväggen kan slå upp via DNS.
Välj Version 2 eller 3 som stöds av servern. Google Secure LDAP kräver version 3.
Ställ in Connection security och Port tillsammans. Använd SSL/TLS eller STARTTLS i produktionsdrift.
Stäng av Anonymous login och ange Bind DN och Password för kontot med läsrättigheter.
Slå endast på Append base DN om brandväggen ska lägga till bas-DN till en ofullständig bindnings-DN vid bindningen.
Vid en säker anslutning ska du göra ett medvetet val om huruvida Validate server certificate ska aktiveras. För vanliga LDAP-servrar är kontrollen det säkra valet i produktionsdrift när certifikatnamnet, DNS-uppslagningen och förtroendekedjan har kontrollerats och fungerar. Google Secure LDAP följer specialfallet som beskrivs nedan. Välj ett eventuellt nödvändigt Client certificate i listan.

Ställ in sökbas och attribut

Ange startpunkten för användarsökningen under Base DN. Get base DN kan hämta sökbasen som servern erbjuder.
Ställ in attributet med inloggningsnamnet som Authentication attribute, ofta uid eller mail.
Ange Display name attribute och Email address attribute så att de motsvarar användarobjektet, till exempel cn och mail.
Ange gruppattributet som returneras från användarobjektet under Group name attribute. memberOf är Sophos rekommendation, men måste matcha schemat och returformatet.
Ange Expiry date attribute som matchar schemat. Om inget sådant attribut finns, kontrollera före driftsättningen om formuläret accepterar ett tomt värde och hur konton utan utgångsdatum hanteras.
Kör Test connection och spara med Save.

Display name attribute och Email address attribute är valfria fält för den generiska LDAP-servern. Visningsnamnet gör det lokala användarobjektet lättare att känna igen; e-postattributet anger den tillhörande adressen. För att skapa Google LDAP-grupper krävs däremot e-postattributet. Ett Expiry date attribute anger kontots utgångsdatum, inte längden på en VPN-session. Sophos anger Date i det allmänna utbildningsexemplet och expiry för Google; det lämpliga attributnamnet beror på respektive schema.

Enligt Sophos kontrollerar Test connection anslutningen och bindningsuppgifterna. Testet bevisar varken att bas-DN omfattar alla användare eller att gruppmappningen eller tjänstebehörigheten fungerar korrekt. En riktig inloggning krävs för detta.

Endast för API-automatisering vid övergången från SFOS 22 till SFOS 23: I LDAP-API-referensen ändras de dokumenterade raderna under Status Message Information: för Add LDAP server från 200/500/502/503 till 200/400/401/403/409/500, för Edit LDAP server från 200/500/503 till 200/400/401/403/404/500. 409 finns bara för Add, 404 bara för Edit. Även presentationssymbolerna ändras från Message.LDAP* till Message.CP*. Dessa dokumentationsrader och symboler garanterar inte de koder eller meddelanden som faktiskt överförs och fastställer ingen bestämd mappning från 502/503 till 409/404. För API-automatisering ska referensen för den använda versionen granskas och de faktiska svaren från målbrandväggen valideras innan en mappning används. Detta är en separat API-kontroll; GUI-kontrollen med Test connection och en riktig inloggning krävs fortfarande.

Före varje automatiserad LDAP-åtgärd för att lägga till eller redigera en server: API-referenserna för SFOS 22 och 23 är motsägelsefulla när det gäller IntegrationType: Exemplet anger LooseIntegration/TightIntegration och markerar DisplayNameAttribute, EmailAddressAttribute, GroupNameAttribute och ExpiryDateAttribute med kommentaren Only For Tight Integration; parametertabellen beskriver båda lägena men tillåter endast 1. Dra inte några slutsatser av detta om stöd för något av lägena, betydelsen av 1 eller huruvida villkorade attribut får utelämnas. Exemplet är inte en payload som är färdig att skickas; inte heller dess textvärden för på/av-inställningar och anslutningssäkerhet stämmer överens med kodningarna i tabellerna. Före en ändring ska du granska schemat respektive API-referensen för målversionen och kontrollera den faktiska målkonfigurationen samt ett tillhörande API-svar utan att göra några ändringar. Om mappningen fortfarande är oklar ska du inte köra någon automatisering som bygger på den, utan använda det verifierade förfarandet i GUI eller klargöra API-kraven med Sophos Support. GUI-stegen som beskrivs ovan är fortsatt separata från detta; Test connection samt verkliga tester av identitet, grupper, i förekommande fall kontots utgångsdatum och varje tjänst som används krävs fortfarande.

Aktivera LDAP för de tjänster som krävs

Öppna Authentication > Services.
Under Firewall authentication methods, flytta LDAP-servern till Selected authentication servers. Om den ska användas först placerar du den överst.
Som Default group, välj den förberedda gruppen LDAP-Benutzer och klicka på Apply.
Välj servern separat för alla metoder som faktiskt används: User portal authentication methods, VPN portal authentication methods, VPN (IPsec/dial-in/L2TP/PPTP) authentication methods, Administrator authentication methods och SSL VPN authentication methods.
Använd arvsalternativ som Set authentication methods same as firewall, Same as firewall eller Same as VPN endast om den resulterande serverlistan är den avsedda.

Maximalt 20 servrar kan väljas per autentiseringsmetod. Om det finns flera servrar kommer brandväggen att fråga dem i den ordning som visas. Administratörsmetoden gäller inte superadministratören. För L2TP och PPTP dokumenterar Sophos endast PAP för LDAP; denna kombination bör inte införas utan föregående kontroll på grund av protokollet och de numera föråldrade VPN-metoderna.

Dessutom för administratörsinloggningar: En användare som autentiseras externt via LDAP skapas först som standardanvändare vid den första inloggningen, även om användaren har en administratörsroll i katalogen. Logga först in med det avsedda kontot på en tjänst där åtkomst har tillåtits, exempelvis användarportalen eller VPN-portalen. Använd därefter den befintliga lokala administratörsinloggningen för att redigera den skapade användaren under Authentication > Users, ändra User type till Administrator, välja ett Profile som är begränsat till de rättigheter som behövs och spara med Save. Det räcker inte att bara välja servern under Administrator authentication methods. Kontrollera sedan WebAdmin-inloggningen samt tillåtna och otillåtna administrationsåtgärder med detta konto; behåll den testade lokala inloggningen för återställning.

Konfigurera Google Secure LDAP

Före brandväggskonfigurationen skapas en LDAP-klient i Googles administratörskonsol under Apps > LDAP. Dess Access permissions begränsas, certifikatet inklusive privat nyckel laddas ner och separata inloggningsuppgifter skapas. Lösenordet är inte längre synligt efter att dialogrutan stängts. Om användarnamnet eller lösenordet är felaktigt eller inte längre tillgängligt, generera nya inloggningsuppgifter i Googles administratörskonsol och uppdatera sedan Bind DN och Password i brandväggens LDAP-serverkonfiguration.

Google kan ändra gränssnittet och stegen i administratörskonsolen. Kontrollera därför före konfigurationen den aktuella Google-dokumentationen om att skapa LDAP-klienter, ladda ned certifikatet och generera inloggningsuppgifter. Om tjänsten är tillgänglig för den egna Google-utgåvan förklaras i Google Secure LDAP; åtkomstbehörigheterna måste motsvara det avsedda användar- och gruppområdet.

Förfarandet som Sophos dokumenterar i Google Admin Console kan följas så här:

Börja under Apps > LDAP med ADD CLIENT, ange ett LDAP-klientnamn och en Description och välj CONTINUE. Ett unikt namn som Sophos-Firewall-Pilot underlättar senare identifiering.
Begränsa Access permissions till det användar- och gruppområde som behövs och bekräfta med ADD LDAP CLIENT.
Välj Download certificate. ZIP-filen innehåller certifikatfilen .cer och den privata nyckeln .key. Packa upp båda filerna i en skyddad arbetsmapp och anteckna lagringsplatsen för den efterföljande importen. Den privata nyckeln hör inte hemma i supportärenden eller oskyddade delade mappar.
Fortsätt med CONTINUE TO CLIENT DETAILS, öppna kortet Authentication och välj GENERATE NEW CREDENTIALS. Spara Username och Password på ett säkert sätt innan du väljer CLOSE; dessa värden används senare som Bind DN och Password, inte inloggningsuppgifterna för en Google-administratör.

Google-inloggningsuppgifterna ersätter inte klientcertifikatet. Sophos Firewall behöver för denna variant både certifikatet med privat nyckel och de genererade bindningsuppgifterna.

Slå sedan på klienten under Service status med ON for everyone och spara med SAVE. Denna tjänststatus aktiverar klienten men ersätter inte de tidigare angivna behörigheterna under Access permissions.

Kontrollera under Administration > Time att brandväggen får rätt tid via NTP innan du importerar certifikatet. Enligt Sophos kan en felaktigt manuellt inställd klocka göra att importen av certifikat misslyckas. Under Certificates > Certificates > Add, välj sedan formatet CER (.cer) och importera både Certificate och Private key från Google-nedladdningen. Certifikatet kan visas som ej betrott eftersom Google signerar det själv. Sophos bekräftar att Google LDAP fortfarande fungerar. Den här indikeringen gäller klientcertifikatet och inte LDAP-servercertifikatkontrollen.

Ange ett unikt certifikatnamn vid importen. Använd Choose File för att välja den uppackade .cer för Certificate och den tillhörande .key för Private key, bekräfta respektive val med Open och välj slutligen Save. Först efter att certifikatet har sparats går det att välja det under Client certificate i LDAP-servern.

Följande värden gäller för LDAP-servern:

Server IP/domain: ldap.google.com
Version: 3
Connection security: SSL/TLS
Port: 636
Anonymous login: av
Bind DN och Password: de genererade Google-LDAP-inloggningsuppgifterna
Append base DN: av
Client certificate: det importerade Google-certifikatet
Base DN: ange eller hämta med Get base DN
Authentication attribute: UID
Display name attribute: CN
Email address attribute: mail
Group name attribute: memberOf
Expiry date attribute: expiry

mail krävs för att skapa Google LDAP-grupper. Sophos anvisningar för Google Secure LDAP anger inte uttryckligen någon inställning för Validate server certificate i sin värdelista. Av detta går det inte att dra slutsatsen att alternativet måste vara vare sig på eller av; inställningen avgörs enligt det allmänna TLS-förfarandet och den egna förtroendekedjan. Att ett Google-klientcertifikat visas som ej betrott är inget skäl att stänga av kontrollen av fjärrserverns certifikat.

Kontrollera Google-anslutningen med Test connection och spara servern med Save. Förbered därefter en lokal LDAP-grupp enligt beskrivningen ovan och välj Google-servern under Authentication > Services för de tjänster som behövs. Även för Google gäller att enbart skapandet av serverobjektet inte gör någon tjänst användbar; testinloggningen under pilotfasen kontrollerar därefter identitet, grupp och behörighet.

Kontrollera inloggning och grupptilldelning

En godkännandekontroll omfattar anslutning, identitet och behörighet:

Test connection måste bekräfta anslutningen och bindningsuppgifterna.
Under Authentication > Services kontrollera serverlista, ordning och arv för varje metod som används. Default group tillhör Firewall authentication methods.
Logga in på den avsedda tjänsten med en testanvändare under pilotfasen. Vid den första inloggningen skapar brandväggen den externt autentiserade användaren lokalt.
Under Authentication > Users, kontrollera att användaren och gruppen visas som förväntat.
Utför ett positivt test för varje relevant kataloggrupp. Kontrollera dessutom med en användare utan en lämplig lokal grupptilldelning om den förväntade Default group gäller.
Kontrollera inte bara inloggningen utan även den avsedda policyn eller testregeln. För SSL VPN ska du testa tillåtna och blockerade resurser med hänsyn till de användar- och grupppolicyer som gäller; dra inte slutsatser om de faktiska behörigheterna enbart utifrån en restriktiv användarpolicy. Använd sedan ett felaktigt lösenord som ett negativt test.
Kontrollera access_server.log för användarinloggning, auktorisering och redovisning; vid VPN-portalproblem även vpnportal.log.
Om ett attribut för kontots utgångsdatum används, inkludera ett testkonto där det är känt om kontot har gått ut.

Om schemavärdena är otydliga kan en administratör läsa användarobjektet utan att ändra det från ett Linux-system för administration eller direkt från LDAP-servern:

ldapsearch -LLL -x -H ldaps://ldap.example.net:636 \
  -D 'cn=svc-sophos,ou=service,dc=example,dc=net' -W \
  -b 'ou=people,dc=example,dc=net' \
  '(uid=max.muster)' '*' '+'

Denna valfria diagnosmetod är inte ett SFOS-kommando och hör inte hemma i Advanced Shell. Exemplet förutsätter LDAPS och förtroende för serverns CA på det system där kommandot körs; STARTTLS kräver ett motsvarande anpassat kommando. -W frågar efter bindningslösenordet interaktivt. Anpassa filtret (uid=max.muster) till det konfigurerade attributet under Authentication attribute. '*' och '+' kan skriva ut många vanliga och operativa attribut med personuppgifter. Innan utdata bifogas till ett supportärende eller delas vidare måste de anonymiseras.

Avgränsa fel efter symtom

Ingen anslutning: Kontrollera routing, DNS, port och Connection security. Kontrollera sedan Bind DN, lösenord och Anonymous login.
TLS- eller certifikatfel: Kontrollera namnet från servercertifikatet, DNS-uppslagning, brandväggens klocka, giltighet och CA-kedja. Inaktivera inte certifikatkontrollen som första steg.
Test connection fungerar, men användaren hittas inte: Jämför Base DN, Authentication attribute och det angivna inloggningsnamnet.
Inloggning fungerar, gruppen är fel: Kontrollera Group name attribute och dess verkliga returvärde, lokal gruppmappning och Default group. memberOf är en rekommendation, men inte en garanterad mappning för varje schema.
Servern är skapad men används inte: Kontrollera serverval, ordning och arv för den berörda tjänsten under Authentication > Services.
Google Secure LDAP-bindningen misslyckas: Kontrollera individuellt version 3, port 636, att Anonymous login och Append base DN är avstängda, klientens tjänststatus, inloggningsuppgifterna och Googles klientcertifikat.
Sökningen är långsam eller returnerar oönskade konton: Begränsa bas-DN till det nödvändiga underträdet.
Inloggning fungerar, den förväntade policyn gör det inte: Kontrollera användarspecifika inställningar, grupppolicy, gruppmappning och berörd brandväggs- eller VPN-regel separat. För SSL VPN ska du ta hänsyn till alla användar- och grupppolicyer som gäller samt de resurser som faktiskt är tillåtna; enbart en restriktiv användarpolicy räcker inte. Den fullständiga diagnostikmodellen beskrivs i Felsök autentiseringsfel systematiskt.
Portalinloggning fungerar, WebAdmin-inloggning gör det inte: Under Authentication > Users, kontrollera den manuellt tilldelade administratörsrollen och Profile. Kontrollera därefter servervalet under Administrator authentication methods och de gällande reglerna för åtkomst till enheten. Behåll den lokala inloggningen för återställning tills den nya inloggningsvägen har testats.

Återställ säkert

Om driftsättningen misslyckas återställer du först det tidigare dokumenterade servervalet, ordningen och arvsinställningarna för varje påverkad metod. Under Firewall authentication methods återställs även den tidigare Default group. Utför ett positivt och ett negativt test med den tidigare autentiseringsmetoden och kontrollera de relevanta loggarna.

Ta bara bort den nya LDAP-servern och gruppen när de inte längre används i någon tjänst eller policy. Rensa inte automatiskt skapade LDAP-användare med Purge AD users: SFOS-22-hjälpen dokumenterar denna funktion endast för Active Directory. Om sådana användare behöver tas bort, bekräfta i förväg med Sophos Support vilken metod som stöds för din konfiguration.