Anslut 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=netochou=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.
⚠️ Bind-kontot 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. Anteckna även den tidigare Default group under Firewall authentication methods. Detta gör att du kan ångra ändringen utan att förhastat ta bort nya objekt.
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, anger 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ändaruppgifter 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 lösa det kan en post skapas under Network > DNS > DNS host entry. TTL, omvänd sökning och resolvertest förklaras Konfigurera DNS-värdposter på Sophos Firewall.
Validate server certificate kontrollerar certifikatet för fjärr-LDAP-servern. Den valfria 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. För TLS-fel, fixa namn, DNS, tid, giltighet och förtroendekedja först istället för att stänga av servercertifikatkontrollen som första steg.
Konfigurera LDAP-grupp och server
Förbered lokal grupp
- Öppna
Authentication > Groupsoch väljAdd. - Ange en unik
Group name, till exempelLDAP-Benutzer. - Välj
Group typeför den avsedda inloggningsmetoden.Normalkräver användarinloggning;Clientlessstyr å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.
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. Användarspecifika policyer har företräde framför grupppolicyer. Den kompletta grupplogiken med pilot, användaröverstyrningar och huvudgrupp finns tillgänglig på Hantera användargrupper säkert på Sophos Firewall.
Skapa anslutningen och konfigurera bindningen
- Öppna
Authentication > Serversoch väljAdd. - Välj
LDAP serversomServer type. - Tilldela en unik
Server name, till exempelLDAP-Firma. - Ange serverns IP eller domännamn under
Server IP/domain. FörValidate server certificate, använd det lösbara namnet från servercertifikatet. - Välj
Version2eller3som stöds av servern. Google Secure LDAP kräver version3. - Ställ in
Connection securityochPorttillsammans. För produktiv drift användSSL/TLSellerSTARTTLS. - Stäng av
Anonymous loginoch angeBind DNochPasswordför läskontot. - Slå endast på
Append base DNom servern ska lägga till bas-DN under bindning. - Om anslutningen är säker, avgör medvetet om
Validate server certificateär aktiverad. För normala LDAP-servrar är kontroll efter framgångsrik beredning av namn, DNS och förtroende det säkra produktionsvalet. Google Secure LDAP följer specialfallet som beskrivs nedan. Välj detClient certificatesom behövs i listan.
Ställ in sökbas och attribut
- Ange startpunkten för användarsökningen under
Base DN.Get base DNkan få sökbasen som servern erbjuder. - Ställ in attributet med inloggningsnamnet som
Authentication attribute, oftauidellermail. - Ange
Display name attributeochEmail address attributeför att matcha användarobjektet, till exempelcnochmail. - Ange gruppattributet som returneras på användarobjektet under
Group name attribute.memberOfär Sophos rekommendation, men måste matcha schemat och returformatet. - Ange
Expiry date attributesom matchar schemat. Om inget sådant attribut finns, kontrollera före lansering om formuläret accepterar ett tomt värde och hur konton utan utgångsdatum hanteras. - Kör
Test connectionoch spara medSave.
Enligt Sophos kontrollerar Test connection anslutningen och bindningsuppgifterna. Testet bevisar varken att bas-DN inkluderar alla användare eller att en grupp eller tjänstebehörighet gäller korrekt. En riktig inloggning krävs för detta.
Aktivera LDAP för de tjänster som krävs
- Öppna
Authentication > Services. - Under
Firewall authentication methods, flytta LDAP-servern tillSelected authentication servers. Om den ska användas först placerar du den överst. - Välj den förberedda gruppen
LDAP-BenutzersomDefault groupoch 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 methodsochSSL VPN authentication methods. - Använd arvsalternativ som
Set authentication methods same as firewall,Same as firewallellerSame as VPNendast om den härledda serverlistan är avsedd.
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 återinföras utan kontroll på grund av protokollet och de numera föråldrade VPN-metoderna.
Konfigurera Google Secure LDAP
Före brandväggskonfigurationen skapas en LDAP-klient i Googles administratörskonsol under Apps > LDAP. Dess Access permissions är begränsade, certifikatet inklusive privat nyckel laddas ner och separata inloggningsuppgifter skapas. Lösenordet är inte längre synligt efter att dialogrutan stängts.
Slå sedan på klienten under Service status med ON for everyone och spara med SAVE. Denna tjänststatus aktiverar klienten men ersätter inte den tidigare inställda Access permissions.
Innan du importerar certifikatet under Administration > Time, kontrollera om brandväggen får rätt tid via NTP. Enligt Sophos kan en felaktigt manuellt inställd klocka göra att importen av certifikat misslyckas. Välj sedan formatet CER (.cer) under Certificates > Certificates > Add 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.
Följande värden gäller för LDAP-servern:
Server IP/domain:ldap.google.comVersion:3Connection security:SSL/TLSPort:636Anonymous login: avBind DNochPassword: de genererade Google LDAP-uppgifternaAppend base DN: avClient certificate: det importerade Google-certifikatetBase DN: ange eller hämta medGet base DNAuthentication attribute:UIDDisplay name attribute:CNEmail address attribute:mailGroup name attribute:memberOfExpiry date attribute:expiry
mail krävs för att skapa Google LDAP-grupper. De officiella Google-instruktionerna anger inte uttryckligen Validate server certificate i sin värdelista. Utan ett SFOS-22-laboratorietest bör man inte dra slutsatsen att alternativet alltid ska vara på eller alltid av; alternativet avgörs enligt det allmänna TLS-förfarandet och din egen förtroendekedja.
Kontrollera inloggning och grupptilldelning
Ett godkännande inkluderar anslutning, identitet och behörighet:
Test connectionmåste bekräfta anslutningen och bindningsuppgifterna.- Under
Authentication > Serviceskontrollera serverlista, ordning och arv för varje metod som används.Default grouptillhörFirewall authentication methods. - Logga in på den avsedda tjänsten med en pilotanvändare. När du loggar in för första gången 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 groupgäller. - Kontrollera inte bara inloggningen utan även den avsedda policyn eller testregeln. Använd sedan ett felaktigt lösenord som ett negativt test.
- Kontrollera
access_server.logför användarinloggning, auktorisering och redovisning; vid VPN-portalproblem ävenvpnportal.log. - Om ett utgångsattribut används, inkludera ett testkonto med känd utgångsstatus.
Om schemavärdena är otydliga kan en administratör göra en skrivskyddad sökning efter användarobjektet från ett Linux-administrationssystem 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 exekverande systemet; STARTTLS kräver ett motsvarande anpassat kommando. -W frågar efter bindningslösenordet interaktivt. Anpassa filtret (uid=max.muster) till den konfigurerade Authentication attribute. '*' och '+' kan mata ut många normala 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 ochAnonymous login. - TLS eller certifikatfel: Kontrollera namnet från servercertifikatet, DNS-upplösning, brandväggstid, giltighet och CA-kedja. Inaktivera inte certifikatkontrollen som första steg.
Test connectionfungerar, men användaren hittas inte: Jämför Base DN,Authentication attributeoch det angivna inloggningsnamnet.- Inloggning fungerar, gruppen är fel: Kontrollera
Group name attributeoch dess verkliga returvärde, lokal gruppmappning ochDefault group.memberOfär en rekommendation, men inte en garanterad mappning för varje schema. - Server skapas men används inte: Kontrollera serverval, ordning och arv för den berörda tjänsten under
Authentication > Services. - Google Secure LDAP binder inte: Kontrollera individuellt version
3, port636, attAnonymous loginochAppend 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ändaröverstyrning, grupppolicy, gruppmappning och berörd brandväggs- eller VPN-regel separat. Den fullständiga diagnostikmodellen visar Felsök autentiseringsfel systematiskt.
Å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.