Ansluta en generisk LDAP-server till Sophos Firewall

Active Directory är den vanligaste autentiseringsservern i Sophos Firewall, men inte den enda. Den som driver OpenLDAP, 389 Directory Server, FreeIPA, Google Secure LDAP eller ett annat rent LDAP-katalog kan koppla Sophos Firewall som LDAP-klient på samma sätt. Servertypen heter medvetet LDAP Server, inte Active Directory, även om Active Directory tekniskt sett också är en LDAP-katalog.

Den här artikeln behandlar specifikt det generiska fallet: en katalogtjänst utan de AD-specifika fälten som domännamn eller Kerberos. För Active Directory-miljöer med LDAPS, gruppimport och AD SSO passar istället ansluta Active Directory till Sophos Firewall. För RADIUS-baserad autentisering, till exempel via Microsoft NPS eller en MFA-gateway, är konfigurera Sophos Firewall RADIUS-server den passande artikeln.

När en generisk LDAP-server passar

En LDAP-server i Sophos Firewall är lämplig när:

• användare och grupper ligger i en katalog som inte är Active Directory, till exempel OpenLDAP, 389 Directory Server eller FreeIPA.
• en molnbaserad katalog erbjuder ett LDAP-gränssnitt, till exempel Google Secure LDAP eller en LDAP-proxy framför Entra ID eller Okta.
• flera system redan autentiserar mot samma LDAP-katalog och brandväggen ska använda samma källa.
• det inte behövs Kerberos eller NTLM, utan en enkel bind-autentisering räcker.

Om det istället körs en Windows Server med Active Directory Domain Services är den specialiserade AD-servertypen oftast det bättre valet, eftersom den hanterar extra fält som domännamn på ett korrekt sätt. Den generiska LDAP-servertypen fungerar visserligen även mot Active Directory, men täcker färre AD-specifika automatiseringar.

Förutsättningar

• Åtkomst till WebAdmin i Sophos Firewall.
• Att LDAP-servern är nåbar från brandväggen, oftast port 389 (Plaintext/StartTLS) eller 636 (LDAPS).
• Ett bind-konto med läsrättigheter på den relevanta delträdet, angivet som Distinguished Name (DN).
• Base DN där användare söks, till exempel ou=people,dc=firma,dc=local.
• Kunskap om vilket attribut som fungerar som inloggningsnamn, ofta uid, sAMAccountName eller mail.
• Vid krypterad anslutning: serverns certifikat eller certifikatkedjan, om brandväggen ska validera det.

⚠️ Ett bind-konto bör bara ha läsrättigheter på det delträd som behövs. Det används inte för administrativa ändringar i katalogen, utan bara för att autentisera brandväggens användarförfrågningar mot LDAP-servern.

Skapa LDAP-server

1. Öppna Authentication > Servers.
2. Välj Add och ange LDAP server som Server type.
3. Ange ett unikt namn under Server name, till exempel LDAP_Firma_Intern.
4. Ange IP-adressen eller DNS-namnet för LDAP-servern under Server IP/domain.
5. Välj den LDAP-version som servern stöder under Version, oftast Version 3.
6. Välj mellan Plaintext, SSL/TLS eller STARTTLS under Connection security.
7. Ange rätt port under Port, om inte standardporten används.
8. Inaktivera Anonymous login om servern inte tillåter anonyma bind-förfrågningar.
9. Ange det tekniska kontot som Distinguished Name under Bind DN, till exempel cn=svc-sophos,ou=service,dc=firma,dc=local.
10. Ange motsvarande Password.
11. Ange sökområdet för användare under Base DN, till exempel ou=people,dc=firma,dc=local.
12. Ange fältet som fungerar som inloggningsnamn under Authentication attribute, ofta uid.
13. Ange vid behov Display name attribute och Email address attribute, till exempel cn och mail.
14. Ange vid behov Group name attribute om gruppmedlemskap ska utvärderas.
15. Kör Test connection och kontrollera resultatet.
16. Välj Save.

Fälten i översikt:

Ett lyckat Test connection bevisar bara att server, port, bind-konto och sökbas i grunden är nåbara. Om rätt användare hittas och grupper tilldelas korrekt måste därefter kontrolleras med en riktig testanvändare.

Välj kryptering korrekt

I produktionsmiljöer bör anslutningen mellan brandväggen och LDAP-servern vara krypterad, antingen via LDAPS på port 636 eller via STARTTLS på den klassiska porten 389. Plaintext-LDAP skickar bind-lösenord och delvis användardata okrypterat och bör bara användas i strikt avgränsade, interna testscenarier.

Med Validate server certificate kontrollerar brandväggen om certifikatet som LDAP-servern presenterar är pålitligt. Vid självsignerade certifikat, som till exempel används vid Google Secure LDAP, kan certifikatet markeras som opålitligt trots att anslutningen fungerar. I det fallet måste ett medvetet beslut fattas om certifikatkontrollen ska anpassas eller certifikatet importeras till brandväggen.

Exempel: Google Secure LDAP

Google Secure LDAP visar tydligt hur en molnbaserad katalog kopplas via generisk LDAP:

• Server IP/domain: ldap.google.com
• Port: 636
• Version: 3
• Connection security: SSL/TLS
• Bind DN och Password: inloggningsuppgifter från de LDAP-klientuppgifter som skapats i Google Admin Console.
• Certifikat: Klientcertifikatet med privat nyckel som utfärdats av Google lagras i brandväggen.
• Attribut: uid för inloggning, cn för visningsnamn, mail för e-postadress, memberOf för grupper.

Det här exemplet kan överföras till andra LDAP-leverantörer med liknande struktur. Avgörande är alltid vilket attribut leverantören faktiskt fyller i för inloggningsnamn, visningsnamn, e-post och gruppmedlemskap.

Ange Bind DN och Base DN korrekt

Den vanligaste felkällan vid en ny LDAP-server är felaktigt skriven eller feltolkad DN-syntax.

Viktiga regler:

• En DN skrivs från den mest specifika till den mest allmänna delen, till exempel cn=svc-sophos,ou=service,dc=firma,dc=local.
• Base DN för användarsökningen måste vara det delträd där de relevanta användarobjekten faktiskt ligger, inte nödvändigtvis katalogens rot.
• Om användare ligger i flera organisationsenheter måste Base DN väljas tillräckligt högt upp i trädet så att den omfattar alla relevanta containrar.
• Append base DN avgör om Base DN dessutom läggs till på Bind DN. Detta beror på servern och bör testas riktat vid problem.

Om Base DN väljs för snävt kan brandväggen under vissa omständigheter rapportera ett lyckat anslutningstest, men senare inte hitta några användare. Om Base DN väljs för brett kan sökningen ta onödigt lång tid eller omfatta oönskade objekt.

Tilldela grupper och attribut

För brandväggsregler, Web Policies eller VPN-behörigheter efter grupp är Group name attribute avgörande. Det bestämmer vilket LDAP-attribut brandväggen tolkar som gruppmedlemskap.

Typiska mönster:

• Kataloger med klassiskt groupOfNames- eller posixGroup-schema använder ofta ett attribut som memberOf eller utvärderar gruppmedlemskap via bakåtreferenser.
• Molnkataloger med LDAP-proxy, till exempel Google Secure LDAP, levererar ofta grupper direkt i attributet memberOf på användarobjektet.
• Om schemat är oklart hjälper en LDAP-browser eller ett kommandoradsverktyg som ldapsearch för att en gång granska användarobjektet fullständigt innan brandväggen konfigureras.

Efter konfigurationen bör minst en användare från varje relevant grupp testas. En enskild lyckad inloggning bevisar inte att gruppmatchningen fungerar korrekt för alla grupper.

Aktivera LDAP-server för tjänster

En skapad LDAP-server autentiserar ännu ingen av sig själv. Den måste dessutom tilldelas önskad tjänst under Authentication > Services, till exempel VPN Portal, SSL VPN, Captive Portal eller admin-inloggning.

Praktiskt förlopp:

1. Öppna Authentication > Services.
2. Välj den aktuella tjänsten, till exempel Firewall authentication methods eller VPN.
3. Lägg till den nyskapade LDAP-servern som autentiseringskälla.
4. Kontrollera ordningen om flera servrar används parallellt.
5. Kontrollera den avsedda tjänsten med en testanvändare.

Om flera autentiseringsservrar är aktiva samtidigt, till exempel LDAP och lokala användare, bör ordningen väljas medvetet. Brandväggen frågar servrarna i den angivna ordningen.

Testa och validera anslutningen

Efter sparandet bör konfigurationen testas i flera steg:

1. Test connection i servervyn: bekräftar nåbarhet, bind-konto och Base DN.
2. Logga in testanvändare på måltjänsten: bekräftar att autentiseringen faktiskt fungerar.
3. Kontrollera gruppmedlemskap: bekräftar att Group name attribute utvärderas korrekt.
4. Testa fel användare eller fel lösenord: bekräftar att misslyckade inloggningar avvisas korrekt.
5. Kontrollera Log Viewer: visar om autentiseringsförfrågningar kommer fram och behandlas som förväntat.

En testanvändare som loggar in framgångsrikt men inte tilldelas den förväntade gruppen tyder oftast på ett felaktigt Group name attribute eller ett oväntat gruppschema.

Vanliga fel

• Fel DN-syntax: Bind DN eller Base DN har blandats ihop, skrivits fel eller använder fel avgränsare. Kontrollera syntaxen mot katalogschemat.
• Base DN vald för snävt: Anslutningstestet lyckas, men verkliga användare hittas inte. Placera Base DN högre upp i katalogträdet.
• Fel port eller fel kryptering: LDAPS på port 389 eller Plaintext på port 636 fungerar inte. Port och Connection security måste stämma överens.
• Certifikat inte pålitligt: Vid självsignerade certifikat kan brandväggen klassa anslutningen som opålitlig. Importera certifikatet medvetet eller anpassa valideringen riktat.
• Anonymous login aktiverat, trots att servern nekar detta: Bind misslyckas. Inaktivera Anonymous login och ange Bind DN/Password.
• Gruppattribut matchar inte schemat: Inloggningen fungerar, men grupprinciper slår inte igenom. Kontrollera attributet mot det faktiska LDAP-schemat, till exempel med ldapsearch.
• LDAP-server inte tilldelad under Authentication > Services: Servern är skapad men används inte av någon tjänst. Gör tilldelningen under Authentication > Services i efterhand.
• Flera autentiseringsservrar i fel ordning: En annan server svarar först och ger oväntat beteende. Kontrollera ordningen under Authentication > Services.

FAQ