Htaccess Datei mit der lmn7

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

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.

Als nächstes kannst du per

ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=config'

die config auslesen - da sollte unter olcTLSCertificateFile der Name der Zertifikats-Datei erscheinen (und entsprechend auch die Datei mit dem Schlüssel).

vermute ich nicht … v7 macht ja alles anders :roll_eyes:
OpenLDAP ist jedenfalls als „Zusatz-Server“ gestrichen – stattdessen liefert Samba4 jetzt selbst das AD.

Auf Client und Server erhalte ich jeweils das gleiche Zertifikat; denke aber nicht, dass es das LE-Zertifikat ist…

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

Das ist für den Client, nicht den server. Da steht wo er die Zertifikate sucht.

Ich hab grad geschaut: LDAP / AD aus Samba wird (tata!) in smb.conf konfiguriert. Da stehen die Direktiven:

tls enabled  = yes
tls keyfile  = /.../key.pem
tls certfile = /.../cert.pem
tls cafile   = /.../root.pem

Es würde mich wundern, wenn LE da eine Rolle spielt, da ja der Samba-Server nur Intern genutzt wird und mit LE das nicht möglich ist (naja, kommt auf den cn an, klar…).

Was sagen die openssl-Befehle, die ich oben geschrieben habe?

Also diese Zertifikate können einen ja echt bekloppt machen … :crazy_face:

Ich habe für das interne Netz (aus diversen Gründen) einen FQDN gewählt, der auch extern auflösbar ist. Von daher habe ich auch ein LE-Zertifikat, das auf meinen Server ausgestellt werden konnte. Im LAN funktioniert das: https://server.linuxmuster.meine-schule.de liefert eine gesicherte Verbindung („grünes Schloss“)

Die Verbindung klappt, ich bekomme ein Zertifikat, das aber wesentlich kürzer als das LE-Zert ist. Nun habe ich in die smb.conf geschaut und siehe da:

tls keyfile = /etc/linuxmuster/ssl/server.key.pem
tls certfile = /etc/linuxmuster/ssl/server.cert.pem
tls cafile = /etc/linuxmuster/ssl/cacert.pem

Das sind also scheinbar alles die selbst erzeugten Zertifikate, die beim Setup erzeugt wurden!?!

Eigentlich gehört dieser Thread ab #13 ans Ende von Nochmal ldaps -- Frage zu Abfragen auf Port 636
Irgendwas ist da durcheinander geraten…

Und welchen issuer und cn hat es?

Gib das dem Apachen (und jedem andren client) als vertrauenswürdigem Zertifikat (also vermutlich in /etc/ssl/certs), dann sollte’s gehn.

Oder stell die Einstellungen da um, offizielle LE Zertifikat zu ziehen, wenn die Namen stimmen (cn muss in den client-Einstellungen genutzt werden und zu der IP führen).

naaa… eigentlich ist das alles ganz einfach :wink: