Wenn sich ein Benutzer an einer Windows NT4/200x/XP Professional-Workstation anmeldet, verbindet sich die Workstation mit einem Domänencontroller (Authentifikationsserver), um zu prüfen, ob der Benutzername und das Passwort, die vom Benutzer eingegeben wurden, gültig sind. Wenn die eingegebenen Informationen nicht mit der Konto-Information übereinstimmen, die in der Domänen-Verwaltungsdatenbank (die SAM oder Security-Account-Manager-Datenbank) abgelegt ist, wird ein Satz von Fehler-Codes an die Workstation zurückgeschickt, die die Anmelde-Anfrage gestellt hat.

Wenn das Benutzername/Passwort-Paar überprüft worden ist, antwortet der Domänencontroller (Authentifikationsserver) mit einer vollständigen Aufzählung der Konto-Informationen, die zu diesem Benutzer in der Benutzer- und Maschinen-Konten-DB für diese Domäne gespeichert sind. Diese Informationen enthalten ein komplettes Netzwerk-Zugriffsprofil für den Benutzer, aber schließt jegliche Informationen aus, die für das Desktop-Profil des Benutzers spezifisch sind, oder schließt zu diesem Zweck alle Desktop-Profile für jene Gruppen aus, denen der Benutzer angehört. Die Informationen enthalten Passwort-Zeit-Limits, Überprüfungen auf die Einzigartigkeit des Passworts, Zeitlimits für den Netzwerkzugriff, Information über die Gültigkeit von Konten, Namen der Maschinen, von denen aus der Benutzer auf das Netzwerk zugreifen kann, und vieles mehr. All diese Informationen wurden von allen Versionen von MS Windows NT (3.10, 3.50, 3.51, 4.0) in der SAM gespeichert.

Die Konten-Informationen (Benutzer und Maschine) werden auf Domänencontrollern in zwei Dateien gespeichert; eine enthält die Sicherheitsinformationen, die andere die SAM. Diese werden in gleichnamigen Dateien im Verzeichnis C:\Windows NT\System32\config gespeichert. Dies sind die Dateien, die in die Replikation der SAM involviert sind, wenn Backup-Domänencontroller im Netzwerk vorhanden sind.

Es gibt zwei Situationen, in denen man Backup-Domänencontroller installieren sollte:

Die Interaktion des PDC mit seinen BDCs in einem Windows NT4-Environment ist es wert, hier erwähnt zu werden. Der PDC enthält die Master-Kopie der SAM. Falls ein Administrator eine Änderung an der Benutzer-Konten-Datenbank vornimmt, während er physisch im LAN des PDCs ist, wird die Veränderung wahrscheinlich direkt am PDC durchgeführt, anstatt in der Master-Kopie der SAM. Sollte diese Veränderung in einer Zweigstelle durchgeführt werden, wird die Änderung wahrscheinlich in einem Delta-File auf dem lokalen BDC gespeichert. Der BDC wird dann einen Trigger an den PDC senden, um die Synchronisation der SAM zu beginnen. Dann wird der PDC das Delta-File vom BDC anfordern und es auf die Master-SAM anwenden. Danach wird der PDC alle BDCs in der Domäne kontaktieren und sie per Trigger veranlassen, sich das Update zu holen und es in ihre eigene Kopie der SAM einzuspielen.

Samba-3 kann nicht an wirklicher SAM-Replikation teilnehmen und ist daher nicht geeignet, exakt dieselben Protokolle zu verwenden wie MS Windows NT4. Ein Samba-3-BDC wird keine SAM-Update-Delta-Files generieren. Der Samba-3-BDC wird nicht mit einem PDC (NT4 oder Samba) zusammenarbeiten, um die SAM mittels Delta-Files von BDCS zu synchronisieren.

Samba-3 kann nicht als BDC für einen MS Windows NT4-PDC arbeiten, und Samba-3 kann nicht korrekt als PDC für einen MS Windows NT4-BDC arbeiten. Sowohl Samba-3 als auch MS Windows NT4 können als BDC für ihren eigenen Typ von PDC arbeiten.

Der BDC speichert eine Read-only-Version der SAM, mit deren Hilfe er Netzwerk-Anmelde-Anfragen bearbeiten und User authentifizieren kann. Der BDC kann damit fortfahren, diesen Dienst anzubieten, insbesondere dann, wenn die WAN-Verbindung zum PDC unterbrochen ist. Ein BDC spielt eine sehr wichtige Rolle, sowohl bei der Aufrechterhaltung der Domänen-Sicherheit als auch für die Integrität des Netzwerks.

Falls der NT4-PDC außer Betrieb genommen werden muss oder falls er ausfällt, kann einer der NT4-BDCs zu einem PDC „befördert“ werden. Wenn dies geschieht, während der originale NT4-PDC online ist, wird dieser automatisch zu einem NT4-BDC „degradiert“. Dies ist ein wichtiger Aspekt des Managements von Domänencontrollern. Es sollte bemerkt werden, dass Samba-3-BDCs NICHT auf diese Art zu PDCs befördert werden können, da die nötige Rekonfiguration von Samba Änderungen an smb.conf bedingt.

Wenn man einen Master- und einen Slave-LDAP-Server konfiguriert, ist es ratsam, den Master-LDAP-Server als PDC und die Slave-LDAP-Server als BDCs zu verwenden. Es ist nicht unbedingt notwendig, Slave-LDAP-Server zu verwenden, auch wenn es viele Administratoren tun werden wollen, um die Redundanz zu erhöhen. Natürlich können ein oder mehrere BDCs jeglichen Slave-LDAP-Server nutzen. Auch dann ist es wieder möglich, einen einzelnen LDAP-Server für das ganze Netzwerk zu verwenden.

Wenn man einen Master-LDAP-Server konfiguriert, der Slave-LDAP-Server haben wird, darf man nicht vergessen, dies in der Datei /etc/openldap/slapd.conf zu konfigurieren. Denken Sie daran, dass der DN eines Server-Zertifikats das CN-Attribut zur Benennung des Servers verwenden muss und dass CN den vollen Domain-Namen (FQDN = fully qualified domain name) des Servers beinhalten muss. Weitere Aliases und Wildcards können in der subjectAltName-Zertifikatserweiterung abgelegt werden. Die Kommunikation zwischen LDAP-PDC und LDAP-BDC muss komplett verschlüsselt ablaufen. Dazu können Sie Zertifikate verwenden. Mehr Details zu Server-Zertifikaten finden Sie in der RFC2830.

Installieren Sie keinen Samba-PDC auf einem OpenLDAP-Slave-Server. Das Hinzufügen von Client-Maschinen zur Domäne wird in dieser Konfiguration fehlschlagen, da die Veränderung am Maschinen-Konto im LDAP-Baum auf dem Master-LDAP-Server stattfinden muss. Dies wird nicht schnell genug auf den Slave-Server repliziert, den der PDC abfragt. Daher gibt es auf der Client-Maschine eine Fehlermeldung, die besagt, dass es nicht möglich sei, die Konto-Informationen richtig zu setzen. Das Maschinen-Konto wird auf dem LDAP-Server angelegt, aber die Passwort-Felder werden leer bleiben. (Anmerkung: Zur Lösung dieser Problematik wurde mit Samba 3.0.1 der smb.conf-Parameter ldap replication sleep eingeführt.)

Mögliche PDC/BDC-plus-LDAP-Konfigurationen beinhalten:

Um eine so genannte Fall-Back-Konfiguration zu haben (sekundärer LDAP-Server), würde man den sekundären LDAP-Server in der Datei smb.conf so angeben wie in ???.

Seit der Veröffentlichung von MS Windows 2000 und Active Directory werden diese Informationen nun in einem Verzeichnis abgelegt, das repliziert werden kann und für das die Administration teilweise oder vollständig delegiert werden kann. Samba-3 kann NICHT Domänencontroller innerhalb eines Active-Directory-Baums sein und es kann NICHT ein Active-Directory-Server sein. Das bedeutet, dass Samba-3 auch NICHT als BDC für einen Active-Directory-DC arbeiten kann.

Jede Maschine, die DC für die Domäne MITTELERDE ist, muss den NetBIOS-Gruppen-Namen MITTELERDE<#1c> am WINS-Server registrieren und/oder diesen Namen im LAN per Broadcast verteilen. Der PDC registriert zusätzlich den eindeutigen NetBIOS-Namen MITTELERDE<#1b> am WINS-Server. Der Namenstyp <#1b> ist normalerweise für den Domänen-Master-Browser reserviert, eine Rolle, die nichts mit irgendetwas in Bezug auf Authentifikation zu tun hat; aber die Microsoft-Domänen-Implementation verlangt, dass der Domänen-Master-Browser auf derselben Maschine läuft wie der PDC.

Wo kein WINS-Server verwendet wird, müssen Namensregistrierungen mittels Broadcast reichen. In ??? finden Sie mehr Informationen zu TCP/IP-Netzwerk-Protokollen und dazu, wie SMB/CIFS-Namen verwendet werden.

Es gibt zwei unterschiedliche Mechanismen, um einen DC zu finden. Je nachdem, ob NetBIOS über TCP/IP aktiviert ist oder nicht, wird die eine oder andere Methode verwendet.

Wenn NetBIOS über TCP/IP deaktiviert ist, beinhaltet jegliche Namensauflösung die Verwendung von DNS, von Broadcasts über UDP und der ADS-Kommunikationstechnologie. In einer solchen Umgebung brauchen alle Maschinen entsprechene DNS-Einträge. Mehr dazu erfahren Sie in ???.

Schlussendlich muss der BDC von den Workstations gefunden werden. Dazu konfigurieren Sie Samba, wie in ??? gezeigt ist.

Diese Einträge nehmen Sie im Abschnitt [global] von smb.conf des BDCs vor. Dies veranlasst den BDC, nur den Namen SAMBA<#1c> am WINS-Server zu registrieren. Das ist kein Problem, da der Name SAMBA<#1c> ein NetBIOS-Gruppen-Name ist, der von mehreren Maschinen registriert werden soll. Der Parameter domain master = no zwingt den BDC dazu, SAMBA<#1b> nicht zu registrieren, der als einzigartiger NetBIOS-Name für den PDC reserviert ist.

Der Parameter idmap backend wird das Werkzeug winbindd dazu veranlassen, die LDAP-Datenbank zur Auflösung aller UIDs und GIDs für UNIX-Konten zu verwenden.

Die Verwendung der Option idmap backend = ldap:ldap://master.quenya/org auf einem BDC macht nur Sinn, wenn ldapsam auf einem PDC eingesetzt wird. Der Zweck eines auf LDAP basierenden idmap-Backends ist es, einem Domänen-Mitglied (das kein eigenes passdb-Backend hat) die Verwendung von winbindd zu gestatten, um Windows-Netzwerk-Benutzer und -Gruppen zu UID/GIDs aufzulösen. Anders gesagt: Diese Option ist für die Verwendung auf Domänen-Mitgliedsservern gedacht.

Dieses Problem tritt auf, wenn die passdb-Dateien (SAM) von einem zentralen Server aus kopiert werden, aber der lokale BDC als PDC arbeitet. Dies führt zu Updates der Passwörter der lokalen Maschinen-Vertrauenskonten in der lokalen SAM. Solche Updates werden nicht zum zentralen Server zurückkopiert. Das neuere Maschinen-Konten-Passwort wird damit überschrieben, sobald die SAM vom PDC neu kopiert wird. Das Ergebnis ist, dass die Domänen-Mitgliedsmaschine beim Start keine Übereinstimmung zwischen ihren eigenen Passwörtern und denen in der Datenbank findet, und da der Sicherheits-Check beim Start daher fehlschlägt, wird diese Maschine keine Anmelde-Versuche zulassen und es wird der Fehler gemeldet, dass das Konto abgelaufen ist.

Die Lösung ist, ein robusteres passdb-Backend zu verwenden, wie z.B. das ldapsam-Backend, und mit diesem für jeden BDC einen Slave-LDAP-Server aufzusetzen sowie einen Master-LDAP-Server für den PDC.

Nein. Die nativen NT4-SAM-Replikationsprotokolle wurden noch nicht vollständig implementiert.

Kann ich die Vorteile eines BDCs mit Samba nutzen? Ja, jedoch nur mit einem Samba-PDC. Das Hauptargument zur Einrichtung eines BDCs ist die gesteigerte Verfügbarkeit. Wenn der PDC ein Samba-Host ist, kann ein zweiter Samba-Host aufgesetzt werden, um Anmelde-Anfragen zu behandeln, wenn der PDC nicht verfügbar ist.

Die Replikation der Datei smbpasswd ist eine sehr empfindliche Angelegenheit. Sie muss geschehen, wann immer Änderungen an der SAM durchgeführt werden. Die Passwort-Änderungen jeden Benutzers werden in der smbpasswd durchgeführt und müssen auf den BDC repliziert werden. Daher ist die Replikation sehr oft notwendig.

Da die Datei smbpasswd Klartext-Passwort-Äquivalente enthält, darf sie nicht unverschlüsselt über das Netz versandt werden. Die beste Art der smbpasswd-Replikation ist die Verwendung des Werkzeugs rsync. rsync kann ssh als Transport-Tunnel nutzen. ssh selbst kann wiederum so konfiguriert werden, dass es only-Transfers mittels rsync erlaubt, ohne vom Benutzer die Eingabe eines Passworts zu verlangen.

Wie bereits einige Male zuvor erwähnt wurde, ist diese Methode fehlerhaft und unvollständig. DIe Synchronisation der Maschinen-Vertrauenskonten gerät aus dem Tritt, was in einer unbrauchbaren Domäne resultiert. Diese Methode wird nicht empfohlen. Verwenden Sie stattdessen LDAP.

Die einfache Antwort lautet: Ja. Der pdb_ldap-Code von Samba ermöglicht es, sich mit einem Replika-LDAP-Server zu verbinden, und folgt außerdem Referrals und Rebinds zum Master, wann immer Samba Änderungen an der Datenbank vornehmen muss. (Normalerweise sind BDCs read-only, daher wird dies nicht oft vorkommen).