zur → Übersicht von OwnCloud
Diese Vorgehensweise sollte auch für paedML5/openML5 funktionieren.
Seit Version 6 ownCloud ist die LDAP Anbindung erneuert worden:
(Paket ist auf linuxmusternet 6 schon installiert)
aptitude install php5-ldap
Das installierte Modul von apache nachladen lassen:
service apache2 force-reload
Liegt die OwnCloud nicht auf dem Server, muss man noch in der Datei /etc/ldap/slapd.conf
by anonymous peername.ip=<Owncloud-IP> auth
und danach der slapd neu gestartet werden
service slapd restart
Nach Anmeldung am WebGUI von ownCloud als ownCloud-Administrator (root
in dieser Anleitung):
+
links unten im WebGUILDAP user and group backend
aktvieren.Dieser Reiter muss korrekt konfiguriert sein, damit die weiteren Reiter funktionieren.
10.16.1.1
389
dc=example,dc=com
(bekommt man auf dem Server mit „grep BASE /etc/ldap/ldap.conf“)
Fortsetzen
. Es wird der nächste Reiter User Filter
angezeigt.Welcher User dürfen sich in ownCloud anmelden?
posixAccount
Nur von diesen Gruppen
ist ausgegraut, wenn der Server das member-of
overlay nicht unterstützt (wie bei openml,paedml5/linuxmusternet6). Leider ist es dadurch nicht möglich nur einer Gruppe den Login zu erlauben.Fortsetzen
. Es wird der nächste Reiter Login Filter
angezeigt.Zurück
um zu sehen, ob posixAccount
nun tatsächlich verwendet wirdWelches Attribut ist als Login zulässig?
Fortsetzen
. Es wird der nächste Reiter Group Filter
angezeigt.Welche Gruppen soll ownCloud kennen?
posixGroup
Die meisten Angaben werden automatisch richtig gesetzt
Verbindungseinstellungen
Konfiguration aktiv
Speichere Time to live zwischen
runterdrehen auf z.B. 5
(Sekunden)Ordnereinstellungen
(Mit Ordner
ist der LDAP-Verzeichnis
-Baum gemeint)memberUID
. (Damit ist der User in ownCloud in der primären posix gruppe (Klasse)Spezielle Eigenschaften
Die Konfiguration ist gültig und die Verbindung konnte hergestellt werden!
OwnCloud kann Benutzer aus mehreren LDAP-Server nutzen. Da sich dabei Doppelungen im Benutzernamen ergeben können, wird für jeden ownCloud-Benutzer-Account eine eindeutige UUID erzeugt, die allerdings wenig aussagekräftig ist wie z.B.:
c886ef6e-16fe-1033-83aa-8f19b87fd5fc
Die Daten dieses Users würden dann in folgendem Verzeichnis gespeichert:
/home/owncloud/c886ef6e-16fe-1033-83aa-8f19b87fd5fc
Wird nur an einen einzigen LDAP-Server angebunden (der linuxmuster.net Schulserver), kann ownCloud dessen eindeutige Loginnamen (uid) ohne Gefahr von Doppelungen als Identifikation nutzen.
Zur Umstelung von UUID auf Loginnamen geht man so vor:
LDAP user and group backend
, Reiter Expert
uid
uid
gidNumber
Nach erfolgreicher Konfiguration sieht die Benutzerliste von ownCloud z.B. so aus:
Zur Kontrolle sollte man prüfen:
Vorname Nachname
Reiter Advanced
, Bereich Ordnereinstellungen
ou=accounts,dc=linuxmuster-net,dc=lokal
(Das vorangestellte ou=accounts,
beschleunigt die LDAP Suche)ou=groups,dc=linuxmuster-net,dc=lokal
(Das vorangestellte ou=groups,
beschleunigt die LDAP Suche)
Reiter Advanced
, Bereich Verbindungseinstellungen
Speichere Time to live zwischen
wieder hochstellen 600
(Sekunden)
Bei Bedarf kann im Reiter User Filter
auf ldaps umgestellt werden:
ldaps://10.16.1.1
und der Port entweder selbst suchen lassen oder auf 636
umstellen.
Hat man sich vergeigt, beginnt man so am besten von vorne:
Server
: Delete KonfigurationNun kann man neu loslegen.
p_owncloud
sich einloggen können → filter anlegen bei user, geht aber nicht, da der LDAP von linuxmuster.net das nicht zulässt.
Damit das klappen kann, muss man jedoch den LDAP-Server so konfigurieren, dass er das Zertifikat des Schulserver nicht prüft, das passiert in der Datei /etc/ldap/ldap.conf
:
root@owncloud:~# cat /etc/ldap/ldap.conf # # 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) # AUSKOMMENTIEREN! #TLS_CACERT /etc/ssl/certs/ca-certificates.crt # # REINSCHREIBEN! PORT 636 TLS_REQCERT never
Prüfen kann man das mit dem folgenden Kommando auf der Kommandozeile:
ldapsearch -x -H ldaps://5.xxx.xxx.99:636 -b "dc=qg-xxxxx,dc=de" "objectClass=*"
dabei muss die Nutzerliste des Servers ausgegeben werden. Solange das nicht geht, muss man die OC gar nicht weiter konfigurieren.
Es ist unbedingt empfehlenswert, die Verbindung zum LDAP Server zu verschlüsseln, dabei sollten die Einstellungen folgendermaßen aussehen:
Ermitteln Sie auf dem Schulserver die basedn wie folgt:
# grep basedn /var/lib/linuxmuster/network.settings
# aptitude install ldap-utils
Dann unverschlüsselten Zugriff testen (IP und DN anpassen):
# ldapsearch -x -H ldap://10.16.1.1:389 -b 'dc=linuxmuster-net,dc=lokal'
Dann sollte der komplette LDAP-Baum durch die Konsole rauschen.
Danach Zugang verschlüsselt OHNE Zertifikat testen:
# LDAPTLS_REQCERT=never ldapsearch -x -H ldaps://10.16.1.1:636 -b 'dc=linuxmuster-net,dc=lokal'
LDAPTLS_REQCERT=never
hat der Eintrag von TLS_REQCERT never
inder Datei /etc/ldap/ldap.conf
Und schließlich verschlüsselter Zugang MIT Zertifikat testen:
# ldapsearch -x -H ldaps://10.16.1.1:636 -b 'dc=linuxmuster-net,dc=lokal'
In den Reitern User Filter
, Login Filter
und Group Filter
können auch ganz spezielle Filter angegeben werden.
Beispiel eines User Filter
:
(&(objectclass=posixAccount) (|(uid=foxal) (uid=beckje) (uid=gal)))
Dieser Filter beschränkt den Zugriff auf ownCloud auf die 3 User foxal
beckje
und gal
.
Die LDAP-Anbindungsdaten werden in der mysql-Datenbank gespeichert:
Sie können abgerufen werden mit:
use owncloud; mysql> select * from oc_appconfig where appid='user_ldap';
oder gedumped werden mit (muster mit Passwort für root
ersetzen):
mysqldump --extended-insert=0 -u root -pmuster owncloud --tables oc_appconfig --where="appid='user_ldap'"
Wiedereingespielt werden kann der Dump mit dem Befehl (ungetestet):
mysql -u root -pserver owncloud < working_config
Log der Datenbankänderungen: