hm – ich hatte den Eindruck, dass man um einen FQDN nicht herum kommt, wenn man früher oder später einen RevProxy braucht und Dienste im internen Netz auch nach außen anbieten will (moodle, nextcloud, eMail, …)?? Täusche ich mich da oder willst du das gar nicht?
ich halte es für eine gaaanz schlechte Idee Webdienste von innerhalb des
grünen Netzes im Internet an zu bieten.
Ich hab ja Zuhause auch eine haustüre: und daneben ist kein loch in der
Wand …
Webdienste gehören immer vor die Firewall (ROT, das mache ich) oder
neben selbige (Orange).
Hallo Holger,
ich habe das heute endlich mal ausprobiert … und komme leider nicht weiter.
Die .htaccess-Datei ist angelegt, ein Verzeichnis test ebenfalls mit diesen Rechten:
<Directory /var/www/html/test>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
Rufe ich elinks http://localhost/test auf, kommt zwar die Anmeldemaske für den Usernamen und das Passwort, aber dann bricht es ab mit Internal Server Error.
In der Log-Datei des Apache heißt es:
[Mon Nov 25 12:09:17.921518 2019] [access_compat:error] [pid 18281] [client ::1:57364] AH01797: client denied by server configuration: /var/www/html/test/
Bist du sicher, dass OU=SCHOOLS groß geschrieben werden muss?
(Wenn ich das „Deny from all“ rausnehme, wird die index-Seite natürlich angezeigt)
Telnet geht – aber mit dem Browser klappt es weiterhin nicht.
Der andere Host hängt zu Testzwecken momentan auch mit im Servernetz, so dass da auch nichts über die Firewall muss. 10.16.1.1 ist also direkt erreichbar.
Eine ldbsearch-Abfrage für den global-binduser klappt jetzt auch:
(zunächst direkt auf dem Server getestet). Da haben wir wieder das Problem, dass der Befehl auf anderen Clients nicht will – da gibt es diverse Optionen nicht
Ich würde ja gerne die ldaps-Verbindung von anderen VMs aus testen – komme aber mit dem Tool ldbsearch so nicht weiter.
Hallo Holger, es will einfach nicht …
Kann es sein, dass deine Syntax noch von einem alten Apache 2.2 stammt?
Ich finde für 2.4 überall nur sowas wie hier:
Ich habe einem Client im Servernetz (10.16.1.13) einen ganz frisch installierten Apache2 (Version 2.4.29-1ubuntu4.11) spendiert und die .htaccess Datei erstellt. Der Zugriff scheitert aber weiterhin …
AH01797: client denied by server configuration: /var/www/html/
Hat das jemand mit einem 2.4er Apachen laufen? Die Verbindung zum ldaps-Server ist laut ldbsearch da ( ldbsearch -H ldap://10.16.1.1 cn=global-binduser -U meinlogin )
– aber ich wüsste auch hier gerne, wo ich die Zugriffe auf ldap in einem Server-Logfile sehen kann. Unter /var/log/samba finde ich jedenfalls nichts?!?
Dieser Befehl läuft auch vom Client zum Server.
ldap(s) ist also ganz sicher da und es ist ein apache-Problem:
Ok, es hat mir keine Ruhe gelassen, da ich dieses Feature unbedingt benötige.
Es funktioniert nun auch mit Apache 2.4.
Dazu:
1.) einen Ordner protected erzeugen unterhalb von /var/www/html
2.) /etc/apache2/sites-enabled/000-default.conf editieren und dort unterhalb von DocumentRoot /var/www/html einfügen:
Ich kann nur dringend davon abraten, das Prüfen des Zertifikats abzuschalten, besonders darum, weil eine korrekte Lösung so einfach ist. Man muss nur dem Apache das Zertifikat als „trusted“ nennen und so bleibt die Verbindung geprüft sicher.
Noch besser wäre für die Schule eine CA zu betreiben, die die verschieden Zertifikate der Dienste signiert. Dann muss man in der Schule nur noch ein zusätzliches root-Zertifikat hinzuinstallieren (zB auch auf den Clients, sodass die Warnung dort Geschichte ist).
Der Umgang mit dem root-Zertifikat sollte allerdings entsprechend vorsichtig erfolgen!
Meine (ungeprüfte) Lösung wäre, das Zertifikat in /etc/ssl/certs/ zu kopieren (Welt-Lesbar), an das zusammengefasste ca-certificates.crt anzuhängen und den Apachen zu restarten.
Es könnte sein, dass der Apache seine Zertifikate woanders herholt, das kann ich grad nicht testen, aber wo immer er sie liest, da sollte’s hin.
… also müsste man z.B. ein LE-Zertifikat, das auf den Server in der DMZ ausgestellt wurde, an diese Stelle kopieren? Damit wäre das Konzept mit dem HAProxy und LE über den Haufen geworfen, oder??
Davor machst du ein csr (certificat signing request) wie du es mit LE machst (SUBJECT ersetze ich entsprechend). Aber das solltest du ja für deinen LDAP getan haben, oder?
Ich habe das nicht getan … vielleicht wird’s bei der Installation automatisch gemacht? Wer kann das beantworten??
Und vielleicht erklärt das auch die Probleme, die ich im Moment mit ldaps://-Abfragen habe??
Ich hatte eigentlich (laut Anleitung von Holger@baumhof ) versucht, moodle mit dem AD zu verbinden. Das soll über Port 636 laufen, liefert mir aber immer nur " Das LDAP-Modul kann keine Serververbindung herstellen: Server: ‚ldaps://server.linuxmuster.meine-schule.de:636‘, Connection: ‚Resource id #536‘, Bind result: ‚‘
Als ldap Server hast du vermutlich slapd. Der hat eine Konfiguration in /etc/ldap/slapd.d, allerdings im .ldif format.
Ich würde erstmal schauen, wo der Knabe lauscht: netstat -lptun|grep slapd sollte zeigen, ob er 389 (ldap) oder 636 (ldaps) anbietet oder noch weitere ports.
Dann kannst du per echo -n | openssl s_client -CApath /etc/ssl/certs/ -connect localhost:636 schauen, was er für ein Zertifikat anbietet. Das würde ich erstmal von der Box schauen, wo der ldap-Server läuft und dann auf den Boxen, die dahin verbinden sollen. Da sollte natürlich immer dieselbe Antwort kommen, ansonsten hast du ein Firewall-Problem.
die config auslesen - da sollte unter olcTLSCertificateFile der Name der Zertifikats-Datei erscheinen (und entsprechend auch die Datei mit dem Schlüssel).
Nein, das ist ein offizielles für „aussen“, denke ich.
Was kommt denn da? Diesen Base64-Teil (zwischen den -----(BEGIN|END) CERTIFICATE----- inkl den ----Zeilen), den du da siehst kannst du in eine Datei packen und dem Apachen geben…
Ah verdammt: Eins vergesse ich immer. Das ganze braucht natürlich korrekte Server-Namen. Wenn alles über die IP läuft, geht natürlich kein SSL oder TLS. Der Name ist der cn im Zertifikat.
funktioniert nicht: ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
Nur so als Vermutung: [root@server:/etc/ldap]$ cat ldap.conf
Da steht:
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
# TLS certificates (needed for GnuTLS)
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
Kann es sein, dass man das DA auf das LE-Zertifikat umbiegen muss??
