Htaccess Datei mit der lmn7

Hallo zusammen,

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 :slight_smile:
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.

ldaps://meineschule.dynalias.org:636

LG Holger

1 Like

Hallo Holger.
Kann ich gut gebrauchen – danke!

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 Michael,

Eine Frage dazu: Gibt’s den global-binduser per default oder hast du ihn angelegt?

der wird immer mit angelegt und das Passwort in
/etc/linuxmuster/.secret/ abgelegt (in welcher Datei dort darfst du
raten :slight_smile: )

Falls ersteres: Hast du dessen PW mit sophomorix ermittelt? Er ist ja selbst offenbar kein Mitglied der Gruppe teachers oder?

nein: er ist kein teacher: er ist noch nciht mal in der default-school

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?

… ich hatte das früher mal: war garnicht so geil: also hab ich es wider
gelassen.

LG

Holger

1 Like

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?

Schönen Gruß,
Michael

Hallo Michael,

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).

LG

Holger

Das wollte ich natürlich auch nicht. Dachte dennoch, dass der Name des Servers (bzw besser gesagt der anderen Services drumherum) einen FQDN benötigt…

Nachtrag:
Einfacher: sophomorix-user -iv -u global-binduser – steht dann auch gleich die base_dn usw

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)

Danke nochmal für einen guten Tipp,
Michael

Hallo Michael,

Bist du sicher, dass OU=SCHOOLS groß geschrieben werden muss?
(Wenn ich das „Deny from all“ rausnehme, wird die index-Seite natürlich
angezeigt)

ich bin mir sicher, dass es so bei mir seit über 2 Monaten funktioniert.

Require ldap-attribute
memberOf="CN=teachers,OU=Teachers,OU=default-school,OU=SCHOOLS,DC=bzpf,DC=lan"

ich habe vor ein paar Tagen sogar noch eine Zeile drunter gesetzt:

Require ldap-user "karlheinz"

so kommt der im LDAP geführte Benutzer „karlheinz“ auch an den
Vertretungsplan, obwohl er kein teacher ist.

Bist du dir den sicher, dass dein Webserver an den LDAP ran kommt?
Würde ich mal testen mit telnet auf dem Webserver

Ich teste das so:

telnet <ip.des.lmn.srv> 636

LG

Holger

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:

ldbsearch --simple-bind-dn="CN=global-binduser,OU=Management,OU=GLOBAL,DC=linuxmuster,DC=meine,DC=schule,DC=de" -H ldap://localhost --password=blabla

(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 :thinking:

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:

ldbsearch --simple-bind-dn="CN=global-binduser,OU=Management,OU=GLOBAL,DC=linuxmuster,DC=meine,DC=schule,DC=de" -H ldap://10.16.1.1 --password=blablabla

Schönen Gruß,
Michael

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:

<Location /protected>
AllowOverride None
Options +FollowSymLinks +Indexes
AuthName "AD/LDAP Authentifikations Test"
AuthBasicProvider ldap
AuthType Basic
AuthLDAPGroupAttribute memberUid
AuthLDAPGroupAttributeIsDN Off
AuthLDAPURL "ldap://10.16.1.1:3268/ou=default-school,ou=SCHOOLS,dc=linuxmuster,dc=meine,dc=schule,dc=de?samaccountname?sub?(objectClass=*)"
AuthLDAPBindDN "global-binduser@linuxmuster.meine-schule.org"
AuthLDAPBindPassword "super-geheim"
Require valid-user
#Require ldap-attribute memberOf="CN=teachers,OU=Teachers,OU=default-school,OU=SCHOOLS,DC=linux,DC=leoninum,DC=org" 
#Require user global-binduser@linux.leoninum.org
</Location>

Seltsamerweise ging es erst, als ich den Port auf 3268 eingestellt hatte – mit 636 wollte es hier nicht?! Ebensowenig mit ldaps.

Als Vorlage diente:
https://wiki.pratznschutz.com/index.php/Apache_2_mit_LDAP/AD_Authentifikation

Bin froh, dass es jetzt funktioniert…
Michael

… und hier steht, wie das ganze verschlüsselt über Port 3269 funktioniert.

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!

… wenn du jetzt noch dazu schreibst, wie man das konkret macht, ist das Problem gelöst, oder?

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??

nein, ein LE Zertifikat hat ein bereits als vertrauenswürdig eingestuftes root-Zertifikat, was bereits installiert ist.

Meine Lösung betrifft sogenannte self-signed Zertifikate, wo also issuer und subject gleich lauten.

na gut – wie hast du sie erzeugt?

Oh… Das habe ich seit LE lange nicht mehr :wink:

openssl x509 -req -days 365 -in SUBJECT.csr -signkey SUBJECT.key -out SUBJECT.selfsiged

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: ‚‘