LDAP: Unterschied zwischen den Versionen
Metaz (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
| (2 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
Hier muss man zwischen zwei LDAP Systemen | Hier muss man zwischen zwei LDAP Systemen unterscheiden: | ||
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. | == 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 [http://www.die.net/doc/linux/man/man5/slapd-sql.5.html man page] der lesenden Zugriff auf die [[Metalab OS]] Benutzerdaten bietet. | Zum anderen gibt es optional, falls eines unserer externen Services dies benötigt, einen slapd-sql [http://www.die.net/doc/linux/man/man5/slapd-sql.5.html 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 LDAP nehmen? == | == Könnte man denn nicht die Datenbank als Backend für unser internes LDAP nehmen? == | ||
'''Nein, kann man nicht.''' | '''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 [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: | [[Kategorie:Metalab_OS]] | ||
[[Kategorie: | [[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].
