Hoppa till innehållet
Avanet

Ansluta en generisk LDAP-server till Sophos Firewall

Sophos Firewall

Med servertypen LDAP server autentiserar Sophos Firewall användare från OpenLDAP, 389 Directory Server, FreeIPA, Google Secure LDAP och andra LDAP-kataloger. Hela processen består av fyra delar: skapa en lokal grupp, anslut LDAP-servern säkert, aktivera servern under Authentication > Services och kontrollera inloggningen och grupptilldelningen med en verklig användare.

För Windows Active Directory med LDAPS, gruppimport eller AD SSO passar Ansluta Active Directory till Sophos Firewall bättre. RADIUS via Microsoft NPS eller en MFA-gateway beskrivs i Konfigurera en RADIUS-server på Sophos Firewall.

Den som måste ersätta den inbyggda servertypen eDirectory före SFOS 23 hittar hela processen med inventering, målval, parallelldrift och återställning i Migrera eDirectory före SFOS 23.

Förutsättningar

  • WebAdmin-åtkomst till Sophos Firewall
  • LDAP-servern är nåbar från brandväggen, vanligtvis via port 389 för STARTTLS eller 636 för SSL/TLS
  • ett bindkonto med läsbehörighet till den del av katalogen som behövs
  • Bind DN och Base DN, till exempel cn=svc-sophos,ou=service,dc=example,dc=net och ou=people,dc=example,dc=net
  • de användarattribut som faktiskt används, exempelvis uid, cn, mail och ett gruppattribut
  • rätt CA-förtroendekedja och fungerande DNS-upplösning när certifikatvalidering är aktiverad

⚠️ Ett bindkonto bör endast ha läsbehörighet till det nödvändiga underträdet. Det används inte för administrativa ändringar i katalogen, utan enbart för att autentisera brandväggens användarfrågor mot LDAP-servern.

Lägga till LDAP-servern

Förbereda den lokala LDAP-gruppen

  1. Öppna Authentication > Groups och välj Add.
  2. Skapa en grupp med ett tydligt namn, till exempel LDAP-Användare.
  3. Ange åtkomst, tidskvoter och andra gruppolicyer efter den avsedda användningen och spara.

Gruppen används senare som Default group. Den hindrar inte automatiskt åtkomst: policyerna som tilldelats gruppen och reglerna för den aktuella tjänsten avgör vad som är tillåtet.

Den allmänna grupplogiken med en restriktiv Default Group, användaråsidosättningar, pilot och återställning beskrivs i Hantera användargrupper i Sophos Firewall säkert; den LDAP-specifika tilldelningen följer sedan av gruppattributet och katalogschemat.

Konfigurera anslutning och bind

  1. Öppna Authentication > Servers och välj Add.
  2. Välj LDAP server som Server type.
  3. Ange ett tydligt Server name, till exempel LDAP-Företag.
  4. Ange LDAP-serverns DNS-namn under Server IP/domain. När certifikatvalidering är aktiv måste namnet motsvara ett namn i servercertifikatet.
  5. Använd Version 3 om katalogen inte kräver en annan version. Google Secure LDAP stöder endast version 3.
  6. Välj SSL/TLS eller STARTTLS och motsvarande port för produktionsdrift.
  7. Inaktivera Anonymous login och ange läskontots Bind DN och Password.
  8. Aktivera endast Append base DN om LDAP-servern förväntar sig att Base DN läggs till vid bind.
  9. Aktivera Validate server certificate när namn, DNS och CA-förtroende är korrekt konfigurerade. Ett Client certificate behövs endast om LDAP-tjänsten kräver ömsesidig certifikatautentisering.

Ange sökbas och attribut

  1. Ange startpunkten för användarsökningen under Base DN, till exempel ou=people,dc=example,dc=net. Get base DN kan hämta sökbasen som servern erbjuder.
  2. Ange inloggningsattributet som Authentication attribute, vanligtvis uid eller mail.
  3. Ange Display name attribute och Email address attribute så att de passar användarobjektet, exempelvis cn och mail.
  4. Under Group name attribute, ange det attribut som brandväggen hämtar användarens gruppinformation från. Sophos rekommenderar memberOf, men rätt värde beror på katalogschemat.
  5. Om katalogen tillhandahåller ett utgångsdatum för konton, ange lämpligt Expiry date attribute.
  6. Kör Test connection och spara med Save.

Enligt Sophos kontrollerar Test connection anslutningen och inloggningsuppgifterna. Endast en verklig inloggning visar om Base DN omfattar alla användare som behövs och om grupperna tilldelas korrekt.

Välja rätt kryptering

LDAP i klartext överför inloggningsuppgifter okrypterat och lämpar sig som mest för ett isolerat test. I produktion bör anslutningen skyddas med SSL/TLS, vanligtvis på port 636, eller STARTTLS, vanligtvis på port 389.

Två certifikatroller måste skiljas åt:

  • Validate server certificate verifierar identiteten för LDAP-fjärrservern. Server IP/domain måste motsvara ett giltigt DNS-namn i certifikatet, antingen Common Name eller ett Subject Alternative Name. Om brandväggen inte kan slå upp namnet lägger man till en lämplig DNS-post under Network > DNS > DNS host entry. Konfigurera och testa DNS Host Entries på Sophos Firewall förklarar TTL, bakåtuppslagning och resolvertestet. Den utfärdande CA:n måste också vara betrodd.
  • Client certificate identifierar brandväggen för en LDAP-tjänst som kräver ömsesidig certifikatautentisering. Certifikatet ersätter inte valideringen av servercertifikatet.

Vid ett TLS-fel bör servernamn, DNS-upplösning, giltighet och CA-kedja korrigeras först. Att inaktivera valideringen av servercertifikatet bör inte vara standardlösningen.

Ange Bind DN och Base DN korrekt

Den vanligaste orsaken till fel med en ny LDAP-server är en felaktigt skriven eller missförstådd DN-syntax.

  • Ett DN går från det specifika objektet till katalogroten, till exempel cn=svc-sophos,ou=service,dc=example,dc=net.
  • Base DN börjar där användarsökningen ska starta. Om användarna finns i flera organisationsenheter måste den ligga tillräckligt högt i trädet för att omfatta dem.
  • En alltför snäv Base DN returnerar inga matchande användare även om servern är nåbar. En onödigt bred sökbas kan göra sökningen långsammare och ta med oönskade objekt.
  • Append base DN lägger till Base DN till ett ofullständigt Bind DN vid bind. Om DN redan är fullständigt förblir alternativet normalt inaktiverat; LDAP-serverns beteende är avgörande.

Aktivera grupper och tjänster

Group name attribute är inte en universell inställning för alla LDAP-gruppstrukturer. Vid inloggning läser brandväggen det konfigurerade attributet i användarobjektet och använder den returnerade gruppinformationen för tilldelningen. Sophos rekommenderar memberOf, och Google Secure LDAP använder detta värde. OpenLDAP, 389-ds eller FreeIPA kan dock kräva ett annat värde beroende på schema, overlay och användarobjekt.

Härled inte användarattributet enbart från grupptypen groupOfNames eller posixGroup. Det avgörande är vad det verkliga användarobjektet faktiskt returnerar och om motsvarande grupp är korrekt mappad på brandväggen. Om brandväggen inte hittar någon passande grupptilldelning placeras användaren i konfigurerad Default group.

Aktivera sedan servern:

  1. Öppna Authentication > Services.
  2. Välj LDAP-servern under Firewall authentication methods och flytta den till önskad plats i Selected authentication servers. Brandväggen frågar flera servrar i denna ordning.
  3. Välj den tidigare skapade gruppen LDAP-Användare som Default group och klicka på Apply.
  4. Om användare ska logga in på User Portal, VPN Portal, via SSL VPN, till en annan VPN-tjänst eller som administratörer, välj även LDAP-servern under motsvarande autentiseringsmetod.

Konfigurera Google Secure LDAP

Innan brandväggen konfigureras skapas en LDAP-klient i Googles administratörskonsol. Där anges klientens åtkomsträttigheter, certifikatet med privat nyckel laddas ned och separata inloggningsuppgifter genereras. Lösenordet visas inte igen när Google-dialogrutan har stängts.

Importera Googles klientcertifikat med certifikatet och den privata nyckeln under Certificates > Certificates > Add. Sophos Firewall kan visa det som ej betrott eftersom det är självsignerat av Google, men det fungerar ändå för klientautentisering. Denna status gäller inte valideringen av servercertifikatet.

Använd följande värden 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 inloggningsuppgifterna för Google LDAP
  • Append base DN: av
  • Client certificate: det importerade Google-certifikatet
  • Base DN: ange det eller hämta det 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 när Google LDAP-grupper skapas. Efter att konfigurationen har sparats gäller samma steg som för en lokal katalog: ange den lokala LDAP-gruppen, aktivera servern under Authentication > Services och testa en verklig inloggning och grupptilldelning.

Kontrollera anslutning och grupptilldelning

Ett tillförlitligt acceptanstest omfattar flera nivåer:

  1. Test connection bekräftar anslutningen och binduppgifterna.
  2. En användare loggar in på den avsedda tjänsten, till exempel VPN Portal eller Captive Portal.
  3. Kontrollera under Authentication > Users att användaren och gruppen visas som förväntat.
  4. Om flera LDAP-grupper används ska minst en användare från varje relevant grupp testas. En policy eller testregel bekräftar att både inloggningen och den aktuella gruppbehörigheten fungerar.
  5. Ett felaktigt lösenord avvisas och Log viewer visar ett begripligt autentiseringsfel.

Om schemat är oklart kan en administratör inspektera användarobjektet skrivskyddat från ett Linux-administrationssystem eller 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)' '*' '+'

-W frågar interaktivt efter bindlösenordet så att det inte lagras i shellhistoriken. '*' visar vanliga attribut och '+' operativa attribut; anpassa sökfiltret om ett annat inloggningsattribut används. Kommandot ska inte köras i Sophos Firewall Advanced Shell. Det viktiga är om användarobjektet faktiskt returnerar de förväntade attributen och gruppvärdena. Utdata kan innehålla personuppgifter från katalogen och måste anonymiseras innan de bifogas till ett ärende eller delas.

Vanliga fel

  • Ingen anslutning: Kontrollera routing, DNS, port och Connection security. Kontrollera därefter Bind DN, lösenord och Anonymous login.
  • TLS- eller certifikatfel: Kontrollera DNS-namnen i servercertifikatet, DNS-upplösningen, giltigheten och CA-kedjan. Inaktivera inte servercertifikatvalideringen som första åtgärd.
  • Test connection fungerar, men användaren hittas inte: Base DN är ofta för snäv eller så motsvarar Authentication attribute inte inloggningsnamnet.
  • Inloggningen fungerar, men användaren hamnar i Default group: Kontrollera Group name attribute i det verkliga användarobjektet, den lokala gruppmappningen och gruppordningen. memberOf är ett vanligt exempel men garanteras inte för alla scheman.
  • Google Secure LDAP utför inte bind: Kontrollera version 3, port 636, inaktiverad Anonymous login, inaktiverad Append base DN, inloggningsuppgifter och Googles klientcertifikat.
  • Servern är konfigurerad men används inte: Kontrollera tilldelning, ordning och Default group under Authentication > Services.
  • Sökningen är långsam eller returnerar oönskade konton: Begränsa Base DN till det underträd som behövs.
  • En annan autentiseringsserver svarar först: Korrigera ordningen på de valda servrarna för den berörda tjänsten.