VPN - Anbindung an SAMBA 4 - LDAP

[almo]

Hallo,

wieder eine Nacht ohne kein neues Problem. Ich würde gerne den VPN-Server gegen meine Windows-AD auf Basis von SAMBA 4 Authentifizieren lassen. Dann muss ich nicht Doppelte Benutzer anlegen. Die Freigabe erfolgt über eine Gruppe.

Die Konfiguration ist im Anhang, sowie ein Test. 

Log Informationen:

Code: [Select]

Mar 7 10:25:45 opnsense: Could not startTLS on ldap connection ()
Mar 7 10:24:19 opnsense: LDAP bind error (Can't contact LDAP server)
Mar 7 10:24:12 opnsense: LDAP bind error (Can't contact LDAP server)
Wenn ich die Konfiguration ändere ob Protokoll Version oder Verschlüsselung auf ohne, bekomme ich folgenden Fehler:

Code: [Select]

Mar 7 10:32:09 opnsense: LDAP bind error (Strong(er) authentication required)
Mar 7 10:31:28 opnsense: LDAP bind error (Strong(er) authentication required)
Mar 7 10:28:38 lighttpd[86578]: (mod_openssl.c.1496) SSL: 1 error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number
Mar 7 10:27:17 opnsense: LDAP bind error (Can't contact LDAP server)
Mar 7 10:26:49 opnsense: LDAP bind error ()
Mit einem LDAP-Browser meiner Wahl bekomme ich per TLS-Zugriff.

[theq86]

Wenn die OPNsense Implementierung von LDAP OpenLDAP ist, wirst du mit deinem Plan kein Glück haben.
Die Samba 4 AD funktioniert mit einer völlig anderen LDAP Implementierung, die OpenLDAP als Backend nicht unterstützt.

[almo]

Okay, das erklärt mein Problem.

Wie sieht es aus wenn es ein echte Microsoft AD ist?

[JeGr]

Du kannst bei den Auth Settings von OPNsense doch auswählen, was du als Template nutzen willst bei der Verbindung. Bei SAMBA würde ich mal stark davon ausgehen, dass es ähnlich wie ein AD aufgebaut ist - sonst könnte es selbiges kaum emulieren. Also würde ich auch nicht OpenLDAP als Template auswählen, sondern Microsoft AD, damit eben Dinge wie Benutzername nicht via "cn" sondern via "sAMAccountName" Attribut selektiert werden.

Zudem steht da im Log für mein Verständnis, dass der Connect via TLS gegen dein AD fehl schlägt. Dass dein anderer Browser funktioniert heißt da erst einmal nicht so sehr viel, das kann auch heißen, dass dem Browser egal ist, ob das TLS Zert bspw. self-signed ist oder nicht. Ob es OPNsense egal ist, weiß ich nicht. Andernfalls kann es auch sein, dass du nicht StartTLS, sondern SSL Enc auswählen musst, da ich aber keine Ahnung habe wie dein Samba konfiguriert ist, ist das eher ein Problem "dazwischen".

Ich würde erst mal TLS lassen und normal versuchen (389 ohne encryption) und ansonsten echte TLS Verbindung via 636 testen. Außerdem die BIND credentials mit kompletter Schreibweise wiedergeben (also user@domain und nicht nur user). Bei uns wurde zwar der User Container "samAccountName" und nicht "sAMAccountName" geschrieben, aber ob das relevant ist kann ich nicht sagen.

Hope that helps.

[almo]

Also als Vorlage hab ich "Microsoft AD" gewählt aus der Stammt auch automatisch das "sAMAccountName"

Aktuelle Version: 18.1.3, dass könnte auch ein Bug sein ? Auch wenn ich den Container per "Auswählen" auswählen will bekomme ich ein Leeres PopUP wo bei Version 18.1.2 noch eine Fehler Meldung gekommen ist mit "LDAP Verbindung fehlgeschlagen"

---
Ein Portscan der Maschine gibt mir folgendes Zurück:

Code: [Select]

Port 22 (TCP)
OpenSSH 6.7p1 Debian 5+deb8u4 protocol 2.0
Port 53 (TCP)
domain
Port 88 (TCP)
Heimdal Kerberos server time: 2018-03-07 11:39:03Z
Port 111 (TCP)
rpcbind
Port 135 (TCP)
Microsoft Windows RPC
Port 139 (TCP)
Samba smbd 4.X workgroup: BRAUSTUEBERL
Port 389 (TCP)
ldap Anonymous bind OK
Port 445 (TCP)
Samba smbd 3.X workgroup: BRAUSTUEBERL
Port 464 (TCP)

Port 636 (TCP)
Tunnel is TLSv1: ldap Anonymous bind OK

Auch über 636 beschwert er sich.

Ich vermute auch das die Firewall das TLS vom Samba nicht akzeptiert. Deswegen hab ich das Zertifikat vom SAMBA auf die Firewall importiert und auf SSL mit dem Zertifikat umgestellt. Aber das will auch nicht.

[JeGr]

bei 389 ohne TLS beschwehrt er sich kaum über das Zertifikat

ansonsten obige Tipps mal ausprobieren was BIND etc. angeht. Gegen ein MS AD kann ich via 389 und gültigem User sauber authentifizieren. Ansonsten mal nachsuchen, wie das AD bei Samba 4 aufgebaut ist, m.E. sollte das ja den MS Kram emulieren und daher mit den Einstellungen laufen.

[almo]

So:

389= opnsense: LDAP bind error (Strong(er) authentication required)
389 TSL = opnsense: LDAP bind error (Can't contact LDAP server)
636= opnsense: LDAP bind error (Can't contact LDAP server)
636 SSL CA von SAMBA = opnsense: LDAP bind error (Can't contact LDAP server)

Aktuelle Konfiguration im Anhang

[JeGr]

In der smb.conf auf dem Samba mal mit

>  ldap server require strong auth = No

versucht? Der blockt dir hier den Zugriff auf den unverschlüsselten Port 389 weg. Ansonsten mss ich bei "in wie weit der Zugriff via 636 mit Zertifikat ein Problem ist" passen.

Edit: die pfSense Troubleshoot Seite hilft da ggf. weiter:

https://doc.pfsense.org/index.php/LDAP_Troubleshooting

When connecting to LDAP with SSL, the hostname given for the server is also used to verify the server certificate. The server certificate's common name must be its hostname, and that hostname must resolve to the LDAP server's IP address, e.g. CN=ldap.example.com, and ldap.example.com is 192.168.1.5.

Sprich nicht die DC IP sondern die Adresse (dc.domain.tld) sollte da rein, sonst gibts schon das erste Problem.
Auch die CA muss die gleiche sein, sprich das Zertifikat des Samba AD Servers muss von der gleichen CA sein, wie die Sense.

[almo]

In der smb.conf auf dem Samba mal mit

>  ldap server require strong auth = No

Da hatten wir wohl zeitgleich den selben Google-Treffe.

Der SAMBA spricht mit der Opnsens nun, jetzt muss ich es nur noch hinbekommen das der Prüfer auch funktioniert ..

Status Update:

- Prüfer funktioniert
- Zugriff per VPN Funktioniert über SAMBA funktioniert

Anleitung als extra Thema für die Zukunft ?

[JeGr]

Wenns ohne TLS jetzt geht, würde ich einfach versuchen es mit TLS auch noch hinzubekommen - das wäre dann ggf. auch zukunftssicherer. Aber sonst super dass es geht.

[almo]

Nach dem ich den SAMBA 4.1 bald gegen einen echten AD ersetzen werde und ein SAMBA Mitglied dieser AD wird als Backupserver - Secondary AD mach ich mir jetzt die mühe nicht mehr. Da der SAMBA 4.1 mit den Windows Clients noch ganz andere Probleme hat und mit Blick auf Windows 10 

Und mit einem echten AD könnte ich auch RADIUS verwenden.

Aktuell bin ich so erst mal Glücklich, das andere ist dann Stufe 2 des Netzwerkumbaus