kb

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Nächste Überarbeitung Beide Seiten der Revision
kb [2016/03/29 07:22]
flacco [Microsoft Actice Directory]
kb [2016/03/29 08:05]
flacco [DNS-Server bind und LDAP]
Zeile 9: Zeile 9:
 ==== Microsoft Actice Directory ==== ==== Microsoft Actice Directory ====
  
-"​Active Directory"​ ist eine von Microsoft entwickelte Kombination aus Kerberos, LDAP-Verzeichnis und Domain-Name-Service. Dabei dient Kerberos der Benutzer-Authentifizierung und ermöglicht sogenanntes "​Single-Sign-On",​ das LDAP-Verzeichnis dient als zentraler Informationsspeicher und DNS wird für eine Technik namens "​Service Location"​ genutzt. Eingeführt wurde "​Active Directory"​ mit Einführung des "​Microsoft Servers 2000".+"​Active Directory"​ ist eine von Microsoft entwickelte Kombination aus Kerberos, LDAP-Verzeichnis und Domain-Name-Service. Dabei dient Kerberos der Benutzer-Authentifizierung und ermöglicht sogenanntes "​Single-Sign-On",​ das LDAP-Verzeichnis dient als zentraler Informationsspeicher und DNS wird für eine Technik namens "​Service Location"​ genutzt. Eingeführt wurde "​Active Directory"​ mit Einführung des "​Microsoft Servers 2000".{{ :​active-directory_ms.png?​300|}}
  
-Single-Sign-On (SSO) ermöglicht,​ dass nur eine Anmeldung am System auch als Autorisierung für alle im Netzwerk angebotenen Dienste gilt. D.h. es genügt beispielsweise sich am eigenen PC mit Benutzernamen und Passwort anzumelden um danach ohne weitere Angabe von Benutzernamen oder Passwort auch Zugriff auf Dienste wie beispielsweise einen Exchange-Server zu erhalten.{{ :​active-directory_ms.png|?​300}}+Single-Sign-On (SSO) ermöglicht,​ dass nur eine Anmeldung am System auch als Autorisierung für alle im Netzwerk angebotenen Dienste gilt. D.h. es genügt beispielsweise sich am eigenen PC mit Benutzernamen und Passwort anzumelden um danach ohne weitere Angabe von Benutzernamen oder Passwort auch Zugriff auf Dienste wie beispielsweise einen Exchange-Server zu erhalten.
  
 Kerberos seinerseits verwaltet keinerlei eigenen Datenbestand. Die Daten auf die Kerberos zurückgreift werden in einem sogenannten LDAP-Verzeichnis abgelegt. Das LDAP-Verzeichnis stellt somit den zentralen Informationsspeicher des Active Directories dar. LDAP (Lightweight Directory Access Protocol) steht dabei sowohl für das Netzwerkprotokoll über welches auf die Informationen im Verzeichnis zugegriffen wird, als auch den Informationsspeicher selbst. Der Datenspeicher arbeitet "​objektorientiert"​ und somit gänzlich anders als eine relationale Datenbank. Der objektorientierte Ansatz ermöglicht es Netzwerk- oder Organisationsstrukturen eins zu ein im Datenspeicher abzubilden. Kerberos seinerseits verwaltet keinerlei eigenen Datenbestand. Die Daten auf die Kerberos zurückgreift werden in einem sogenannten LDAP-Verzeichnis abgelegt. Das LDAP-Verzeichnis stellt somit den zentralen Informationsspeicher des Active Directories dar. LDAP (Lightweight Directory Access Protocol) steht dabei sowohl für das Netzwerkprotokoll über welches auf die Informationen im Verzeichnis zugegriffen wird, als auch den Informationsspeicher selbst. Der Datenspeicher arbeitet "​objektorientiert"​ und somit gänzlich anders als eine relationale Datenbank. Der objektorientierte Ansatz ermöglicht es Netzwerk- oder Organisationsstrukturen eins zu ein im Datenspeicher abzubilden.
Zeile 21: Zeile 21:
 ==== Active Directory auf invis-Server ==== ==== Active Directory auf invis-Server ====
  
-Die Verwendung eines LDAP-Verzeichnisses als zentralen Informationsspeicher für Benutzerverwaltung,​ DNS- & DHCP-Server sowie weitere Zwecke zu nutzen ist für invis-Server nicht neu. Mit openLDAP verfügte auch der invis Classic schon immer über ein LDAP-Verzeichnis. Was fehlte waren Kerberos und Service Location.+{{ :​active-directory_invis-server.png?​350|}}Die Verwendung eines LDAP-Verzeichnisses als zentralen Informationsspeicher für Benutzerverwaltung,​ DNS- & DHCP-Server sowie weitere Zwecke zu nutzen ist für invis-Server nicht neu. Mit openLDAP verfügte auch der invis Classic schon immer über ein LDAP-Verzeichnis. Was fehlte waren Kerberos und Service Location.
  
-Mit Einführung von Samba 4.0 brachte Samba eine eigene Implementation von Microsofts Active Directory mit. Dies ermöglichte uns den Umstieg von openLDAP auf Active Directory. ​+Mit Einführung von Samba 4.0 brachte Samba eine eigene Implementation von Microsofts Active Directory mit. Dies ermöglichte uns den Umstieg von openLDAP auf Active Directory. Um alle Informationen die der invis Classic im LDAP speicherte auch im AD speichern zu können mussten wir eigene Schemaerweiterungen einspielen und darüber hinaus auch den von uns verwendeten DHCP-Server des ISC (Internet Systems Consortium) patchen.
  
-... to be continued+Als DNS-Server verwenden wir nicht den "Samba Internal DNS", sondern weiterhin "​bind"​ (ebenfalls vom ISC)Dies wird allerdings von Samba direkt unterstütztDie Anbindung erfolgt hier über einen DLZ-Treiber den Samba selbst mitbringt. 
-===== DNS-Server bind und LDAP =====+ 
 +Für die Benutzerverwaltung haben sich die Vorzeichen umgekehrt. Beim invis Classic wurden im LDAP prinzipiell POSIX-kompatible Benutzerkonten angelegt, die um Windows- respektive Samba-Attribute ergänzt wurden. Mit Active Directory bilden jetzt Windows-Benutzerkonten die Basis, die um POSIX-Attribute erweitert werden. Da Microsoft dies selbst unter Verwendung der eigenen Erweiterung "​Services for UNIX" (SFU) anbietet, bricht es nicht die Kompatibilität zur MS-Welt. Unter Samba wird diese Ergänzung "RFC 2307 Erweiterung"​ genannt.  
 + 
 +Die Anbindung von Linux-Clients wird über eine Kombination aus Samba und {{https://​fedoraproject.org/​wiki/​Features/​SSSD|SSSD}} (System Security Services Daemon) realisiert. Dabei wird Samba genutzt um (genau wie Windows Clients) der Domäne beizutreten und SSSD ist für die Abbildung der Benutzerkonten via PAM auf Linux-Systemen sowie die Benutzeranmeldung selbst zuständig. Selbstverständlich wird auch hier Kerberos verwendet. 
 + 
 +Genau wie es für Windows-Domänenmitglieder möglich ist, ermöglicht der SSSD auch für Linux-Clients Offline-Logins an der Domäne. 
 + 
 +Grundsätzlich beherrschen invis-Server damit auch Single Sign On, leider haben wir dass noch nicht für die Dienste des invis-Servers umgesetzt. 
 + 
 +==== Active Directory und Firewall ==== 
 + 
 +Die vielen an AD beteiligten Netzwerkprotokolle erfordern ein besonderes Augenmerk auf eine zwischen geschaltete Firewall. invis-Server nutzen beispielsweise immer die "​SuSEfirewall2"​ auch zwischen dem Server selbst und dem lokalen Netzwerk (interne Zone). 
 + 
 +Die folgende Tabelle gibt einen Überblick über die beteiligten Protokolle und zugehörigen Ports: 
 + 
 +^Protokoll ​ ^Transportprotokoll ​ ^Port  ^Bemerkung ​ ^ 
 +|Kerberos ​ |  TCP & UDP  |  88  |    | 
 +|LDAP  |  TCP & UDP  |  389  |    | 
 +|LDAPs ​ |  TCP  |  636  |    | 
 +|DNS  |  TCP & UDP  |  53  |    | 
 +|GC  |  TCP  |  3268  |  Global Catalog ​ | 
 +|SMB/​CIFS ​ |  TCP & UDP  |  445  |  Zugriff auf sysvol Freigabe ​ | 
 +|RPC  |  TCP  |  135  |Früheres Microsoft Messaging Protokoll, wird genutzt für die Replikation der sysvol FreigabeDies wird von Samba noch nicht unterstützt | 
 +===== DNS-Server bind und LDAP (invis Classic) ​=====
  
 Schon von Anfang an setzen wir ein LDAP-Verzeichnis als Daten-Backend für den DNS-Server //bind// ein. Der zugrunde liegende Patch, welchen wir schon seit einiger Zeit selbst in die Software-Pakete einbauen müssen, wird inzwischen kaum noch weiter entwickelt. Statt dessen gehört der sogenannte DLZ (dynamic loadable zone) Treiber seit etwa openSUSE 11.2 (oder so) fest zum Funktionsumfang der openSUSE-Pakete. Die Nutzung dieses Treibers würde uns eine Menge Arbeit ersparen, da wir keine eigenen //bind// Pakete mehr im openSUSE-Buildservice pflegen müssten. Schon von Anfang an setzen wir ein LDAP-Verzeichnis als Daten-Backend für den DNS-Server //bind// ein. Der zugrunde liegende Patch, welchen wir schon seit einiger Zeit selbst in die Software-Pakete einbauen müssen, wird inzwischen kaum noch weiter entwickelt. Statt dessen gehört der sogenannte DLZ (dynamic loadable zone) Treiber seit etwa openSUSE 11.2 (oder so) fest zum Funktionsumfang der openSUSE-Pakete. Die Nutzung dieses Treibers würde uns eine Menge Arbeit ersparen, da wir keine eigenen //bind// Pakete mehr im openSUSE-Buildservice pflegen müssten.
  • kb.txt
  • Zuletzt geändert: 2020/10/20 10:47
  • von flacco