LDAP: Unterschied zwischen den Versionen

aus Metalab Wiki, dem offenen Zentrum für meta-disziplinäre Magier und technisch-kreative Enthusiasten.
Zur Navigation springenZur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
Zeile 14: Zeile 14:
Und um weitere Diskussionen zu vermeiden, hier auch der Verweis zum Grund warum eine relationale Datenbank als volles Backend für einen LDAP Server keine gute Idee ist und anscheinend auch nicht vollständig implementiert wurde [http://www.openldap.org/faq/data/cache/378.html].
Und um weitere Diskussionen zu vermeiden, hier auch der Verweis zum Grund warum eine relationale Datenbank als volles Backend für einen LDAP Server keine gute Idee ist und anscheinend auch nicht vollständig implementiert wurde [http://www.openldap.org/faq/data/cache/378.html].


[[Kategorie:Metalab OS]]
[[Kategorie:Metalab_OS]]
[[Kategorie:Server]]
[[Kategorie:Netzwerk]]

Aktuelle Version vom 27. Januar 2013, 00:46 Uhr

Hier muss man zwischen zwei LDAP Systemen unterscheiden:

Metalab interne Systeme

Zum einen gibt es den internen LDAP Server der dazu verwendet wird Benutzeraccounts und Berechtigungen für interne Workstations, Server, Terminal Server und Fileserver, etc. zu halten. Hier ist nicht geplant ein grossartiges Benutzerprofil zu speichern sondern möglichst nur was wirklich benötigt wird um alle internen Rechner mit einer Benutzerdatenbank zu versorgen.

MOS Verwaltungsteil

Zum anderen gibt es optional, falls eines unserer externen Services dies benötigt, einen slapd-sql man page der lesenden Zugriff auf die Metalab OS Benutzerdaten bietet.

Wenn die MOS Benutzerverwaltung ersteren LDAP Server als Quelle der Benutzerdaten verwendet kann man sich den zweiten LDAP Server sparen und einfach ein Replikat des internen LDAPs verwenden. Da dafür aber in den Innereien von Django herumgebastelt werden muss wird es vorerst wahrscheinlich keine vollständige Integration geben.

Könnte man denn nicht die Datenbank als Backend für unser internes LDAP nehmen?

Nein, kann man nicht.

Und um weitere Diskussionen zu vermeiden, hier auch der Verweis zum Grund warum eine relationale Datenbank als volles Backend für einen LDAP Server keine gute Idee ist und anscheinend auch nicht vollständig implementiert wurde [1].