Kapitel 3 (PDF, 1,8 MB) - Fachgebiet Komplexe und Verteilte IT ...

3. Verzeichnisdienste 

Vorlesung 

Betrieb Komplexer IT-Systeme 

(BKITS)

Verzeichnisdienste 

● Schon aus dem Blickwinkel „Identity Management“ bekannt 

■ Speicherung von Informationen über Personen, Ressourcen, … 

■ Hierarchische Ordnung der Informationen 

■ Vererbung von Attributen an Kind-Elemente 

● Fokus dieses Kapitels: Allgemeiner Blickwinkel 

■ Was sind Verzeichnisse? Was sind Verzeichnisdienste? 

■ Wozu kann man Verzeichnisse benutzen? 

■ Welche Ansätze gibt es? 

♦ DNS, NIS, LDAP, Active Directory, … 

15.10.2011 Matthias Hovestadt - BKITS 

3-2

Vom Suchen und Finden 

● Unumstritten: Informationen sind wertvoll 

■ Allerdings: Wert hängt vom Aufwand des Auffindens ab 

♦ Aufwand kann Zeitaufwand sein, aber auch Geld oder Tätigkeit 

■ Daher: Strukturierung von Datensammlungen 

♦ Hierarchie von Datensätzen oder sonstwie geordnete Form 

♦ Ziel: Aufwand für Auffinden von Informationen gering halten 

● Strukturierte Datensammlungen bilden Verzeichnisse 

■ Beispiele aus dem Alltag: Telefonbuch, Fernsehzeitung, Katalog 

■ Beispiele aus der IT: Domain Name System (DNS), Suchmaschine 


3-3

Verzeichnisse und 

Verzeichnisdienste 

● Gemeinsamkeiten von Verzeichnissen 

■ Sammeln von Informationen 

■ Aufbereitung der Information 

■ Bereitstellung von Informationsdiensten für Abruf 

♦ Wichtig: Zugriff über einfache und standardisierte Wege 

● Verzeichnisse haben speziellen Anwendungsbereich 

■ Ermittlung von Telefonnummern, Übersicht Fernsehprogramm 

■ Keine weitere Verwendung der Daten vorgesehen 

● Verzeichnisdienste haben breiteren Fokus, z.B. TV-Service: 

■ Sat-Receiver programmiert sich auf Frequenz des Senders 

■ Videorecorder programmiert Zeiten und merkt sich EPG-Daten 

■ Stereoanlage optimiert Equalizer, z.B. Modus „Theater“ oder „Live“ 


3-4

Aktualität und Redundanz 

● Viele verschiedene Dienste im Netzwerk vorhanden 

● Wie kann Aktualität der Daten sichergestellt werden? 

■ Neuer Mitarbeiter muss in vielen Systemen bekannt sein 

♦ Mailserver, Webserver, Fileserver, Telefonanlage, … 

■ Datenstamm kann sich über die Zeit ändern 

♦ Namensänderung aufgrund einer Hochzeit 

● Wo ist Grenze zwischen flexibler Datenhaltung und 

inkonsistentem Datenstamm? 

● Weiteres Problem: Redundanzen 

■ Jeder Dienst hält seine eigene Benutzerdatenbank 

● Ansatz: 

Zentrales Verzeichnis, dass Daten für alle Dienste hält 


3-5

● Häufigste Form der Speicherung 

■ Speicherung beliebiger Information 

● Hierarchische Speicherung 

■ Baumstruktur 

♦ Directory Information Tree (DIT) 

■ Ziel: Schnelle Antwortzeiten 

■ Spiegelt oft geographische oder 

organisatorische Struktur wider 

● Relative Distinguished Name 

● Distinguined Name (DN) 

■ Von Wurzel bis RDN, eindeutig 

■ CN=Peter Müller, O=Firma,C=DE 

Verzeichnisse (1/2) 


Enterprise Dir 

C=US C=DE 

O=Musterfirma 

OU=Finanz OU=IT 

CN=Peter Müller 

2-6

Verzeichnisse (2/2) 

● Verzeichnisse sind objektorientiert 

■ Eigenschaften werden vererbt 

■ Knoten erben alle Attribute darüber liegender Knoten 

♦ Attribute von Knoten müssen für alle Kindknoten (Knoten in 

tieferen Hierarchieebenen) relevant sein 

■ Gegensatz: Relationales Datenbankmodell 

● Schema: Beschreibung der Struktur eines Verzeichnisses 

■ Welche Arten von Informationen sollen gespeichert werden? 

■ Welche Attribute werden verwendet? 

■ Definition von Sub-Schemata, die nur für Teilbaum gelten 

■ Verteilung der Administration eines Verzeichnisses 

♦ Administrator ist nur für einen Teilbaum zuständig 


2-7

● Vorteil von Verzeichnissen: 

Such-Operation ist schnell 

Vor- und Nachteile 

von Verzeichnissen 

■ Häufigste Operation in IdM-Systemen 

■ Prädestiniert für Einsatz in IdM 

● Nachteil von Verzeichnissen: 

Schreiben, Ändern der Struktur 

■ Schreiben ist langsamer als bei relationalen Datenbanken 

■ Änderungen an Struktur sind aufwändig und können Auswirkungen 

auf andere Daten haben 

♦ Exakte Planung notwendig, wie eine Organisationsstruktur im 

Rahmen eines Directory Information Trees (DIT) abgebildet wird 


2-8

Elemente eines 

Verzeichnisses (1/2) 

● Verzeichnis-Objekt 

■ Datenelement mit einer bestimmten Menge von Attributen 

♦ Datenattribute können optional oder Pflicht sein 

■ Repräsentiert ein Objekt im Netzwerk (Benutzer, Rechner, …) 

● Verzeichnis-Schema 

■ Legt generelles Aussehen des Verzeichnisses fest 

♦ Welche Objekte mit welchen Attributen können erfasst werden? 

♦ Welche Struktur hat das Verzeichnis? 

● Schema legt Verzeichnis-Namespace fest 

■ Fest umgrenzter Bereich mit Objekten, die den gleichen Namens- 

konventionen folgen 


3-9

Elemente eines 

Verzeichnisses (2/2) 

● Verzeichnis-Baum 

■ Logische Struktur eines Verzeichnisses 

lässt sich als Baum darstellen 

■ Objekte sind in gemeinsamen Namespace 

■ Objekte sind zusammenhängend 

■ Baum repräsentiert eine logische 

Hierarchie zwischen den Elementen 

● Partitionen 

15.10.2011 

■ Aufteilen der Datenbasis auf mehrere 

verteilte Systeme (z.B. wg. Skalierung) 

■ Replikation der Datenbasis zwischen 

verschiedenen Server-Systemen 

♦ Kann Dienste von Datenbankservern 

hierfür nutzen 

Matthias Hovestadt - BKITS 

de eu be 

tu-berlin.de 

cit.tu-berlin.de 

3-10

Abgrenzung gegen 

Datenbanken 

● Auch in Datenbanken können Daten gehalten werden 

■ Jedoch: neuartige Anforderungen an Verzeichnisse 

● Transaktionsorientiert vs. operationsorientiert 

■ Datenbank: Änderung erst gültig, wenn alle Änderungen der 

Transaktion erfolgreich getätigt wurden 

■ Verzeichnis: Nur einzelne Datenänderung ist atomar, Änderungen 

werden jedoch sequentiell abgearbeitet 

● Zugriff auf Daten 

■ Datenbank: Optimiert für Lese- und Schreib-Operationen 

■ Verzeichnis: Daten sind statisch, Lese-Operation überwiegt (1:1000) 

♦ Daher: Ist Schreib-Operation häufiger, empfiehlt sich Datenbank 


3-11

Virtuelle Verzeichnisse 

● Zentrale Anlaufstelle für Requests im Unternehmen 

■ Weiterleitung der Anfragen an jeweiliges Quellsystem 

● Transparent für den Client 

■ Client stellt Anfrage an virtuelles Verzeichnis 

■ Virtuelles Verzeichnis leitet Anfrage weiter und antwortet dem Client 

■ Einbindung anderer Technologien möglich 

♦ Relationalen Datenbanken oder Web Services als Datenquelle 

● Quell-Verzeichnisse können autonom verwaltet bleiben 

■ Dezentrale Verwaltung ist politisch oft gewollt 

● Nachteil: Geschwindigkeit 

■ Jede Anfrage muss weitergeleitet werden 


2-12

3.1 Domain Name System (DNS) 

● Nummern sind schwieriger zu merken als Wörter 

■ Vanity-Number: „CALL-TOM“ besser als „2355-866“ 

■ Internet: „www.heise.de“ besser als 193.99.144.85 

♦ Hierarchische Information in bkits-demo.cit.tu-berlin.de 

● Unix: Ansprechen eines Rechners über seinen Namen 

■ Jedoch: Mapping auf IP-Adresse notwendig 

● Bis 1985: /etc/hosts 

■ Zentrale Stelle im Internet pflegte die hosts-Datei 

♦ Datei existiert bis heute, wird aber nur für lokale Knoten genutzt 

■ Jedes System zog täglich ein Update per FTP 

■ Probleme: Skalierbarkeit, Aktualität 


3-13

● Applikation kontaktiert den 

Name Server über einen sog. 

Resolver 

■ Läuft auf dem gleichen System 

● Resolver fragt Name Server 

■ Anfrage nach IP-Adresse für den 

von Applikation übermittelten Host- 

Namen 

● Name Server antwortet mit IP- 

Adresse, die der Resolver an 

die Applikation weiter reicht 

15.10.2011 

■ Auch Reverse-Lookup möglich, 

also Anfrage „IP nach Name“ 

Neuer Ansatz: 

Der Name Server 


www.heise.de 

App Resolver 

193.99.144.85 

Lokales System 

Entferntes System 

193.99.144.85 

Name 

Server 

www.heise.de 

3-14

Eigenschaften von DNS 

● Hierarchischer Aufbau, genannt Domain Namespace 

● Eine Partei kann Kontrolle über einen Teilbaum erhalten 

■ Autonomes Einfügen zusätzlicher Schichten innerhalb d. Teilbaums 

■ Z.B. bkits.cit.tu-berlin.de 

● Knotennamen sind von tatsächlichem Ort unabhängig 

■ Rechner bkits.cit.tu-berlin.de muss nicht in Berlin stehen 

● Üblich: DNS-Einträge folgen IP-Bereichen 

■ Alle IP-Adressen in 130.149/24 gehören tu-berlin.de 


3-15

● Aufbau von DNS ist streng 

hierarchisch 

■ Baumstruktur 

■ Jeder Knoten ist DNS-Name 

♦ FQDN: Fully Qualified 

Domain Name 

■ Durch Knoten aufgespannter 

Teilbaum heisst Domäne 

● Länder-Domänen als 

Kinder an Wurzel 

■ verwaltet durch ICANN 

● NICs verwalten TLDs 

● Delegation im Teilbaum 

15.10.2011 

Hierarchischer Aufbau 

TLD 

Verwaltet 

durch TUB 


root 

com org de eu 

bkits.cit.tu-berlin.de 

tu-berlin.de 


Verwaltet 

durch CIT 

3-16

Hierarchie von 

Name Servern 

● Auch die DNS Auflösung ist streng 

hierarchisch gegliedert 

● Jeder Server ist verantwortlich für 

zusammenhängenden DNS-Bereich 

■ Server ist „authoritative Server“ 

■ Teilbaum wird „DNS Zone“ genannt 

■ Zone ist Teil des Teilbaums 

■ Zone ist Einheit der Delegation von 

Verantwortlichkeiten im DNS 

● Authoritative Server beantwortet 

DNS-Anfragen zu Knoten in seiner 

Zone 

15.10.2011 


.de 

Server für 

.tu-berlin.de 

Server für 


3-17

Root-Nameserver im DNS 

● Root-Nameserver kontrollieren Top Level Domains 

■ Neue TDLs müssen von diesen geroutet werden 

● 123 Server, viele davon jedoch geographisch gespiegelt 


3-18

Hierarchische Namensauflösung 

● Applikation nutzt lokalen 

Resolver für DNS-Auflösung 

● Resolver wendet sich an den 

konfigurierten Nameserver 

■ Hier: TUB Nameserver 

● Nameserver prüft: „bin ich der 

authoritative NS für Anfrage?“ 

15.10.2011 

■ Ja: Direkte Beantwortung 

■ Nein: Weiterleitung zu anderem 

NS, anschließend Weiterleitung 

der erhaltenen Antwort 


www.heise.de 

Firefox Resolver 

193.99.144.85 

Lokales System 

193….85 

Name 

Server 

Nameserver TUB www.h..de 

Nameserver DE 

193….85 Name 

Server 

www.h..de 

3-19

● Resolver nutzt Nameserver 

■ Sendet Anfragen 

■ Erhält Antworten 

DNS Anfragetypen 

● Anfragetyp: hierarchisch 

■ Nameserver leitet Anfrage ggf. an andere Nameserver weiter 

● Anfragetyp: iterativ 

■ Nameserver antwortet Resolver ggf. mit Adresse eines anderen 

Nameservers 

■ Resolver kann sich dann selbst an diesen Nameserver wenden 


3-20

● Lokaler Resolver stellt eine 

hierarchische Anfrage an den 

Name Server 

● Name Server kann Anfrage 

selbst nicht beantworten, startet 

daher an der Wurzel die 

Auflösung der Adresse 

■ Rekursives vorgehen, bis der 

„Authoritative Nameserver“ der 

angefragten Adresse erreicht ist 

● Rückgabe von IP an Resolver 

15.10.2011 

Hierarchische Anfragen 


Name 

Server 

Resolver 

1. Anfrage 

Adresse von TLD für .de 

2. Anfrage 

Adresse von TUB 

3. Anfrage 

Adr. von CIT 

4. Anfrage 

IP von Host 

root 

.de 

.tu-ber- 

lin.de 

.cit.tu- 

berlin. 

de 

3-21

● Lokaler Resolver stellt eine 

iterative Anfrage an den Name 

Server 

● Name Server kann Anfrage 

nicht selbst beantworten und 

antwortet mit Adresse des root 

Name Servers 

● Iterative Anfrage aller Name 

Server, bis „Authoritative NS“ 

für Hostnamen erreicht ist 

15.10.2011 

Iterative Anfragen 

Anfrage nach bkits.cit.tu-berlin.de 


Name 

Server 

Adresse des root Name Servers 

Resolver 

1. Anfrage 

2. Anfrage 

3. Anfrage 

4. Anfrage 

IP von Host 

root 

Adresse von TLD 

für .de 

.de 

Adresse von TUB 

Adr. von CIT 

.tu-ber- 

lin.de 

.cit.tu- 

berlin. 

de 

3-22

Caching von 

DNS Anfragen 

● Hierarchische Anfragen sind Standard 

■ Server leitet ggf. Anfrage weiter 

■ Server antwortet mit IP 

● Hohe Anfragelast, speziell am root Knoten 

■ Muss Adressen der TLD Name Server bekannt geben 

● Caching im Name Server hilft Last zu senken 

■ Name Server merkt sich Antworten zu Anfragen 

■ Bei neuer Anfrage wird ohne Rückfrage direkt geantwortet 

♦ Antwort ist als „non authoritative“ gekennzeichnet 

■ Timeout für Gültigkeit gecachter Antworten, dann neue Anfrage 

■ Problem: Caching verzögert die Propagierung neuer Werte 

♦ Beispiel: IP-Adresse eines Hosts kann sich ändern 


3-23

DNS Resource Records 

● Häufigste Nutzung von DNS: 

Auflösung von Hostname in IP-Adresse 

● Aber auch andere Nutzungen 

■ Welchen Nameserver muss ich kontaktieren? 

■ An welchen Mailserver kann ich per SMTP EMail ausliefern? 

● Zahlreiche DNS „Resource Record“ Typen 

■ A = Host Address 

■ NS = Authoritative Name Server 

■ MX = Mail Exchanger Record 

■ RP = Responsible person 

■ … 


3-24

Abfrage von DNS (1/3) 

● Üblich: Auflösung von Hostnamen durch Applikation 

● Auch manuelle Name Server Anfragen möglich 

■ Beispielsweise mit dem Tool nslookup 

● Beispiel: Ausgabe des MX-Records des NDR: 

maho@cheers:~$ nslookup -type=mx ndr.de 

Server: 145.253.2.11 

Address: 145.253.2.11#53 

Non-authoritative answer: 

ndr.de mail exchanger = 200 fallback.mail.de.uu.net. 

ndr.de mail exchanger = 50 mail.ndr.de. 

ndr.de mail exchanger = 100 mail1.ndr.de. 

● Bemerke: Antwort ist „non-authoritative“ 


3-25


● Ermittlung des authoritative Name Servers des NDR 

maho@cheers:~$ nslookup -type=ns ndr.de 

Server: 145.253.2.11 

Address: 145.253.2.11#53 

Non-authoritative answer: 

ndr.de nameserver = auth04.ns.de.uu.net. 

ndr.de nameserver = auth54.ns.de.uu.net. 


3-26


● Erneute Anfrage nach MX-Record 

■ Diese Anfrage wird direkt an Name Server des NDR gerichtet 

maho@cheers:~$ nslookup -type=mx ndr.de auth04.ns.de.uu.net 

Server: auth04.ns.de.uu.net 

Address: 192.76.144.17#53 

ndr.de mail exchanger = 200 fallback.mail.de.uu.net. 

ndr.de mail exchanger = 50 mail.ndr.de. 

ndr.de mail exchanger = 100 mail1.ndr.de. 

maho@cheers:~$ 

● Bemerke: Antwort ist diesmal authoritative 


3-27

Gewichtete Antworten 

● Manche Records liefern mehrere gewichtete Antworten zu 

einer Anfrage 

■ Im Beispiel: 3 MX-Einträge für die Domäne ndr.de 

● Zweck: Ausfallschutz 

■ Zuerst: Kontaktiere Host mit kleinstem Gewicht 

■ Wenn Host nicht erreichbar: Kontaktiere nächsten Host 

■ usw. 

● Sinnvoll für MX-Records 

■ Mail kann zugestellt werden, auch wenn primärer Mailserver der 

Domäne vorübergehend nicht online ist 


3-28

Sicherheitsaspekte 

● DNS ist sehr anfällig für Angriffe 

■ Kommunikation basiert auf UDP (verbindungslos) 

♦ Keine Überprüfung des Absenders 

♦ Absenderadresse der Antwort kann beliebig sein 

■ Keinerlei Signierung oder Verschlüsselung 

■ Einfach durchführbare Man-in-the-middle Attacken 

♦ Umleitung des Browsers auf präparierten Server 

♦ Relaying aller Mails über eigenen Mailserver 

● Beispiel: Aufruf von www.berliner-sparkasse.de 

■ Falsche DNS Antwort leitet auf falschen Webserver 

■ Bankkunde bemerkt lediglich Zertifikatsfehler oder fehlende 

Verschlüsselung der Verbindung 

♦ Normalnutzer bemerkt/versteht diese Probleme kaum 


3-29

DNSsec 

● Handlungsbedarf wurde schon 1997 erkannt 

■ Definition: Domain Name System Security Extensions (DNSsec) 

■ Standardisiert in RFC 4034 

■ Problem: Protokoll mit viel Kommunikation 

♦ Nur anwendbar in kleinen Netzen 

● Überarbeitete Version: DNSsec-bis 

■ Standardisiert: 2005 

■ Idee: Signatur der Antwortpakete 

♦ Anbieter signiert DNS-Aussagen zu seiner Zone 

■ Antwort erhält DNS-Information, Signatur und Zertifikat 

♦ Übertragung der Informationen als zusätzl. Resource Records 

♦ Empfänger kann Gültigkeit der Antwort überprüfen 

■ Wichtig: Vollständig abwärtskompatibel zu herkömmlichem DNS 

15.10.2011 Matthias Hovestadt - BKITS 3-30

Überprüfung der Signatur 

1. Überprüfung des KEY Records 

■ KEY Record des Unterzeichners des SIG Records anfragen 

2. Überprüfung des SIG Records 

■ SIG Record anfragen, der zum KEY-Record aus Schritt 1 gehört 

3. Berechnung des MD5 Hashes aus Schritt 1 

4. Ermittlung der Signatur aus Schritt 2 

5. Wenn beide Werte überein stimmen, wird Antwort akzept. 

● Wichtig: Es werden keine Teilnehmer authentifiziert, 

sondern nur die Gültigkeit von Antworten überprüft 

■ Authentifizierung erfolgt über Chain of Trust 


3-31

● Möglichkeit 1: Symmetrisch 

■ Offensichtlich unpraktikabel 

● Möglichkeit 2: Asymmetrisch 

Verschlüsselung/Signierung 

in DNSsec 

■ Aufbau einer Chain of Trust 

♦ Zentrale Instanz: ICANN 

♦ Zertifizierung nationaler Stellen (DeNIC) 

♦ Zertifizierung der jeweiligen Domänen-Inhaber 

■ Öffentlicher Key kann in DNS-Anfragen mitgeteilt werden 

■ Privater Schlüssel muss sicher verwahrt werden 

♦ ICANN: Nur 7 Personen mit Zugang zu Signier-Hardware, 

5 Personen müssen bei Erzeugung des Keys anwesend sein 

♦ SE-NIC: Geschützter Rechner holt alle 2 Stunden zentrale 

Hostliste, signiert diese und spielt sie danach zurück 


Sicherheit vs. Aufwand 

● Sicherheit hängt von Länge des Schlüssels ab 

■ Langer Schlüssel (z.B. 2048bit) 

♦ + : Sicher 

♦ - : Zu hoher Rechenaufwand für DNS-Server ► unpraktikabel 

■ Kurzer Schlüssel (z.B. 512bit) 

♦ + : Geringer Rechenaufwand 

♦ - : Unsicher gegen Angriffe ► Kein Vorteil mehr durch DNSsec 

● Idee: kurze Schlüssel und kurze Gültigkeit der Zertifikate 

■ + : Erfolgreicher Angriff hätte geringere Auswirkungen 

♦ Geknackter Schlüssel verliert nach kurzer Zeit seine Gültigkeit 

■ - : Verlagerung des hohen Aufwands vom DNS-Server 

in die Zertifizierungsstelle ► unpraktikabel 


Teilung der Schlüssel: 

KSK - ZSK 

● Lösung: Nutzung unterschiedlicher Arten Schlüssel 

● Typ 1: Key Signing Key (KSK) 

■ Langer (und sicherer) Schlüssel mit langer Lebenszeit 

● Typ 2: Zone Signing Key (ZSK) 

■ Kurze (und potentiell unsichere) Schlüssel mit kurzer Lebenszeit 

● Einbettung in die Chain of Trust 

■ Zentrale Stelle signiert KSK des Providers 

♦ Authentizität des KSK kann geprüft werden 

■ Provider signiert ZSK mit eigenem KSK 

♦ Auch die Authentizität des ZSK kann geprüft werden 


Wechsel des 

Zone Signing Keys 

● Üblich: Mehr als ein ZSK pro Provider 

■ Überlappende Zeiträume für Gültigkeit 

♦ Wichtig für Timeout-Problematik gecachter Anfragen 

bei einem Wechsel des ZSK 

ZSK 1 

ZSK 2 

ZSK 3 

● Doppelte Signatur während Übergangszeit 

■ Nameserver cachen Antwort mit neuem und altem ZSK 

Zeit 

■ Solang alter ZSK gültig, werden beide Antworten aus Cache akzept. 

■ Nach Ablauf der Gültigkeit von ZSKn wird Antwort ZSK(n+1) akzept. 


3.2 Network Information System 

(NIS) 

● Sun Microsystems: Network File System 

■ Bereitstellung von Dateien in einem Netzwerk 

■ Problem: User-IDs, Gruppen-IDs, Passwörter, … 

● Informationsdienst von Sun: „Yellow Pages“ (YP) 

■ Bereitstellung von Netzwerk-Informationen, Verteilung im Netz 

■ Synchronisation in einer großen Menge von Rechnern möglich 

● Umbenennung in „Network Information Service“ (NIS) 

■ British Telecom ist in UK Eigentümer des Begriffs „Yellow Pages“ 


3-36

Komponenten von NIS 

● Master-Server 

■ Hält die Master-Kopie der NIS-Datenbank 

■ Änderung der NIS-Daten nur hier möglich 

■ Nur ein Master-Server pro Domäne 

● Slave-Server 

■ Hält eine Kopie der NIS-Datenbank 

♦ Master übermittelt die Daten 

■ Kopie ist R/O, keine Änderungen möglich 

■ Mehrere Slave-Server pro Domäne möglich 

♦ Optimal: Verteilung über das Netzwerk 

● Client 

15.10.2011 

■ Fragt im Netz nach NIS Informationen 

■ Keine Speicherung von NIS-Daten 


Slave 

Server 

Client 

Master 

Server 

Client 

Client 

Slave 

Server 

Client 

3-37

NIS Maps 

● Idee von NIS: Synchronisation von Daten im Netz 

■ Viele Daten stehen in Unix-Systemen unter „/etc“ 

♦ Beispiel: passwd, groups, services, rpc, … 

● Eine NIS Map repräsentiert eine dieser Dateien 

■ NIS Map ist eine Sammlung von Schlüsseln und Werten 

● Zugriff auf NIS Map 

■ Jede NIS Map hat einen eigenen Namen 

■ Client nutzt bei Anfragen an NIS Map diesen Namen 

♦ Name der NIS Map muss im Netzwerk bekannt sein 


3-38

NIS Domäne 

● Höchstes Element in NIS: Die Domäne 

■ Jede NIS Domäne hat einen eindeutigen Namen 

♦ Name wird für Anfragen an NIS Database benötigt 

■ NIS Domäne umfasst einen Satz von NIS Maps 

■ Eine NIS Domäne ist ein Namespace 

♦ Separation von Namespaces über verschiedene Domänen 

● Komponenten einer NIS Domäne 

■ Ein Master-Server 

■ Ein oder mehrere Slave-Server 

■ Beliebig viele Clients 


3-39

● NIS hat zahlreiche Nachteile 

■ Datentransfer läuft unverschlüsselt 

NIS+ 

■ Synchronisation der NIS-DB auf Slave-Server 

♦ Was passiert, wenn Slave-Server bei Update nicht vom Master- 

Server erreicht werden kann? 

■ Keine Hierarchien innerhalb der Domäne möglich 

■ Skalierbarkeit 

♦ Probleme bei der Administration sehr großer Domänen 

■ Austausch von Daten zwischen Domänen 

● Folge: Entwicklung von NIS+ als Nachfolger von NIS 

■ Komplette Neuentwicklung, kein einfaches Update 


3-40

3.3 LDAP 

● Ursprung von Directories: X.500 Standard 

■ Entwickelt 1988 von int. Fernmeldeunion CCITT 

■ Großer Funktionsumfang, mehrere Kommunikationsprotokolle 

■ Problem: X.500 war sehr schwierig umzusetzen 

♦ Hohe Anforderungen an die Client-Implementierung 

■ Üblich: Für jeden X.500 Server gab es einen passenden Client 

♦ Widerspruch zur Idee eines Standards 

● Konsequenz: Lightweight Directory Access Protocol (LDAP) 

■ Entwickelt 1995 (RFC1777) 

■ Einfaches Kommunikationsmuster zwischen Client und Server 

♦ Leicht zu implementieren, Interoperabilitiät 

■ Schon wenige Kommandos reichen zur Erfüllung der Aufgaben eines 

Directories aus 


2-41

Operationen von LDAP (1/2) 

● Bind 

■ Initiierung einer Client/Server Verbindung 

■ Authentisierung 

● Search 

■ Start einer Suche durch den Client 

● Modify 

■ Änderung eines Objekts im Directory durch den Client 

● Add/Delete 

■ Löschen bzw. Hinzufügen von Einträgen durch den Client 


2-42

Operationen von LDAP (2/2) 

● Modify RDN 

■ Änderung des letzten Teils des Namens eines Eintrags 

durch den Client 

● Compare 

■ Vergleich eines Wertes gegen das Directory 

● Adandon 

■ Bricht eine Operation des Directories ab, die auf Grund einer 

Anfrage des Clients durchgeführt wurde 

● Unbind 

■ Abbau der Verbindung zwischen Client und Server 


2-43

DSML: 

Directory Service Markup Language 

● DSML v1 (1999) 

■ Einziges Ziel: Darstellung von Directory Information als XML 

● DSML v2 (seit 2001) 

■ Ziel: Nicht nur Darstellung, sondern auch Interaktion mit Directory 

♦ Ermöglicht die Arbeit mit Directory ohne LDAP-Client 

● DSML v2 kennt zwei Dokumenttypen 

■ Anfrage-Dokumente (request) 

■ Antwort-Dokumente (response) 

■ Jeder Anfrage steht eine Antwort gegenüber 

■ Optional: Gruppierung von Request/Response in einem Batch Req. 

■ Transport der Dokumente über SMTP oder SOAP 


2-44

Beispiel: modifyRequest 

Änderung der Mobilfunk-Nummer 

 

 

 

0171 7397499 

0171 9182000 

 

… 


2-45

Beispiel: addRequest 

Anlegen eines neuen Mitarbeiters 

 

top 

person 

organizationPerson 

Meier 

Ulf 

Leiter IT 

 

 


2-46

Beispiel: batchResponse 

Antwort auf vorherigen Request 

< batchResponse xmlns=„urn:oasis:names:tc:DSML:2:0:core“> 

 

 

Person nicht gefunden 

 

 

 

Completed 

 

 


2-47

LDAP und Resolver 

● Resolver schon von DNS bekannt 

■ Aufgabe dort: Auflösung von Hostnamen in IP-Adressen 

■ Hier: Auflösen von Usernamen/Gruppen in User-IDs/Group-IDs 

● Authentisierung des Benutzers 

■ Erfolgt aus leicht nachvollziehbaren Gründen nicht über Resolver 

15.10.2011 

Files 

NIS 

DB 

LDAP 

Resolver ApplicaMon 

■ Authentisierung über Plugable Authentication Module (PAM) 

♦ SSHD verbindet sich über PAM mit LDAP 

♦ Unterstützung auch durch Apache: libapache-auth-ldap 


3-48

~ $ cat /etc/nsswitch.conf 

passwd: files ldap 

#passwd: db nis nisplus 

shadow: files ldap 

group: files ldap 

hosts: files dns 

networks: files dns 

services: db files 

protocols: db files 

rpc: db files 

ethers: db files 

netmasks: files 

netgroup: files 

bootparams: files 

automount: files 

aliases: files 

Konfiguration des Resolvers 


3-49

3.4 Exkurs Sicherheit: 

Authentifizierungsprotokoll von 

Needham und Schroeder 

● Grundlage für viele Sicherheitstechniken, u.a. Kerberos 

■ Authentifizierung zwischen Clients und Servern in Intranets von einer 

einzigen Verwaltungsdomäne 

■ Authentifizierung und Schlüsselverteilung basierend auf einem 

Authentifizerungsserver 

● Aufgaben des Authentifizerungsservers (AS) 

■ Bereitstellung einer sicheren Methode zur Erzeugung von 

gemeinsamen Schlüsseln 

■ Verteilung von geheimen Schlüsseln an Clients 

● AS verwaltet eine Tabelle mit Namen und geheimen Schlüsseln für 

jeden in der Verwaltungsdomäne bekannten Prinzipal 

■ Der Schlüssel dient der Identifikation des Clients beim AS und der 

sicheren Kommunikation zwischen AS und Client 

■ Der Schlüssel wird nie Dritten offen gelegt und wird höchstens einmal 

– bei der Erzeugung – übers Netz übertragen 


3-50

N-S-Authentifizierungsprotokoll mit 

geheimen Schlüsseln: Szenario 

● Protokoll basiert auf Erstellen und Übertragen von Tickets durch AS 

● Ticket: Verschlüsselte Nachricht mit geheimem Schlüssel für AB 

Header Message Notes 

1. A à� AS: A, B, N A A requests AS to supply a key for communication 

with B. 

2. ASà�A: {N A , B, K AB , 

3. Aà�B: 

4. Bà�A: 

5. Aà�B: 

{K AB , A}KB }KA 

{K AB , A}KB 

{N B }KAB 

{N B - 1}KAB 

AS returns a message encrypted in A’s secret key, 

containing a newly generated key K AB and a 

‘ticket’ encrypted in B’s secret key. The nonce N A 

demonstrates that the message was sent in response 

to the preceding one. A believes that AS sent the 

message because only AS knows A’s secret key. 

A sends the ‘ticket’ to B. 

B decrypts the ticket and uses the new key K AB to 

encrypt another nonce N B . 

A demonstrates to B that it was the sender of the 

previous message by returning an agreed 

transformation of N B . 


3-51

N-S-Authentifizierungsprotokoll mit 

geheimen Schlüsseln (2) 

● N A , N B Einmalstempel zum Beweis der Aktualität einer Nachricht 

● Schwäche des Protokolls 

■ B hat keinen Grund zu glauben, dass die Nachricht Nummer 3 aktuell 

ist. Falls es ein Angreifer schafft, den Schlüssel K AB zu erhalten und 

eine Kopie des Tickets {K AB , A}KB anzulegen, kann sich später als A 

ausgeben 

■ Lösung durch Hinzufügen von Einmalstempeln oder Zeitstempeln 

{K AB , A, t}KB mit einer Ablauffrist 

⇒ B entschlüsselt die Nachricht und überprüft, ob t aktuell ist 

⇒ Realisierung in Kerberos 

● Wurde das Protokoll erfolgreich ausgeführt, so können sowohl A als 

auch B sicher sein, dass alle in K AB verschlüsselten und empfangenen 

Nachrichten von dem jeweiligen Partner stammten und nur von A,B 

und AS (vertrauenswürdig) verstanden werden 


3-52

3.5 Exkurs Sicherheit: 

Kerberos 

● Entwicklung der MIT für Authentifizierung und Sicherheit in Intranets, 

Version 5 gehört zum Internetstandard 

■ Voraussetzungen bei Entwicklung 

♦ Universitätsnetzwerk mit 5000 Benutzern 

♦ Unsicheres Netzwerk, in dem jeder lauschen kann 

♦ Gut gewählte Passwörter vorhanden 

● Aufgabe von Kerberos: Authentifizierung von Prinzipalen 

■ Prinzipal = allgemeine Bezeichnung für Benutzer, Services, … 

■ Server verlangen bei jedem Zugriff (Dateizugriff bei NFS/AFS, 

Mailversand, Anmeldungen, Druckerdienste, …) ein Ticket vom Client 

■ Passwörter sind Benutzern und dem Kerberos-Authentifizierungsdienst 

bekannt 

■ Dienste haben geheime Schlüssel, die nur Kerberos und den Dienst 

bereitstellenden Servern bekannt sind 


3-53

Anmeldung mit Kerberos 

● Meldet sich ein Benutzer an einer Workstation an, sendet das 

Anmeldeprogramm den Benutzernamen an den Kerberos- 

Authentifizierungsdienst 

● Ist der Benutzer dem Authentifizierungsdienst bekannt, kommt eine 

Antwort mit 

■ Sitzungsschlüssel mit Einmalstempel, verschlüsselt mit dem Passwort 

des Benutzers 

■ Ticket für Ticketverteilungsdienst (Ticket-Granting Service, TGS) 

● Anmeldeprogramm versucht mittels des aktuell eingegebenen 

Passworts, den Inhalt der Antwort zu entschlüsseln 

● Bei Erfolg ⇒ Überprüfung des Einmalstempels und ggf. Speicherung 

des Sitzungsschlüssels mit dem Ticket für weitere Kommunikation mit 

dem Ticketverteilungsdienst TGS 

● Jetzt wird die temporäre Kopie des Passworts gelöscht und der 

Anmeldevorgang beendet ⇒ Passwörter werden niemals übers Netz 

übertragen 


3-54

Zugriff auf andere Server 

● Bei jedem Zugriff/Dienstanforderung verlangt der betroffene Server 

ein Ticket vom Client 

■ Das Clientprogramm fordert ein Ticket für den entsprechenden Server 

beim Ticketverteilungsdienst TGS an 

■ Das erworbene Ticket wird zusammen mit einer neuen 

Authentifizierung verschlüsselt mit dem geheimen Schlüssel dieses 

Dienstes an den Serverdienst gesendet 

■ Serverdienst entschlüsselt das Ticket, überprüft die Haltbarkeitsdauer 

(Ticket abgelaufen?) und extrahiert einen Sitzungsschlüssel 

■ Der Sitzungsschlüssel wird zur Entschlüsselung der Authentifizierung 

eingesetzt ⇒ Server überprüft, ob der Schlüssel bislang unbenutzt ist 

■ Login/Passwort des Benutzers zur Anmeldung nicht mehr notwendig 


3-55

Kerberos Sicherheitsobjekte 

● Kerberos arbeitet mit 3 Arten von Sicherheitsobjekten 

1. Ticket: Token, das vom Dienst TGS an Clients ausgegeben wird 

♦ Präsentation an Server als Beweis, dass Client durch Kerberos 

authentifiziert wurde 

♦ Beinhaltet Sitzungsschlüssel und Ablaufdatum 

2. Authentifizierung: Einmaltoken, das vom Client erzeugt wird 

♦ Beweist Identität des Benutzers und Aktualität der Kommunikation 

♦ Verschlüsselter (Mit Sitzungsschlüssel) Clientname und Zeitstempel 

3. Sitzungsschlüssel: Geheimer Schlüssel, der von Kerberos nach dem 

Zufallsprinzip erzeugt wird 

♦ Wird zur Kommunikation mit einem bestimmten Server benutzt 

● Clients müssen für jeden Server ein Ticket und einen 

Sitzungsschlüssel besitzen, welche die Lebensdauer von einigen 

Stunden haben 


3-56

Step A 

1. Request for 

TGS ticket 

2. TGS 

ticket 

Kerberos-Architektur 

Kerberos Key Distribution Centre (KDC) 

Authen- 

tication 

service A 

Authentication 

database 

Ticket- 

granting 

service T 

Step B 

3. Request for 

server ticket 

Login 

4. Server ticket Step C 

session setup 

5. Service 

Server 

request 

Client session setup 

Service 

Server 

C Request encrypted with session key 

function 

S 

DoOperation 

Reply encrypted with session key 


3-57

● Verzeichnisdienst von Microsoft 

■ Erste Version im Jahr 2000 

■ Standard seit Exchange 2000 

● Vier Hauptkomponenten 

■ LDAP-Server 

■ DNS-Server 

■ Kerberos 

3.5 Active Directory (AD) 

■ Common Internet File System (CIFS) Protokoll 

♦ Erweiterung des Server Message Block (SMB) Protokolls 

○ Datei-/Druckerfreigabe, Windows-RPC, NT-Domänendienst 

● Eigenschaften von AD ergeben sich wesentlich aus den 

Eigenschaften der vier Hauptkomponenten 


3-58

Entwicklungsstufe 1: 

Host-Systeme 

● Zentraler leistungsstarker Server als zentrales Element 

■ Direkter Anschluss von Datenbanken und teurer Hardware 

■ Zugriff von leistungsschwachen Terminals 

♦ Terminals im Wesentlichen nur Geräte zur Anzeige 

● Mainframe als zentrale Instanz der Infrastruktur 

■ Terminals haben selbst keine Intelligenz 

15.10.2011 

Terminals 

■ Zentraler Server übernimmt Authentisierung der Benutzer 


DB 

3-59


Arbeitsgruppen 

● Arbeitsgruppe: Gruppe von Rechnern unter einem Namen 

■ Start 1992 mit „Windows 3.1.1 for Workgroups“ 

■ Grundsatz: 

Alle Rechner dürfen alle Ressourcen gleichberechtigt nutzen 

♦ Keine weitere Abstufung von Rechten vorgesehen 

♦ Keine Zugriffsdatenbank 


3-60


Arbeitsgruppen NT 

● Arbeitsgruppen mit steuerbaren Freigaben 

■ Start 1993 mit „Windows NT 3.1“ 

15.10.2011 

■ Jeder Rechner führt eigene Benutzerdatenbank 

♦ Benutzer melden sich an Arbeitsgruppe an 

♦ Password wird über das Netz zum Zielsystem übertragen 

♦ Zielsystem prüft Gültigkeit und erlaubt Zugriff 

■ Kein Domain- 

Controller! 

Problem: 

Synchronisation 

Host-Keys 

Sec. 

DB 

Sec. 

DB 


Problem: 

Synchronisation 

Username/Pass 

Sec. 

DB 

Sec. 

DB 

3-61


Domänen 

● Kernidee: Zentrale Verwaltung 

■ Administrativer Stab wacht über Einstellungen 

■ Zentrale Verwaltung aller Benutzer, Rechner, Dienste, … 

■ Ganzheitliches Management mit nur einem Tool 

● Zentrale Komponente: Active Directory 

15.10.2011 

Administrator 

Serverdienste 

(Drucken, Files, 

Email, …) 

Domäne 

AD 

Benutzer bzw. 

Computer- 

Konten 


Gruppen- 

richtlinien 

Netzwerk 

3-62

Begriff: Domäne 

● Schon aus anderen Bereichen bekannt: 

■ DNS: Teil des Namensraums, unter einheitlicher Verwaltung 

■ LDAP: Namensraum mit einheitlichen Konventionen 

● Andere Bedeutung im Kontext von Microsoft 

■ Domäne = logische Gruppierung von Ressourcen, die zentrale 

Verzeichnisdatenbank nutzen 

■ Hier ist Verzeichnisdienst ist nur ein Teil der Domäne 

♦ Genutzt zur Speicherung von Informationen 

● Domäne nicht lokal begrenzt 

■ Verbindung der Ressourcen einer Domäne über beliebige Netze 

■ Verschlüsselung von Datenverbindungen 


3-63

Vor- und Nachteile 

von Domänen 

● Vorteile 

■ Einheitliche und nachvollziehbare Verwaltung 

♦ Umgehung von Inkonsistenzen einer lokalen Konfiguration 

■ Realisierung eines netzwerkweiten „Single Sign On“ 

■ Erhöhter Sicherheitslevel in einer Domäne 

♦ Einheitliche Vertrauenseinstellungen 

♦ Zentrale Koordination und Überwachung der Systeme 

● Nachteile 

■ Deutliche Erhöhung der Komplexität im Netzwerk 

♦ Anstieg des Administrationsaufwands 

♦ Intensive Schulung des administrativen Personals notwendig 

■ Eingeschränkte Interoperabilität mit Linux, MacOS X, … 


3-64

Ebenen des Active Directory (1/4): 

Objekt 

● Kleinste Organisationseinheit 

■ Ein Mitarbeiter, ein Computer, ein Drucker, … 

■ Keine weitere Aufteilung des Objekts möglich 

● Objekte verfügen über Eigenschaften 

■ Eigenschaften werden als Attribute definiert 

♦ Name, Telefonnummer, Berechtigungen, … 

■ Spezifiziert durch den Objekt-Typ des Objekts 

● Kategorien 

■ Ressource: Drucker, Server, Computer, … 

■ Dienst: Email, … 

■ Konto: Benutzerkonto, Gruppenkonto, Computerkonto, … 


3-65


Organisationseinheit (OU) 

● Erlaubt die hierarchische Strukturierung 

■ OU ist sowohl Container für Objekte als auch für andere OUs 

♦ Strukturierung in Ober-OUs und Unter-OUs 

■ Container vererbt seine Eigenschaften 

● Möglichkeiten der Strukturierung 

■ Logisch: Nach Struktur der Organisation 

■ Physikalisch: Nach Netzen, Systemen, Orten, … 

● Einheitliche Zuweisung von Gruppen-Richtlinien 

■ Alle Objekte einer OU fallen unter die gleichen Regelsätze 

● Üblich: OU als kleinste Ebene der Administration 

■ Beispiel: IT-Verantwortlicher für Abteilung 


3-66


Domäne und Bäume/Strukturen 

● Nächste Ebene in der Strukturierung: Domäne 

■ Name der Domäne folgt den Regeln des DNS 

■ Domänen umfassen größere Teile der Organisation 

● Domänen im Active Directory 

■ Ein Active Directory umfasst beliebig viele Domänen 

■ Domänencontroller regelt Zugriff auf Ressourcen in Domäne 

● Strukturen/Bäume (Trees) umfassen Domänen 

■ Beliebig viele Domänen je Tree 

■ Domänen stehen in transitiven Vertrauensverhältnis 


3-67


Gesamtstruktur/Wald 

● Höchste Gliederungsebene: Gesamtstruktur/Wald (Forest) 

■ Umfasst sämtliche Elemente eines Active Directories 

15.10.2011 

■ Ein Wald verwaltet einen oder mehrere Bäume 

♦ Transitives Vertrauensverhältnis zwischen den Bäumen 


Service 

Europa 

Office 

Berlin 

Service 

weltweit 

Service 

Asien 

Office 

Paris 

Service 

Amerika 

3-68

Domänen-Controller (1/2) 

NT4-Mode: PDC/BDC 

● Einführung des Konzepts Domänen-Controller in Win NT 

■ Primary Domain Controller (PDC): Hält Master-Kopie der Datenbank 

■ Backup Domain Controller (BDC): Hält lediglich Read-Only Kopie 

♦ Schreibvorgang auf Datenbank erfordert Zugriff auf PDC 

♦ Bei Ausfall von PDC: Auswahl eines BDC zum neuen PDC 

● Verfahren: Master-Replikation 

■ Datenbank wird immer vom PDC auf die BDCs repliziert 

● Hauptproblem: Skalierbarkeit 


3-69

Domänen-Controller (2/2) 

Native Mode: DC 

● Umstieg auf Peer-Modell in Windows 2000 

■ Alle DCs eines Forest sind gleichberechtigt 

■ Datenbank kann auf jedem DC verändert werden 

♦ Änderungen werden über Replikation verteilt 

● Verfahren: Multi-Master-Replikation 

■ Gleichberechtigte Replikation zwischen DCs 

■ DCs geben Änderungen untereinander weiter, maximal drei Hops 

♦ Standard-Intervall in Windows 2003: 15 Sek 

♦ Verteilung der Information in der Domäne: 45 Sek 

■ Verfahren zur Behandlung von Replikationskonflikten 

● Native-Mode Domain vs. Mixed-Mode Domain 

■ Mixed-Mode Domain enthält alte NT4-PDCs, nur Master-Repl. Mögl. 


3-70

Vertrauensverhältnisse 

im Native-Mode 

● One-Way Trust vs. Two-Way Trust 

■ Domain räumt Mitgliedern der anderen Domain Zugriff ein 

■ Domain selbst erhält keinen (bzw. ebenfalls) Zugriff 

● Trusting Domain vs. Trusted Domain 

■ Domäne, die Zugriff einräumt, bzw. eingeräumt bekommt 

● Transitive Trust vs. Intransitive Trust 

■ Vertrauensverhältnis überträgt sich (nicht) zwischen Domänen 

♦ Transitiv: A vertraut B, B vertraut C, also vertraut A auch C 

● Explicit Trust: Explizit vom Administrator eingerichtet 


3-71

Ausgewählte Dienste 

im Active Directory 

● Replikationsdienste 

■ Verteilung von Verzeichnisdaten zwischen Domain-Controllern 

● Remote-Installation 

■ Deployment mittels Clone-Verfahren 

■ Doployment mittels automatischer Installation 

♦ Gesteuert durch Scripte 

● Verteiltes Dateisystem 

■ Zusammensetzung verschiedener Freigabe zu einem (virt.) Ordner 

● Zertifikatsdienste und DNS 

■ Datenspeicherung im Active Directory 


3-72

Integration von Unix-Systemen 

in ein Active Directory 

● Zugriff auf Verzeichnis-Dienst 

■ Active Directory bietet LDAP-Schnittstelle 

■ Jedoch: lediglich Datenabruf, keine Interpretation von Gruppen- 

Richtlinien, etc. 

● Nutzung von LDAP im Resolving 

■ Genormte Speicherung von Verzeichnisdaten 

■ Unterstützung durch Active Directory vorhanden (RFC2307) 

■ Einsatz von PAM Modulen mit Zugriff auf LDAP 

● Kommerzielle Produkte für Integration von Unix in AD 

■ Weitgehende Unterstützung der AD Mechanismen in Unix-Umfeld 

● Samba 4: Unterstützung von Native-Mode ADs 


3-73

● Verzeichnisdienste 

Literatur 

■ Doug and Beth Sheresh: Understanding Directory Services, 

New Riders Publications, 2000 

● LDAP 

● DNS 

■ Dieter Klünter, Jochen Laser: LDAP verstehen, OpenLDAP 

einsetzen, dPunkt-Verlag, 2007 

■ Paul Albitz, Cricket Liu: DNS und Bind, O‘Reilly, 2002 

● Active Directory 

■ Alistar Lowe-Norris: Windows 2000 Active Directory, 

O‘Reilly Verlag, 2001 


3-74

Kapitel 3 (PDF, 1,8 MB) - Fachgebiet Komplexe und Verteilte IT ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?