ich hab vor zwei Wochen eine .htaccess Datei erstellt um ein Verzeichnis auf einem Webserver gegen die lmn7 zu authentifizieren.
Ich schreibs mal hier hien: falls es niemand braucht, dann kann wenigstens ich es irgend wann mal wieder finden
Hier ist die .htaccess Datei:
AuthType Basic
AuthName "Stundenplan meiner Schule"
AuthBasicProvider ldap
AuthLDAPBindAuthoritative On
AuthLDAPBindDN "global-binduser@bzpf.lan"
# Passwort vom global-binduser vom Server
AuthLDAPBindPassword "GeHeimesPWD"
AuthLdapURL "ldaps://meineschule.dynalias.org:636/ou=default-school,ou=schools,dc=bzpf,dc=lan?samaccountname"
AuthLDAPGroupAttributeIsDN Off
AuthLDAPGroupAttribute memberUid
Require ldap-attribute memberOf="CN=teachers,OU=Teachers,OU=default-school,OU=SCHOOLS,DC=bzpf,DC=lan"
Order deny,allow
Deny from all
Allow from 10.17.101.
#Allow from 10.17.102.17
Satisfy ANY
Das AllowFrom nimmt eine IP von der Authentifizierung aus (Anzeigensystem in der Schule).
Wer das verwenden will muß seine Domäne anpassen.
Normalerweise ist es linuxmuster.lan
Der muß alle
DC=bzpf,DC=lan
ändern zu
DC=linuxmuster,DC=lan
Was die Domain ist, steht in der /etc/hosts auf dem Server. Bei mir:
10.16.1.1 server.bzpf.lan server
Die Domain ist alles hinter server. (man beachte den Punkt!)
Das trennt man dann auf und schreibt vor jedes Wort ein DC= und dahinter ein Komma.
Dann bleibt noch die Adresse, unter der der AD zu erreichen ist: also die externe Adresse des Servers.
Nun muß man nurnoch den Port 636 im BeWürouter (oder DSL Router) und in der opnsense frei geben.
Eine Frage dazu: Gibt’s den global-binduser per default oder hast du ihn angelegt?
Falls ersteres: Hast du dessen PW mit sophomorix ermittelt? Er ist ja selbst offenbar kein Mitglied der Gruppe teachers oder?
Noch eine ganz andere Frage: Hat das einen bestimmten Grund, warum du für das interne Netz keinen FQDN nimmst, sondern bei .lan geblieben bist?
Schöne Grüße,
Michael
Hallo Holger – gut zu wissen. Danke! Die Syntax ist evtl für das andere Problem gleich mit nutzbar…
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?
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: ‚‘
)
