LDAP: Unterschied zwischen den Versionen
Metaz (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Metaz (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| Zeile 1: | Zeile 1: | ||
Hier muss man zwischen zwei LDAP Systemen trennen: | |||
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. | |||
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. | |||
Den SQL basierenden LDAP Server kann man eventuell auch ganz weglassen, wenn die [[MOS Benutzerverwaltung]] ersteren LDAP Server als Quelle der Benutzerdaten verwendet. Da dafür aber in den Innereien von Django herumgebastelt werden muss wird es vorerst wahrscheinlich keine vollständige Integration geben. | |||
Und um weitere Diskussionen zu vermeiden, hier noch mal der Grund warum SQL 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:Server]] | |||
Version vom 25. August 2006, 00:36 Uhr
Hier muss man zwischen zwei LDAP Systemen trennen:
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.
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.
Den SQL basierenden LDAP Server kann man eventuell auch ganz weglassen, wenn die MOS Benutzerverwaltung ersteren LDAP Server als Quelle der Benutzerdaten verwendet. Da dafür aber in den Innereien von Django herumgebastelt werden muss wird es vorerst wahrscheinlich keine vollständige Integration geben.
Und um weitere Diskussionen zu vermeiden, hier noch mal der Grund warum SQL als volles Backend für einen LDAP Server keine gute Idee ist und anscheinend auch nicht vollständig implementiert wurde [1].
