Hoppa till innehållet
Avanet

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=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.

⚠️ 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

  1. Öppna Authentication > Groups och välj Add.
  2. Ange en unik Group name, till exempel LDAP-Benutzer.
  3. Välj Group type för den avsedda inloggningsmetoden. Normal kräver användarinloggning; Clientless styr åtkomst baserat på en IP-adress.
  4. 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

  1. Öppna Authentication > Servers och välj Add.
  2. Välj LDAP server som Server type.
  3. Tilldela en unik Server name, till exempel LDAP-Firma.
  4. Ange serverns IP eller domännamn under Server IP/domain. För Validate server certificate, använd det lösbara namnet från servercertifikatet.
  5. Välj Version 2 eller 3 som stöds av servern. Google Secure LDAP kräver version 3.
  6. Ställ in Connection security och Port tillsammans. För produktiv drift använd SSL/TLS eller STARTTLS.
  7. Stäng av Anonymous login och ange Bind DN och Password för läskontot.
  8. Slå endast på Append base DN om servern ska lägga till bas-DN under bindning.
  9. 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 det Client certificate som behövs i listan.

Ställ in sökbas och attribut

  1. Ange startpunkten för användarsökningen under Base DN. Get base DN kan få sökbasen som servern erbjuder.
  2. Ställ in attributet med inloggningsnamnet som Authentication attribute, ofta uid eller mail.
  3. Ange Display name attribute och Email address attribute för att matcha användarobjektet, till exempel cn och mail.
  4. Ange gruppattributet som returneras på användarobjektet under Group name attribute. memberOf är Sophos rekommendation, men måste matcha schemat och returformatet.
  5. Ange Expiry date attribute som 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.
  6. Kör Test connection och spara med Save.

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

  1. Öppna Authentication > Services.
  2. Under Firewall authentication methods, flytta LDAP-servern till Selected authentication servers. Om den ska användas först placerar du den överst.
  3. Välj den förberedda gruppen LDAP-Benutzer som Default group och klicka på Apply.
  4. 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.
  5. Använd arvsalternativ som Set authentication methods same as firewall, Same as firewall eller Same as VPN endast 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.com
  • Version: 3
  • Connection security: SSL/TLS
  • Port: 636
  • Anonymous login: av
  • Bind DN och Password: de genererade Google LDAP-uppgifterna
  • 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. 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:

  1. Test connection måste bekräfta anslutningen och bindningsuppgifterna.
  2. Under Authentication > Services kontrollera serverlista, ordning och arv för varje metod som används. Default group tillhör Firewall authentication methods.
  3. 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.
  4. Under Authentication > Users, kontrollera att användaren och gruppen visas som förväntat.
  5. 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.
  6. Kontrollera inte bara inloggningen utan även den avsedda policyn eller testregeln. Använd sedan ett felaktigt lösenord som ett negativt test.
  7. Kontrollera access_server.log för användarinloggning, auktorisering och redovisning; vid VPN-portalproblem även vpnportal.log.
  8. 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 och Anonymous 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 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.
  • 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, 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ä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.